Using X.509 Cert. subject and issuer for authorization with EAP-TLS

Arnaud Ebalard arno at
Mon Apr 14 09:51:40 CEST 2008


Jouni Malinen <j at> 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 :-(



More information about the Freeradius-Devel mailing list