draft-haverinen-pppext-eap-sim-11.txt

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

   Figure 1 shows an overview of the EAP/SIM full authentication 
   procedure. This version of EAP/SIM exchange uses three roundtrips to 
   authenticate the user and generate keying material. In this 
   document, the term EAP Server refers to the network element that 
   terminates the EAP protocol. The Authenticator typically 
   communicates with the user's EAP server using an AAA protocol. The 
   AAA communications is not shown in the figure. 

   The first EAP Request issued by the Authenticator is EAP-
   Request/Identity. The client's response includes either the user's 
   International Mobile Subscriber Identity (IMSI) or a temporary 
   identity (pseudonym), as specified in Section 5.3. 

   Following the client's EAP-Response/Identity packet, the client 
   receives EAP Requests of type 18 (SIM) from the Authenticator and 
   sends the corresponding EAP Responses. The EAP packets that are of 
   the Type SIM also have a Subtype field. On full authentication, the 
   first EAP-Request/SIM packet is of the Subtype 10 (Start). EAP SIM 
   packets encapsulate parameters in attributes, encoded in a Type, 
   Length, Value format. The packet format and the use of attributes 
   are specified in Section 7. 

   The EAP-Request/SIM/Start packet contains the list of EAP/SIM 
   version supported by the Authenticator in the AT_VERSION_LIST 
   attribute. This packet may also include attributes for requesting 
   the subscriber identity, as specified in Section 5.3. 

  
Haverinen and Salowey   Expires in six months                [Page 5] 


Internet Draft          EAP SIM Authentication               June 2003 
 
 
   The client responds to EAP-Request/SIM/Start with the EAP-
   Response/SIM/Start packet, which includes the AT_NONCE_MT attribute 
   that contains a random number NONCE_MT, chosen by the client, and 
   the AT_SELECTED_VERSION attribute that contains the version number 
   selected by the client. The version negotiation is protected by 
   including the version list and the selected version in the 
   calculation of keying material (Section 17). The client MUST NOT 
   reuse the NONCE_MT value from previous sessions but the client MUST 
   choose it freshly for each EAP/SIM authentication exchange. The 
   client SHOULD use a good source of randomness to generate NONCE_MT. 

   In this document, we assume that the EAP server is implemented on 
   the AAA server and has an interface to the GSM network, so it 
   operates as a gateway between the Internet AAA network and the GSM 
   authentication infrastructure. After receiving the EAP 
   Response/SIM/Start, the EAP server obtains n GSM triplets from the 
   user's home operator's Authentication Centre (AuC) on the GSM 
   network, where n = 1, n = 2 or n = 3. From the triplets, the EAP 
   server derives the keying material, as specified in Section 17.  

   The next EAP Request the EAP Server issues is of the type SIM and 
   subtype Challenge (11). It contains the RAND challenges and a 
   message authentication code attribute AT_MAC to cover the 
   challenges.  

   The EAP server MUST NOT reuse the RAND values (triplets) from 
   previous successful sessions but the server MUST obtain fresh RANDs 
   for each EAP/SIM authentication exchange. However, if client 
   authentication fails, the server MAY reuse the RANDs in the next 
   authentication attempt. 

   On receipt of the EAP-Request/SIM/Challenge message, the client runs 
   the GSM authentication algorithm and calculates a copy of the 
   message authentication code. The client then verifies that the 
   calculated MAC equals the received MAC. If the MAC's do not match, 
   then the client silently ignores the EAP packet and does not send 
   any authentication values to the network. Eventually, if another 
   EAP-Request/SIM/Challenge packet with a valid AT_MAC is not 
   received, the connection establishment will time out. 

   Since the RAND's given to a client are accompanied with the message 
   authentication code AT_MAC, and since the client's NONCE_MT value 
   contributes to AT_MAC, the client is able to verify that the EAP SIM 
   message is fresh (not a replay) and that the sender possesses valid 
   GSM triplets for the subscriber.  

   If all checks out, the client responds with the EAP-
   Response/SIM/Challenge, containing the AT_MAC attribute that covers 
   the client's SRES response values (Section 12). The EAP server 
   verifies that the MAC is correct and sends the EAP-Success packet, 
   indicating that the authentication was successful. The EAP server 
   may also include derived keying material in the message it sends to 
   the Authenticator. 
  
Haverinen and Salowey   Expires in six months                [Page 6] 


Internet Draft          EAP SIM Authentication               June 2003 
 
 
   The EAP-Request/SIM/Challenge, EAP-Response/SIM/Challenge, or the 
   packets used on re-authentication may optionally include the 
   AT_CHECKCODE attribute, which enables the protocol peers to ensure 
   the integrity of the EAP-Request/SIM/Start and EAP-
   Response/SIM/Start packets. AT_CHECKCODE is specified in Section 
   8.2. 

     Client                                               Authenticator 
       |                                                          | 
       |                               EAP-Request/Identity       | 
       |<---------------------------------------------------------| 
       |                                                          | 
       | EAP-Response/Identity                                    | 
       |--------------------------------------------------------->| 
       |                                                          | 
       |                        EAP-Request/SIM/Start             | 
       |                        (AT_VERSION_LIST)                 | 
       |<---------------------------------------------------------| 
       |                                                          | 
       | EAP-Response/SIM/Start                                   | 
       | (AT_NONCE_MT, AT_SELECTED_VERSION)                       | 
       |--------------------------------------------------------->| 
       |                                                          | 
       |               EAP-Request/SIM/Challenge                  | 
       |               (AT_RAND, AT_MAC)                          | 
       |<---------------------------------------------------------| 
       |                                                          | 
   +-------------------------------------+                        | 
   | Client runs GSM algorithms,         |                        | 
   | verifies AT_MAC and derives         |                        | 
   | session keys                        |                        | 
   +-------------------------------------+                        | 
       |                                                          | 
       | EAP-Response/SIM/Challenge                               | 
       | (AT_MAC)                                                 | 
       |--------------------------------------------------------->| 
       |                                                          | 
       |                                                          | 
       |                                             EAP-Success  | 
       |<---------------------------------------------------------| 
       |                                                          | 

   Figure 1 EAP/SIM full authentication procedure 

   EAP SIM also includes a separate re-authentication procedure, which 
   does not make use of the A3/A8 algorithms or the GSM infrastructure. 
   Re-authentication is based on keys derived on full authentication. 

4. Version Negotiation 

   EAP/SIM includes version negotiation so as to allow future 
   developments in the protocol. The version negotiation is performed 
   on full authentication and it uses two attributes, AT_VERSION_LIST 
  
Haverinen and Salowey   Expires in six months                [Page 7] 


Internet Draft          EAP SIM Authentication               June 2003 
 
 
   (Section 9), which the server includes in EAP-Request/SIM/Start, and 
   AT_SELECTED_VERSION (Section 10), which the client includes in EAP-
   Response/SIM/Start. 

   AT_VERSION_LIST includes the EAP/SIM versions supported by the 
   server. The server MUST only include versions that it implements and 
   that are allowed in its security policy. The versions are listed in 
   the order of preference, most preferred versions first. At least one 
   version number MUST be included. The version number for the protocol 
   described in this document is one (0x0001). 

   If AT_VERSION_LIST does not include a version that is implemented by 
   the client and allowed in the client's security policy, then the 
   client MUST silently ignore the EAP-Request/SIM/Start packet. If a 
   suitable version is included, then the client includes the 
   AT_SELECTED_VERSION attribute, containing the selected version, in 
   the EAP-Response/SIM/Start packet. The client MUST only indicate a 
   version that is included in AT_VERSION_LIST. If several versions are 
   acceptable, then the client SHOULD choose the version that occurs 
   first in the version list. 

   The version number list of AT_VERSION_LIST and the selected version 
   of AT_SELECTED_VERSION are included in the key derivation procedure 
   (Section 17). If an attacker modifies either one of these 
   attributes, then the client and the server will derive different 
   keying material. Because K_aut keys are different, the server and 
   client will calculate different AT_MAC values. Hence, the client 
   will detect that AT_MAC is incorrect and discard the EAP-
   Request/SIM/Challenge packet. The authentication procedure will time 
   out. 

5. Identity Management 

5.1. User identity in EAP-Response/Identity 

   In the beginning of EAP authentication, the Authenticator issues the 
   EAP-Request/Identity packet to the client. The client responds with 
   EAP-Response/Identity, which contains the user's identity. The 
   formats of these packets are specified in [1]. 

   GSM subscribers are identified with the International Mobile 
   Subscriber Identity (IMSI) [4]. The IMSI is composed of a three 
   digit Mobile Country Code (MCC), a two or three digit Mobile Network 
   Code (MNC) and a not more than 10 digit Mobile Subscriber 
   Identification Number (MSIN). In other words, the IMSI is a string 
   of not more than 15 digits. MCC and MNC uniquely identify the GSM 
   operator. 

   Internet AAA protocols identify users with the Network Access 
   Identifier (NAI) [5]. When used in a roaming environment, the NAI is 
   composed of a username and a realm, separated with "@" 
   (username@realm). The username portion identifies the subscriber 
   within the realm. The AAA nodes use the realm portion of the NAI to 
  
Haverinen and Salowey   Expires in six months                [Page 8] 


Internet Draft          EAP SIM Authentication               June 2003 
 
 
   route AAA requests to the correct AAA server. The realm name used in 
   this protocol MAY be chosen by the operator and it MAY a 
   configurable parameter in the EAP/SIM client implementation. In this 
   case, the client is typically configured with the NAI realm of the 
   home operator. Operators MAY reserve a specific realm name for 
   EAP/SIM users. This convention makes it easy to recognize that the 
   NAI identifies a GSM subscriber. Such reserved NAI realm may be 
   useful as a hint as to the first authentication method to use during 
   method negotiation. 

   There are three types of NAI username portions in EAP/SIM: non-
   pseudonym permanent usernames, pseudonym usernames and re-
   authentication usernames. The first two are only used on full 
   authentication and the last one only on re-authentication. When the 
   optional identity privacy support is not used, the non-pseudonym 
   permanent username is used.  

   The non-pseudonym permanent username MAY be derived from the IMSI. 
   In this case, the permanent username MUST be of the format "1imsi". 
   In other words, the first character of the username is the digit one 
   (ASCII value 0x31), followed by the IMSI. The IMSI is an ASCII 
   string that consists of not more than 15 decimal digits (ASCII 
   values between 0x30 and 0x39) as specified in [4]. 

   The EAP server MAY use the leading "1" as a hint to try EAP/SIM as 
   the first authentication method during method negotiation, rather 
   than for example EAP/AKA. The EAP/SIM server MAY propose EAP/SIM 
   even if the leading character was not "1". 

   Alternatively, an implementation MAY choose a permanent username 
   that is not based on the IMSI. In this case the selection of the 
   username, its format, and its processing is a local matter. In this 
   case, the client implementation MUST NOT prepend any leading 
   characters to the username. 

   When the optional identity privacy support is used on full 
   authentication, the client MAY use the pseudonym received as part of 
   the previous full authentication sequence as the username portion of 
   the NAI, as specified in Section 5.3. The client MUST NOT modify the 
   pseudonym received in AT_NEXT_PSEUDONYM. For example, the client 
   MUST NOT prepend any leading characters in the pseudonym. 

   On re-authentication, the client uses the re-authentication identity 
   received as part of the previous authentication sequence as the NAI. 
   A new re-authentication identity may be delivered as part of both 
   full authentication and re-authentication. The client MUST NOT 
   modify the re-authentication identity received in AT_NEXT_REAUTH_ID. 
   For example, the client MUST NOT prepend any leading characters in 
   the re-authentication identity. 

   If no configured realm name is available, the client MAY derive the 
   realm name from the MCC and MNC portions of the IMSI. A recommended 
   way to derive the realm from the IMSI will be specified in [6].