Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)
RFC 5281

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'Extensible Authentication Protocol 
         Tunneled Transport Layer Security Authenticated Protocol Version 
         0 (EAP-TTLSv0)' to Informational RFC 

The IESG has approved the following document:

- 'Extensible Authentication Protocol Tunneled Transport Layer Security 
   Authenticated Protocol Version 0 (EAP-TTLSv0) '
   <draft-funk-eap-ttls-v0-06.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-06.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.