eap Mailing List: Re: Confidentiality of TLS keying information for wireless

[Bernard Aboba (aboba]

On August 9, 2004, Frank Akujobi wrote:

"Hi,
I have a couple of questions concerning wireless clients using EAP-TLS
authentication against a radius server:

1. Are all the TLS session negotiations between supplicant (on the
client) and authenticator (AP) sent in the clear? In other words is
there any form of confidentiality for TLS keying information?

2. If there is none, what prevents a potential attacker from listening
in on TLS sessions and eventually gathering enough information (like the
session key and eventually WEP keys) to launch a man-in-the-middle
attack?

Thanks,

Frank Akujobi, M.A.Sc.
Network Analyst
Computing and Communications Services
Carleton University
(613) 520-2600 x 2291"

-------------------------------------------------------------------------
Frank --

TLS is a modern key exchange protocol that is documented in RFC 2246,
as well as in the following updated Internet Draft:
http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc2246-bis-07.txt

Another good source of information on TLS is the following book:
Rescorla, Eric, "SSL and TLS Designing and Building Secure Systems",
Addison-Wesley, 2001.

As noted in those documents, the properties of the SSL/TLS exchange vary
depending on the ciphersuite chosen.  EAP-TLS requires selection of a
ciphersuite that provides for both client and server authentication.  This
implies that some of the existing SSL/TLS modes (such as anonymous DH) are
not suitable for use with EAP-TLS.

Through use of cryptographic mechanisms such as the exchange of
certificates and corresponding RSA public keys, TLS is able to provide for
mutual authentication as well as to set up an encrypted channel.  As with
any modern key exchange protocol, keying material is never sent in the
clear.  Given mutual authentication between client and server,
man-in-the-middle attacks are precluded, barring the failure of a
fundamental cryptographic assumption, such as compromise of a server
certificate or trust anchor.

As noted in Section 3 of [Rescorla], when server certificate
authentication is supported, the server sends its certificate to the
client in the Certificate message.  The client then responds with the
ClientKeyExchange message, in which it encrypts a randomly chosen
PreMasterSecret and encrypts it using the server's public key.  The server
subsequently demonstrates receipt of the PreMasterSecret (and possession
of the private key corresponding to the public enclosed within its
certificate) by using it in the calculation of the Finished message.

As noted in Section 4 of [Rescorla] when the client authentication is
supported and certificates are used, client authentication is initiated by
the server sending a CertificateRquest message to the client.  The client
responds by sending a Certificate message to the server as well as a
CertificateVerify message, which is signed with the private key associated
with the transmitted client certificate.  The client therefore
demonstrates possession of the private key corresponding to the public key
enclosed within its certificate.