Re: [security-services-comment] holder-of-key-browser-sso-draft-09

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

Hi Peter,

Sorry for the delay getting back to you regarding your comments re
draft-09.  I'm just now finishing up draft-11 of the Holder-of-Key Web
Browser SSO Profile.  See below for inline comments.

On Fri, Nov 28, 2008 at 11:04 AM, Peter Sylvester
<Peter.Sylvester@edelweb.fr> wrote:
> Hi, the following is a little bit in disorder:
>
> - 2.2 lines 245 to 249 needs some work IMO.

Agreed.

>  "globally unique namespace" can be easily misunderstood.
>  (Later one talks about unique identifiers!)
>  "mutually" trusted root means what? Who are the entities?
>  isn't "PKI validation" related to CRL and OCSP?
>
>  "or for all participants in SSO to utilise X.509": In the following
>  description, both the SP and the IdP use X.509. (see end of 2.4.4
>  and 2.4.6)
>
> Both parties use keys exchanged in the form of X.509, but they do not
> necessarily use PKI services such as certificate validation procedures
> of X.509 or OCSP (in particular, the SP).

I believe the paragraph you're referring to is comparing X.509-based
PKI with SAML-based PKI.  I will try to reformulate the paragraph for
clarity or remove it altogether in draft-11.

> - There seems to be duplicate and slightly inconsistent text between
>  among the corresponding subparagraphs of 2.3 and 2.4. One has in fact
>  three descriptions if one counts the text in the figure of page 9.
>
> Details:
>
> The paragraph after line 258 on page 9 concerning
> "Service Provider Determines Identity Provider":
> 261: add ", and/or any" before other at the end of the line.
> I suggest to remove "such as the X.509 subject". Seems to be
> inconsistent with "no need for globally unique namespace" in 2.2.
>
> "This may done through the use of a discovery service as described in
> [IDPdisco],
> by examining fields in a certificate if presented through TLS client
> authentication,
> or any other means. " or remove the whole sentence

The text you're referring to has been rewritten and moved to what was
section 2.4.2 in draft-09.  Discussion re using the X.509 certificate
for IdP discovery has been moved wholly to section 4.

> The last sentence  in line 266/267 is unclear. Using TLS is not a sufficient
> terminology.

I agree.

> one has to
> deduce from the graphics that client authneticaton is happening.

This profile does not rely on SSL/TLS client authentication, and
therein lies half the problem.  Therefore, I've removed that phrase
from the normative portions of draft-11.  The benefits of X.509 client
authentication are discussed briefly in section 4.

In draft-11, in place of "SSL/TLS client authentication," I use the
phrases "bilateral SSL/TLS" and "mutual SSL/TLS exchange" throughout.
If you have suggestions for other relevant terminology, I'd be happy
to hear them.

> I am not sure then that the text is consistent with paragraph 2.4.3

The text you're referring to has been reworded in draft-11:

"The service provider issues a <samlp:AuthnRequest> message to be
delivered by the user agent to the identity provider.  An HTTP binding
is used (section 2.5) to transport the message to the identity
provider through the user agent.  The user agent presents the message
to the identity provider in an HTTP request over bilateral SSL/TLS."

> in line 276, it is not indicated that TLS client authentication is used.

Because it is not (see above).

> ... presents this response in using TLS client authentication with the
>   confirmed certificate.

The text you're referring to has been reworded in draft-11:

"The identity provider issues a <samlp:Response> message to be
delivered by the user agent to the service provider.  The response
either indicates an error or includes at least an authentication
statement in a holder-of-key assertion.  An HTTP binding is used
(section 2.5) to transport the message to the service provider through
the user agent.  The user agent presents the message to the service
provider in an HTTP request over bilateral SSL/TLS."

A new section entitled "TLS Usage" has been added to draft-11:

"As noted in the introduction, this profile is an alternative to
ordinary SAML Web Browser SSO [SAML2Prof].  The primary difference
between ordinary Web Browser SSO and this Holder-of-Key Web Browser
SSO Profile is that the principal MUST present an X.509 certificate
and prove possession of the private key associated with the public key
bound to the certificate.  This results in holder-of-key subject
confirmation, a type of subject confirmation that is stronger than the
bearer subject confirmation inherent in ordinary Web Browser SSO."

"The principal presents the X.509 certificate via a mutual SSL/TLS
exchange.  It is important to realize that the presented certificate
need not be a trusted certificate (although this is permitted).
However, the certificate MUST be presented via bilateral SSL/TLS.
This proves possession of the corresponding private key."

"The principal MUST both present an X.509 certificate (via SSL/TLS)
and prove possession of the private key at steps 3 and 5 (sections
2.6.3 and 2.6.5, resp.).  However, presentation of an X.509
certificate at step 1 (section 2.6.1) is strictly OPTIONAL."

"At any step of the flow described in this specification, the identity
provider or the service provider (or both) MAY use the public key
bound to the certificate or the SSL/TLS session key to create a
security context for the principal."

Let me know what you think.  It's not too late to make additional
changes to draft-11.

Cheers,
Tom