[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] Comments on TLS identity protection



Normally, client auth is not allowed on a PKI-class ciphersuite, if the server has not performed server auth. (In a mix of PKIand non-pki ciphersuites -during a change-ciher-spec between the two - things are admittedly more ambiguous.)

On a PKI-class limited renegotiation case (or a session resumption case), server auth is implied, of course - assuming both enc and mac ciphers mechanism are not NULL.

For SSL3 using the RSA ciphersuites, one can ask for client auth on handshake#2, without having provided server cert chain on that second 'shake; server auth being established in the TLS resumed session (and renewed Connection) state.

(I've still simply (and honestly) no idea what TLS1.0 TLS1.1 (or either of those stds with their "RFC updates" demands) being entirely different beasts to SSL3.)

What https requires - and then what SLS3/TLSx.y+upd. requires - are of course different things. By virtue of its definition, https or other "SSL application" gets to set what the usage profile and the cert requirements are for an SSL/TLS layer 4.51 port. "Usage profile" includes: constraints on cert contents, cert chains rules,root certs, TLS transport handling, handling of cleartext and SSLtext data upon TLS upgrade/downgrade events (LDAP, HTTP1.1). By analogy, the implementor of https gets to set rules like: (1) client cert always requires a new handshake, even on the same TLS Transport connection (2) new server auth via certs is also required, on that second round


----- Original Message -----
From: "Bodo Moeller" <bmoeller@xxxxxxx>
To: "Martin Rex" <martin.rex@xxxxxxx>
Cc: <tls@xxxxxxxx>
Sent: Wednesday, December 20, 2006 4:36 AM
Subject: Re: [TLS] Comments on TLS identity protection

On Tue, Dec 19, 2006 at 10:15:01PM +0100, Martin Rex wrote:

However, as you say in most cases the request for client auth
is contingent upon seeing the request and so a rehandshake is
required here in any case. A one-pass protocol wouldn't work
here.

I had the same thought but completely failed to point this out.

In the not uncommon case with IIS renegotiating after having
evaluated the HTTP(S)-request, [...]

This, by the way, applies not only to IIS servers.  The Apache HTTP
server with mod_ssl can also be configured to request client
certificates only for specific requests, which of course is achieved
through a renegotiation.  This approach is reasonable not only for
HTTP applications: An SMTP server supporting TLS might perform
certificate-based client authentication only when used as a mail
relay, and finish without attempting client authentication if
a connection only involves local mail delivery.

Bodo


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls