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

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

On Wed, Aug 6, 2008 at 11:10 PM, Nate Klingenstein <ndk@internet2.edu> wrote:
>
>> - 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

No, I mean 423--425:

"If the user agent cannot satisfy the <saml:SubjectConfirmation>
present in the <samlp:AuthnRequest>, the identity provider MUST
respond with a <samlp:Response> message containing an error status and
no assertions."

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

The other use is specifically asking for a particular type of
SubjectConfirmation (e.g., <ds:X509Certificate>).

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

I'm complaining about the wording since an IdP doesn't confirm the
subject based on a SubjectConfirmation element in the request.
Indeed, Core is clear that the Subject in the assertion strongly
matches the Subject in the AuthnRequest.

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

Well, this is related to the previous comment.  If the SP includes a
SubjectConfirmation element in the AuthnRequest, it is indicating its
desire to receive and process such an element.  Essentially, the SP is
pre-confirming the subject!

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

I think this sentence actually introduces ambiguity, unfortunately.
What's missing here is a precise processing requirement regarding the
SubjectConfirmation element.  This is of course omitted because the
contents of the SubjectConfirmation element are not spelled out.  If
the spec was clear about the SubjectConfirmation element and how it
was to be processed, there would be no question about what it meant to
"confirm a subject."

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

The SP can do this by including a SubjectConfirmation element in the
request.  The IdP, otoh, has no such luxury.  The IdP must resort to
metadata (if at all).  The only way I see to do this is to specify a
new RoleDescriptor (which addresses the previous comment as well).

Tom