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@acm.org>
To: "Martin Rex" <martin.rex@sap.com>
Cc: <tls@ietf.org>
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@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
> 

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