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

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

On Mon, Jan 5, 2009 at 10:22 AM, Peter Sylvester
<Peter.Sylvester@edelweb.fr> wrote:
>
>> This profile does not rely on SSL/TLS client authentication...
>
> IMO the profile does rely on SSL/TLS client authentication, textually,
> if one looks at teh TLS text.

Then I guess we have to do more work to clear this up :-)

> Both, idP and service provider use a client key-pair and some
> certificate.

True.

> What differs is the way how the certificate
> is accepted, and how an identity is determined, and this part is
> very "small" in TLS.

Indeed, we want to exploit that fact.

> The TLS RFC doesn't say much about how a client certificate
> is accepted validated or else, it only says that a client certificate
> is presented to the server.

All three of the TLS RFCs (2246, 4346, and 5246) address this issue in
section 7.4.6.  RFC 5246 does the best job of clarifying the issue:

"If the client does not send any certificates, the server MAY at its
discretion either continue the handshake without client
authentication, or respond with a fatal handshake_failure alert.
Also, if some aspect of the certificate chain was unacceptable (e.g.,
it was not signed by a known, trusted CA), the server MAY at its
discretion either continue the handshake (considering the client
unauthenticated) or send a fatal alert."

>> 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 whether I like these terms. SSL/TLS client authentication
> seems (almost) appropriate to me. 'echange' is not good, there
> is "two party authentication".
> maybe "TLS/SSL session establishment with mutual authentication"

The TLS spec itself uses the phrase "TLS Handshake Protocol" so maybe
we should use that as well.  In any event,  the handshake we have in
mind does not necessarily result in mutual authentication.  Each party
presents a certificate to the other, yes, and the server certificate
is presumably validated by the browser, but we do not require that the
client certificate be validated by the server.  The TLS spec clearly
does not require this, so that is good.  However, the TLS spec leaves
it up to the server whether or not to continue the handshake in the
presence of an untrusted certificate.  We definitely do not want the
handshake to terminate if the client certificate can not be validated.
 In fact, an untrusted client certificate is expected to be the
typical case.

Okay, good, so you've helped me "discover" a couple of additional
requirements:  the TLS handshake MUST run to completion, each peer
presents a certificate to the other peer, and the identity provider
MUST be able to retrieve the client certificate chain presented by the
user agent.  On the other hand, there is no requirement that the TLS
server must validate the presented client certificate.

> which also reminds me: In the security section on should say
> something about the client that has to authenticate both the IdP and the
> service.

No, the client presents a signed SAML assertion to the SP, which the
SP uses to create a security context for the principal.  There is no
authentication at the SP (unless you want to think of this as "SAML
authentication").

Thanks, Peter.

Tom