Hi, Jouni Malinen <j@w1.fi> writes:
On Sun, Apr 13, 2008 at 12:11:20PM +0200, Arnaud Ebalard wrote:
Regarding the identity privacy argument: usually, the certificate leaks more information (DN, issuer, ...) than the User-Name itself. As it sent in clear during the TLS handshake, there is simple way to provide identity privacy. If someone has access to the EAP-Response/Identity, it also has access to client and server certificates.
Agreed as far as EAP-TLS as defined in RFC 2716 is concerned. However, RFC 2716bis (i.e., RFC 5216; it was published last month) introduces support for client privacy. This allows the client certificate to be sent encrypted and only after having validated server certificate chain. As long as both the EAP-TLS server and peer implement RFC 5216 and support the optional privacy, there is a way to provide client identity privacy.
Interesting. Thanks, Jouni. I just took a quick look at section 2.1.4 of RFC 5216. Too bad (both in term of performance and latency) that the only way to support privacy for the client is by performing a first TLS handshake to protect a complete second one which provides the client authentication. This puts a price on privacy :-( Cheers, a+