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

["Tom Scavo" <trscavo@gmail.com>]

Ari, I agree with all your points except two.  See below.

On 3/13/07, Ari Kermaier <ari.kermaier@oracle.com> wrote:
> Some comments inline below.
> ::Ari
>
> > 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.

Sorry, I didn't do a very good job of making my point.  According to
the Assertion Query/Request Profile, the SP SHOULD authenticate to the
IdP (and vice versa) but I don't think this is adequate in this case.
On lines 188--189 of draft-11, it says

  The <Assertion> element MUST contain an <AudienceRestriction>
  element that includes the service provider's unique identifier as an
  <Audience>.

but this seems to imply that the SP has authenticated to the IdP.
Moreover, unauthenticated queries using well-known persistent
identifiers (DNs) are not advisable.  So my question is: should mutual
authentication be mandated?

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

I tend to agree, so I'll add a phrase about this "session key" to option 2.

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

I don't remember that.  I'm not sure why we would choose to call some
other profile a "deployment profile" and not this one.  I think it's
advisable to call this a "deployment profile", at least in the
abstract on page 1, in the introduction in section 1, and in the use
case description in section 2.  Everything else (including the title)
can remain the same.  Agreed?

Thanks,
Tom