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

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

      The Vendor-ID field is present if the 'V' bit is set in the AVP 
      Flags field. It is four octets, and contains the vendor's IANA-
      assigned "SMI Network Management Private Enterprise Codes" [9] 
      value. Vendors defining their own AVPs must maintain a consistent 
      namespace for use of those AVPs within RADIUS, Diameter and EAP-
      TTLS. 

      A Vendor-ID value of zero is equivalent to absence of the Vendor-
      ID field altogether. 

9.2 AVP Sequences 

   Data encapsulated within the TLS Record Layer must consist entirely 
   of a sequence of zero or more AVPs. 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. 

   Note that the AVP Length does not include the padding. 

9.3 Guidelines for Maximum Compatibility with AAA Servers 

   For maximum compatibility, the following guidelines for AVP usage 
   are suggested: 

   -  Non-vendor-specific AVPs should be selected from the set of 
      attributes defined for RADIUS; that is, attributes with codes 
      less than 256. This provides compatibility with both RADIUS and 
      Diameter. 

   -  Vendor-specific AVPs should be defined in terms of RADIUS. 
      Vendor-specific RADIUS attributes translate to Diameter (and, 
      hence, to EAP-TTLS) automatically; the reverse is not true. 
      RADIUS vendor-specific attributes use RADIUS attribute 26 and 
      include vendor ID, vendor-specific attribute code and length; see 
      [6] for details. 

10. Tunneled Authentication 

   EAP-TTLS permits user authentication information to be tunneled 
   within the TLS record layer between client and TTLS server, 



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


   guaranteeing the security of the authentication information against 
   active and passive attack between the client and TTLS server. The 
   TTLS server decrypts and forwards this information to the AAA/H over 
   the AAA carrier protocol.  

   Any type of password or other authentication may be tunneled. Also, 
   multiple tunneled authentications may be performed. Normally, 
   tunneled authentication is used when the client has not been issued 
   a certificate and the TLS handshake provides only one-way 
   authentication of the TTLS server to the client; however, in certain 
   cases it may be desired to perform certificate authentication of the 
   client during the TLS handshake as well as tunneled user 
   authentication afterwards. 

10.1 Implicit challenge 

   Certain authentication protocols that use a challenge/response 
   mechanism rely on challenge material that is not generated by the 
   authentication server, and therefore require special handling. 

   In CHAP, MS-CHAP and MS-CHAP-V2, for example, the NAS issues a 
   challenge to the client, the client then hashes the challenge with 
   the password and forwards the response to the NAS. The NAS then 
   forwards both challenge and response to a AAA server. But because 
   the AAA server did not itself generate the challenge, such protocols 
   are susceptible to replay attack.  

   If the client were able to create both challenge and response, 
   anyone able to observe a CHAP or MS-CHAP exchange could pose as that 
   user, even using EAP-TTLS.  

   To make these protocols secure under EAP-TTLS, it is necessary to 
   provide a mechanism to produce a challenge that the client cannot 
   control or predict. This is accomplished using the same technique 
   described above for generating data connection keying material. 

   When a challenge-based authentication mechanism is used, both client 
   and TTLS server use the pseudo-random function to generate as many 
   octets as are required for the challenge, using the constant string 
   "ttls challenge", based on the master secret and random values 
   established during the handshake: 

      EAP-TTLS_challenge = PRF(SecurityParameters.master_secret, 
                             "ttls challenge", 
                             SecurityParameters.client_random + 
                             SecurityParameters.server_random); 

10.2 Tunneled Authentication Protocols 

   This section describes the methods for tunneling specific 
   authentication protocols within EAP-TTLS.  



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


   For the purpose of explication, it is assumed that the TTLS server 
   and AAA/H use RADIUS as a AAA carrier protocol between them. 
   However, this is not a requirement, and any AAA protocol capable of 
   carrying the required information may be used. 

10.2.1 EAP 

   When EAP is the tunneled authentication protocol, each tunneled EAP 
   packet between the client and TTLS server is encapsulated in an EAP-
   Message AVP, prior to tunneling via the TLS record layer. 

   The client's first tunneled EAP packet within phase 2 will contain 
   the EAP-Response/Identity. The client places the actual username in 
   this packet; the privacy of the user's identity is now guaranteed by 
   the TLS encryption. This username must be a Network Access 
   Identifier (NAI) [7]; that is, it must be in the following format: 

      username@realm 

   The @realm portion is optional, and is used to allow the TTLS server 
   to forward the EAP packet to the appropriate AAA/H.  

   Note that the client has two opportunities to specify realms. The 
   first, in the initial EAP-Response/Identity packet, indicates the 
   realm of the TTLS server. The second, in the tunneled 
   authentication, indicates the realm of the client's home network. 
   Thus, the access point need only know how to route to the realm of 
   the TTLS server; the TTLS server is assumed to know how to route to 
   the client's home realm. This serial routing architecture is 
   anticipated to be useful in roaming environments, allowing access 
   points or AAA proxies behind access points to be configured only 
   with a small number of realms. 

   Upon receipt of the tunneled EAP-Response/Identity, the TTLS server 
   forwards it to the AAA/H in a RADIUS Access-Request.  

   The AAA/H may immediately respond with an Access-Reject, in which 
   case the TTLS server completes the negotiation by sending an EAP-
   Failure to the access point. This could occur if the AAA/H does not 
   recognize the user's identity, or if it does not support EAP. 

   If the AAA/H does recognize the user's identity and does support 
   EAP, it responds with an Access-Challenge containing an EAP-Request, 
   with the Type and Type-Data fields set according to the EAP protocol 
   with which the AAA/H wishes to authenticate the client; for example 
   MD-Challenge, OTP or Generic Token Card. 

   The EAP authentication between client and AAA/H proceeds normally, 
   as described in [2], with the TTLS server acting as a passthrough 
   device. Each EAP-Request sent by the AAA/H in an Access-Challenge is 
   tunneled by the TTLS server to the client, and each EAP-Response 



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


   tunneled by the client is decrypted and forwarded by the TTLS server 
   to the AAA/H in an Access-Request. 

   This process continues until the AAA/H issues an Access-Accept or 
   Access-Reject, at which point the TTLS server completes the 
   negotiation by sending an EAP-Success or EAP-Failure to the access 
   point using the AAA carrier protocol. 

10.2.2 CHAP 

   The CHAP algorithm is described in [5]; RADIUS attribute formats are 
   described in [6]. 

   Both client and TTLS server generate 17 octets of challenge 
   material, using the constant string "ttls challenge" as described 
   above. These octets are used as follows: 

      CHAP-Challenge    [16 octets] 
      CHAP Identifier   [1 octet] 

   The client tunnels User-Name, CHAP-Challenge and CHAP-Password AVPs 
   to the TTLS server. The CHAP-Challenge value is taken from the 
   challenge material. The CHAP-Password consists of CHAP Identifier, 
   taken from the challenge material; and CHAP response, computed 
   according to the CHAP algorithm. 

   Upon receipt of these AVPs from the client, the TTLS server must 
   verify that the value of the CHAP-Challenge AVP and the value of the 
   CHAP Identifier in the CHAP-Password AVP are equal to the values 
   generated as challenge material. If either item does not match 
   exactly, the TTLS server must reject the client. Otherwise, it 
   forwards the AVPs to the AAA/H in an Access-Request.  

   The AAA/H will respond with an Access-Accept or Access-Reject. The 
   TTLS server will then issue an EAP-Success or EAP-Failure to the 
   access point. 

10.2.3 MS-CHAP 

   The MS-CHAP algorithm is described in [10]; RADIUS attribute formats 
   are described in [12]. 

   Both client and TTLS server generate 9 octets of challenge material, 
   using the constant string "ttls challenge" as described above. These 
   octets are used as follows: 

      MS-CHAP-Challenge [8 octets] 
      Ident         [1 octet] 

   The client tunnels User-Name, MS-CHAP-Challenge and MS-CHAP-Response 
   AVPs to the TTLS server. The MS-CHAP-Challenge value is taken from 



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


   the challenge material. The MS-CHAP-Response consists of Ident, 
   taken from the challenge material; Flags, set according the client 
   preferences; and LM-Response and NT-Response, computed according to 
   the MS-CHAP algorithm. 

   Upon receipt of these AVPs from the client, the TTLS server must 
   verify that the value of the MS-CHAP-Challenge AVP and the value of 
   the Ident in the client's MS-CHAP-Response AVP are equal to the 
   values generated as challenge material. If either item does not 
   match exactly, the TTLS server must reject the client. Otherwise, it 
   forwards the AVPs to the AAA/H in an Access-Request.  

   The AAA/H will respond with an Access-Accept or Access-Reject. The 
   TTLS server will then issue an EAP-Success or EAP-Failure to the 
   access point. 

10.2.4 MS-CHAP-V2 

   The MS-CHAP-V2 algorithm is described in [11]; RADIUS attribute 
   formats are described in [12]. 

   Both client and TTLS server generate 17 octets of challenge 
   material, using the constant string "ttls challenge" as described 
   above. These octets are used as follows: 

      MS-CHAP-Challenge [16 octets] 
      Ident         [1 octet] 

   The client tunnels User-Name, MS-CHAP-Challenge and MS-CHAP2-
   Response AVPs to the TTLS server. The MS-CHAP-Challenge value is 
   taken from the challenge material. The MS-CHAP2-Response consists of 
   Ident, taken from the challenge material; Flags, set to 0; Peer-
   Challenge, set to a random value; and Response, computed according 
   to the MS-CHAP-V2 algorithm. 

   Upon receipt of these AVPs from the client, the TTLS server must 
   verify that the value of the MS-CHAP-Challenge AVP and the value of 
   the Ident in the client's MS-CHAP2-Response AVP are equal to the 
   values generated as challenge material. If either item does not 
   match exactly, the TTLS server must reject the client. Otherwise, it 
   forwards the AVPs to the AAA/H in an Access-Request.  

   If the authentication is successful, the AAA/H will respond with an 
   Access-Accept containing the MS-CHAP2-Success attribute. This 
   attribute contains a 42-octet string that authenticates the AAA/H to 
   the client based on the Peer-Challenge. The TTLS server tunnels this 
   AVP to the client. Note that the authentication is not yet complete; 
   the client must still accept the authentication response of the 
   AAA/H.