pppext-eap-sim-12.txt

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

   pseudonym username. 

   (3) Re-authentication usernames. For example, 
   [e-mail] might be a valid re-authentication 
   identity. In this case, 53953754 is the re-authentication username. 

   The first two types of identities 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 identity is used on full authentication. The re-
   authentication exchange is specified in Section 4.3. 

Username Decoration 

   In some environments, the peer may need to decorate the identity by 
   prepending or appending the username with a string, in order to 
   indicate supplementary AAA routing information in addition to the 
   NAI realm. (The usage of a NAI realm portion is not considered to be 
   decoration.) Username decoration is out of the scope of this 
   document. However, it should be noted that username decoration might 
   prevent the server from recognizing a valid username. Hence, 
   although the peer MAY use username decoration in the identities the 
 
Haverinen and Salowey  Expires: 27 April, 2004              [Page 10] 


Internet Draft          EAP SIM Authentication        27 October, 2003 


   peer includes in EAP-Response/Identity, and the EAP server MAY 
   accept a decorated peer username in this message, the peer or the 
   EAP server MUST NOT decorate any other peer identities that are used 
   in various EAP/SIM attributes. Only the identity used in EAP-
   Response/Identity may be decorated. 

NAI Realm Portion 

   The peer MAY include a realm portion in the peer identity, as per 
   the NAI format. The use of a realm portion is not mandatory. 

   If a realm is used, the realm MAY be chosen by the operator and it 
   MAY a configurable parameter in the EAP/SIM peer implementation. In 
   this case, the peer 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. When the peer is using a pseudonym username 
   instead of the permanent username, the peer selects the realm name 
   portion similarly as it select the realm portion when using the 
   permanent username. 

   If no configured realm name is available, the peer MAY derive the 
   realm name from the MCC and MNC portions of the IMSI. A recommended 
   way to derive the realm from the IMSI using the realm 
   3gppnetwork.org will be specified in [Draft 3GPP TS 23.234]. 
   Alternatively, the realm name may be obtained by concatenating 
   "mnc", the MNC digits of IMSI, ".mcc", the MCC digits of IMSI and 
   ".owlan.org". For example, if the IMSI is 123456789098765, and the 
   MNC is three digits long, then the derived realm name is 
   "mnc456.mcc123.owlan.org". 

   The IMSI is a string of digits without any explicit structure, so 
   the peer may not be able to determine the length of the MNC portion. 
   If the peer is not able to determine whether the MNC is two or three 
   digits long, the peer MAY use a 3-digit MNC. If the correct length 
   of the MNC is two, then the MNC used in the realm name includes the 
   first digit of MSIN. Hence, when configuring AAA networks for 
   operators that have 2-digit MNC's, the network SHOULD also be 
   prepared for realm names with incorrect 3-digit MNC's. 

Format of the Permanent Username 

   The non-pseudonym permanent username SHOULD be derived from the 
   IMSI. In this case, the permanent username MUST be of the format "1" 
   | IMSI, where the character "|" denotes concatenation. 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 [GSM 03.03]. 


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


Internet Draft          EAP SIM Authentication        27 October, 2003 


   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 out of the scope of this 
   document. In this case, the peer implementation MUST NOT prepend any 
   leading characters to the username. 

Generating Pseudonyms and Re-authentication Identities by the Server 

   Pseudonym usernames and re-authentication identities are generated 
   by the EAP server. The EAP server produces pseudonym usernames and 
   re-authentication identities in an implementation-dependent manner. 
   Only the EAP server needs to be able to map the pseudonym username 
   to the permanent identity, or to recognize a re-authentication 
   identity. Regardless of construction method, the pseudonym username 
   MUST conform to the grammar specified for the username portion of an 
   NAI. The re-authentication identity also MUST conform to the NAI 
   grammar. The EAP servers that the subscribers of an operator can use 
   MUST ensure that the pseudonym usernames and the username portions 
   used in re-authentication identities they generate are unique. 

   In any case, it is necessary that permanent usernames, pseudonym 
   usernames and re-authentication usernames are separate and 
   recognizable from each other. It is also desirable that EAP SIM and 
   EAP AKA user names be recognizable from each other as an aid for the 
   server to which method to offer. 

   In general, it is the task of the EAP server and the policies of its 
   administrator to ensure sufficient separation in the usernames. 
   Pseudonym usernames and re-authentication usernames are both 
   produced and used by the EAP server. The EAP server MUST compose 
   pseudonym usernames and re-authentication usernames so that it can 
   recognize if a NAI username is an EAP SIM pseudonym username or an 
   EAP SIM re-authentication username. For instance, when the usernames 
   have been derived from the IMSI, the server could use different 
   leading characters in the pseudonym usernames and re-authentication 
   usernames (e.g. the pseudonym could begin with a leading "3" 
   character). When mapping a re-authentication identity to a permanent 
   identity, the server SHOULD only examine the username portion of the 
   re-authentication identity and ignore the realm portion of the 
   identity. 

   Because the peer may fail to save a pseudonym username sent to in an 
   EAP-Request/SIM/Challenge, for example due to malfunction, the EAP 
   server SHOULD maintain at least one old pseudonym username in 
   addition to the most recent pseudonym username. 



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


Internet Draft          EAP SIM Authentication        27 October, 2003 


Transmitting Pseudonyms and Re-authentication Identities to the Peer 

   The server transmits pseudonym usernames and re-authentication 
   identities to the peer in cipher, using the AT_ENCR_DATA attribute. 

   The EAP-Request/SIM/Challenge message MAY include an encrypted 
   pseudonym username and/or an encrypted re-authentication identity in 
   the value field of the AT_ENCR_DATA attribute. Because identity 
   privacy support and re-authentication are optional to implement, the 
   peer MAY ignore the AT_ENCR_DATA attribute and always use the 
   permanent identity. On re-authentication (discussed in Section 4.3), 
   the server MAY include a new encrypted re-authentication identity in 
   the EAP-Request/SIM/Re-authentication message. 

   On receipt of the EAP-Request/SIM/Challenge, the peer MAY decrypt 
   the encrypted data in AT_ENCR_DATA and if a pseudonym username is 
   included, the peer may use the obtained pseudonym username on the 
   next full authentication. If a re-authentication identity is 
   included, then the peer MAY save it and other re-authentication 
   state information, as discussed in Section 4.3, for the next re-
   authentication.  

   If the peer does not receive a new pseudonym username in the EAP-
   Request/SIM/Challenge message, the peer MAY use an old pseudonym 
   username instead of the permanent username on next full 
   authentication. The username portions of re-authentication 
   identities are one-time usernames, which the peer MUST NOT re-use. 

Usage of the Pseudonym by the Peer 

   When the optional identity privacy support is used on full 
   authentication, the peer MAY use the pseudonym username received as 
   part of the previous full authentication sequence as the username 
   portion of the NAI. The peer MUST NOT modify the pseudonym username 
   received in AT_NEXT_PSEUDONYM. However, as discussed above, the peer 
   MAY need to decorate the username in some environments by appending 
   or prepending the username with a string that indicates 
   supplementary AAA routing information. 

   When using a pseudonym username in an environment where a realm 
   portion is used, the peer concatenates the received pseudonym 
   username with the "@" character and a NAI realm portion. The 
   selection of the NAI realm is discussed above.  

Usage of the Re-authentication Identity by the Peer 

   On re-authentication, the peer uses the re-authentication identity, 
   received as part of the previous authentication sequence. A new re-
   authentication identity may be delivered as part of both full 
   authentication and re-authentication. The peer MUST NOT modify the 
   username part of the re-authentication identity received in 
   AT_NEXT_REAUTH_ID, except in cases when username decoration is 
   required. Even in these cases, the "root" re-authentication username 
 
Haverinen and Salowey  Expires: 27 April, 2004              [Page 13] 


Internet Draft          EAP SIM Authentication        27 October, 2003 


   must not be modified, but it may be appended or prepended with 
   another string. 

4.2.2 Communicating the Peer Identity to the Server 

General 

   The peer identity MAY be communicated to the server with the EAP-
   Response/Identity message. This message MAY contain the permanent 
   identity, a pseudonym identity, or a re-authentication identity. If 
   the peer uses the permanent identity or a pseudonym identity, which 
   the server is able to map to the permanent identity, then the 
   authentication proceeds as discussed in the overview of Section 3. 
   If the peer uses a re-authentication identity, and the server 
   recognized the identity and agrees on using re-authentication, then 
   a re-authentication exchange is performed, as described in 4.3. 

   The peer identity can also be transmitted from the peer to the 
   server using EAP/SIM messages instead of EAP-Response/Identity. In 
   this case, the server includes an identity requesting attribute 
   (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the 
   EAP-Request/SIM/Start message, and the peer includes the AT_IDENTITY 
   attribute, which contains the peer's identity, in the EAP-
   Response/SIM/Start message. The AT_ANY_ID_REQ attribute is a general 
   identity requesting attribute, which the server uses if it does not 
   specify which kind of an identity the peer should return in 
   AT_IDENTITY. The server uses the AT_FULLAUTH_ID_REQ attribute to 
   request either the permanent identity or a pseudonym identity. The 
   server uses the AT_PERMANENT_ID_REQ attribute to request the peer to 
   send its permanent identity. 

   The identity format in the AT_IDENTITY attribute is the same as in 
   the EAP-Response/Identity packet (except that identity decoration is 
   not allowed). The AT_IDENTITY attribute contains a permanent 
   identity, a pseudonym identity or a re-authentication identity. 

   Obtaining the subscriber identity via EAP/SIM messages is useful if 
   the server does not have any EAP/SIM peer identity at the beginning 
   of the EAP/SIM exchange or does not recognize the identity the peer 
   used in EAP-Response/Identity.  This may happen if, for example, the 
   EAP-Response/Identity has been issued by some EAP method other than 
   EAP/SIM or if intermediate entities or software layers in the peer 
   have modified the identity string in the EAP-Response/Identity 
   packet. Also, some EAP layer implementations may cache the identity 
   string from the first EAP authentication and do not obtain a new 
   identity string from the EAP method implementation on subsequent 
   authentication exchanges. 

   As the identity string is used in key derivation, any of these cases 
   will result in failed authentication unless the EAP server uses 
   EAP/SIM attributes to obtain an unmodified copy of the identity 
   string.  Therefore, unless the EAP server can be certain that no 
   intermediate element or software layer has modified the EAP-
 
Haverinen and Salowey  Expires: 27 April, 2004              [Page 14] 


Internet Draft          EAP SIM Authentication        27 October, 2003 


   Response/Identity packet, the EAP server SHOULD always use the 
   EAP/SIM attributes to obtain the identity, even if the identity 
   received in EAP-Response/Identity was valid. 

   Please note that the EAP/SIM peer and the EAP/SIM server only 
   process the AT_IDENTITY attribute and entities that only pass 
   through EAP packets do not process this attribute. Hence, if the EAP 
   server is not co-located in the authenticator, then the 
   authenticator and other intermediate AAA elements (such as possible 
   AAA proxy servers) will continue to refer to the peer with the 
   original identity from the EAP-Response/Identity packet regardless 
   of whether the AT_IDENTITY attribute is used in EAP/SIM to transmit 
   another identity. 

Choice of Identity for the EAP-Response/Identity 

   If EAP/SIM peer is started upon receiving an EAP-Request/Identity 
   message, then the peer performs the following steps.