RE: [security-services] Attribute Sharing Profile

["Ari Kermaier" <ari.kermaier@oracle.com>]

> 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.

You're right, we should discuss the motivation for enhanced mode. I'm not clear at the moment on whether that would take the form of a different message flow/entity topology or just a discussion of a different security environment.

> 
> [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.

Well, the text in the Basic Mode section [lines 147-148] describes optional authentication of the SP, so maybe using language like "after (optionally) verifying that the service provider is a valid requester" would help?

> 
> [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.

I don't know why this was specified, though I imagine it wasn't completely gratuitous.
Anyone?

> 
> [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.

Again, I don't know but we should try to find out before changing it.

> 
> [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.

The original proponents of this profile continue to insist that both the Response and the Assertion MUST be signed. Is there a reason you feel this requirement needs to be relaxed?

> 
> [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.

Same issue as [line 174], right?

> 
> [lines 248--249] Why MUST the assertion contain exactly one attribute
> statement?  This is overly restrictive.

Same issue as [lines 176-177], right?

> 
> [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.

I imagine the NameID in the Assertion would not be separately encrypted, but would rely on the enclosing Assertion's encryption. But do we need to make this explicit, if SAMLCore does not?

> 
> [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.

Why can't the profile express a precedence in the use of previously established symmetric keys to mandate the use of the most recently established one (i.e., sent via an EncryptedKey element in the AttributeQuery) if known? The SP will know whether it sent an EncryptedKey in the Request, and will expect the IdP to follow the precendence in the profile's rules. So the three options are distinct.

> 
> [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.

Could you elaborate on what's too lax/too strict?

::Ari