[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Attribute Sharing Profile
Attached is a proposed cd-04 of the Attribute Sharing Profile. Most of my previous comments regarding this document have been accumulated in this version. Comments that have not been incorporated are listed below. -------------------------------------------------------- Document identifier: sstc-saml-x509-authn-attrib-profile-cd-02 Comments re version cd-02 of this document (for reference): http://lists.oasis-open.org/archives/security-services-comment/200606/msg00057.html http://lists.oasis-open.org/archives/security-services-comment/200606/msg00085.html Comments/Suggestions: [section 2.2] The use case in subsection 2.2 is applicable to basic mode, but it fails to motivate encrypted mode. Why would you encrypt at the message level if there were only two endpoints taking part in the exchange? Discuss a use case scenario that motivates encrypted mode. [line 131] The phrase "after verifying that the service provider is a valid requester" is problematic since client authentication is not required, at least in basic mode, which is what this use case illustrates. [line 174] Why MUST the response contain exactly one assertion? This is overly restrictive. Indeed, I have a use case that returns two attribute assertions to the SP, one an assertion of federated attributes and the other an assertion of VO attributes. Unfortunatetly, this profile precludes such a scenario. [lines 176--177] Why MUST the assertion contain exactly one attribute statement? This is overly restrictive. I don't have a use case for more than one attribute statement, but unless there's good reason for this, I'd suggest deleting these lines. [section 4] Evidently, both the <Response> and the <Assertion> MUST be signed (lines 194--195 and lines 250--251, resp.). Is this really necessary? I suggest the <Assertion> MAY be signed if the situation warrants. [line 245] Why MUST the response contain exactly one encrypted assertion? This is overly restrictive. Indeed, I have a use case that returns two attribute assertions to the SP, one an assertion of federated attributes (which SHOULD be encrypted) and the other an assertion of VO attributes (which MAY be encrypted). Unfortunately, this profile precludes such a scenario. [lines 248--249] Why MUST the assertion contain exactly one attribute statement? This is overly restrictive. [sections 4.1.2 and 4.2.2] Since both modes may employ encryption, most of the content in these sections should be pulled out of section 4 and put in sections 3 or 5. Any content specific to the mode (such as the FIPS requirement) should remain in section 4, of course. [sections 4.1.3 and 4.2.3] Since both modes may employ digital signatures, most of the content in these sections should be pulled out of section 4 and put in sections 3 or 5. Any content specific to the mode (such as the FIPS requirement) should remain in section 4, of course. [section 4.2.1] Does the name identifier in the response need to be encrypted? Since the assertion itself is encrypted, this doesn't seem to be necessary, but you need to be explicit about this since [SAMLCore] does not specify what is to be done in this case. [section 4.2.2] The IdP is allowed to reuse a previously established symmetric key only if the SP did not include a symmetric key in the request. As far as I can tell, this restriction is unwarranted. If there is no symmetric key in the response, the SP won't know if the IdP used the symmetric key in the request or some other previously established symmetric key, so there is no point restricting the IdP's use of encryption in this case. From the perspective of this profile, the symmetric key in the request *is* a previously established symmetric key, and therefore the three encryption options for the IdP may be safely reduced to two. [general] Security considerations are too tightly bound to the protocol bits. The normative security language is either too lax (basic mode) or too strict (encrypted mode). It would be better if much of the security language were relegated to section 5. [general] Encrypted mode is not properly motivated. The use case in section 2 applies to basic mode, not encrypted mode. It seems encrypted mode is geared more towards multi-hop web service frameworks, so perhaps such an example could be given (or at least mentioned) in section 2. Tom Scavo NCSA/University of Illinois
sstc-saml-x509-authn-attrib-profile-cd-04.odt
sstc-saml-x509-authn-attrib-profile-cd-04.pdf
sstc-saml-x509-authn-attrib-profile-cd-04-marked.pdf
sstc-saml-x509-authn-attrib-profile.xsd
sstc-saml-x509-authn-attrib-profile-usecase1.odg
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]