Subject: [Emu] Identity Protection in EAP-TLS

From: Pascal Urien <[email-masked]>
Date: Sun, 04 Jun 2006 16:27:31 +0200

Hi Everybody,

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Identity Protection within EAP-TLS
	Author(s)	: P. Urien, M. Badra
	Filename	: draft-urien-badra-eap-tls-identity-protection-00.txt
	Pages		: 7
	Date		: 2006-5-31
	
This document defines a mechanism providing EAP-TLS identity
protection.

It defines new TLS extension, in order to negotiate the symmetric
encryption algorithm that is used to encrypt or decrypt the client's
certificate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-urien-badra-eap-tls-identity-protection-00.txt

Pascal 

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: Sam Hartman <[email-masked]>
Date: Sun, 04 Jun 2006 12:06:17 -0400

In general, it seems that the TLS community has been recommending a
second authentication if you have data you need to exchange that is
confidential and would normally be in the first authentication.  See
draft-housley-tls-authz-extns for an example of the use of this
method.

Clearly using this within eap-tls would require some specification
work, but I think would be preferable to your approach.

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 04 Jun 2006 11:41:03 -0700

>work, but I think would be preferable to your approach.

The EMU WG charter states:
"Backwards compatibility with RFC 2716 is a requirement."

So I'd like to understand which approach (if any) is backward compatible 
with existing RFC 2716 implementations.

EAP-TLS server implementations always request a certificate.   If the client 
desires privacy, it can choose not to respond to the certificate request.  
An EAP-TLS server supporting privacy would then bring up the TLS channel and 
request the certificate again, and a client supporting privacy would comply. 
However, existing EAP-TLS servers will terminate the connection if a 
certificate is not provided in response to the first request, so an uplevel 
client talking to a downlevel server would have to choose between 
connectivity and privacy, at least on the first attempt.  On subsequent 
attempts, the uplevel client could choose whether it is willing to hand over 
its certificate in cleartext and if so, it could connect using the RFC 
2716-specified sequence.

The backward compatibility of the client extension approach depends on the 
server's reaction to the offering of client extensions.  There seems to be 
an assumption that a downlevel server will ignore the extensions and that 
therefore the conversation would complete as in RFC 2716.  This would allow 
a client supporting privacy extensions but willing to connect without 
privacy to successfully authenticate on the first attempt.  However, I'm not 
clear whether the underlying assumption of extension backward compatibliity 
is actually true or not -- as I understand it, some EAP-TLS server 
implementations do not react well to extensions.

---

From: Pascal Urien <[email-masked]>
Date: Mon, 05 Jun 2006 11:57:22 +0200

Hi Everybody

At 11:41 04/06/2006 -0700, you wrote:
>EAP-TLS server implementations always request a certificate.   If the 
>client desires privacy, it can choose not to respond to the certificate 
>request.
>An EAP-TLS server supporting privacy would then bring up the TLS channel 
>and request the certificate again, and a client supporting privacy would 
>comply. However, existing EAP-TLS servers will terminate the connection if 
>a certificate is not provided in response to the first request, so an 
>uplevel client talking to a downlevel server would have to choose between 
>connectivity and privacy,

 From our point of view the main issue in today RFC 2716 document is that 
the client always sent its identity (X509 certificate) in clear text.

In a Wi-Fi context, this is clearly a major security threat.

>at least on the first attempt.  On subsequent attempts, the uplevel client 
>could choose whether it is willing to hand over its certificate in 
>cleartext and if so, it could connect using the RFC 2716-specified sequence.
>
>therefore the conversation would complete as in RFC 2716.  This would 
>allow a client supporting privacy extensions but willing to connect 
>without privacy to successfully authenticate on the first 
>attempt.  However, I'm not clear whether the underlying assumption of 
>extension backward compatibliity is actually true or not -- as I 
>understand it, some EAP-TLS server implementations do not react well to 
>extensions.

According to 

the TLS extension is used in order to indicate to the server, that the 
client certificate will (MUST) be sent encrypted,
A choice of encryption algorithms MAY be supported by the client.

However the server can easily detects the encryption of the client's 
certificate, because the first bytes
(in clear text) are knows :
Certificate: [30]  [8x]  (with x=2) [Certficate_Length] [30] [8x] (with =2)

Furthermore if the server ignores  the TLS extension the client MAY send 
its certificate encrypted with its preferred
encryption algorithm (the first in the TLS extension list)

Pascal

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 05 Jun 2006 05:16:06 -0700

>encryption algorithm (the first in the TLS extension list)

This definitely breaks backward compatibility.

---

From: Pascal Urien <[email-masked]>
Date: Mon, 05 Jun 2006 16:04:54 +0200

Hi Bernard

>This definitely breaks backward compatibility.

The issue is that any malicious access point may forge EAP-TLS packets in 
order to collect
the supplicant's certificate (e;G. its identity)

 From the supplicant point of view, the meaning of the TLS extension is 
something like
"i want to keep secret my identity"

So a negative answer to the supplicant's request, sings like
"i need your identity in clear text"

At this step the supplicant doesn't know if the access point is malicious 
or not..

This leads to two questions

1) what is the right way to manage backward compatibility, without 
sacrificing privacy issues ?

2) do we need a new EAP type for that concern?.

Pascal