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 .......................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
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.
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.
AT_VERSION_LIST includes the EAP-SIM versions supported by the
server. If AT_VERSION_LIST does not include a version that is