Re: [security-services] comments: sstc-saml-holder-of-key-browser-sso-draft-01

[Nate Klingenstein <ndk@internet2.edu>]

Tom,

> This is an important piece of work.  I've reviewed this draft document
> and have a large number of comments (which is good :).  Rather than
> post all of these here (mostly due to laziness, but partly to avoid
> being counter-productive), I'll provide some general comments below in
> hopes that my (unreported) detailed comments will be addressed as a
> matter of course in the next revision.

Thanks a lot for all your excellent suggestions so far to improve this  
profile.  This is creative and useful feedback that has challenged a  
few of my preconceptions -- but what a brutal introduction to the  
standards process. :D

> - This document needs a section entitled 'Security and Privacy
> Considerations" (or something similar).  There's a lot of text in this
> document, mentioned in passing, that would have more effect if it were
> aggregated in a non-normative "Security" section.  Examples of such
> text include much of section 2.2 (including lines 223--232) and any
> reference to "issuer," "subject," "X.509 subject," "subjectAltName,"
> and "X.509 subjectAltName" set in monospace font.

Given that security is one of the primary benefits from adoption of  
this profile, that's probably a good idea.  This'll take me a little  
while.

> (By the way, why are the latter set in monospace font?)

Keywords.  It's to set them apart as being specified fields, even if  
from another standard.  Is that inappropriate?

> - IMO, section 2.3 (Profile Overview) should not use normative
> language.  I realize [SAML2Prof] does this, but I don't recommend it,
> especially since related requirements are spread throughout section 2.
> So I suggest you state all normative requirements in the body of
> section 2, beginning with section 2.4.

That's a good idea.  (almost) All normative requirements stated there  
were already in section 2.4 anyway, and this clarifies the purpose of  
each section.  That's done now.

> - Is this profile meant to be a refinement of the Web Browser SSO
> Profile in [SAML2Prof] or is it meant to be a complete replacement?
> (Yes, I read lines 195--196 but I have to ask.)  I suspect it's meant
> to be a refinement, otherwise there's more work to do to cover all the
> bases touched by [SAML2Prof].  In that case, I recommend you remove
> any redundant requirements (i.e., requirements already covered by
> [SAML2Prof]) unless reiterating those requirements helps to prevent
> misinterpretation.  Some requirements can be removed regardless of the
> profile's relationship to [SAML2Prof]; for example, most (if not all)
> of section 2.7 (Use of Metadata) can be eliminated, I think.

Unfortunately, it can't be a pure derivation/refinement because the  
Web Browser SSO profile mandates the use of bearer SubjectConfirmation  
with a normative MUST.  What do you believe it needs to include that  
isn't already if it seeks to be an alternative rather than a refinement?

> - Wherever encryption is mentioned, one gets the impression it is
> required or assumed.  But encryption is not required as far as I know,
> so any subsequent conclusions or requirements seem to be based on a
> false assumption.  So what are the encryption requirements of this
> profile?  I suspect there are none, so I suggest you go back and
> rewrite any paragraph that has the word "encryption" in it.

Every reference to encryption that I can find is explanatory or  
describes options faced by a deployer and isn't normative.  Many of  
these would be migrated into a consolidated security/privacy  
considerations section.

> - In section 1.3 (Conformance), try to specify what sections are
> required for a conforming SP.  Similarly, specify what sections are
> required for a conforming IdP.  I don't think you want to leave this
> up to the reader.

There's no harm in tabulating them, really, but isn't it somewhat self- 
evident?

> - The body of section 2 (sections 2.4 and 2.5) is disorganized.  For
> one thing, there is more than one incorrect cross-reference, which is
> annoying.  Perhaps the next version of the document can reorganize the
> subsections in section 2.  It would be helpful if there were a
> one-to-one mapping between the subsections of sections 2.4 and 2.5,
> respectively.  In the very least, cross-references should be used
> freely, and they should be correct.

With the exception of incorrect cross-references, my (totally  
mislabeled) intent was to split the sections into the protocols/ 
bindings and the assertion/messages they transport.  This is made more  
awkward by the fact that the authentication request is protocol only.   
For some of the steps in 2.4, there is no real corresponding text to  
put in 2.5: it's all binding, and sometimes not SAML.

What would you suggest?  Collapse them into one section, try to draw  
this distinction more sharply, or use another separator entirely?

> - I suggest you break out the authentication request/response sequence
> into a separate profile.  This will, first of all, simplify an already
> complicated section 2. Secondly, it's likely someone will want to
> implement the authentication exchange outside of the normal browser
> profile.  Indeed, the HTTP-based authentication request/response that
> you've profiled here is much easier to implement than the SOAP-based
> attribute self-query I profiled recently!  So having those
> requirements in a separate section would be very helpful.

As mentioned above, I hoped to draw this same line between 2.4 and  
2.5.  I can understand (and am pleased by) the desire to recycle the  
concepts in the profile.  However, I don't think splitting this into  
two separate profiles is the right way to do that.  I believe the  
coupling between the application-layer assertion and the transport- 
layer TLS protocol makes this profile interesting, so pulling them  
apart seems like it'd leave two somewhat disjointed halves that don't  
say much.

Thanks again,
Nate.