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

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

   and key distribution for the subsequent data connection. 

   If a tunneled client authentication is performed, the TTLS server 
   de-tunnels and forwards the authentication information to the AAA/H. 
   If the AAA/H performs a challenge, the TTLS server tunnels the 
   challenge information to the client. The AAA/H server may be a 
   legacy device and needs to know nothing about EAP-TTLS; it only 



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


   needs to be able to authenticate the client based on commonly used 
   authentication protocols. 

   Keying material for the subsequent data connection between client 
   and access point may be generated based on secret information 
   developed during the TLS handshake between client and TTLS server. 
   At the conclusion of a successful authentication, the TTLS server 
   may transmit this keying material to the access point, encrypted 
   based on the existing security associations between those devices 
   (e.g., RADIUS).  

   The client and access point now share keying material which they can 
   use to encrypt data traffic between them. 

4.4 Resulting Security 

   As the diagram above indicates, EAP-TTLS allows user identity and 
   password information to be securely transmitted between client and 
   TTLS server, and performs key distribution to allow network data 
   subsequent to authentication to be securely transmitted between 
   client and access point.  

5. Protocol Layering Model 

   EAP-TTLS packets are encapsulated within EAP, and EAP in turn 
   requires a carrier protocol to transport it. EAP-TTLS packets 
   themselves encapsulate TLS, which is then used to encapsulate user 
   authentication information. Thus, EAP-TTLS messaging can be 
   described using a layered model, where each layer is encapsulated by 
   the layer beneath it. The following diagram clarifies the 
   relationship between protocols: 

   +--------------------------------------------------------+ 
   | User Authentication Protocol (PAP, CHAP, MS-CHAP, etc.)| 
   +--------------------------------------------------------+ 
   |                       TLS                              | 
   +--------------------------------------------------------+ 
   |                     EAP-TTLS                           | 
   +--------------------------------------------------------+ 
   |                       EAP                              | 
   +--------------------------------------------------------+ 
   | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.)  | 
   +--------------------------------------------------------+ 

   When the user authentication protocol is itself EAP, the layering is 
   as follows: 








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


   +--------------------------------------------------------+ 
   | User EAP Authentication Protocol (MD-Challenge, etc.)  | 
   +--------------------------------------------------------+ 
   |                       EAP                              | 
   +--------------------------------------------------------+ 
   |                       TLS                              | 
   +--------------------------------------------------------+ 
   |                     EAP-TTLS                           | 
   +--------------------------------------------------------+ 
   |                       EAP                              | 
   +--------------------------------------------------------+ 
   | Carrier Protocol (PPP, EAPOL, RADIUS, Diameter, etc.)  | 
   +--------------------------------------------------------+ 

   Methods for encapsulating EAP within carrier protocols are already 
   defined. For example, PPP [5] or EAPOL [4] may be used to transport 
   EAP between client and access point; RADIUS [6] or Diameter [8] are 
   used to transport EAP between access point and TTLS server. 

6. EAP-TTLS version 0 Overview 

   [Authors' note: This section as well as sections 7, 8, 9 and 10, 
   describe version 0 of the EAP-TTLS protocol. Section 11 describes 
   version 1 of EAP-TTLS. Much of the material describing version 0 
   also applies to version 1; the version 1 documentation will refer to 
   the version 0 material as required. The intention is to provide a 
   separate draft for each of the two versions in the near future.] 

   A EAP-TTLS negotiation comprises two phases: the TLS handshake phase 
   and the TLS tunnel phase.  

   During phase 1, TLS is used to authenticate the TTLS server to the 
   client and, optionally, the client to the TTLS server. Phase 1 
   results in the activation of a cipher suite, allowing phase 2 to 
   proceed securely using the TLS record layer. (Note that the type and 
   degree of security in phase 2 depends on the cipher suite negotiated 
   during phase 1; if the null cipher suite is negotiated, there will 
   be no security!) 

   During phase 2, the TLS record layer is used to tunnel information 
   between client and TTLS server to perform any of a number of 
   functions. These might include user authentication, negotiation of 
   data communication security capabilities, key distribution, 
   communication of accounting information, etc.. Information between 
   client and TTLS server is exchanged via attribute-value pairs (AVPs) 
   compatible with RADIUS and Diameter; thus, any type of function that 
   can be implemented via such AVPs may easily be performed. 

   EAP-TTLS specifies how user authentication may be performed during 
   phase 2. The user authentication may itself be EAP, or it may be a 
   legacy protocol such as PAP, CHAP, MS-CHAP or MS-CHAP-V2. Phase 2 



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


   user authentication may not always be necessary, since the user may 
   already have been authenticated via the mutual authentication option 
   of the TLS handshake protocol.  

   EAP-TTLS is also intended for use in key distribution, and specifies 
   how keying material for the data connection between client and 
   access point is generated. The keying material is developed 
   implicitly between client and TTLS server based on the results of 
   the TLS handshake; the TTLS server will communicate the keying 
   material to the access point over the carrier protocol  However, 
   EAP-TTLS does not specify particular key distribution AVPs and their 
   use, since the needs of various systems will be different. Instead, 
   a general model for key distribution is suggested. Organizations may 
   define their own AVPs for this use, possibly using vendor-specific 
   AVPs, either in conformance with the suggested model or otherwise. 

6.1 Phase 1: Handshake 

   In phase 1, the TLS handshake protocol is used to authenticate the 
   TTLS server to the client and, optionally, to authenticate the 
   client to the TTLS server. 

   Phase 1 is initiated when the client sends an EAP-Response/Identity 
   packet to the TTLS server. This packet specifically should not 
   include the name of the user; however, it may include the name of 
   the realm of a trusted provider to which EAP-TTLS packets should be 
   forwarded; for example, "@myisp.com". 

   The TTLS server responds to the EAP-Response/Identity packet with a 
   EAP-TTLS/Start packet, which is an EAP-Request with Type = EAP-TTLS, 
   the S (Start) bit set, and no data. This indicates to the client 
   that it should begin TLS handshake by sending a ClientHello message. 

   EAP packets continue to be exchanged between client and TTLS server 
   to complete the TLS handshake, as described in [1]. Phase 1 is 
   completed when the client and TTLS server exchange ChangeCipherSpec 
   and Finished messages. At this point, additional information may be 
   securely tunneled. 

   As part of the TLS handshake protocol, the TTLS server will send its 
   certificate along with a chain of certificates leading to the 
   certificate of a trusted CA. The client will need to be configured 
   with the certificate of the trusted CA in order to perform the 
   authentication.  

   If certificate-based authentication of the client is desired, the 
   client must have been issued a certificate and must have the private 
   key associated with that certificate 






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


6.2 Phase 2: Tunnel 

   In phase 2, the TLS Record Layer is used to securely tunnel 
   information between client and TTLS server. This information is 
   encapsulated in sequences of attribute-value pairs (AVPS), whose use 
   and format are described in later sections. 

   Any type of information may be exchanged during phase 2, according 
   to the requirements of the system. (It is expected that applications 
   utilizing EAP-TTLS will specify what information must be exchanged 
   and therefore which AVPs must be supported.) 

   The client begins the phase 2 exchange by encoding information in a 
   sequence of AVPs, passing this sequence to the TLS record layer for 
   encryption, and sending the resulting data to the TTLS server.  

   The TTLS server recovers the AVPs in clear text from the TLS record 
   layer. If the AVP sequence includes authentication information, it 
   forwards this information to the AAA/H server using the AAA carrier 
   protocol. Note that the EAP-TTLS and AAA/H servers may be one and 
   the same, in which case it simply processes the information locally. 

   The TTLS server may respond with its own sequence of AVPs. The TTLS 
   server passes the AVP sequence to the TLS record layer for 
   encryption and sends the resulting data to the client. For example, 
   the TTLS server may send key distribution information, or it may 
   forward an authentication challenge received from the AAA/H. 

   This process continues until the TTLS server has enough information 
   to issue either an EAP-Success or EAP-Failure. Thus, if the AAA/H 
   rejects the client based on forwarded authentication information, 
   the TTLS server would issue an EAP-Failure. If the AAA/H accepts the 
   client, the TTLS server would issue an EAP-Success. 

   The TTLS server distributes data connection keying information and 
   other authorization information to the access point in the same AAA 
   carrier protocol message that carries the EAP-Success. 

6.3 Piggybacking 

   While it is convenient to describe EAP-TTLS messaging in terms of 
   two phases, it is sometimes required that a single EAP-TTLS packet 
   to contain both phase 1 and phase 2 TLS messages.  

   Such "piggybacking" occurs when the party that completes the 
   handshake also has AVPs to send. For example, when negotiating a 
   resumed TLS session, the TTLS server sends its ChangeCipherSpec and 
   Finished messages first, then the client sends its own 
   ChangeCipherSpec and Finished messages to conclude the handshake. If 
   the client has authentication or other AVPs to send to the TTLS 
   server, it must tunnel those AVPs within the same EAP-TTLS packet 



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


   immediately following its Finished message. If the client fails to 
   do this, the TTLS server will incorrectly assume that the client has 
   no AVPs to send, and the outcome of the negotiation could be 
   affected. 

6.4 Session Resumption 

   When a client and TTLS server that have previously negotiated a EAP-
   TTLS session begin a new EAP-TTLS negotiation, the client and TTLS 
   server may agree to resume the previous session. This significantly 
   reduces the time required to establish the new session. This could 
   occur when the client connects to a new access point, or when an 
   access point requires reauthentication of a connected client. 

   Session resumption is accomplished using the standard TLS mechanism. 
   The client signals its desire to resume a session by including the 
   session ID of the session it wishes to resume in the ClientHello 
   message; the TTLS server signals its willingness to resume that 
   session by echoing that session ID in its ServerHello message.  

   If the TTLS server elects not to resume the session, it simply does 
   not echo the session ID and a new session will be negotiated. This 
   could occur if the TTLS server is configured not to resume sessions, 
   if it has not retained the requested session's state, or if the 
   session is considered stale. A TTLS server may consider the session 
   stale based on its own configuration, or based on session-limiting 
   information received from the AAA/H (e.g., the RADIUS Session-
   Timeout attribute). 

   Tunneled authentication is specifically not performed for resumed 
   sessions; the presumption is that the knowledge of the master secret 
   as evidenced by the ability to resume the session is authentication 
   enough. This allows session resumption to occur without any 
   messaging between the TTLS server and the AAA/H. If periodic 
   reauthentication to the AAA/H is desired, the AAA/H must indicate 
   this to the TTLS server when the original session is established, 
   for example, using the RADIUS Session-Timeout attribute.