Approval announcement
Draft of message to be sent after approval:
Announcement
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
Ballot Text
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.