Re: [TLS] TLS Renegotiation - Any implications to EAP-TLS ?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] TLS Renegotiation - Any implications to EAP-TLS ?



Right. EAP-TLS wouldn't be vulnerable to this attack.

PEAP might be vulnerable (theoretically), but the attacker would gain nothing by injecting data before the tunnelled EAP.

 

 

From: tls-bounces at ietf.org [mailto:tls-bounces at ietf.org] On Behalf Of Zheng Kanghong
Sent: Tuesday, November 10, 2009 08:52
To: tls at ietf.org
Subject: [TLS] TLS Renegotiation - Any implications to EAP-TLS ?

 

Hi all,

Anyone discussed the implications of the TLS renegotiation vulnerability to EAP-TLS?

From my little understanding, it seems like EAP-TLS is not vulnerable.

  • There is no application layer protocol involved when EAP-TLS is executed [Please correct me if I'm wrong].
  • If client certificate authentication is required (it should), the server will always request for client certificates.
  • After a successful EAP-TLS exchange, the TLS tunnel is not used; only the keying material is exported [Although the tunnel is not used, is it still present and can be used in some way? Or is there no state information stored for the EAP method after a successful EAP exchange?).
  • EAP re-authentication is a new EAP exchange which is independent of the previous exchange. It is not the same as TLS renegotiation which is executed in the previous TLS tunnel.


Any comments? Thanks.
- kh



This email and any files transmitted with it are confidential material. They are intended solely for the use of the designated individual or entity to whom they are addressed. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, use, distribution or copying of this communication is strictly prohibited and may be unlawful.

If you have received this email in error please immediately notify the sender and delete or destroy any copy of this message

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.