draft-ietf-pppext-eap-ttls-05.txt

Linux上的802.1x 的supplicant的实现。很多supplicant程序都是基于它开发的

PPPEXT Working Group                                          Paul Funk 
Internet-Draft                                      Funk Software, Inc. 
Category: Standards Track                            Simon Blake-Wilson 
<draft-ietf-pppext-eap-ttls-05.txt>                    Basic Commerce &  
                                                       Industries, Inc. 
                                                              July 2004 

                                     

               EAP Tunneled TLS Authentication Protocol 
                              (EAP-TTLS) 

                                     

Status of this Memo 

   This document is an Internet-Draft and is subject to all provisions 
   of Section 10 of RFC2026. 

   Internet-Drafts are working documents of the Internet Engineering 
   Task Force (IETF), its areas, and its working groups. Note that 
   other groups may also distribute working documents as Internet-
   Drafts. 

   Internet-Drafts are draft documents valid for a maximum of six 
   months and may be updated, replaced, or obsoleted by other documents 
   at any time. It is inappropriate to use Internet-Drafts as reference 
   material or to cite them other than as "work in progress." 

   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/1id-abstracts.html 

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 

Copyright Notice 

   Copyright (C) The Internet Society (2001-2004). All Rights Reserved. 

Abstract 

   EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS 
   handshake is used to mutually authenticate a client and server. EAP-
   TTLS extends this authentication negotiation by using the secure 
   connection established by the TLS handshake to exchange additional 
   information between client and server. In EAP-TTLS, the TLS 
   handshake may be mutual; or it may be one-way, in which only the 
   server is authenticated to the client. The secure connection 
   established by the handshake may then be used to allow the server to 
   authenticate the client using existing, widely-deployed 
   authentication infrastructures such as RADIUS. The authentication of 

Internet-Draft                                              April 2004         


   the client may itself be EAP, or it may be another authentication 
   protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. 

   Thus, EAP-TTLS allows legacy password-based authentication protocols 
   to be used against existing authentication databases, while 
   protecting the security of these legacy protocols against 
   eavesdropping, man-in-the-middle and other cryptographic attacks. 

   EAP-TTLS also allows client and server to establish keying material 
   for use in the data connection between the client and access point. 
   The keying material is established implicitly between client and 
   server based on the TLS handshake.  

   This document describes two versions of EAP-TTLS - version 0 and 
   version 1. Most of the document concerns EAP-TTLS v0, a form of the 
   protocol that has been implemented by multiple vendors. Section 11 
   defines EAP-TTLS v1, an enhanced version of the protocol that 
   utilizes the TLS extensions mechanism to allow authentications to 
   occur within, rather than after, the TLS handshake. The TLS 
   extension that is defined is believed to useful in its own right, 
   and may be used in other contexts in addition to EAP-TTLS v1. 

Table of Contents 

1.  Introduction......................................................3 
2.  Motivation........................................................4 
3.  Terminology.......................................................6 
4.  Architectural Model...............................................8 
4.1    Carrier Protocols.............................................9 
4.2    Security Relationships.......................................10 
4.3    Messaging....................................................10 
4.4    Resulting Security...........................................11 
5.  Protocol Layering Model..........................................11 
6.  EAP-TTLS version 0 Overview......................................12 
6.1    Phase 1: Handshake...........................................13 
6.2    Phase 2: Tunnel..............................................14 
6.3    Piggybacking.................................................14 
6.4    Session Resumption...........................................15 
6.4.1      TTLS Server Guidelines for Session Resumption............16 
7.  Generating Keying Material.......................................16 
8.  EAP-TTLS Encoding................................................17 
8.1    EAP-TTLS Start Packet........................................17 
8.2    EAP-TTLS Packets with No Data................................18 
9.  Encapsulation of AVPs within the TLS Record Layer................18 
9.1    AVP Format...................................................19 
9.2    AVP Sequences................................................20 
9.3    Guidelines for Maximum Compatibility with AAA Servers........20 
10. Tunneled Authentication..........................................20 
10.1   Implicit challenge...........................................21 
10.2   Tunneled Authentication Protocols............................21 
10.2.1     EAP ......................................................22 



Paul Funk                expires January 2005                 [Page 2] 

Internet-Draft                                              April 2004         


10.2.2     CHAP .....................................................23 
10.2.3     MS-CHAP..................................................23 
10.2.4     MS-CHAP-V2...............................................24 
10.2.5     PAP ......................................................25 
10.3   Performing Multiple Authentications..........................26 
11. EAP-TTLS Version 1...............................................27 
11.1   EAP-TTLS v1 Introduction.....................................27 
11.2   Intentions Beyond EAP-TTLS...................................28 
11.3   The InnerApplication Extension to TLS........................28 
11.3.1     TLS/IA Overview..........................................29 
11.3.2     Message Exchange.........................................31 
11.3.3     Master Key Permutation...................................31 
11.3.4     Session Resumption.......................................33 
11.3.5     Error Termination........................................33 
11.3.6     Application Session Key Material.........................33 
11.3.7     Computing Verification Data..............................34 
11.3.8     Attribute-Value Pairs (AVPs).............................36 
11.3.9     TLS/IA Messages..........................................36 
11.3.10    The InnerApplication Extension...........................37 
11.3.11    The PhaseFinished Handshake Message......................37 
11.3.12    The ApplicationPayload Handshake Message.................37 
11.3.13    The InnerApplicationFailure Alert........................38 
11.4   Binding of TLS/IA to EAP-TTLS v1.............................38 
11.4.1     Flags Octet..............................................38 
11.4.2     Version Negotiation......................................39 
11.4.3     Acknowledgement Packets..................................39 
11.4.4     Generating Keying Material...............................40 
12. Discussion of Certificates and PKI...............................40 
13. Message Sequences................................................42 
13.1   Successful authentication via tunneled CHAP..................42 
13.2   Successful authentication via tunneled EAP/MD5-Challenge.....44 
13.3   Successful session resumption................................46 
14. Security Considerations..........................................47 
15. Changes since previous drafts....................................49 
16. References.......................................................50 
17. Authors' Addresses...............................................51 
18. Full Copyright Statement.........................................51 
    

1. Introduction 

   Extensible Authentication Protocol (EAP) [2] defines a standard 
   message exchange that allows a server to authenticate a client based 
   on an authentication protocol agreed upon by both parties. EAP may 
   be extended with additional authentication protocols by registering 
   such protocols with IANA or by defining vendor specific protocols. 

   Transport Layer Security (TLS) [3] is an authentication protocol 
   that provides for client authentication of a server or mutual 
   authentication of client and server, as well as secure ciphersuite 
   negotiation and key exchange between the parties. TLS has been 



Paul Funk                expires January 2005                 [Page 3] 

Internet-Draft                                              April 2004         


   defined as an authentication protocol for use within EAP (EAP-TLS) 
   [1]. 

   Other authentication protocols are also widely deployed. These are 
   typically password-based protocols, and there is a large installed 
   base of support for these protocols in the form of credential 
   databases that may be accessed by RADIUS, Diameter or other AAA 
   servers. These include non-EAP protocols such as PAP, CHAP, MS-CHAP 
   and MS-CHAP-V2, as well as EAP protocols such as MD5-Challenge. 

   EAP-TTLS is an EAP protocol that extends EAP-TLS. In EAP-TLS, a TLS 
   handshake is used to mutually authenticate a client and server. EAP-
   TTLS extends this authentication negotiation by using the secure 
   connection established by the TLS handshake to exchange additional 
   information between client and server. In EAP-TTLS, the TLS 
   handshake may be mutual; or it may be one-way, in which only the 
   server is authenticated to the client. The secure connection 
   established by the handshake may then be used to allow the server to 
   authenticate the client using existing, widely-deployed 
   authentication infrastructures such as RADIUS. The authentication of 
   the client may itself be EAP, or it may be another authentication 
   protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. 

   Thus, EAP-TTLS allows legacy password-based authentication protocols 
   to be used against existing authentication databases, while 
   protecting the security of these legacy protocols against 
   eavesdropping, man-in-the-middle and other cryptographic attacks. 

   EAP-TTLS also allows client and server to establish keying material 
   for use in the data connection between the client and access point. 
   The keying material is established implicitly between client and 
   server based on the TLS handshake.  

   In EAP-TTLS, client and server communicate using attribute-value 
   pairs encrypted within TLS. This generality allows arbitrary 
   functions beyond authentication and key exchange to be added to the 
   EAP negotiation, in a manner compatible with the AAA infrastructure. 

2. Motivation 

   Most password-based protocols in use today rely on a hash of the 
   password with a random challenge. Thus, the server issues a 
   challenge, the client hashes that challenge with the password and 
   forwards a response to the server, and the server validates that 
   response against the user's password retrieved from its database. 
   This general approach describes CHAP, MS-CHAP, MS-CHAP-V2, EAP/MD5-
   Challenge and EAP/One-Time Password. 

   An issue with such an approach is that an eavesdropper that observes 
   both challenge and response may be able to mount a dictionary 
   attack, in which random passwords are tested against the known 



Paul Funk                expires January 2005                 [Page 4] 

Internet-Draft                                              April 2004         


   challenge to attempt to find one which results in the known 
   response. Because passwords typically have low entropy, such attacks 
   can in practice easily discover many passwords.  

   While this vulnerability has long been understood, it has not been 
   of great concern in environments where eavesdropping attacks are 
   unlikely in practice. For example, users with wired or dial-up 
   connections to their service providers have not been concerned that 
   such connections may be monitored. Users have also been willing to 
   entrust their passwords to their service providers, or at least to 
   allow their service providers to view challenges and hashed 
   responses which are then forwarded to their home authentication 
   servers using, for example, proxy RADIUS, without fear that the 
   service provider will mount dictionary attacks on the observed 
   credentials. Because a user typically has a relationship with a 
   single service provider, such trust is entirely manageable. 

   With the advent of wireless connectivity, however, the situation 
   changes dramatically: 

   -  Wireless connections are considerably more susceptible to 
      eavesdropping and man-in-the-middle attacks. These attacks may 
      enable dictionary attacks against low-entropy passwords. In 
      addition, they may enable channel hijacking, in which an attacker 
      gains fraudulent access by seizing control of the communications 
      channel after authentication is complete. 

   -  Existing authentication protocols often begin by exchanging the 
      client苨 username in the clear. In the context of eavesdropping 
      on the wireless channel, this can compromise the client苨 
      anonymity and locational privacy. 

   -  Often in wireless networks, the access point does not reside in 
      the administrative domain of the service provider with which the 
      user has a relationship. For example, the access point may reside 
      in an airport, coffee shop, or hotel in order to provide public 
      access via 802.11. Even if password authentications are protected 
      in the wireless leg, they may still be susceptible to 
      eavesdropping within the untrusted wired network of the access 
      point. 

   -  In the traditional wired world, the user typically intentionally 
      connects with a particular service provider by dialing an 
      associated phone number; that service provider may be required to 
      route an authentication to the user's home domain. In a wireless 
      network, however, the user does not get to choose an access 
      domain, and must connect with whichever access point is nearby; 
      providing for the routing of the authentication from an arbitrary 
      access point to the user's home domain may pose a challenge.