The IESG has approved the following document: - 'EAP Tunneled TLS Authentication Protocol Version 0 (EAP-TTLSv0) ' <draft-funk-eap-ttls-v0-05.txt> as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Jari Arkko. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-funk-eap-ttls-v0-05.txt Technical Summary EAP-TTLS is an EAP method that allows the peer to authenticate itself using legacy protocols such as PAP, CHAP, MS-CHAP or MS-CHAP-V2, and more importantly using legacy password databases. The peer can also use certificates or any EAP method to authenticate itself. EAP-TTLS also protects the security of these legacy protocols against eavesdropping, man-in-the-middle and other attacks. EAP-TTLS is a key generating method and it protects the peer's anonymity. Finally, the protocol is extensible. Working Group Summary This is an individual submission. Agreement has been reached with the EMU WG chair that documenting TTLS as is can be done via AD sponsoring; the EMU WG may still document additional tunnel methods or improve TTLS in some manner. Document Quality There are many existing interoperable implementations of the protocol. Some SDOs include the use of TTLS in their new specifications and that may increase additional adoption of this protocol. A number of reviewers contributed to the quality of the document. Some of them are listed in the acknowledgments section of the document. Personnel Document Shepherd is Laksminath Dondeti. The responsible AD is Jari Arkko. RFC Editor Note In Section 1, make the following change: OLD: EAP-TTLS is an EAP method that provides functionality beyond what is available in EAP-TLS. In EAP-TLS, a TLS ... NEW: EAP-TTLS is an EAP method that provides functionality beyond what is available in EAP-TLS. EAP-TTLS has been widely deployed and this specification documents what existing implementations do. It has some limitations and vulnerabilities, however. These are addressed in EAP-TTLS extensions and ongoing work in the creation of standardized tunneled EAP methods at the IETF. Users of EAP-TTLS are strongly encouraged to consider these in their deployments. In EAP-TLS, a TLS ... Add to the end of Section 1: NEW: The main limitation of EAP-TTLS is that its base version lacks support for cryptographic binding between the outer and inner authentication. Please refer to Section 14.1.11 for details and the conditions where this vulnerability exists. It should be noted that an extension of EAP-TTLS [TTLS-EXT] fixes this vulnerability. Users of EAP-TTLS are strongly encouraged to adopt this extension. In Section 11.2.1, change OLD: Upon receipt of the tunneled EAP-Response/Identity, the TTLS server forwards it to the AAA/H in a RADIUS Access-Request. NEW: Note that TTLS processing of the initial identity exchange is different from plain EAP. The state machine of TTLS is different. However, it is expected that server side is capable of dealing with client initiation, because even normal EAP protocol runs are client initiated over AAA. On the client side there are various implementation techniques to deal with the differences. Even an TTLS unaware EAP protocol run could be used, if TTLS makes it appear as if EAP Request/Identity message was actually received. This is similar to what authenticators do when operating between a client and a AAA server. Upon receipt of the tunneled EAP-Response/Identity, the TTLS server forwards it to the AAA/H in a RADIUS Access-Request. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
