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

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

   the AT_MAC is invalid, then the client MUST silently discard the EAP 
   packet. If the AT_MAC attribute is valid, then the client MAY 
   decrypt the encrypted data in AT_ENCR_DATA and use the obtained 
   pseudonym on the next full authentication.  

   If the client does not receive a new pseudonym in the EAP-
   Request/SIM/Challenge message, the client MAY use an old pseudonym 
   instead of the permanent identity on next full authentication. 

   The EAP server produces pseudonyms in an implementation-dependent 
   manner. Please see [7] for examples on how to produce pseudonyms. 
   Only the EAP server needs to be able to map the pseudonym to the 
   permanent identity. Regardless of construction method, the pseudonym 
   MUST conform to the grammar specified for the username portion of an 
   NAI. 

   In any case, it is necessary that permanent usernames and pseudonyms 
   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. 
   Pseudonyms, for instance, are both produced and used by the EAP 
   server. The EAP server MUST compose pseudonyms so that it can 
   recognize if a NAI username is an EAP SIM pseudonym. For instance, 
   when the usernames have been derived from the IMSI, the pseudonym 
   could begin with a leading "3" character. 

   On the next full authentication with the EAP server, the client MAY 
   transmit the received pseudonym in the first EAP-Response/Identity 
   packet. The client concatenates the received pseudonym with the "@" 
  
Haverinen and Salowey   Expires in six months               [Page 14] 


Internet Draft          EAP SIM Authentication               June 2003 
 
 
   character and the NAI realm portion. The client selects the realm 
   name portion similarly as it select the realm name portion when 
   using the permanent identity. If the EAP server successfully decodes 
   the pseudonym received in the EAP-Response/Identity packet to a 
   known client permanent identity, the authentication proceeds with 
   the EAP-Request/SIM/Start message as usual. 

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

   If the EAP server requests the client to include its identity in the 
   EAP-Response/SIM/Start packet, as specified in Section 5.2, the 
   client MAY transmit the received pseudonym in the AT_IDENTITY 
   attribute. If the EAP server successfully decodes the pseudonym to a 
   known identity, then the authentication proceeds with the EAP-
   Request/SIM/Challenge packet as usual. 

   If the EAP server fails to decode the pseudonym to a known identity, 
   then the EAP server requests the permanent identity (non-pseudonym 
   identity) by including the AT_PERMANENT_ID_REQ attribute (Section 9) 
   in the EAP-Request/SIM/Start message. Because another EAP server may 
   have generated the pseudonym using a different coding scheme, the 
   EAP server SHOULD use AT_PERMANENT_ID_REQ also in cases when it does 
   not recognize the format of the client identity. 

   The EAP server issues the EAP-Request/SIM/Start message also in the 
   case when it received the undecodable pseudonym in AT_IDENTITY 
   included the EAP-Response/SIM/Start packet. In this case, an extra 
   EAP/SIM/Start round trip is required. 

   A received AT_PERMANENT_ID_REQ does not necessarily originate from 
   the valid network, but an active attacker may transmit an EAP-
   Request/SIM/Start packet with an AT_PERMANENT_ID_REQ attribute to 
   the client, in an effort to find out the true identity of the user. 
   The client MAY silently discard any EAP-Request/SIM/Start messages 
   that include AT_PERMANENT_ID_REQ for a while in order to wait for an 
   EAP-Request/SIM/Start packet without AT_PERMANENT_ID_REQ. If the 
   valid network sent the message, the message will be retransmitted, 
   so the client can reconsider replying to the message when it 
   receives a retransmission. 

   Basically, there are two different policies that the client can 
   employ with regard to AT_PERMANENT_ID_REQ. A "conservative" client 
   assumes that the network is able to maintain pseudonyms robustly. 
   Therefore, if a conservative client has a pseudonym, the client 
   silently ignores the EAP packet with AT_PERMANENT_ID_REQ, because 
   the client believes that the valid network is able to decode the 
   pseudonym. (Alternatively, the conservative client may respond to 
   AT_PERMANENT_ID_REQ in certain circumstances, for example if the 
   pseudonym was received a long time ago.) The benefit of this policy 
   is that it protects the client against active attacks on anonymity. 
  
Haverinen and Salowey   Expires in six months               [Page 15] 


Internet Draft          EAP SIM Authentication               June 2003 
 
 
   On the other hand, a "liberal" client always accepts the 
   AT_PERMANENT_ID_REQ and responds with the permanent identity. The 
   benefit of this policy is that it works even if the valid network 
   sometimes loses pseudonyms and is not able to decode them to the 
   permanent identity. 

   Regardless how the identity is communicated to the server, the full 
   authentication message sequence and the attributes are the same in 
   all cases. For example, AT_NONCE_MT and AT_SELECTED_VERSION are 
   always included in the EAP-Response/SIM/Start packet on full 
   authentication, even if they were already transmitted in the 
   previous EAP-Response/SIM/Start. AT_VERSION_LIST is also included in 
   every EAP-Request/SIM/Start message. The values used on the last 
   EAP/SIM/Start round trip are used and the previous EAP/SIM/Start 
   round trips is ignored. (However, all EAP/SIM/Start rounds are taken 
   into account when calculating the checkcode for AT_CHECKCODE. 
   AT_CHECKCODE is specified in Section 8.2). The NONCE_MT value and 
   the version negotiation attributes included in the last EAP-
   Response/SIM/Start packet are used in all calculations. The EAP/SIM 
   client MAY use the same NONCE_MT value in both EAP-
   Response/SIM/Start packets. 

   The value field of the AT_PERMANENT_ID_REQ does not contain any data 
   but the attribute is included to request the client to include the 
   AT_IDENTITY attribute (Section 10) with the permanent authentication 
   identity in the EAP-Response/SIM/Start message. In this case, the 
   AT_IDENTITY attribute contains the client's permanent identity in 
   the clear.  

   Please note that the EAP/SIM client 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 client with the 
   original identity from the EAP-Response/Identity packet regardless 
   if the decoding fails in the EAP server. 

   The figure below illustrates the case when the EAP server fails to 
   decode the pseudonym included in the EAP-Response/Identity packet. 













  
Haverinen and Salowey   Expires in six months               [Page 16] 


Internet Draft          EAP SIM Authentication               June 2003 
 
 
   Client                                             Authenticator 
          |                                                       | 
          |                               EAP-Request/Identity    | 
          |<------------------------------------------------------| 
          |                                                       | 
          | EAP-Response/Identity                                 | 
          | (Includes a pseudonym)                                | 
          |------------------------------------------------------>| 
          |                                                       | 
          |                            +------------------------------+ 
          |                            | Server fails to decode the   | 
          |                            | Pseudonym.                   | 
          |                            +------------------------------+ 
          |                                                       | 
          |  EAP-Request/SIM/Start                                | 
          |  (AT_PERMANENT_ID_REQ, AT_VERSION_LIST)               | 
          |<------------------------------------------------------| 
          |                                                       | 
          |                                                       | 
          | EAP-Response/SIM/Start                                | 
          | (AT_IDENTITY with permanent identity, AT_NONCE_MT,    | 
          |  AT_SELECTED_VERSION)                                 | 
          |------------------------------------------------------>| 
          |                                                       | 
    
   If the server recognizes the permanent identity, then the 
   authentication sequence proceeds as usual with the EAP Server 
   issuing the EAP-Request/SIM/Challenge message.  

   If the server does not recognize the permanent identity, or if the 
   server is not able to continue the authentication exchange with the 
   client after receiving the permanent identity, then the server 
   issues the EAP Failure packet and the authentication exchange 
   terminates. 

   The figure below illustrates the case when the EAP server fails to 
   decode the pseudonym included in the AT_IDENTITY attribute. 
















  
Haverinen and Salowey   Expires in six months               [Page 17] 


Internet Draft          EAP SIM Authentication               June 2003 
 
 
   Client                                             Authenticator 
          |                                                       | 
          |                            +------------------------------+ 
          |                            | Server does not have any     | 
          |                            | Subscriber identity available| 
          |                            | When starting EAP/SIM        | 
          |                            +------------------------------+ 
          |                                                       | 
          |        EAP-Request/SIM/Start                          | 
          |        (AT_ANY_ID_REQ, AT_VERSION_LIST)               | 
          |<------------------------------------------------------| 
          |                                                       | 
          |                                                       | 
          |EAP-Response/SIM/Start                                 | 
          |(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT,   | 
          | AT_SELECTED_VERSION)                                  | 
          |------------------------------------------------------>| 
          |                                                       | 
          |                                                       | 
          |                            +------------------------------+ 
          |                            | Server fails to decode the   | 
          |                            | Pseudonym in AT_IDENTITY     | 
          |                            +------------------------------+ 
          |                                                       | 
          |                EAP-Request/SIM/Start                  | 
          |                (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) | 
          |<------------------------------------------------------| 
          |                                                       | 
          |                                                       | 
          | EAP-Response/SIM/Start                                | 
          | (AT_IDENTITY with permanent identity,                 | 
          |  AT_NONCE_MT, AT_SELECTED_VERSION)                    | 
          |------------------------------------------------------>| 
          |                                                       | 
    
   In the worst case, there are three EAP/SIM/Start round trips before 
   the server has obtained an acceptable identity: on the first round, 
   the client sends its re-authentication identity in AT_IDENTITY. The 
   server fails to accept it and request a full authentication identity 
   with a second EAP-Request/SIM/Start. The client responds with a 
   pseudonym identity in AT_IDENTITY. The server fails to decode the 
   pseudonym and has to issue a third EAP-Request/SIM/Start, including 
   AT_PERMANENT_ID_REQ. Finally, the server accepts the client's EAP-
   Response/SIM/Start with the AT_IDENTITY attribute and proceeds with 
   full authentication. This is illustrated in the figure below.