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

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

  
Haverinen and Salowey   Expires in six months               [Page 18] 


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                          | 
          |        (Includes AT_ANY_ID_REQ, AT_VERSION_LIST)      | 
          |<------------------------------------------------------| 
          |                                                       | 
          | EAP-Response/SIM/Start                                | 
          | (AT_IDENTITY with re-authentication identity)         | 
          |------------------------------------------------------>| 
          |                                                       | 
          |                            +------------------------------+ 
          |                            | Server does not accept       | 
          |                            | The re-authentication        | 
          |                            | Identity                     | 
          |                            +------------------------------+ 
          |                                                       | 
          |     EAP-Request/SIM/Start                             | 
          |     (AT_FULLAUTH_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)                                 | 
          |------------------------------------------------------>| 
          |                                                       | 
    
   After the last EAP-Response/SIM/Start message, the full 
   authentication sequence proceeds as usual. If the EAP Server 
   recognizes the permanent identity and is able to proceed, the server 
   issues 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 
  
Haverinen and Salowey   Expires in six months               [Page 19] 


Internet Draft          EAP SIM Authentication               June 2003 
 
 
   the permanent identity, then the server issues the EAP Failure 
   packet and the authentication exchange terminates. 

6. Re-Authentication 

   In some environments, EAP authentication may be performed 
   frequently. Because the EAP SIM full authentication procedure makes 
   use of the GSM SIM A3/A8 algorithms, and it therefore requires 2 or 
   3 fresh triplets from the Authentication Centre, the full 
   authentication procedure is not very well suitable for frequent use. 
   Therefore, EAP SIM includes a more inexpensive re-authentication 
   procedure that does not make use of the SIM A3/A8 algorithms and 
   does not need new triplets from the Authentication Centre. Re-
   authentication can be performed in fewer roundtrips than the full 
   authentication.  

   Re-authentication is optional to implement for both the EAP SIM 
   server and client. On each EAP authentication, either one of the 
   entities may also fall back on full authentication if they do not 
   want to use re-authentication. 

   Re-authentication is based on the keys derived on the preceding full 
   authentication. The same K_aut and K_encr keys as in full 
   authentication are used to protect EAP SIM packets and attributes, 
   and the original Master Key from full authentication is used to 
   generate a fresh Master Session Key, as specified in Section 17.  

   On re-authentication, the client protects against replays with an 
   unsigned 16-bit counter, included in the AT_COUNTER attribute. On 
   full authentication, both the server and the client initialize the 
   counter to one. The counter value of at least one is used on the 
   first re-authentication. On subsequent re-authentications, the 
   counter MUST be greater than on any of the previous re-
   authentications. For example, on the second re-authentication, 
   counter value is two or greater etc. The AT_COUNTER attribute is 
   encrypted. 

   The server includes an encrypted server nonce (AT_NONCE_S) in the 
   re-authentication request. The AT_MAC attribute in the client's 
   response is calculated over NONCE_S to provide a challenge/response 
   authentication scheme. The NONCE_S also contributes to the new 
   Master Session Key. 

   As discussed in Section 5.3, in some environments the client may 
   assume that the network can reliably store pseudonyms and therefore 
   the client may fail to respond to the AT_PERMANENT_ID_REQ attribute. 
   The network SHOULD store pseudonyms on a reliable database. Because 
   one of the objectives of the re-authentication procedure is to 
   reduce load on the network, the re-authentication procedure does not 
   require the EAP server to contact a reliable database. Therefore, 
   the re-authentication procedure makes use of separate re-
   authentication user identities. Pseudonyms and the permanent 
   identity are reserved for full authentication only. The network does 
  
Haverinen and Salowey   Expires in six months               [Page 20] 


Internet Draft          EAP SIM Authentication               June 2003 
 
 
   not need to store re-authentication identities as carefully as 
   pseudonyms. If a re-authentication identity is lost and the network 
   does not recognize it, the EAP server can fall back on full 
   authentication. 

   If the EAP server supports re-authentication, it MAY include the 
   skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP-
   Request/SIM/Challenge message (Section 11). This attribute contains 
   a new re-authentication identity for the next re-authentication. The 
   client MAY ignore this attribute, in which case it will use full 
   authentication next time. If the client wants to use re-
   authentication, it uses this re-authentication identity on next 
   authentication. Even if the client has a re-authentication identity, 
   the client MAY discard the re-authentication identity and use a 
   pseudonym or the permanent identity instead, in which case full 
   authentication will be performed. 

   The re-authentication identity received in AT_NEXT_REAUTH_ID 
   contains both the username portion and the realm portion of the 
   Network Access Identifier. The EAP Server can choose an appropriate 
   realm part in order to have the AAA infrastructure route subsequent 
   re-authentication related requests to the same AAA server. For 
   example, the realm part MAY include a portion that is specific to 
   the AAA server. Hence, it is sufficient to store the context 
   required for re-authentication in the AAA server that performed the 
   full authentication. 

   The client MAY use the re-authentication identity in the EAP-
   Response/Identity packet or, in response to server's AT_ANY_ID_REQ 
   attribute, the client MAY use the re-authentication identity in the 
   AT_IDENTITY attribute of the EAP-Response/SIM/Start packet. 

   Even if the client uses a re-authentication identity, the server may 
   want to fall back on full authentication, for example because the 
   server does not recognize the re-authentication identity or does not 
   want to use re-authentication. In this case, the server starts the 
   full authentication procedure by issuing an EAP-Request/SIM/Start 
   packet. This packet always starts a full authentication sequence if 
   it does not include the AT_ANY_ID_REQ attribute. If the server was 
   not able to recover the client's identity from the re-authentication 
   identity, the server includes either the AT_FULLAUTH_ID_REQ or the 
   AT_PERMANENT_ID_REQ attribute in this EAP request. (As specified in 
   Sections 5.2 and 5.3, the server MAY use AT_ANY_ID_REQ, 
   AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ attributes if it does not 
   know the client's identity.) 

   Both the client and the server SHOULD have an upper limit for the 
   number of subsequent re-authentications allowed before a full 
   authentication needs to be performed. Because a 16-bit counter is 
   used in re-authentication, the theoretical maximum number of re-
   authentications is reached when the counter value reaches 0xFFFF. 


  
Haverinen and Salowey   Expires in six months               [Page 21] 


Internet Draft          EAP SIM Authentication               June 2003 
 
 
   In order to use re-authentication, the client and the server need to 
   store the following values: Master Key, K_aut, K_encr, latest 
   counter value and the next re-authentication identity. 

   The following figure illustrates the re-authentication procedure. 
   Encrypted attributes are denoted with '*'. The client uses its re-
   authentication identity in the EAP-Response/Identity packet. As 
   discussed above, an alternative way to communicate the re-
   authentication identity to the server is for the client to use the 
   AT_IDENTITY attribute in the EAP-Response/SIM/Start message. This 
   latter case is not illustrated in the figure below, and it is only 
   possible when the server requests the client to send its identity by 
   including the AT_ANY_ID_REQ attribute in the EAP-Request/SIM/Start 
   packet. 

   If the server recognizes the re-authentication identity and agrees 
   on using re-authentication, then the server sends the EAP-
   Request/SIM/Re-authentication packet to the client. This packet MUST 
   include the encrypted AT_COUNTER attribute, with a fresh counter 
   value, the encrypted AT_NONCE_S attribute that contains a random 
   number chosen by the server, the AT_ENCR_DATA and the AT_IV 
   attributes used for encryption, and the AT_MAC attribute that 
   contains a message authentication code over the packet. The packet 
   MAY also include an encrypted AT_NEXT_REAUTH_ID attribute that 
   contains the next re-authentication identity.  

   Re-authentication identities are one-time identities. If the client 
   does not receive a new re-authentication identity, it MUST use 
   either the permanent identity or a pseudonym identity on the next 
   authentication to initiate full authentication. 

   The client verifies that the counter value is fresh (greater than 
   any previously used value). The client also verifies that AT_MAC is 
   correct. The client MAY save the next re-authentication identity 
   from the encrypted AT_NEXT_REAUTH_ID for next time. If all checks 
   are successful, the client responds with the EAP-Response/SIM/Re-
   authentication packet, including the AT_COUNTER attribute with the 
   same counter value and the AT_MAC attribute. 

   The server verifies the AT_MAC attribute and also verifies that the 
   counter value is the same that it used in the EAP-Request/SIM/Re-
   authentication packet. If these checks are successful, the re-
   authentication has succeeded and the server sends the EAP-Success 
   packet to the client. 









  
Haverinen and Salowey   Expires in six months               [Page 22] 


Internet Draft          EAP SIM Authentication               June 2003 
 
 
   Client                                             Authenticator 
          |                                                       | 
          |                               EAP-Request/Identity    | 
          |<------------------------------------------------------| 
          |                                                       | 
          | EAP-Response/Identity                                 | 
          | (Includes a re-authentication identity)               | 
          |------------------------------------------------------>| 
          |                                                       | 
          |                          +--------------------------------+ 
          |                          | Server recognizes the identity | 
          |                          | and agrees on using fast       | 
          |