pppext-eap-sim-12.txt

使用最广泛的radius的linux的源码

      A pseudonym identity of the peer, including an NAI realm portion 
      in environments where a real is used. Used on full authentication 
      only. 

   Pseudonym Username 

      The username portion of pseudonym identity, ie. not including any 
      realm portions. 

 
Haverinen and Salowey  Expires: 27 April, 2004               [Page 5] 


Internet Draft          EAP SIM Authentication        27 October, 2003 


   Re-authentication Identity 

      A re-authentication identity of the peer, including an NAI realm 
      portion in environments where a real is used. Used on re-
      authentication only. 

   Re-authentication Username 

      The username portion of re-authentication identity, ie. not 
      including any realm portions. 

   SIM 

      Subscriber Identity Module. The SIM is an application 
      traditionally resident on smart cards distributed by GSM 
      operators. 

3. Overview 

   Figure 1 shows an overview of the EAP/SIM full authentication 
   procedure. The authenticator typically communicates with an EAP 
   server that is located on a backend authentication server using an 
   AAA protocol. The AAA communications is not shown in the figure. 

   The first EAP Request issued by the network is EAP-Request/Identity. 
   On full authentication, the peer's response includes either the 
   user's International Mobile Subscriber Identity (IMSI) or a 
   temporary identity (pseudonym) if identity privacy is in effect, as 
   specified in Section 4.2. 

   Following the peer's EAP-Response/Identity packet, the peer receives 
   EAP Requests of type 18 (SIM) from the EAP server 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 5. 

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

   The peer 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 peer, and the 
   AT_SELECTED_VERSION attribute that contains the version number 
   selected by the peer. The version negotiation is protected by 
   including the version list and the selected version in the 
   calculation of keying material (Section 4.6).  


 
Haverinen and Salowey  Expires: 27 April, 2004               [Page 6] 


Internet Draft          EAP SIM Authentication        27 October, 2003 


   After receiving the EAP Response/SIM/Start, the EAP server obtains n 
   GSM triplets for use in authenticating the subscriber, where n = 2 
   or n = 3. From the triplets, the EAP server derives the keying 
   material, as specified in Section 4.6. The triplets may be obtained 
   by contacting an Authentication Centre (AuC) on the GSM network; per 
   GSM specifications, between 1 and 5 triplets may be obtained at a 
   time. 

   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.  

   On receipt of the EAP-Request/SIM/Challenge message, the peer runs 
   the GSM authentication algorithm and calculates a copy of the 
   message authentication code. The peer then verifies that the 
   calculated MAC equals the received MAC. If the MAC's do not match, 
   then the peer sends the EAP-Response/SIM/Client-Error packet and the 
   authentication exchange terminates. 

   Since the RAND's given to a peer are accompanied with the message 
   authentication code AT_MAC, and since the peer's NONCE_MT value 
   contributes to AT_MAC, the peer 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 peer responds with the EAP-
   Response/SIM/Challenge, containing the AT_MAC attribute that covers 
   the peer's SRES response values (Section 6.4). 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: 27 April, 2004               [Page 7] 


Internet Draft          EAP SIM Authentication        27 October, 2003 


     Peer                                               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)                          | 
       |<---------------------------------------------------------| 
       |                                                          | 
   +-------------------------------------+                        | 
   | Peer 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. 
   If the peer has maintained state information for re-authentication 
   and wants to use re-authentication, then the peer indicates this by 
   using a specific re-authentication identity instead of the permanent 
   identity or a pseudonym identity. The re-authentication procedure is 
   described in Section 4.3. 

4. Operation 

4.1. 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: 27 April, 2004               [Page 8] 


Internet Draft          EAP SIM Authentication        27 October, 2003 


   which the server always includes in EAP-Request/SIM/Start, and 
   AT_SELECTED_VERSION, which the peer includes in EAP-
   Response/SIM/Start on full authentication. 

   AT_VERSION_LIST includes the EAP/SIM versions supported by the 
   server. If AT_VERSION_LIST does not include a version that is 
   implemented by the peer and allowed in the peer's security policy, 
   then the peer MUST send the EAP-Response/SIM/Client-Error packet 
   (Section 6.7) to the server with the error code "unsupported 
   version". If a suitable version is included, then the peer includes 
   the AT_SELECTED_VERSION attribute, containing the selected version, 
   in the EAP-Response/SIM/Start packet. The peer MUST only indicate a 
   version that is included in AT_VERSION_LIST. If several versions are 
   acceptable, then the peer 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 4.6). If an attacker modifies either one of these 
   attributes, then the peer and the server derive different keying 
   material. Because K_aut keys are different, the server and peer 
   calculate different AT_MAC values. Hence, the peer detects that 
   AT_MAC included in EAP-Request/SIM/Challenge is incorrect and sends 
   the EAP-Response/SIM/Client-Error packet. The authentication 
   procedure terminates. 

4.2. Identity Management 

4.2.1 Format, Generation and Usage of Peer Identities 

General 

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

   GSM subscribers are identified with the International Mobile 
   Subscriber Identity (IMSI) [GSM 03.03]. 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 and  help identify the AuC from which the authentication 
   vectors need to be retrieved for this subscriber. 

   Internet AAA protocols identify users with the Network Access 
   Identifier (NAI) [RFC 2486]. 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. 

 
Haverinen and Salowey  Expires: 27 April, 2004               [Page 9] 


Internet Draft          EAP SIM Authentication        27 October, 2003 


   This section specifies the peer identity format used in EAP/SIM. In 
   this document, the term identity or peer identity refers to the 
   whole identity string that is used to identify the peer. The peer 
   identity may include a realm portion. "Username" refers to the 
   portion of the peer identity that identifies the user, i.e. the 
   username does not include the realm portion. 

Identity Privacy Support 

   EAP/SIM includes optional identity privacy (anonymity) support that 
   can be used to hide the cleartext permanent identity and thereby to 
   make the subscriber's EAP exchanges untraceable to eavesdroppers. 
   Because the permanent identity never changes, revealing it would 
   help observers to track the user. The permanent identity is usually 
   based on the IMSI, which may further help the tracking, because the 
   same identifier may used in other contexts as well. Identity privacy 
   is based on temporary identities, or pseudonyms, which are 
   equivalent to but separate from the Temporary Mobile Subscriber 
   Identities (TMSI) that are used on cellular networks. Please see 
   Section 9.1 for security considerations regarding identity privacy. 

Username Types in EAP/SIM identities 

   There are three types of usernames in EAP/SIM peer identities:  

   (1) Permanent usernames. For example, 
   [e-mail] might be a valid permanent identity. 
   In this example, 1123456789098765 is the permanent username.  

   (2) Pseudonym usernames. For example, [e-mail] might 
   be a valid pseudonym identity. In this example, 3s7ah6n9q is the