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

[Nate Klingenstein <ndk@internet2.edu>]

Tom,

> Document ID: sstc-saml-holder-of-key-browser-sso-draft-05
> - Changes to this draft, especially sections 2.4.1 and 2.4.2, seem to
> indicate that the initial request to the SP does *not* require SSL/TLS
> client authentication.  I agree that's the way it should be, I'm just
> double-checking my reading of the manuscript.  Should this fact be
> highlighted, perhaps by noting that the initial request by the UA to
> the SP MAY be mutually authenticated SSL/TLS?

Yes, this is the intention.  I'll call it out in section 2.3 as well.

> - In lines 377--379, I'm concerned that the assertion "MAY be signed
> if the HTTP Artifact binding is used," especially in light of the note
> on lines 389--390.  I believe a HoK assertion MUST be signed,
> regardless of how it is obtained.

Why do you believe this?  To enable secure forwarding or re-use of  
assertions, or ensure better auditing and repudiation?  I'd like to  
leave Artifact using TLS/SSL authentication as a viable option to  
allow for use of this profile under heavy loads without serious  
hardware if the deployer doesn't need to recycle or pass along the  
assertions.  I can put some text in to this effect, but I'd be  
hesitant to require signing unless I'm missing something.

> - The requirement on lines 423--425 is incorrect.  The IdP is not in
> the business of confirming the subject, its job is to produce
> confirmable HoK <saml:SubjectConfirmation> elements.  The two are not
> the same.

Assuming you mean 425-427, this is in there to allow the IdP to honor  
any SubjectConfirmation that might be included in an AuthnRequest.   
The original browser SSO profile explicitly forbids the use of  
SubjectConfirmation there, but I allowed it in case the SP wanted to  
use that to persist state using the TLS session/key between the  
initial access and subsequent return.  If that's not going to be a  
use case, I can strike this and a little more text in other sections,  
but I can imagine some implementations could take advantage of it,  
e.g. authenticating a user within an existing session.

> - On line 450, how does "the service provider indicates its ability to
> process such keying information?"

Excellent question.  The obvious answer is to put something in the  
AuthnRequest or the Metadata, but in an effort to keep this short and  
sweet, I didn't want to define an extensible set of URI's and two  
places to stick them.  Might be a good idea, though.

> - Thank you for editing the sentence on lines 472--473, but
> unfortunately I still don't understand this requirement.  If that
> sentence were omitted, what negative consequences would ensue?

Some of my worries were conflicting information, such as the subject  
and LoA/CP, or assertions rejected based on an expired certificate or  
an unrecognized issuer.  I'd like to be certain that there is no  
ambiguity in the interpretation of the assertion and it can be  
processed with no dependency on the underlying certificate other than  
the key.  That's valuable enough to me to include some text, even if  
in its current form it's more of an advisory reminder than anything  
else.

> - The type of the Protocol XML attribute should be a URI (since the
> Binding XML attribute is a URI).

Oops.  Fixed.

> - Earlier, Nate asked me privately what I thought about possible
> metadata requirements (section 2.6), and if I'd taken the time to
> think about it then (sorry, Nate), I probably wouldn't be making the
> following comments now.  Hijacking the Binding attribute like this is
> a bit of a kludge.  Why not define new endpoints just for this
> purpose?  Yes, I know you say (on line 494) that you'd rather not do
> that, but why not?  That seems like the proper approach to me.

See your response to yourself. :D  This seems like the least ugly  
approach, and yes, they're all awful.

> - In the same way an endpoint calls out its support for certain
> NameIDs (with md:NameIDFormat), how does an endpoint call out its
> support of various child elements of ds:KeyInfo? (This would require
> new endpoint definitions, I think, as mentioned above.)

See earlier answer, and please suggest anything you think is most  
appropriate.

Take care,
Nate.