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

["Scott Cantor" <cantor.2@osu.edu>]

> - On lines 301--303, it says the endpoint location is determined by
> the binding and that SAML metadata may be used for this purpose.  I
> don't think binding determines the endpoint since this profile, for
> example, may require a separate endpoint location (but read on).
> Along these lines, how would one configure metadata for this purpose
> (if, in fact, one were using SAML metadata)?

Strictly speaking, I don't see any harm if an SP chose to utilize an
existing SSO endpoint it found in metadata (and so I generally agree with
your later comment), but since the existing element/binding combinations
imply the standard SSO profile, it is probably advisable to provide a
metadata extension attribute that signals support for this profile.

The problem with that approach is that it doesn't prevent an old SP from
using such an endpoint for use with the old profile. In other words, the
only way to formally advertise an endpoint that *only* supports this profile
is to use an alternate Binding value or an extension element instead of
md:SingleSignOnService.

In other words, a lot of problems are created if you want to isolate these
endpoints, which might lead one to just share them. But this particular
profile requires TLS with a client certificate, that may not be appropriate
for the general SSO case.

So I don't think you have much choice but to define a new endpoint element
and stick it in as an extension. The element-as-profile model for endpoints
has its downsides, and this is one of them.

Sorry to ramble. This might be easier to explain on a call.

> - The sentence on lines 308--310 is ambiguous.  Is a signature required or
> not?

Don't think that's the intent, and I'd really suggest just copying whatever
the original SSO profile says. I would change as little as possible in these
kinds of areas unless the original text is just wrong.

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

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

> - On lines 346--347, it says the endpoint location of the assertion
> consumer service at the SP may be obtained from SAML metadata.  Why
> can't SP metadata indicate that the SP wants holder-of-key SSO
> assertions (something like 'wantsHolderOfKey' for instance)?

That's more or less the same issue as with the SSO service in reverse.
Again, it's about whether you need to prevent an old SP from using the same
endpoint. If the profile isn't unambiguous, you'd have to rely on an
extension element.

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

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

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

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

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

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

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

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

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

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

> - On line 465, I think it would be better to say "this profile is
> related to the Web Browser SSO Profile."

I think derived from might be better.

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

> - I see you removed lines 489--492 from draft-04 (due to a comment
> from Scott, I presume).  In doing so, an important point was thrown
> away, namely, this profile guarantees that a replay attempt is
> virtually guaranteed to be from the requested subject.  In other
> words, replay attempts from rogue third parties are eliminated.

Replay definitely needs to be cleaned up, but I think the simplest path, and
the one consistent with the intent of this profile and its overall design is
to simply emulate the old profile and assume short-lived single-use
assertions that can be replay-checked like any other. But I'd be ok with
relaxing that as well, as long as its clearly worded.

> - The sentence on line 493 is accurate, but the rest of that bulleted
> item is confusing and seems to have nothing to do with h-o-k SSO
> assertions.  Am I missing something?  What exactly are you trying to
> say in this bullet?

Probably to justify the need to retain the audience condition, but it may be
more confusing to say anything here at all.

> - 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. However, I would move that text to a separate section on
metadata usage.

> - In general, you need to describe the metadata requirements of this
> profile (if, in fact, SAML metadata is used).

+1

> - The SP should be able to call out its desire for holder-of-key SSO
> assertions, either via metadata or by including a SubjectConfirmation
> element (but no KeyInfo) in the request.  For IdP-first scenarios,
> metadata is the only option that will work.  For SP-first flows, a
> SubjectConfirmation element should be sufficient.  In either case, I
> don't see why the IdP should need a separate endpoint location for
> this profile.

I can see both sides of it. It's a big deal to require client TLS (it's a
nightmare, actually, believe me). Granted, though, you could defer that step
to a redirected location that's separate from the initial SSO service, and
that's probably how most people would do it. But I can see why somebody
might object to having to do that, I guess.

Anyway, I agree that it's a significant issue, on both ends, and has a lot
of implications on metadata usage.

-- Scott