RFC 4186
Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)
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.
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
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
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 .......................901. 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
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].
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.
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.
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
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
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)
