draft-funk-eap-ttls-v1-01.txt

来自「linux 下通过802.1认证的安装包」· 文本 代码 · 共 1,298 行 · 第 1/4 页

   the layer beneath it. The following diagram clarifies the 
   relationship between protocols: 

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

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

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

   Methods for encapsulating EAP within carrier protocols are already 
   defined. For example, PPP [RFC1661] or EAPOL [802.1X] may be used to 
   transport EAP between client and access point; RADIUS [RFC2685] or 
   Diameter [RFC3588] are used to transport EAP between access point 
   and TTLS server. 

6. EAP-TTLSv1 Overview 

   EAP-TTLSv1 is initiated by the server's transmission of a Start 
   packet to the client.  

   The EAP exchange proceeds with transmission of TLS/IA message 
   sequences alternately by client and server, with each message 
   sequence encapsulated in an EAP-TTLSv1 frame. Descriptions of the 
   TLS/IA messages can be found in [TLS/IA].  



Paul Funk               expires September 2006               [Page 12] 

Internet-Draft                                              March 2006         


   A successful authentication will result in the server sending a 
   TLS/IA FinalPhaseFinished message and the client responding with 
   it's own FinalPhaseFinished message.  

   The server then sends an EAP-Success to the client to complete the 
   authentication. This message is the standard EAP success message and 
   is sent in the clear. 

   Client and server each computes the MSK (the Master Sesion Key, as 
   defined in [RFC3784]), based on information generated in the TLS/IA 
   exchange. The server may then transmit the MSK to the access point 
   for use in its data communications with the client. 

   If the TLS/IA negotiation fails, the server sends an EAP-Failure to 
   the client. 

6.1 Session Resumption 

   When a client and TTLS server that have previously negotiated a EAP-
   TTLSv1 session begin a new EAP-TTLSv1 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). 

   Addition messages beyond the TLS handshake may or may not occur 
   within a resumed session. TLS/IA provides a negotiation mechanism 
   allowing client and server to determine whether InnerApplication 
   messages are to ensue upon session resumption. Typically, inner 
   authentications would not be required in a resumed session, as the 
   ability to resume the session may provide sufficient evidence to 
   either party of the identity of the other. However, there may be 
   additional information that needs to be refreshed or renegotiated 
   during a session resumption. 




Paul Funk               expires September 2006               [Page 13] 

Internet-Draft                                              March 2006         


   When an inner authentication is not performed during a resumed 
   session, the TTLS server will not receive new authorization 
   information from the AAA/H. In this case, the TTLS server must 
   retain authorization information initially returned by the AAA/H for 
   use in resumed sessions. Authorization information might include the 
   maximum time for the session, the maximum allowed bandwidth, packet 
   filter information and the like. The TTLS server is responsible for 
   modifying time values, such as Session-Timeout, appropriately for 
   each resumed session. 

   A TTLS server MUST NOT permit a session to be resumed if that 
   session did not result in a successful completion of the entire 
   TLS/IA exchange, and a client MUST NOT propose the session ID of a 
   failed session for resumption. The consequence of incorrectly 
   implementing this aspect of session resumption would be 
   catastrophic; any attacker could easily gain network access by first 
   initiating a session that succeeds in the TLS handshake but fails 
   the inner authentication, and then resuming that session. 

   [Implementation note: Toolkits that implement TLS often cache 
   resumable TLS sessions automatically. Implementers must take care to 
   override such automatic behavior, and prevent sessions from being 
   cached for possible resumption until the user has been positively 
   authenticated.] 

   A TTLS server MUST NOT permit a session negotiated with different 
   tunneled TLS-based EAP protocol to be resumed in an EAP-TTLSv1 
   session, and a client MUST NOT propose the session ID resulting from 
   such a protocol for resumption in EAP-TTLSv1. Note that previous 
   versions of EAP-TTLS are considered different tunneled TLS-based 
   protocols for the purposes of this paragraph. Thus, a session 
   negotiated using EAP-PEAP, EAP-FAST or EAP-TTLSv0 are not candidate 
   sessions for resumption in EAP-TTLSv1. 

6.1.1 TTLS Server Guidelines for Session Resumption 

   When a domain comprises multiple TTLS servers, a client's attempt to 
   resume a session may fail because each EAP-TTLS negotiation may be 
   routed to a different TTLS server. 

   One strategy to ensure that subsequent EAP-TTLS negotiations are 
   routed to the original TTLS server is for each TTLS server to encode 
   its own identifying information, for example, IP address, in the 
   session IDs that it generates. This would allow any TTLS server 
   receiving a session resumption request to forward the request to the 
   TTLS server that established the original session. 








Paul Funk               expires September 2006               [Page 14] 

Internet-Draft                                              March 2006         


7. Generating Keying Material 

   Upon successful conclusion of an EAP-TTLSv1 negotiation, a 64-octet 
   MSK (Master Session Key) is generated and exported for use in 
   securing the data connection between client and access point. 

   The MSK is generated using the TLS PRF function [RFC2246], with 
   inputs consisting of the inner secret exported by TLS/IA, the ASCII-
   encoded constant string "ttls v1 keying material", the TLS client 
   random, and the TLS server random. The constant string is not null-
   terminated. The TLS/IA inner secret, rather than the TLS master 
   secret, is used because it binds session keys from inner 
   authentications with the TLS master secret and therefore provides 
   greater security in the (unlikely) case that an adversary is able to 
   compromise the master secret. 

      MSK = PRF(inner_secret, 
                "ttls v1 keying material", 
                SecurityParameters.client_random + 
                SecurityParameters.server_random) [0..63] 

   Note that the order of client_random and server_random for EAP-TTLS 
   is reversed from that of the TLS protocol [RFC2246]. This ordering 
   follows the key derivation method of EAP-TLS [RFC2716]. Altering the 
   order of randoms avoids namespace collisions between constant 
   strings defined for EAP-TTLSv1 and those defined for the TLS 
   protocol. 

   The inner secret used in the PRF MUST be the one generated at the 
   conclusion of the final InnerApplication phase of TLS/IA; the client 
   random and server random MUST be those established during the TLS 
   handshake. Client and TTLS server generate this keying material 
   independently, and the result is guaranteed to be the same for each 
   if the TLS/IA exchange succeeds.  

   The TTLS server distributes this keying material to the access point 
   via the AAA carrier protocol. When RADIUS is the AAA carrier 
   protocol, the MPPE-Recv-Key and MPPE-Send-Key attributes may be used 
   to distribute the first 32 octets and second 32 octets of the MSK, 
   respectively. 

8. EAP-TTLSv1 Protocol 

8.1 Packet Format 

   The EAP-TTLSv1 packet format is shown below. The fields are 
   transmitted left to right. 







Paul Funk               expires September 2006               [Page 15] 

Internet-Draft                                              March 2006         


    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Code      |   Identifier  |            Length             | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |     Type      |     Flags     |        Message Length 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
            Message Length         |             Data... 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

   Code 
      1 for request, 2 for response. 

   Identifier 
      The Identifier field is one octet and aids in matching responses 
      with requests.  The Identifier field MUST be changed for each 
      request packet and MUST be echoed in each response packet. 

   Length 
      The Length field is two octets and indicates the number of octets 
      in the entire EAP packet, from the Code field through the Data 
      field. 

   Type 
      21 (EAP-TTLS, all versions) 

   Flags 
        0   1   2   3   4   5   6   7 
      +---+---+---+---+---+---+---+---+ 
      | L | M | S | R | R |     V     | 
      +---+---+---+---+---+---+---+---+ 

      L = Length included 
      M = More fragments 
      S = Start 
      R = Reserved 
      V = Version (001 for EAP-TTLSv1) 

      The L bit is set to indicate the presence of the four octet TLS 
      Message Length field. The M bit indicates that more fragments are 
      to come. The S bit indicates a Start message. The V bit is set to 
      the version of EAP-TTLS, and is set to 001 for EAP-TTLSv1. 

   Message Length 
      The Message Length field is four octets, and is present only if 
      the L bit is set. This field provides the total length of the raw 
      data message sequence prior to fragmentation. 

   Data 
      For all packets other than a Start packet, the Data field 
      consists of the raw TLS message sequence or fragment thereof. For 



Paul Funk               expires September 2006               [Page 16] 

Internet-Draft                                              March 2006         


      a Start packet, the Data field may optionally contain an AVP 
      sequence. 

8.2 EAP-TTLS Start Packet 

   The S bit MUST be set on the first packet sent by the server to 
   initiate the EAP-TTLSv1 protocol. It MUST NOT be set on any other 
   packet. 

   This packet MAY contain additional information in the form of AVPs, 
   which may provide useful hints to the client; for example, the 
   server identity may be useful to the client to allow it to pick the 
   correct TLS session ID for session resumption. Each AVP must begin 
   on a 4-octet boundary relative to the first AVP in the sequence. If 
   an AVP is not a multiple of 4 octets, it must be padded with 0s to 
   the next 4-octet boundary. 

8.2.1 Version Negotiation 

   The version of EAP-TTLS is negotiated in the first exchange between 
   server and client. The server sets the highest version number of 
   EAP-TTLS that it supports in the V field of its Start message (in 
   the case of EAP-TTLS v1, this is 1). In its first EAP message in 
   response, the client sets the V field to the highest version number 
   that it supports that is no higher than the version number offered 
   by the server. If the client version is not acceptable to the 
   server, it sends an EAP-Failure to terminate the EAP session. 
   Otherwise, the version sent by the client is the version of EAP-TTLS 
   that MUST be used, and both server and client set the V field to