Network Working Group J. Arkko Request for Comments: 4187 Ericsson Category: Informational H. Haverinen Nokia January 2006 Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP-AKA)
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-AKA protocol was developed by 3GPP. The documentation of
EAP-AKA is provided as information to the Internet community. While the EAP WG has verified that EAP-AKA is compatible with EAP as
defined in RFC 3748, no other review has been done, including
validation of the curity claims. The IETF has also not reviewed
the curity of the underlying UMTS AKA algorithms.
Abstract
This document specifies an Extensible Authentication Protocol (EAP)
mechanism for authentication and ssion key distribution that us
the Authentication and Key Agreement (AKA) mechanism. AKA is ud in the 3rd generation mobile networks Universal Mobile
Telecommunications System (UMTS) and CDMA2000. AKA is bad on
symmetric keys, and typically runs in a Subscriber Identity Module,
which is a UMTS Subscriber Identity Module, USIM, or a (Removable)
Ur Identity Module, (R)UIM, similar to a smart card.
EAP-AKA includes optional identity privacy support, optional result
indications, and an optional fast re-authentication procedure.
Arkko & Haverinen Informational [Page 1]
Table of Contents
1. Introduction and Motivation (4)
2. Terms and Conventions Ud in This Document (5)
3. Protocol Overview (9)
4. Operation (15)
4.1. Identity Management (15)
4.1.1. Format, Generation, and Usage of Peer Identities (15)
4.1.2. Communicating the Peer Identity to the Server (21)
4.1.3. Choice of Identity for the EAP-Respon/Identity (23)
4.1.4. Server Operation in the Beginning of
EAP-AKA Exchange (23)
4.1.
5. Processing of EAP-Request/AKA-Identity by
the Peer (24)
4.1.6. Attacks against Identity Privacy (25)
4.1.7. Processing of AT_IDENTITY by the Server (26)
4.2. Message Sequence Examples (Informative) (27)
4.2.1. Usage of AT_ANY_ID_REQ (27)
4.2.2. Fall Back on Full Authentication (28)
4.2.3. Requesting the Permanent Identity 1 (29)
4.2.4. Requesting the Permanent Identity 2 (30)
4.2.5. Three EAP/AKA-Identity Round Trips (30)
5. Fast Re-Authentication (32)
5.1. General (32)
5.2. Comparison to AKA (33)
5.3. Fast Re-Authentication Identity (33)
5.4. Fast Re-Authentication Procedure (35)
5.5. Fast Re-Authentication Procedure when Counter is
Too Small (37)
6. EAP-AKA Notifications (38)
6.1. General (38)
6.2. Result Indications (39)
6.3. Error Cas (40)
6.3.1. Peer Operation (41)
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/AKA-Identity (48)
9.2. EAP-Respon/AKA-Identity (48)
9.3. EAP-Request/AKA-Challenge (49)
9.4. EAP-Respon/AKA-Challenge (49)
9.5. EAP-Respon/AKA-Authentication-Reject (50)
9.6. EAP-Respon/AKA-Synchronization-Failure (50)
Arkko & Haverinen Informational [Page 2]
9.7. EAP-Request/AKA-Reauthentication (50)
9.8. EAP-Respon/AKA-Reauthentication (51)
9.9. EAP-Respon/AKA-Client-Error (52)
9.10. EAP-Request/AKA-Notification (52)
9.11. EAP-Respon/AKA-Notification (52)
10. Attributes (53)
10.1. Table of Attributes (53)
10.2. AT_PERMANENT_ID_REQ (54)
10.3. AT_ANY_ID_REQ (54)
10.4. AT_FULLAUTH_ID_REQ (54)
10.5. AT_IDENTITY (55)
10.6. AT_RAND (55)
10.7. AT_AUTN (56)
10.8. AT_RES (56)
10.9. AT_AUTS (57)
10.10. AT_NEXT_PSEUDONYM (57)
10.11. AT_NEXT_REAUTH_ID (58)
10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING (58)
10.13. AT_CHECKCODE (60)
10.14. AT_RESULT_IND (62)
10.15. AT_MAC (63)
10.16. AT_COUNTER (64)
10.17. AT_COUNTER_TOO_SMALL (64)
10.18. AT_NONCE_S (65)
10.19. AT_NOTIFICATION (65)
10.20. AT_CLIENT_ERROR_CODE (66)
11. IANA and Protocol Numbering Considerations (66)
12. Security Considerations (68)
12.1. Identity Protection (69)
12.2. Mutual Authentication (69)
12.3. Flooding the Authentication Centre (69)
12.4. Key Derivation (70)
12.5. Brute-Force and Dictionary Attacks (70)
12.6. Protection, Replay Protection, and Confidentiality (70)
12.7. Negotiation Attacks (71)
12.8. Protected Result Indications (72)
12.9. Man-in-the-Middle Attacks (72)
12.10. Generating Random Numbers (73)
13. Security Claims (73)
14. Acknowledgements and Contributions (74)
15. References (74)
15.1. Normative References (74)
15.2. Informative References (76)
Appendix A. Pudo-Random Number Generator (77)
Arkko & Haverinen Informational [Page 3]
1. Introduction and Motivation
This document specifies an Extensible Authentication Protocol (EAP)
mechanism for authentication and ssion key distribution that us
the 3rd generation Authentication and Key Agreement mechanism,
specified for Universal Mobile Telecommunications System (UMTS) in
[TS33.102] and for CDMA2000 in [S.S0055-A]. UMTS and CDMA2000 are
global 3rd generation mobile network standards that u the same AKA mechanism.
2nd generation mobile networks and 3rd generation mobile networks u different authentication and key agreement mechanisms. The Global
System for Mobile communications (GSM) is a 2nd generation mobile
network standard, and EAP-SIM [EAP-SIM] specifies an EAP mechanism
that is bad on the GSM authentication and key agreement primitives. AKA is bad on challenge-respon mechanisms and symmetric
cryptography. AKA typically runs in a UMTS Subscriber Identity
Module (USIM) or a CDMA2000 (Removable) Ur Identity Module
((R)UIM). In this document, both modules are referred to as identity modules. Compared to the 2nd generation mechanisms such as GSM AKA, the 3rd generation AKA provides substantially longer key lengths and mutual authentication.
The introduction of AKA inside EAP allows veral new applications.
The include the following:
o The u of the AKA also as a cure PPP authentication method in
devices that already contain an identity module.
o The u of the 3rd generation mobile network authentication
infrastructure in the context of wireless LANs
o Relying on AKA and the existing infrastructure in a amless way
with any other technology that can u EAP.
AKA works in the following manner:
o The identity module and the home environment have agreed on a
cret key beforehand. (The "home environment" refers to the home operator’s authentication network infrastructure.)
o The actual authentication process starts by having the home
environment produce an authentication vector, bad on the cret key and a quence number. The authentication vector contains a
random part RAND, an authenticator part AUTN ud for
authenticating the network to the identity module, an expected
result part XRES, a 128-bit ssion key for integrity check IK,
and a 128-bit ssion key for encryption CK.
Arkko & Haverinen Informational [Page 4]
o The RAND and the AUTN are delivered to the identity module.
o The identity module verifies the AUTN, again bad on the cret
key and the quence number. If this process is successful (the
AUTN is valid and the quence number ud to generate AUTN is
within the correct range), the identity module produces an
authentication result RES and nds it to the home environment.
o The home environment verifies the correct result from the identity module. If the result is correct, IK and CK can be ud to
protect further communications between the identity module and the home environment.
When verifying AUTN, the identity module may detect that the quence number the network us is not within the correct range. In this
ca, the identity module calculates a quence number
synchronization parameter AUTS and nds it to the network. AKA
authentication may then be retried with a new authentication vector
generated using the synchronized quence number.
For a specification of the AKA mechanisms and how the cryptographic
values AUTN, RES, IK, CK and AUTS are calculated, e [TS33.102] for UMTS and [S.S0055-A] for CDMA2000.
In EAP-AKA, the EAP rver node obtains the authentication vectors,
compares RES and XRES, and us CK and IK in key derivation.
In the 3rd generation mobile networks, AKA is ud for both radio
network authentication and IP multimedia rvice authentication
purpos. Different ur identities and formats are ud for the; the radio network us the International Mobile Subscriber Identifier (IMSI), whereas the IP multimedia rvice us the Network Access
Identifier (NAI) [RFC4282].
2. Terms and Conventions Ud in This Document
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 rver", "EAP rver", "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 us the following terms and abbreviations. The AKA parameters are specified in detail in [TS33.102] for UMTS and [S.S0055-A] for CDMA2000.
Arkko & Haverinen Informational [Page 5]
