Subject: Re: [security-services] comments re sstc-saml-holder-of-key-browser-sso-draft-05
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.