rcf4186.txt

RCF4186 about EAP-SIM

Haverinen & Salowey          Informational                      [Page 5]

RFC 4186                 EAP-SIM Authentication             January 2006


   This document frequently uses the following terms and abbreviations:

   AAA protocol

         Authentication, Authorization, and Accounting protocol

   AuC

         Authentication Centre.  The GSM network element that provides
         the authentication triplets for authenticating
         the subscriber.

   Authentication vector

         GSM triplets can be alternatively called authentication
         vectors.

   EAP

         Extensible Authentication Protocol

   Fast re-authentication

         An EAP-SIM authentication exchange that is based on keys
         derived upon a preceding full authentication exchange.
         The GSM authentication and key exchange algorithms are not
         used in the fast re-authentication procedure.

   Fast Re-authentication Identity

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

   Fast Re-authentication Username

         The username portion of fast re-authentication identity,
         i.e., not including any realm portions.

   Full authentication

         An EAP-SIM authentication exchange based on the GSM
         authentication and key agreement algorithms.

   GSM

         Global System for Mobile communications.




Haverinen & Salowey          Informational                      [Page 6]

RFC 4186                 EAP-SIM Authentication             January 2006


   GSM Triplet

         The tuple formed by the three GSM authentication values RAND,
         Kc, and SRES.

   IMSI

         International Mobile Subscriber Identifier, used in GSM to
         identify subscribers.

   MAC

         Message Authentication Code

   NAI

         Network Access Identifier

   Nonce

         A value that is used at most once or that is never repeated
         within the same cryptographic context.  In general, a nonce can
         be predictable (e.g., a counter) or unpredictable (e.g., a
         random value).  Since some cryptographic properties may depend
         on the randomness of the nonce, attention should be paid to
         whether a nonce is required to be random or not.  In this
         document, the term nonce is only used to denote random nonces,
         and it is not used to denote counters.

   Permanent Identity

         The permanent identity of the peer, including an NAI realm
         portion in environments where a realm is used.  The permanent
         identity is usually based on the IMSI.  Used on full
         authentication only.

   Permanent Username

         The username portion of permanent identity, i.e., not including
         any realm portions.

   Pseudonym Identity

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





Haverinen & Salowey          Informational                      [Page 7]

RFC 4186                 EAP-SIM Authentication             January 2006


   Pseudonym Username

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

   SIM

         Subscriber Identity Module.  The SIM is traditionally a smart
         card distributed by a GSM operator.

3.  Overview

   Figure 1 shows an overview of the EAP-SIM full authentication
   procedure, wherein optional protected success indications are not
   used.  The authenticator typically communicates with an EAP server
   that is located on a backend authentication server using an AAA
   protocol.  The authenticator shown in the figure is often simply
   relaying EAP messages to and from the EAP server, but these backend
   AAA communications are not shown.

     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




Haverinen & Salowey          Informational                      [Page 8]

RFC 4186                 EAP-SIM Authentication             January 2006


   The first EAP Request issued by the authenticator 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 8.

   The EAP-Request/SIM/Start packet contains the list of EAP-SIM
   versions 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 a 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 7).

   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 7.  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.
   Triplets may be stored in the EAP server for use at a later time, but
   triplets MUST NOT be re-used, except in some error cases that are
   specified in Section 10.9.

   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 AT_MAC attribute is a general message authentication code
   attribute that is used in many EAP-SIM messages.

   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



Haverinen & Salowey          Informational                      [Page 9]

RFC 4186                 EAP-SIM Authentication             January 2006


   sends the EAP-Response/SIM/Client-Error packet and the authentication
   exchange terminates.

   Since the RANDs given to a peer are accompanied by 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 (i.e., 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 9.4).  The EAP server
   verifies that the MAC is correct.  Because protected success
   indications are not used in this example, the EAP server sends the
   EAP-Success packet, indicating that the authentication was
   successful.  (Protected success indications are discussed in
   Section 6.2.)  The EAP server may also include derived keying
   material in the message it sends to the authenticator.  The peer has
   derived the same keying material, so the authenticator does not
   forward the keying material to the peer along with EAP-Success.

   EAP-SIM also includes a separate fast re-authentication procedure
   that does not make use of the A3/A8 algorithms or the GSM
   infrastructure.  Fast re-authentication is based on keys derived on
   full authentication.  If the peer has maintained state information
   for fast re-authentication and wants to use fast re-authentication,
   then the peer indicates this by using a specific fast
   re-authentication identity instead of the permanent identity or a
   pseudonym identity.  The fast re-authentication procedure is
   described in Section 5.

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,
   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.