Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4186

Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)

Pages: 92
Informational
Errata
Part 1 of 5 – Pages 1 to 10
None   None   Next

Top   ToC   RFC4186 - Page 1
Network Working Group                                  H. Haverinen, Ed.
Request for Comments: 4186                                         Nokia
Category: Informational                                  J. Salowey, Ed.
                                                           Cisco Systems
                                                            January 2006


             Extensible Authentication Protocol Method for
             Global System for Mobile Communications (GSM)
                 Subscriber Identity Modules (EAP-SIM)

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

IESG Note

   The EAP-SIM protocol was developed by 3GPP.  The documentation of
   EAP-SIM is provided as information to the Internet community.  While
   the EAP WG has verified that EAP-SIM is compatible with EAP, as
   defined in RFC 3748, no other review has been done, including
   validation of the security claims.  The IETF has also not reviewed
   the security of the cryptographic algorithms.

Abstract

This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is a second generation mobile network standard. The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure.
Top   ToC   RFC4186 - Page 2

Table of Contents

1. Introduction ....................................................4 2. Terms ...........................................................5 3. Overview ........................................................8 4. Operation ......................................................10 4.1. Version Negotiation .......................................10 4.2. Identity Management .......................................11 4.2.1. Format, Generation and Usage of Peer Identities ....11 4.2.2. Communicating the Peer Identity to the Server ......17 4.2.3. Choice of Identity for the EAP-Response/Identity ...19 4.2.4. Server Operation in the Beginning of EAP-SIM Exchange ...................................19 4.2.5. Processing of EAP-Request/SIM/Start by the Peer ....20 4.2.6. Attacks Against Identity Privacy ...................21 4.2.7. Processing of AT_IDENTITY by the Server ............22 4.3. Message Sequence Examples (Informative) ...................23 4.3.1. Full Authentication ................................24 4.3.2. Fast Re-authentication .............................25 4.3.3. Fall Back to Full Authentication ...................26 4.3.4. Requesting the Permanent Identity 1 ................27 4.3.5. Requesting the Permanent Identity 2 ................28 4.3.6. Three EAP-SIM/Start Roundtrips .....................28 5. Fast Re-Authentication .........................................30 5.1. General ...................................................30 5.2. Comparison to UMTS AKA ....................................31 5.3. Fast Re-authentication Identity ...........................31 5.4. Fast Re-authentication Procedure ..........................33 5.5. Fast Re-authentication Procedure when Counter Is Too Small .................................................36 6. EAP-SIM Notifications ..........................................37 6.1. General ...................................................37 6.2. Result Indications ........................................39 6.3. Error Cases ...............................................40 6.3.1. Peer Operation .....................................40 6.3.2. Server Operation ...................................41 6.3.3. EAP-Failure ........................................42 6.3.4. EAP-Success ........................................42 7. Key Generation .................................................43 8. Message Format and Protocol Extensibility ......................45 8.1. Message Format ............................................45 8.2. Protocol Extensibility ....................................47 9. Messages .......................................................48 9.1. EAP-Request/SIM/Start .....................................48 9.2. EAP-Response/SIM/Start ....................................49 9.3. EAP-Request/SIM/Challenge .................................49 9.4. EAP-Response/SIM/Challenge ................................50 9.5. EAP-Request/SIM/Re-authentication .........................51
Top   ToC   RFC4186 - Page 3
      9.6. EAP-Response/SIM/Re-authentication ........................51
      9.7. EAP-Response/SIM/Client-Error .............................52
      9.8. EAP-Request/SIM/Notification ..............................52
      9.9. EAP-Response/SIM/Notification .............................53
   10. Attributes ....................................................53
      10.1. Table of Attributes ......................................53
      10.2. AT_VERSION_LIST ..........................................54
      10.3. AT_SELECTED_VERSION ......................................55
      10.4. AT_NONCE_MT ..............................................55
      10.5. AT_PERMANENT_ID_REQ ......................................56
      10.6. AT_ANY_ID_REQ ............................................56
      10.7. AT_FULLAUTH_ID_REQ .......................................57
      10.8. AT_IDENTITY ..............................................57
      10.9. AT_RAND ..................................................58
      10.10. AT_NEXT_PSEUDONYM .......................................59
      10.11. AT_NEXT_REAUTH_ID .......................................59
      10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING .....................60
      10.13. AT_RESULT_IND ...........................................62
      10.14. AT_MAC ..................................................62
      10.15. AT_COUNTER ..............................................63
      10.16. AT_COUNTER_TOO_SMALL ....................................63
      10.17. AT_NONCE_S ..............................................64
      10.18. AT_NOTIFICATION .........................................64
      10.19. AT_CLIENT_ERROR_CODE ....................................65
   11. IANA Considerations ...........................................66
   12. Security Considerations .......................................66
      12.1. A3 and A8 Algorithms .....................................66
      12.2. Identity Protection ......................................66
      12.3. Mutual Authentication and Triplet Exposure ...............67
      12.4. Flooding the Authentication Centre .......................69
      12.5. Key Derivation ...........................................69
      12.6. Cryptographic Separation of Keys and Session
            Independence .............................................70
      12.7. Dictionary Attacks .......................................71
      12.8. Credentials Re-use .......................................71
      12.9. Integrity and Replay Protection, and Confidentiality .....72
      12.10. Negotiation Attacks .....................................73
      12.11. Protected Result Indications ............................73
      12.12. Man-in-the-Middle Attacks ...............................74
      12.13. Generating Random Numbers ...............................74
   13. Security Claims ...............................................74
   14. Acknowledgements and Contributions ............................75
      14.1. Contributors .............................................75
      14.2. Acknowledgements .........................................75
           14.2.1. Contributors' Addresses ...........................77
   15. References ....................................................78
      15.1. Normative References .....................................78
      15.2. Informative References ...................................79
Top   ToC   RFC4186 - Page 4
   Appendix A.  Test Vectors .........................................81
      A.1.  EAP-Request/Identity .....................................81
      A.2.  EAP-Response/Identity ....................................81
      A.3.  EAP-Request/SIM/Start ....................................82
      A.4.  EAP-Response/SIM/Start ...................................82
      A.5.  EAP-Request/SIM/Challenge ................................83
      A.6.  EAP-Response/SIM/Challenge ...............................86
      A.7.  EAP-Success ..............................................86
      A.8.  Fast Re-authentication ...................................86
      A.9.  EAP-Request/SIM/Re-authentication ........................87
      A.10.  EAP-Response/SIM/Re-authentication ......................89
   Appendix B.  Pseudo-Random Number Generator .......................90

1. Introduction

This document specifies an Extensible Authentication Protocol (EAP) [RFC3748] mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is a second generation mobile network standard. Second generation mobile networks and third generation mobile networks use different authentication and key agreement mechanisms. EAP-AKA [EAP-AKA] specifies an EAP method that is based on the Authentication and Key Agreement (AKA) mechanism used in 3rd generation mobile networks. GSM authentication is based on a challenge-response mechanism. The A3/A8 authentication and key derivation algorithms that run on the SIM can be given a 128-bit random number (RAND) as a challenge. The SIM runs operator-specific algorithms, which take the RAND and a secret key Ki (stored on the SIM) as input, and produce a 32-bit response (SRES) and a 64-bit long key Kc as output. The Kc key is originally intended to be used as an encryption key over the air interface, but in this protocol, it is used for deriving keying material and is not directly used. Hence, the secrecy of Kc is critical to the security of this protocol. For more information about GSM authentication, see [GSM-03.20]. See Section 12.1 for more discussion about the GSM algorithms used in EAP-SIM. The lack of mutual authentication is a weakness in GSM authentication. The derived 64-bit cipher key (Kc) is not strong enough for data networks in which stronger and longer keys are required. Hence, in EAP-SIM, several RAND challenges are used for generating several 64-bit Kc keys, which are combined to constitute stronger keying material. In EAP-SIM, the client issues a random number NONCE_MT to the network in order to contribute to key derivation, and to prevent replays of EAP-SIM requests from previous
Top   ToC   RFC4186 - Page 5
   exchanges.  The NONCE_MT can be conceived as the client's challenge
   to the network.  EAP-SIM also extends the combined RAND challenges
   and other messages with a message authentication code in order to
   provide message integrity protection along with mutual
   authentication.

   EAP-SIM specifies optional support for protecting the privacy of
   subscriber identity using the same concept as the GSM, which uses
   pseudonyms/temporary identifiers.  It also specifies an optional fast
   re-authentication procedure.

   The security of EAP-SIM builds on underlying GSM mechanisms.  The
   security properties of EAP-SIM are documented in Section 11 of this
   document.  Implementers and users of EAP-SIM are advised to carefully
   study the security considerations in Section 11 in order to determine
   whether the security properties are sufficient for the environment in
   question, especially as the secrecy of Kc keys is essential to the
   security of EAP-SIM.  In brief, EAP-SIM is in no sense weaker than
   the GSM mechanisms.  In some cases EAP-SIM provides better security
   properties than the underlying GSM mechanisms, particularly if the
   SIM credentials are only used for EAP-SIM and are not re-used from
   GSM/GPRS.  Many of the security features of EAP-SIM rely upon the
   secrecy of the Kc values in the SIM triplets, so protecting these
   values is key to the security of the EAP-SIM protocol.

   The 3rd Generation Partnership Project (3GPP) has specified an
   enhanced Authentication and Key Agreement (AKA) architecture for the
   Universal Mobile Telecommunications System (UMTS).  The 3rd
   generation AKA mechanism includes mutual authentication, replay
   protection, and derivation of longer session keys.  EAP-AKA [EAP-AKA]
   specifies an EAP method that is based on the 3rd generation AKA.
   EAP-AKA, which is a more secure protocol, may be used instead of
   EAP-SIM, if 3rd generation identity modules and 3G network
   infrastructures are available.

2. Terms

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terms and abbreviations "authenticator", "backend authentication server", "EAP server", "peer", "Silently Discard", "Master Session Key (MSK)", and "Extended Master Session Key (EMSK)" in this document are to be interpreted as described in [RFC3748].
Top   ToC   RFC4186 - Page 6
   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.
Top   ToC   RFC4186 - Page 7
   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.
Top   ToC   RFC4186 - Page 8
   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
Top   ToC   RFC4186 - Page 9
   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
Top   ToC   RFC4186 - Page 10
   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.



(page 10 continued on part 2)

Next Section