Subject: [eap] Re: Confidentiality of TLS keying information for wireless

From: Bernard Aboba <[email-masked]>
Date: Mon, 9 Aug 2004 19:03:33 -0700 (PDT)

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.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Frank Akujobi" <[email-masked]>
Date: Tue, 10 Aug 2004 00:54:39 -0400

Aboba,
Thanks for your response. I understand how TLS provides mutual
authentication and key exchange. I also understand that data frames sent
after the key negotiations are encrypted and from that stand point a
man-in-the-middle attack can be prevented.
However my question was directed towards the confidentiality of the
signaling process (more like the management frames NOT data frames)
between the client and server before session key and WEP keys are
generated. Is the signaling traffic itself encrypted? Pls find my
comments within:
------------------------------------------------------------------------
----
"Hi,
I have a couple of questions concerning wireless clients using EAP-TLS
authentication against a radius server:

Thanks
Frank

------------------------------------------------------------------------
-
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.
------------------------------------------------------------------------
----
From your comments about section 3, I would be concerned as to whether
the "Certificate message" sent from the server was encrypted and if so
with what key?
------------------------------------------------------------------------
----
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.
------------------------------------------------------------------------
----
Also from your comments about section 4, I would be concerned as to
whether the "Certificate message" for the client to server was
encrypted.
------------------------------------------------------------------------
----

Thanks
Frank.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.709 / Virus Database: 465 - Release Date: 22/06/2004

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Aug 2004 07:28:42 -0700 (PDT)

> the "Certificate message" sent from the server was encrypted and if so

In the TLS protocol, the Certificate message from the server is not
encrypted, since at that point a key has not been derived.

> whether the "Certificate message" from the client to server was
> encrypted.

Typically the client Certificate message is sent prior to turning on
encryption, so that the client identity is not private.  If privacy is
desired, then it is possible for the server to wait until an encrypted
channel has been brought up to send a CertificateRequest.  I am not sure
whether privacy is supported by all TLS implementations.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap