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

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

On Sun, Jul 13, 2008 at 10:20 PM, Scott Cantor <cantor.2@osu.edu> wrote:
>
>> - On lines 311--312, a signature would preclude HTTP Redirect as well,
>> correct? (I think you mention this elsewhere, but this is where it
>> belongs, I think.)
>
> Why? You can sign redirect-based messages.

In practice, does a signed AuthnRequest exceed the size limitations of
URLs?  I thought so, which is why I made that comment.

>> - The requirement on lines 328--330 is crucial and should be elevated
>> to an earlier section.
>
> Earlier paragraph maybe, but what section could you move it to? That's the
> step where it applies...

It strikes me that these lines are the essence of this profile (in a
single sentence).  I was disappointed to read them on page 11.

>> - On line 364, it says the SP "grants or denies access to the
>> resource."  I don't think this is correct.  Should it say instead that
>> the SP "creates a security context for the user?"
>
> It should be the same language as the old profile, and I think it more or
> less is.

I see that now, but I think that's wrong.  At the risk of preaching to
the choir, the basic task of the SP is to accept and process the
assertion.  Access control is out of scope.

>> - On line 367, it says the SP "MAY establish a security context with
>> the user agent."  I'm not sure I buy this.  When would the SP NOT
>> establish a security context (if only a short-lived one)?  This is, in
>> fact, what the SP does (see previous comment).
>
> The old profile says MAY, so this one should too. Or the old one's wrong and
> there should be an errata, but I don't think so.

It doesn't seem right to me.  Can you give an example of an SP that
does not provide a security context?  Not doing so prevents the access
control mechanism downstream from arriving at a decision.

> IIRC, the basic idea was that it's out of scope and we just don't want to go
> there. The SP accepts the assertion and that's that. The rest is its
> business (or the business of other policies about use of data, etc.)

I agree.

>> - The introduction to section 2.5 is crucial, portions of which should
>> perhaps be elevated to an earlier section.  For example, the fact that
>> the SP is the requester precludes the principal as requester.  More
>> importantly, this section is clearly not about the use of the
>> AuthnRequest protocol since the latter has nothing to say about the
>> SP.  The AuthnRequest protocol is between the presenter and the IdP.
>
> No, it's not. It's beween the requester and the responder. The delivery of
> the request by the presenter is "half" of the first half of the protocol, if
> as in this case, the presenter != the requester.

Yes, you're right of course.  I misspoke.

>> - On lines 381--384, I see no reason why the SP would want to include
>> KeyInfo in the request.  What would be the purpose of doing so?
>
> Pure speculation, but is the idea that perhaps the SP wants to establish
> some kind of initial state based on the TLS key it gets, and make sure that
> the resulting assertion is issued to that key?

Okay, that's fine.  If the IdP sees a h-o-k SubjectConfirmation
element in the request, regardless of whether or not a KeyInfo is
included, it knows this profile is required.  But now that I think of
it, maybe that's dangerous since other h-o-k profiles may exist in the
future.

>> On the other hand, I could imagine the SP might include a holder-of-key
>> SubjectConfirmation element (with no KeyInfo) to signal its desire for
>> a h-o-k SSO assertion.  Why not include this in this specification?
>
> The definition of HoK in Profiles explicitly says "one or more" MUST be
> present.

No, I'm talking about the request, not the response.  I'm suggesting
the SP insert an empty h-o-k SubjectConfirmation element in the
AuthnRequest.  But yes, I think you're right, this is not general
enough.  Metadata is required.

>> - On line 391, it says "authentication of the parties is OPTIONAL" in
>> the case of HTTP Artifact, but authentication is optional in any
>> event, is it not?
>
> That's just the same text as in the original profile. It was called out
> because the Artifact binding is sometimes authenticated and sometimes not.
> Traditionally it is, so it was felt that it would be less confusing to
> explicitly state that here it isn't.

Sorry, it doesn't clarify anything for me, and I'd hesitate to include
it in the new profile unless it adds something significant (which as
far as I can tell, it does not).

>> - I'm not sure what you're worried about on lines 447--448.
>
> People infecting a non-PKI profile with PKI. The danger of that warrants
> some text, I think.

As long as that text is advisory and/or not vague.

>> In fact,
>> the certificate may very well contain other information the SP may
>> wish to add to the user's security context.  Would it be better to say
>> that anything else the SP does with the certificate is out of scope
>> with respect to this profile?
>
> I think it can be reworded a bit to permit what you're suggesting without
> causing a problem. The danger is in people implementing the profile in such
> a way that the certificate has to be "valid" in order to satisfy the
> profile-defined processing rules for satisfying the confirmation. We wanted
> it to be specifically NOT legal for an SP to do anything with the
> certificate in the context of deciding whether to accept the assertion.

Then why not define what it means to "valid" with respect to this profile.

>> I don't believe this profile has any
>> business telling the SP that it can not process the certificate
>> further if it wishes.
>
> It depends on what that means. Something has to be said, or the profile will
> devolve into the non-interoperable mess that every other use of certificates
> ends up turning into when nothing more is said.

If you're explicit about what's required (and I think you've mostly
done that), the rest is simply out of scope.

>> - The introductory sentence to section 4 doesn't make any sense to me,
>> I'm afraid.
>
> It read fine to me, although I'd probably add a comma.
>
> "The holder-of-key assertions, and protocols supporting their issuance and
> verification, in this profile have some different security and privacy
> characteristics from the bearer assertions used in the Web Browser
> SSO Profile."

In that case, I would simply delete the phrase between the commas.

>> - I don't understand the requirement on line 501.  If the SP says it's
>> going to sign requests, the IdP doesn't have to do anything but verify
>> the signature (which it would have to do in any event).  The fact that
>> the SP calls this out in metadata seems like one of those metadata
>> items that carries little if any significance whatsoever.
>
> If an SP says that it will sign in metadata, you know to reject anything
> that isn't signed.

This is an aside, but I don't get that impression by reading the metadata spec.

Tom