RE: [security-services] Re: comments:sstc-saml-x509-authn-attrib-profile-draft-11

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

Some comments inline below.
::Ari

> -----Original Message-----
> From: Tom Scavo [mailto:trscavo@gmail.com]
> Sent: Monday, March 12, 2007 10:21 PM
> To: OASIS SSTC
> Subject: [security-services] Re: comments:
> sstc-saml-x509-authn-attrib-profile-draft-11
> 
> 
> Ari and I have agreed that I will submit draft-12 for review asap.
> All the previous comments re draft-11 seem fairly straightforward
> except the ones below.  Comments welcome.
> 
> Tom
> 
> On 2/26/07, Tom Scavo <trscavo@gmail.com> wrote:
> > Document identifier: sstc-saml-x509-authn-attrib-profile-draft-11
> >
> > [lines 188--189] This requirement assumes that the IdP is able to
> > authenticate the SP, but nowhere in this section is client
> > authentication required.
> >
> > [section 3] What are the security requirements of Basic 
> Mode?  This is
> > not clear from reading this section.

I think that the security requirements for Basic Mode, including SP authentication, should be inherited from the Assertion Query profile in [SAMLProf]. I suppose that we could call that out explicitly and reference [SAMLProf] in either section 3.2 or 3.3, but I would avoid reiterating the specifics of those requirements here.

> >
> > [lines 287--291] In effect, this key becomes a "previously 
> established
> > symmetric key."  How long does this key remain a previously
> > established symmetric key?  In other words, should the IdP 
> cache this
> > symmetric key, or should it be discarded immediately after use?

I think the assumption is that a symmetric key that is first distributed by the SP as an EncryptedKey in the AttributeQuery should be treated as a session key that would not be reused after the IdP sends the Response. Otherwise, in the 3rd encryption option [lines 292-296], the IdP would have to assume that when the SP omits an EncryptedKey from the AttributeQuery that the intent is for the IdP to use (I guess?) the key most recently sent in an AttributeQuery. Seems too ad hoc -- I'd rather that the 3rd option be based on a symmetric key explicitly established for that purpose.

> >
> > [lines 303--306] The <Assertion> signature is discussed, but what
> > about the <Response>?  Must it, too, satisfy FIPS 140-2 Security
> > Requirements?

Yes, I would think so. The Response signature needs to be mentioned in the text.

> >
> > Shouldn't this spec be cast as a "deployment profile"?  I may be
> > mistaken, but I thought it was agreed that this spec was to be
> > formulated as a deployment profile.

My recollection is that we agreed it should have been formulated as a deployment profile but, since the document was born under a different star, we would leave it's nature as-is.

> >
> > The diff is evidently against CD-02, but I believe it should be
> > against draft-10, right?

I think a diff against draft-10 would be very hard to read due to the changes in document structure from cd-02 to draft-10 that are not reflected in draft-11.

> >
> > ----------------------
>