RE: [security-services] Attribute Sharing Profile

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

> -----Original Message-----
> From: Tom Scavo [mailto:trscavo@gmail.com]
> Sent: Tuesday, August 22, 2006 3:09 PM
> To: Ari Kermaier
> Cc: OASIS SSTC
> Subject: Re: [security-services] Attribute Sharing Profile
> 
> 
> On 8/16/06, Ari Kermaier <ari.kermaier@oracle.com> wrote:
> > >
> > > [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.
> 
> For the life of me, I can not think of an actual use case for 
> enhanced mode.

I believe the general thinking is for cases involving multiple system entities in a processing pipeline that would result in messages being stored and forwarded in multiple hops. This might provide the motivation for encrypted NameIDs and Assertions, as well as signing of Request and Response messages. The motivation for signing both Response and Assertion may stem from the desire to allow responder and attribute authority to be distinct entities, as well as to support the model where the Response signature is verified in one context, and the Assertion is then stripped out and validated by a different system entity.

Regardless, I think Enhanced mode was originally all there was to this profile -- Basic mode was added for generality's sake.

> 
> > > [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?
> 
> Yeah.  Whether or not the SP authenticates to the IdP is irrelevant to
> the use case description, so I think this phrase can be safely
> dropped.

Agreed.

> 
> > > [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?
> 
> Well, multiple assertions raises the possibility that some may be
> encrypted and some may not.  Is it all or none, or is a mix allowed?
> Frankly, I can't think of a reason why it would matter.

I think you're right -- there doesn't seem to be any good reason to preclude sending multiple assertions in the response.

> 
> Indeed, the way the profile is written, it is the SP that dictates to
> the IdP that the assertion must be encrypted.  This seems backwards.
> The IdP is usually in a better position to determine if encryption is
> necessary.  It can take the wishes of the SP into account, but the IdP
> may choose to encrypt if even the SP does not require it, right?
> 
> That reminds me, there doesn't seem to be a way for the SP to call out
> its desire for encrypted assertions, either in the protocol (apart
> from the implicit assumptions of the current profile) or in metadata.
> In the case of metadata, the SP is able to call out its desire for
> signed assertions.  Is there no way for the SP to advertise its desire
> for encrypted assertions?
> 
> > > [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.
> 
> I doubt there's anyone who cares but you and me.  At any rate, I see
> no reason to constrain the number of statements, so why do it?

You're right, there's probably no need to constrain the number of statements.

As an aside, this has brought to mind a question about SAMLCore -- what are the uniqueness requirements, if any, for Attribute{Name, Format} elements within a single AttributeStatement, across AttributeStatements within a single Assertion, and/or accross AttributeStatements in multiple Assertions in a single Response? I.e., how is the SP to interpret receipt of two Attribute elements with identical Name and Format, but having different AttributeValue child elements? Is it equivalent to receiving a single Attribute element with the union of the two sets of AttributeValue elements, or is it an error, or is it deployment/use-case dependent?

> 
> > > [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.
> 
> I haven't heard anything one way or the other.  Are you in
> communication with the originators of this profile?
> 
> > Is there a reason you feel this requirement needs to be relaxed?
> 
> Without a reasonable use case for enhanced mode that can be analyzed
> in terms of its security requirements, I simply don't understand the
> current signature requirements.
> 

This is a hard requirement of the profile's originators, to support processing models where Response processing/verification is performed by one system entity, after which the Assertion is stripped out and processed by a second system entity. Also, the generator of the Response might be a distinct entity from the generator of the Assertion, and so the signing keys could be different.

> > > [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?
> 
> Yes, same issue.  Why is this requirement necessary?
> 
> > > [lines 248--249] Why MUST the assertion contain exactly 
> one attribute
> > > statement?  This is overly restrictive.
> >
> > Same issue as [lines 176-177], right?
> 
> Yes.
> 
> > > [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?
> 
> Agreed.
> 
> > > [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.
> 
> I think that's a good suggestion.  I'll write it into the next draft.
> 
> > > [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?
> 
> Perhaps we can revisit this later after we resolve the above issues.
> 
> Thanks, Ari.
> 
> Tom
>