diff options
Diffstat (limited to 'doc/rfc/rfc4187.txt')
| -rw-r--r-- | doc/rfc/rfc4187.txt | 4427 |
1 files changed, 4427 insertions, 0 deletions
diff --git a/doc/rfc/rfc4187.txt b/doc/rfc/rfc4187.txt new file mode 100644 index 0000000..913f917 --- /dev/null +++ b/doc/rfc/rfc4187.txt @@ -0,0 +1,4427 @@ + + + + + + +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 security claims. The IETF has also not reviewed + the security of the underlying UMTS AKA algorithms. + +Abstract + + This document specifies an Extensible Authentication Protocol (EAP) + mechanism for authentication and session key distribution that uses + the Authentication and Key Agreement (AKA) mechanism. AKA is used in + the 3rd generation mobile networks Universal Mobile + Telecommunications System (UMTS) and CDMA2000. AKA is based on + symmetric keys, and typically runs in a Subscriber Identity Module, + which is a UMTS Subscriber Identity Module, USIM, or a (Removable) + User 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] + +RFC 4187 EAP-AKA Authentication January 2006 + + +Table of Contents + + 1. Introduction and Motivation .....................................4 + 2. Terms and Conventions Used 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-Response/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 Cases ...............................................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-Response/AKA-Identity .................................48 + 9.3. EAP-Request/AKA-Challenge .................................49 + 9.4. EAP-Response/AKA-Challenge ................................49 + 9.5. EAP-Response/AKA-Authentication-Reject ....................50 + 9.6. EAP-Response/AKA-Synchronization-Failure ..................50 + + + +Arkko & Haverinen Informational [Page 2] + +RFC 4187 EAP-AKA Authentication January 2006 + + + 9.7. EAP-Request/AKA-Reauthentication ..........................50 + 9.8. EAP-Response/AKA-Reauthentication .........................51 + 9.9. EAP-Response/AKA-Client-Error .............................52 + 9.10. EAP-Request/AKA-Notification .............................52 + 9.11. EAP-Response/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. Pseudo-Random Number Generator .......................77 + + + + + + + +Arkko & Haverinen Informational [Page 3] + +RFC 4187 EAP-AKA Authentication January 2006 + + +1. Introduction and Motivation + + This document specifies an Extensible Authentication Protocol (EAP) + mechanism for authentication and session key distribution that uses + 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 use the same AKA + mechanism. + + 2nd generation mobile networks and 3rd generation mobile networks use + 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 based on the GSM authentication and key agreement primitives. + + AKA is based on challenge-response mechanisms and symmetric + cryptography. AKA typically runs in a UMTS Subscriber Identity + Module (USIM) or a CDMA2000 (Removable) User 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 several new applications. + These include the following: + + o The use of the AKA also as a secure PPP authentication method in + devices that already contain an identity module. + o The use of the 3rd generation mobile network authentication + infrastructure in the context of wireless LANs + o Relying on AKA and the existing infrastructure in a seamless way + with any other technology that can use EAP. + + AKA works in the following manner: + + o The identity module and the home environment have agreed on a + secret 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, based on the secret + key and a sequence number. The authentication vector contains a + random part RAND, an authenticator part AUTN used for + authenticating the network to the identity module, an expected + result part XRES, a 128-bit session key for integrity check IK, + and a 128-bit session key for encryption CK. + + + + + +Arkko & Haverinen Informational [Page 4] + +RFC 4187 EAP-AKA Authentication January 2006 + + + o The RAND and the AUTN are delivered to the identity module. + o The identity module verifies the AUTN, again based on the secret + key and the sequence number. If this process is successful (the + AUTN is valid and the sequence number used to generate AUTN is + within the correct range), the identity module produces an + authentication result RES and sends 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 used to + protect further communications between the identity module and the + home environment. + + When verifying AUTN, the identity module may detect that the sequence + number the network uses is not within the correct range. In this + case, the identity module calculates a sequence number + synchronization parameter AUTS and sends it to the network. AKA + authentication may then be retried with a new authentication vector + generated using the synchronized sequence number. + + For a specification of the AKA mechanisms and how the cryptographic + values AUTN, RES, IK, CK and AUTS are calculated, see [TS33.102] for + UMTS and [S.S0055-A] for CDMA2000. + + In EAP-AKA, the EAP server node obtains the authentication vectors, + compares RES and XRES, and uses CK and IK in key derivation. + + In the 3rd generation mobile networks, AKA is used for both radio + network authentication and IP multimedia service authentication + purposes. Different user identities and formats are used for these; + the radio network uses the International Mobile Subscriber Identifier + (IMSI), whereas the IP multimedia service uses the Network Access + Identifier (NAI) [RFC4282]. + +2. Terms and Conventions Used 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 + 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. + The AKA parameters are specified in detail in [TS33.102] for UMTS and + [S.S0055-A] for CDMA2000. + + + + + +Arkko & Haverinen Informational [Page 5] + +RFC 4187 EAP-AKA Authentication January 2006 + + + AAA protocol + + Authentication, Authorization and Accounting protocol + + AKA + + Authentication and Key Agreement + + AuC + + Authentication Centre. The mobile network element that can + authenticate subscribers in the mobile networks. + + AUTN + + AKA parameter. AUTN is an authentication value generated by + the AuC, which, together with the RAND, authenticates the + server to the peer, 128 bits. + + AUTS + + AKA parameter. A value generated by the peer upon + experiencing a synchronization failure, 112 bits. + + EAP + + Extensible Authentication Protocol [RFC3748] + + Fast Re-Authentication + + An EAP-AKA authentication exchange that is based on keys + derived upon a preceding full authentication exchange. The + 3rd Generation AKA is 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 re-authentication only. + + Fast Re-Authentication Username + + The username portion of fast re-authentication identity, + i.e., not including any realm portions. + + + + + + +Arkko & Haverinen Informational [Page 6] + +RFC 4187 EAP-AKA Authentication January 2006 + + + Full Authentication + + An EAP-AKA authentication exchange that is based on the + 3rd Generation AKA procedure. + + GSM + + Global System for Mobile communications. + + NAI + + Network Access Identifier [RFC4282] + + Identity Module + + Identity module is used in this document to refer to the + part of the mobile device that contains authentication and + key agreement primitives. The identity module may be an + integral part of the mobile device or it may be an application + on a smart card distributed by a mobile operator. USIM and + (R)UIM are identity modules. + + 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). Because 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. + + + + + + + +Arkko & Haverinen Informational [Page 7] + +RFC 4187 EAP-AKA Authentication January 2006 + + + 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. + + RAND + + An AKA parameter. Random number generated by the AuC, + 128 bits. + + RES + + Authentication result from the peer, which, together with + the RAND, authenticates the peer to the server, + 128 bits. + + (R)UIM + + CDMA2000 (Removable) User Identity Module. (R)UIM is an + application that is resident on devices such as smart cards, + which may be fixed in the terminal or distributed by CDMA2000 + operators (when removable). + + SQN + + An AKA parameter. Sequence number used in the authentication + process, 48 bits. + + SIM + + Subscriber Identity Module. The SIM is traditionally a smart + card distributed by a GSM operator. + + SRES + + The authentication result parameter in GSM, corresponds to + the RES parameter in 3G AKA, 32 bits. + + + + + + + + +Arkko & Haverinen Informational [Page 8] + +RFC 4187 EAP-AKA Authentication January 2006 + + + UAK + + UIM Authentication Key, used in CDMA2000 AKA. Both the + identity module and the network can optionally generate the UAK + during the AKA computation in CDMA2000. UAK is not used in + this version of EAP-AKA. + + UIM + + Please see (R)UIM. + + USIM + + UMTS Subscriber Identity Module. USIM is an application that + is resident on devices such as smart cards distributed by UMTS + operators. + +3. Protocol Overview + + Figure 1 shows the basic, successful full authentication exchange in + EAP-AKA, when optional result 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. At the minimum, EAP-AKA uses two + roundtrips to authenticate and authorize the peer and generate + session keys. As in other EAP schemes, an identity request/response + message pair is usually exchanged first. On full authentication, the + peer's identity 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.1. (As specified in [RFC3748], the initial identity + request is not required, and MAY be bypassed in cases where the + network can presume the identity, such as when using leased lines, + dedicated dial-ups, etc. Please see Section 4.1.2 for specification + of how to obtain the identity via EAP AKA messages.) + + After obtaining the subscriber identity, the EAP server obtains an + authentication vector (RAND, AUTN, RES, CK, IK) for use in + authenticating the subscriber. From the vector, the EAP server + derives the keying material, as specified in Section 6.4. The vector + may be obtained by contacting an Authentication Centre (AuC) on the + mobile network; for example, per UMTS specifications, several vectors + may be obtained at a time. Vectors may be stored in the EAP server + for use at a later time, but they may not be reused. + + + + + +Arkko & Haverinen Informational [Page 9] + +RFC 4187 EAP-AKA Authentication January 2006 + + + In CDMA2000, the vector may include a sixth value called the User + Identity Module Authentication Key (UAK). This key is not used in + EAP-AKA. + + Next, the EAP server starts the actual AKA protocol by sending an + EAP-Request/AKA-Challenge message. EAP-AKA 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/AKA-Challenge message contains a RAND + random number (AT_RAND), a network authentication token (AT_AUTN), + and a message authentication code (AT_MAC). The EAP-Request/ + AKA-Challenge message MAY optionally contain encrypted data, which is + used for identity privacy and fast re-authentication support, as + described in Section 4.1. The AT_MAC attribute contains a message + authentication code covering the EAP packet. The encrypted data is + not shown in the figures of this section. + + The peer runs the AKA algorithm (typically using an identity module) + and verifies the AUTN. If this is successful, the peer is talking to + a legitimate EAP server and proceeds to send the EAP-Response/ + AKA-Challenge. This message contains a result parameter that allows + the EAP server, in turn, to authenticate the peer, and the AT_MAC + attribute to integrity protect the EAP message. + + The EAP server verifies that the RES and the MAC in the EAP-Response/ + AKA-Challenge packet are 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. + + + + + + + + + + + + + + + + + + +Arkko & Haverinen Informational [Page 10] + +RFC 4187 EAP-AKA Authentication January 2006 + + + Peer Authenticator + | EAP-Request/Identity | + |<------------------------------------------------------| + | | + | EAP-Response/Identity | + | (Includes user's NAI) | + |------------------------------------------------------>| + | +------------------------------+ + | | Server runs AKA algorithms, | + | | generates RAND and AUTN. | + | +------------------------------+ + | EAP-Request/AKA-Challenge | + | (AT_RAND, AT_AUTN, AT_MAC) | + |<------------------------------------------------------| + +-------------------------------------+ | + | Peer runs AKA algorithms, | | + | verifies AUTN and MAC, derives RES | | + | and session key | | + +-------------------------------------+ | + | EAP-Response/AKA-Challenge | + | (AT_RES, AT_MAC) | + |------------------------------------------------------>| + | +--------------------------------+ + | | Server checks the given RES, | + | | and MAC and finds them correct.| + | +--------------------------------+ + | EAP-Success | + |<------------------------------------------------------| + + Figure 1: EAP-AKA full authentication procedure + + + + + + + + + + + + + + + + + + + + + +Arkko & Haverinen Informational [Page 11] + +RFC 4187 EAP-AKA Authentication January 2006 + + + Figure 2 shows how the EAP server rejects the Peer due to a failed + authentication. + + Peer Authenticator + | EAP-Request/Identity | + |<------------------------------------------------------| + | | + | EAP-Response/Identity | + | (Includes user's NAI) | + |------------------------------------------------------>| + | +------------------------------+ + | | Server runs AKA algorithms, | + | | generates RAND and AUTN. | + | +------------------------------+ + | EAP-Request/AKA-Challenge | + | (AT_RAND, AT_AUTN, AT_MAC) | + |<------------------------------------------------------| + +-------------------------------------+ | + | Peer runs AKA algorithms, | | + | possibly verifies AUTN, and sends an| | + | invalid response | | + +-------------------------------------+ | + | EAP-Response/AKA-Challenge | + | (AT_RES, AT_MAC) | + |------------------------------------------------------>| + | +------------------------------------------+ + | | Server checks the given RES and the MAC, | + | | and finds one of them incorrect. | + | +------------------------------------------+ + | EAP-Request/AKA-Notification | + |<------------------------------------------------------| + | EAP-Response/AKA-Notification | + |------------------------------------------------------>| + | EAP-Failure | + |<------------------------------------------------------| + + Figure 2: Peer authentication fails + + + + + + + + + + + + + + +Arkko & Haverinen Informational [Page 12] + +RFC 4187 EAP-AKA Authentication January 2006 + + + Figure 3 shows the peer rejecting the AUTN of the EAP server. + + The peer sends an explicit error message (EAP-Response/ + AKA-Authentication-Reject) to the EAP server, as usual in AKA when + AUTN is incorrect. This allows the EAP server to produce the same + error statistics that AKA generally produces in UMTS or CDMA2000. + + Peer Authenticator + | EAP-Request/Identity | + |<------------------------------------------------------| + | EAP-Response/Identity | + | (Includes user's NAI) | + |------------------------------------------------------>| + | +------------------------------+ + | | Server runs AKA algorithms, | + | | generates RAND and a bad AUTN| + | +------------------------------+ + | EAP-Request/AKA-Challenge | + | (AT_RAND, AT_AUTN, AT_MAC) | + |<------------------------------------------------------| + +-------------------------------------+ | + | Peer runs AKA algorithms | | + | and discovers AUTN that can not be | | + | verified | | + +-------------------------------------+ | + | EAP-Response/AKA-Authentication-Reject | + |------------------------------------------------------>| + | EAP-Failure | + |<------------------------------------------------------| + + Figure 3: Network authentication fails + + The AKA uses shared secrets between the Peer and the Peer's home + operator, together with a sequence number, to actually perform an + authentication. In certain circumstances, shown in Figure 4, it is + possible for the sequence numbers to get out of sequence. + + + + + + + + + + + + + + + +Arkko & Haverinen Informational [Page 13] + +RFC 4187 EAP-AKA Authentication January 2006 + + + Peer Authenticator + | EAP-Request/Identity | + |<------------------------------------------------------| + | EAP-Response/Identity | + | (Includes user's NAI) | + |------------------------------------------------------>| + | +------------------------------+ + | | Server runs AKA algorithms, | + | | generates RAND and AUTN. | + | +------------------------------+ + | EAP-Request/AKA-Challenge | + | (AT_RAND, AT_AUTN, AT_MAC) | + |<------------------------------------------------------| + +-------------------------------------+ | + | Peer runs AKA algorithms | | + | and discovers AUTN that contains an | | + | inappropriate sequence number | | + +-------------------------------------+ | + | EAP-Response/AKA-Synchronization-Failure | + | (AT_AUTS) | + |------------------------------------------------------>| + | +---------------------------+ + | | Perform resynchronization | + | | Using AUTS and | + | | the sent RAND | + | +---------------------------+ + | | + + Figure 4: Sequence number synchronization + + After the resynchronization process has taken place in the server and + AAA side, the process continues by the server side sending a new + EAP-Request/AKA-Challenge message. + + In addition to the full authentication scenarios described above, + EAP-AKA includes a fast re-authentication procedure, which is + specified in Section 5. Fast re-authentication is based on keys + derived on full authentication. If the peer has maintained state + information for 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. + + + + + + + + + +Arkko & Haverinen Informational [Page 14] + +RFC 4187 EAP-AKA Authentication January 2006 + + +4. Operation + +4.1. Identity Management + +4.1.1. Format, Generation, and Usage of Peer Identities + +4.1.1.1. General + + In the beginning of EAP authentication, the Authenticator or the EAP + server usually issues the EAP-Request/Identity packet to the peer. + The peer responds with EAP-Response/Identity, which contains the + user's identity. The formats of these packets are specified in + [RFC3748]. + + Subscribers of mobile networks are identified with the International + Mobile Subscriber Identity (IMSI) [TS23.003]. The IMSI is a string + of not more than 15 digits. It is composed of a Mobile Country Code + (MCC) of 3 digits, a Mobile Network Code (MNC) of 2 or 3 digits, and + a Mobile Subscriber Identification Number (MSIN) of not more than 10 + digits. MCC and MNC uniquely identify the GSM operator and help + identify the AuC from which the authentication vectors need to be + retrieved for this subscriber. + + Internet AAA protocols identify users with the Network Access + Identifier (NAI) [RFC4282]. When used in a roaming environment, the + NAI is composed of a username and a realm, separated with "@" + (username@realm). The username portion identifies the subscriber + within the realm. + + This section specifies the peer identity format used in EAP-AKA. In + this document, the term identity or peer identity refers to the whole + identity string that is used to identify the peer. The peer identity + may include a realm portion. "Username" refers to the portion of the + peer identity that identifies the user, i.e., the username does not + include the realm portion. + +4.1.1.2. Identity Privacy Support + + EAP-AKA includes optional identity privacy (anonymity) support that + can be used to hide the cleartext permanent identity and thereby make + the subscriber's EAP exchanges untraceable to eavesdroppers. Because + the permanent identity never changes, revealing it would help + observers to track the user. The permanent identity is usually based + on the IMSI, which may further help the tracking, because the same + identifier may be used in other contexts as well. Identity privacy + is based on temporary identities, or pseudonyms, which are equivalent + + + + + +Arkko & Haverinen Informational [Page 15] + +RFC 4187 EAP-AKA Authentication January 2006 + + + to but separate from the Temporary Mobile Subscriber Identities + (TMSI) that are used on cellular networks. Please see Section 12.1 + for security considerations regarding identity privacy. + +4.1.1.3. Username Types in EAP-AKA Identities + + There are three types of usernames in EAP-AKA peer identities: + + (1) Permanent usernames. For example, + 0123456789098765@myoperator.com might be a valid permanent identity. + In this example, 0123456789098765 is the permanent username. + + (2) Pseudonym usernames. For example, 2s7ah6n9q@myoperator.com might + be a valid pseudonym identity. In this example, 2s7ah6n9q is the + pseudonym username. + + (3) Fast re-authentication usernames. For example, + 43953754@myoperator.com might be a valid fast re-authentication + identity. In this case, 43953754 is the fast re-authentication + username. Unlike permanent usernames and pseudonym usernames, fast + re-authentication usernames are one-time identifiers, which are not + re-used across EAP exchanges. + + The first two types of identities are used only on full + authentication, and the last type only on fast re-authentication. + When the optional identity privacy support is not used, the + non-pseudonym permanent identity is used on full authentication. The + fast re-authentication exchange is specified in Section 5. + +4.1.1.4. Username Decoration + + In some environments, the peer may need to decorate the identity by + prepending or appending the username with a string, in order to + indicate supplementary AAA routing information in addition to the NAI + realm. (The usage of an NAI realm portion is not considered to be + decoration.) Username decoration is out of the scope of this + document. However, it should be noted that username decoration might + prevent the server from recognizing a valid username. Hence, + although the peer MAY use username decoration in the identities that + the peer includes in EAP-Response/Identity, and although the EAP + server MAY accept a decorated peer username in this message, the peer + or the EAP server MUST NOT decorate any other peer identities that + are used in various EAP-AKA attributes. Only the identity used in + EAP-Response/Identity may be decorated. + + + + + + + +Arkko & Haverinen Informational [Page 16] + +RFC 4187 EAP-AKA Authentication January 2006 + + +4.1.1.5. NAI Realm Portion + + The peer MAY include a realm portion in the peer identity, as per the + NAI format. The use of a realm portion is not mandatory. + + If a realm is used, the realm MAY be chosen by the subscriber's home + operator and it MAY be a configurable parameter in the EAP-AKA peer + implementation. In this case, the peer is typically configured with + the NAI realm of the home operator. Operators MAY reserve a specific + realm name for EAP-AKA users. This convention makes it easy to + recognize that the NAI identifies an AKA subscriber. Such a reserved + NAI realm may be useful as a hint of the first authentication method + to use during method negotiation. When the peer is using a pseudonym + username instead of the permanent username, the peer selects the + realm name portion similarly to how it selects the realm portion when + using the permanent username. + + If no configured realm name is available, the peer MAY derive the + realm name from the MCC and MNC portions of the IMSI. A RECOMMENDED + way to derive the realm from the IMSI, using the realm + 3gppnetwork.org, will be specified in [TS23.003]. + + Some old implementations derive the realm name from the IMSI by + concatenating "mnc", the MNC digits of IMSI, ".mcc", the MCC digits + of IMSI, and ".owlan.org". For example, if the IMSI is + 123456789098765, and the MNC is three digits long, then the derived + realm name is "mnc456.mcc123.owlan.org". As there are no DNS servers + running at owlan.org, these realm names can only be used with + manually configured AAA routing. New implementations SHOULD use the + mechanism specified in [TS23.003] instead of owlan.org. + + The IMSI is a string of digits without any explicit structure, so the + peer may not be able to determine the length of the MNC portion. If + the peer is not able to determine whether the MNC is two or three + digits long, the peer MAY use a 3-digit MNC. If the correct length + of the MNC is two, then the MNC used in the realm name includes the + first digit of MSIN. Hence, when configuring AAA networks for + operators that have 2-digit MNC's, the network SHOULD also be + prepared for realm names with incorrect 3-digit MNC's. + +4.1.1.6. Format of the Permanent Username + + The non-pseudonym permanent username SHOULD be derived from the IMSI. + In this case, the permanent username MUST be of the format "0" | + IMSI, where the character "|" denotes concatenation. In other words, + the first character of the username is the digit zero (ASCII value 30 + hexadecimal), followed by the IMSI. The IMSI is an ASCII string that + consists of not more than 15 decimal digits (ASCII values between 30 + + + +Arkko & Haverinen Informational [Page 17] + +RFC 4187 EAP-AKA Authentication January 2006 + + + and 39 hexadecimal), one character per IMSI digit, in the order as + specified in [TS23.003]. For example, a permanent username derived + from the IMSI 295023820005424 would be encoded as the ASCII string + "0295023820005424" (byte values in hexadecimal notation: 30 32 39 35 + 30 32 33 38 32 30 30 30 35 34 32 34) + + The EAP server MAY use the leading "0" as a hint to try EAP-AKA as + the first authentication method during method negotiation, rather + than using, for example, EAP-SIM. The EAP-AKA server MAY propose + EAP-AKA even if the leading character was not "0". + + Alternatively, an implementation MAY choose a permanent username that + is not based on the IMSI. In this case the selection of the + username, its format, and its processing is out of the scope of this + document. In this case, the peer implementation MUST NOT prepend any + leading characters to the username. + +4.1.1.7. Generating Pseudonyms and Fast Re-Authentication Identities by + the Server + + Pseudonym usernames and fast re-authentication identities are + generated by the EAP server. The EAP server produces pseudonym + usernames and fast re-authentication identities in an + implementation-dependent manner. Only the EAP server needs to be + able to map the pseudonym username to the permanent identity, or to + recognize a fast re-authentication identity. + + EAP-AKA includes no provisions to ensure that the same EAP server + that generated a pseudonym username will be used on the + authentication exchange when the pseudonym username is used. It is + recommended that the EAP servers implement some centralized mechanism + to allow all EAP servers of the home operator to map pseudonyms + generated by other severs to the permanent identity. If no such + mechanism is available, then the EAP server, failing to understand a + pseudonym issued by another server, can request the peer to send the + permanent identity. + + When issuing a fast re-authentication identity, the EAP server may + include a realm name in the identity that will cause the fast + re-authentication request to be forwarded to the same EAP server. + + When generating fast re-authentication identities, the server SHOULD + choose a fresh, new fast re-authentication identity that is different + from the previous ones that were used after the same full + authentication exchange. A full authentication exchange and the + associated fast re-authentication exchanges are referred to here as + the same "full authentication context". The fast re-authentication + identity SHOULD include a random component. The random component + + + +Arkko & Haverinen Informational [Page 18] + +RFC 4187 EAP-AKA Authentication January 2006 + + + works as a full authentication context identifier. A context- + specific fast re-authentication identity can help the server to + detect whether its fast re-authentication state information matches + the peer's fast re-authentication state information (in other words, + whether the state information is from the same full authentication + exchange). The random component also makes the fast re- + authentication identities unpredictable, so an attacker cannot + initiate a fast re-authentication exchange to get the server's + EAP-Request/AKA-Reauthentication packet. + + Transmitting pseudonyms and fast re-authentication identities from + the server to the peer is discussed in Section 4.1.1.8. The + pseudonym is transmitted as a username, without an NAI realm, and the + fast re-authentication identity is transmitted as a complete NAI, + including a realm portion if a realm is required. The realm is + included in the fast re-authentication identity in order to allow the + server to include a server-specific realm. + + Regardless of construction method, the pseudonym username MUST + conform to the grammar specified for the username portion of an NAI. + Also, the fast re-authentication identity MUST conform to the NAI + grammar. The EAP servers that the subscribers of an operator can use + MUST ensure that the pseudonym usernames and the username portions + used in fast re-authentication identities that they generate are + unique. + + In any case, it is necessary that permanent usernames, pseudonym + usernames, and fast re-authentication usernames are separate and + recognizable from each other. It is also desirable that EAP-SIM and + EAP-AKA usernames be recognizable from each other as an aid to the + server when deciding which method to offer. + + In general, it is the task of the EAP server and the policies of its + administrator to ensure sufficient separation of the usernames. + Pseudonym usernames and fast re-authentication usernames are both + produced and used by the EAP server. The EAP server MUST compose + pseudonym usernames and fast re-authentication usernames so that it + can recognize if an NAI username is an EAP-AKA pseudonym username or + an EAP-AKA fast re-authentication username. For instance, when the + usernames have been derived from the IMSI, the server could use + different leading characters in the pseudonym usernames and fast + re-authentication usernames (e.g., the pseudonym could begin with a + leading "2" character). When mapping a fast re-authentication + identity to a permanent identity, the server SHOULD only examine the + username portion of the fast re-authentication identity and ignore + the realm portion of the identity. + + + + + +Arkko & Haverinen Informational [Page 19] + +RFC 4187 EAP-AKA Authentication January 2006 + + + Because the peer may fail to save a pseudonym username that was sent + in an EAP-Request/AKA-Challenge (for example, due to malfunction), + the EAP server SHOULD maintain, at least, the most recently used + pseudonym username in addition to the most recently issued pseudonym + username. If the authentication exchange is not completed + successfully, then the server SHOULD NOT overwrite the pseudonym + username that was issued during the most recent successful + authentication exchange. + +4.1.1.8. Transmitting Pseudonyms and Fast Re-Authentication Identities + to the Peer + + The server transmits pseudonym usernames and fast re-authentication + identities to the peer in cipher, using the AT_ENCR_DATA attribute. + + The EAP-Request/AKA-Challenge message MAY include an encrypted + pseudonym username and/or an encrypted fast re-authentication + identity in the value field of the AT_ENCR_DATA attribute. Because + identity privacy support and fast re-authentication are optional to + implement, the peer MAY ignore the AT_ENCR_DATA attribute and always + use the permanent identity. On fast re-authentication (discussed in + Section 5), the server MAY include a new, encrypted fast re- + authentication identity in the EAP-Request/AKA-Reauthentication + message. + + On receipt of the EAP-Request/AKA-Challenge, the peer MAY decrypt the + encrypted data in AT_ENCR_DATA; and if a pseudonym username is + included, the peer may use the obtained pseudonym username on the + next full authentication. If a fast re-authentication identity is + included, then the peer MAY save it together with other fast re- + authentication state information, as discussed in Section 5, for the + next fast re-authentication. + + If the peer does not receive a new pseudonym username in the + EAP-Request/AKA-Challenge message, the peer MAY use an old pseudonym + username instead of the permanent username on next full + authentication. The username portions of fast re-authentication + identities are one-time usernames, which the peer MUST NOT re-use. + When the peer uses a fast re-authentication identity in an EAP + exchange, the peer MUST discard the fast re-authentication identity + and not re-use it in another EAP authentication exchange, even if the + authentication exchange was not completed. + +4.1.1.9. Usage of the Pseudonym by the Peer + + When the optional identity privacy support is used on full + authentication, the peer MAY use a pseudonym username received as + part of a previous full authentication sequence as the username + + + +Arkko & Haverinen Informational [Page 20] + +RFC 4187 EAP-AKA Authentication January 2006 + + + portion of the NAI. The peer MUST NOT modify the pseudonym username + received in AT_NEXT_PSEUDONYM. However, as discussed above, the peer + MAY need to decorate the username in some environments by appending + or prepending the username with a string that indicates supplementary + AAA routing information. + + When using a pseudonym username in an environment where a realm + portion is used, the peer concatenates the received pseudonym + username with the "@" character and an NAI realm portion. The + selection of the NAI realm is discussed above. The peer can select + the realm portion similarly, regardless of whether it uses the + permanent username or a pseudonym username. + +4.1.1.10. Usage of the Fast Re-Authentication Identity by the Peer + + On fast re-authentication, the peer uses the fast re-authentication + identity received as part of the previous authentication sequence. A + new fast re-authentication identity may be delivered as part of both + full authentication and fast re-authentication. The peer MUST NOT + modify the username part of the fast re-authentication identity + received in AT_NEXT_REAUTH_ID, except in cases when username + decoration is required. Even in these cases, the "root" fast + re-authentication username must not be modified, but it may be + appended or prepended with another string. + +4.1.2. Communicating the Peer Identity to the Server + +4.1.2.1. General + + The peer identity MAY be communicated to the server with the + EAP-Response/Identity message. This message MAY contain the + permanent identity, a pseudonym identity, or a fast re-authentication + identity. If the peer uses the permanent identity or a pseudonym + identity, which the server is able to map to the permanent identity, + then the authentication proceeds as discussed in the overview of + Section 3. If the peer uses a fast re-authentication identity, and + if the fast re-authentication identity matches with a valid fast + re-authentication identity maintained by the server, then a fast + re-authentication exchange is performed, as described in Section 5. + + The peer identity can also be transmitted from the peer to the server + using EAP-AKA messages instead of EAP-Response/Identity. In this + case, the server includes an identity requesting attribute + (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the + EAP-Request/AKA-Identity message; and the peer includes the + AT_IDENTITY attribute, which contains the peer's identity, in the + EAP-Response/AKA-Identity message. The AT_ANY_ID_REQ attribute is a + general identity requesting attribute, which the server uses if it + + + +Arkko & Haverinen Informational [Page 21] + +RFC 4187 EAP-AKA Authentication January 2006 + + + does not specify which kind of an identity the peer should return in + AT_IDENTITY. The server uses the AT_FULLAUTH_ID_REQ attribute to + request either the permanent identity or a pseudonym identity. The + server uses the AT_PERMANENT_ID_REQ attribute to request that the + peer send its permanent identity. The EAP-Request/AKA-Challenge, + EAP-Response/AKA-Challenge, or the packets used on fast re- + authentication may optionally include the AT_CHECKCODE attribute, + which enables the protocol peers to ensure the integrity of the + AKA-Identity packets. AT_CHECKCODE is specified in Section 10.13. + + The identity format in the AT_IDENTITY attribute is the same as in + the EAP-Response/Identity packet (except that identity decoration is + not allowed). The AT_IDENTITY attribute contains a permanent + identity, a pseudonym identity, or a fast re-authentication identity. + + Please note that only the EAP-AKA peer and the EAP-AKA server process + the AT_IDENTITY attribute and entities that pass through; EAP packets + do not process this attribute. Hence, the authenticator and other + intermediate AAA elements (such as possible AAA proxy servers) will + continue to refer to the peer with the original identity from the + EAP-Response/Identity packet unless the identity authenticated in the + AT_IDENTITY attribute is communicated to them in another way within + the AAA protocol. + +4.1.2.2. Relying on EAP-Response/Identity Discouraged + + The EAP-Response/Identity packet is not method specific; therefore, + in many implementations it may be handled by an EAP Framework. This + introduces an additional layer of processing between the EAP peer and + EAP server. The extra layer of processing may cache identity + responses or add decorations to the identity. A modification of the + identity response will cause the EAP peer and EAP server to use + different identities in the key derivation, which will cause the + protocol to fail. + + For this reason, it is RECOMMENDED that the EAP peer and server use + the method-specific identity attributes in EAP-AKA, and the server is + strongly discouraged from relying upon the EAP-Response/Identity. + + In particular, if the EAP server receives a decorated identity in + EAP-Response/Identity, then the EAP server MUST use the + identity-requesting attributes to request the peer to send an + unmodified and undecorated copy of the identity in AT_IDENTITY. + + + + + + + + +Arkko & Haverinen Informational [Page 22] + +RFC 4187 EAP-AKA Authentication January 2006 + + +4.1.3. Choice of Identity for the EAP-Response/Identity + + If EAP-AKA peer is started upon receiving an EAP-Request/Identity + message, then the peer MAY use an EAP-AKA identity in the EAP- + Response/Identity packet. In this case, the peer performs the + following steps. + + If the peer has maintained fast re-authentication state information + and if the peer wants to use fast re-authentication, then the peer + transmits the fast re-authentication identity in + EAP-Response/Identity. + + Else, if the peer has a pseudonym username available, then the peer + transmits the pseudonym identity in EAP-Response/Identity. + + In other cases, the peer transmits the permanent identity in + EAP-Response/Identity. + +4.1.4. Server Operation in the Beginning of EAP-AKA Exchange + + As discussed in Section 4.1.2.2, the server SHOULD NOT rely on an + identity string received in EAP-Response/Identity. Therefore, the + RECOMMENDED way to start an EAP-AKA exchange is to ignore any + received identity strings. The server SHOULD begin the EAP-AKA + exchange by issuing the EAP-Request/AKA-Identity packet with an + identity-requesting attribute to indicate that the server wants the + peer to include an identity in the AT_IDENTITY attribute of the EAP- + Response/AKA-Identity message. Three methods to request an identity + from the peer are discussed below. + + If the server chooses to not ignore the contents of + EAP-Response/Identity, then the server may already receive an EAP-AKA + identity in this packet. However, if the EAP server has not received + any EAP-AKA peer identity (permanent identity, pseudonym identity, or + fast re-authentication identity) from the peer when sending the first + EAP-AKA request, or if the EAP server has received an + EAP-Response/Identity packet but the contents do not appear to be a + valid permanent identity, pseudonym identity, or a re-authentication + identity, then the server MUST request an identity from the peer + using one of the methods below. + + The server sends the EAP-Request/AKA-Identity message with the + AT_PERMANENT_ID_REQ attribute to indicate that the server wants the + peer to include the permanent identity in the AT_IDENTITY attribute + of the EAP-Response/AKA-Identity message. This is done in the + following cases: + + + + + +Arkko & Haverinen Informational [Page 23] + +RFC 4187 EAP-AKA Authentication January 2006 + + + o The server does not support fast re-authentication or identity + privacy. + o The server decided to process a received identity, and the server + recognizes the received identity as a pseudonym identity, but the + server is not able to map the pseudonym identity to a permanent + identity. + + The server issues the EAP-Request/AKA-Identity packet with the + AT_FULLAUTH_ID_REQ attribute to indicate that the server wants the + peer to include a full authentication identity (pseudonym identity or + permanent identity) in the AT_IDENTITY attribute of the + EAP-Response/AKA-Identity message. This is done in the following + cases: + + o The server does not support fast re-authentication and the server + supports identity privacy + o The server decided to process a received identity, and the server + recognizes the received identity as a re-authentication identity + but the server is not able to map the re-authentication identity + to a permanent identity + + The server issues the EAP-Request/AKA-Identity packet with the + AT_ANY_ID_REQ attribute to indicate that the server wants the peer to + include an identity in the AT_IDENTITY attribute of the + EAP-Response/AKA-Identity message, and the server does not indicate + any preferred type for the identity. This is done in other cases, + such as when the server ignores a received EAP-Response/Identity, + when the server does not have any identity, or when the server does + not recognize the format of a received identity. + +4.1.5. Processing of EAP-Request/AKA-Identity by the Peer + + Upon receipt of an EAP-Request/AKA-Identity message, the peer MUST + perform the following steps. + + If the EAP-Request/AKA-Identity includes AT_PERMANENT_ID_REQ, and if + the peer does not have a pseudonym available, then the peer MUST + respond with EAP-Response/AKA-Identity and include the permanent + identity in AT_IDENTITY. If the peer has a pseudonym available, then + the peer MAY refuse to send the permanent identity; hence, in this + case the peer MUST either respond with EAP-Response/AKA-Identity and + include the permanent identity in AT_IDENTITY or respond with + EAP-Response/AKA-Client-Error packet with code "unable to process + packet". + + If the EAP-Request/AKA-Identity includes AT_FULL_AUTH_ID_REQ, and if + the peer has a pseudonym available, then the peer SHOULD respond with + EAP-Response/AKA-Identity and include the pseudonym identity in + + + +Arkko & Haverinen Informational [Page 24] + +RFC 4187 EAP-AKA Authentication January 2006 + + + AT_IDENTITY. If the peer does not have a pseudonym when it receives + this message, then the peer MUST respond with EAP-Response/ + AKA-Identity and include the permanent identity in AT_IDENTITY. The + Peer MUST NOT use a fast re-authentication identity in the + AT_IDENTITY attribute. + + If the EAP-Request/AKA-Identity includes AT_ANY_ID_REQ, and if the + peer has maintained fast re-authentication state information and + wants to use fast re-authentication, then the peer responds with + EAP-Response/AKA-Identity and includes the fast re-authentication + identity in AT_IDENTITY. Else, if the peer has a pseudonym identity + available, then the peer responds with EAP-Response/AKA-Identity and + includes the pseudonym identity in AT_IDENTITY. Else, the peer + responds with EAP-Response/AKA-Identity and includes the permanent + identity in AT_IDENTITY. + + An EAP-AKA exchange may include several EAP/AKA-Identity rounds. The + server may issue a second EAP-Request/AKA-Identity, if it was not + able to recognize the identity the peer used in the previous + AT_IDENTITY attribute. At most three EAP/AKA-Identity rounds can be + used, so the peer MUST NOT respond to more than three + EAP-Request/AKA-Identity messages within an EAP exchange. The peer + MUST verify that the sequence of EAP-Request/AKA-Identity packets the + peer receives comply with the sequencing rules defined in this + document. That is, AT_ANY_ID_REQ can only be used in the first + EAP-Request/AKA-Identity; in other words, AT_ANY_ID_REQ MUST NOT be + used in the second or third EAP-Request/AKA-Identity. + AT_FULLAUTH_ID_REQ MUST NOT be used if the previous + EAP-Request/AKA-Identity included AT_PERMANENT_ID_REQ. The peer + operation, in cases when it receives an unexpected attribute or an + unexpected message, is specified in Section 6.3.1. + +4.1.6. Attacks against Identity Privacy + + The section above specifies two possible ways the peer can operate + upon receipt of AT_PERMANENT_ID_REQ because a received + AT_PERMANENT_ID_REQ does not necessarily originate from the valid + network. However, an active attacker may transmit an + EAP-Request/AKA-Identity packet with an AT_PERMANENT_ID_REQ attribute + to the peer, in an effort to find out the true identity of the user. + If the peer does not want to reveal its permanent identity, then the + peer sends the EAP-Response/AKA-Client-Error packet with the error + code "unable to process packet", and the authentication exchange + terminates. + + Basically, there are two different policies that the peer can employ + with regard to AT_PERMANENT_ID_REQ. A "conservative" peer assumes + that the network is able to maintain pseudonyms robustly. Therefore, + + + +Arkko & Haverinen Informational [Page 25] + +RFC 4187 EAP-AKA Authentication January 2006 + + + if a conservative peer has a pseudonym username, the peer responds + with EAP-Response/AKA-Client-Error to the EAP packet with + AT_PERMANENT_ID_REQ, because the peer believes that the valid network + is able to map the pseudonym identity to the peer's permanent + identity. (Alternatively, the conservative peer may accept + AT_PERMANENT_ID_REQ in certain circumstances, for example if the + pseudonym was received a long time ago.) The benefit of this policy + is that it protects the peer against active attacks on anonymity. On + the other hand, a "liberal" peer always accepts the + AT_PERMANENT_ID_REQ and responds with the permanent identity. The + benefit of this policy is that it works even if the valid network + sometimes loses pseudonyms and is not able to map them to the + permanent identity. + +4.1.7. Processing of AT_IDENTITY by the Server + + When the server receives an EAP-Response/AKA-Identity message with + the AT_IDENTITY (in response to the server's identity requesting + attribute), the server MUST operate as follows. + + If the server used AT_PERMANENT_ID_REQ, and if the AT_IDENTITY does + not contain a valid permanent identity, then the server sends an + EAP-Request/AKA-Notification packet with AT_NOTIFICATION code + "General failure" (16384) to terminate the EAP exchange. If the + server recognizes the permanent identity and is able to continue, + then the server proceeds with full authentication by sending + EAP-Request/AKA-Challenge. + + If the server used AT_FULLAUTH_ID_REQ, and if AT_IDENTITY contains a + valid permanent identity or a pseudonym identity that the server can + map to a valid permanent identity, then the server proceeds with full + authentication by sending EAP-Request/AKA-Challenge. If AT_IDENTITY + contains a pseudonym identity that the server is not able to map to a + valid permanent identity, or an identity that the server is not able + to recognize or classify, then the server sends EAP-Request/ + AKA-Identity with AT_PERMANENT_ID_REQ. + + If the server used AT_ANY_ID_REQ, and if the AT_IDENTITY contains a + valid permanent identity or a pseudonym identity that the server can + map to a valid permanent identity, then the server proceeds with full + authentication by sending EAP-Request/ AKA-Challenge. + + If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid + fast re-authentication identity and the server agrees on using + re-authentication, then the server proceeds with fast + re-authentication by sending EAP-Request/AKA-Reauthentication + (Section 5). + + + + +Arkko & Haverinen Informational [Page 26] + +RFC 4187 EAP-AKA Authentication January 2006 + + + If the server used AT_ANY_ID_REQ, and if the peer sent an EAP- + Response/AKA-Identity with AT_IDENTITY that contains an identity that + the server recognizes as a fast re-authentication identity, but the + server is not able to map the identity to a permanent identity, then + the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ. + + If the server used AT_ANY_ID_REQ, and if AT_IDENTITY contains a valid + fast re-authentication identity, which the server is able to map to a + permanent identity, and if the server does not want to use fast + re-authentication, then the server proceeds with full authentication + by sending EAP-Request/AKA-Challenge. + + If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an + identity that the server recognizes as a pseudonym identity but the + server is not able to map the pseudonym identity to a permanent + identity, then the server sends EAP-Request/AKA-Identity with + AT_PERMANENT_ID_REQ. + + If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an + identity that the server is not able to recognize or classify, then + the server sends EAP-Request/AKA-Identity with AT_FULLAUTH_ID_REQ. + +4.2. Message Sequence Examples (Informative) + + This section contains non-normative message sequence examples to + illustrate how the peer identity can be communicated to the server. + +4.2.1. Usage of AT_ANY_ID_REQ + + Obtaining the peer identity with EAP-AKA attributes is illustrated in + Figure 5 below. + + Peer Authenticator + | | + | +------------------------------+ + | | Server does not have any | + | | Subscriber identity available| + | | When starting EAP-AKA | + | +------------------------------+ + | EAP-Request/AKA-Identity | + | (AT_ANY_ID_REQ) | + |<------------------------------------------------------| + | | + | EAP-Response/AKA-Identity | + | (AT_IDENTITY) | + |------------------------------------------------------>| + | | + Figure 5: Usage of AT_ANY_ID_REQ + + + +Arkko & Haverinen Informational [Page 27] + +RFC 4187 EAP-AKA Authentication January 2006 + + +4.2.2. Fall Back on Full Authentication + + Figure 6 illustrates the case when the server does not recognize the + fast re-authentication identity the peer used in AT_IDENTITY. + + Peer Authenticator + | | + | +------------------------------+ + | | Server does not have any | + | | Subscriber identity available| + | | When starting EAP-AKA | + | +------------------------------+ + | EAP-Request/AKA-Identity | + | (AT_ANY_ID_REQ) | + |<------------------------------------------------------| + | | + | EAP-Response/AKA-Identity | + | (AT_IDENTITY containing a fast re-auth. identity) | + |------------------------------------------------------>| + | +------------------------------+ + | | Server does not recognize | + | | The fast re-auth. | + | | Identity | + | +------------------------------+ + | EAP-Request/AKA-Identity | + | (AT_FULLAUTH_ID_REQ) | + |<------------------------------------------------------| + | EAP-Response/AKA-Identity | + | (AT_IDENTITY with a full-auth. Identity) | + |------------------------------------------------------>| + | | + + Figure 6: Fall back on full authentication + + If the server recognizes the fast re-authentication identity, but + still wants to fall back on full authentication, the server may issue + the EAP-Request/AKA-Challenge packet. In this case, the full + authentication procedure proceeds as usual. + + + + + + + + + + + + + +Arkko & Haverinen Informational [Page 28] + +RFC 4187 EAP-AKA Authentication January 2006 + + +4.2.3. Requesting the Permanent Identity 1 + + Figure 7 illustrates the case when the EAP server fails to decode a + pseudonym identity included in the EAP-Response/Identity packet. + + Peer Authenticator + | EAP-Request/Identity | + |<------------------------------------------------------| + | EAP-Response/Identity | + | (Includes a pseudonym) | + |------------------------------------------------------>| + | +------------------------------+ + | | Server fails to decode the | + | | Pseudonym. | + | +------------------------------+ + | EAP-Request/AKA-Identity | + | (AT_PERMANENT_ID_REQ) | + |<------------------------------------------------------| + | | + | EAP-Response/AKA-Identity | + | (AT_IDENTITY with permanent identity) | + |------------------------------------------------------>| + | | + + Figure 7: Requesting the permanent identity 1 + + If the server recognizes the permanent identity, then the + authentication sequence proceeds as usual with the EAP Server issuing + the EAP-Request/AKA-Challenge message. + + + + + + + + + + + + + + + + + + + + + + +Arkko & Haverinen Informational [Page 29] + +RFC 4187 EAP-AKA Authentication January 2006 + + +4.2.4. Requesting the Permanent Identity 2 + + Figure 8 illustrates the case when the EAP server fails to decode the + pseudonym included in the AT_IDENTITY attribute. + + Peer Authenticator + | | + | +------------------------------+ + | | Server does not have any | + | | Subscriber identity available| + | | When starting EAP-AKA | + | +------------------------------+ + | EAP-Request/AKA-Identity | + | (AT_ANY_ID_REQ) | + |<------------------------------------------------------| + | | + |EAP-Response/AKA-Identity | + |(AT_IDENTITY with a pseudonym identity) | + |------------------------------------------------------>| + | +------------------------------+ + | | Server fails to decode the | + | | Pseudonym in AT_IDENTITY | + | +------------------------------+ + | EAP-Request/AKA-Identity | + | (AT_PERMANENT_ID_REQ) | + |<------------------------------------------------------| + | EAP-Response/AKA-Identity | + | (AT_IDENTITY with permanent identity) | + |------------------------------------------------------>| + | | + + Figure 8: Requesting the permanent identity 2 + +4.2.5. Three EAP/AKA-Identity Round Trips + + Figure 9 illustrates the case with three EAP/AKA-Identity round + trips. + + + + + + + + + + + + + + +Arkko & Haverinen Informational [Page 30] + +RFC 4187 EAP-AKA Authentication January 2006 + + + Peer Authenticator + | | + | +------------------------------+ + | | Server does not have any | + | | Subscriber identity available| + | | When starting EAP-AKA | + | +------------------------------+ + | EAP-Request/AKA-Identity | + | (AT_ANY_ID_REQ) | + |<------------------------------------------------------| + | | + | EAP-Response/AKA-Identity | + | (AT_IDENTITY with fast re-auth. identity) | + |------------------------------------------------------>| + | +------------------------------+ + | | Server does not accept | + | | The fast re-authentication | + | | Identity | + | +------------------------------+ + | | + : : + : : + + + : : + : : + | EAP-Request/AKA-Identity | + | (AT_FULLAUTH_ID_REQ) | + |<------------------------------------------------------| + |EAP-Response/AKA-Identity | + |(AT_IDENTITY with a pseudonym identity) | + |------------------------------------------------------>| + | +------------------------------+ + | | Server fails to decode the | + | | Pseudonym in AT_IDENTITY | + | +------------------------------+ + | EAP-Request/AKA-Identity | + | (AT_PERMANENT_ID_REQ) | + |<------------------------------------------------------| + | EAP-Response/AKA-Identity | + | (AT_IDENTITY with permanent identity) | + |------------------------------------------------------>| + | | + + Figure 9: Three EAP-AKA Start rounds + + After the last EAP-Response/AKA-Identity message, the full + authentication sequence proceeds as usual. + + + +Arkko & Haverinen Informational [Page 31] + +RFC 4187 EAP-AKA Authentication January 2006 + + +5. Fast Re-Authentication + +5.1. General + + In some environments, EAP authentication may be performed frequently. + Because the EAP-AKA full authentication procedure uses the AKA + algorithms, and therefore requires fresh authentication vectors from + the Authentication Centre, the full authentication procedure may + result in many network operations when used very frequently. + Therefore, EAP-AKA includes a more inexpensive fast re-authentication + procedure that does not make use of the AKA algorithms and does not + need new vectors from the Authentication Centre. + + Fast re-authentication is optional to implement for both the EAP-AKA + server and peer. On each EAP authentication, either one of the + entities may fall back on full authentication if is does not want to + use fast re-authentication. + + Fast re-authentication is based on the keys derived on the preceding + full authentication. The same K_aut and K_encr keys used in full + authentication are used to protect EAP-AKA packets and attributes, + and the original Master Key from full authentication is used to + generate a fresh Master Session Key, as specified in Section 7. + + The fast re-authentication exchange makes use of an unsigned 16-bit + counter, included in the AT_COUNTER attribute. The counter has three + goals: 1) it can be used to limit the number of successive + reauthentication exchanges without full-authentication 2) it + contributes to the keying material, and 3) it protects the peer and + the server from replays. On full authentication, both the server and + the peer initialize the counter to one. The counter value of at + least one is used on the first fast re-authentication. On subsequent + fast re-authentications, the counter MUST be greater than on any of + the previous fast re-authentications. For example, on the second + fast re-authentication, counter value is two or greater, etc. The + AT_COUNTER attribute is encrypted. + + Both the peer and the EAP server maintain a copy of the counter. The + EAP server sends its counter value to the peer in the fast + re-authentication request. The peer MUST verify that its counter + value is less than or equal to the value sent by the EAP server. + + The server includes an encrypted server random nonce (AT_NONCE_S) in + the fast re-authentication request. The AT_MAC attribute in the + peer's response is calculated over NONCE_S to provide a + challenge/response authentication scheme. The NONCE_S also + contributes to the new Master Session Key. + + + + +Arkko & Haverinen Informational [Page 32] + +RFC 4187 EAP-AKA Authentication January 2006 + + + Both the peer and the server SHOULD have an upper limit for the + number of subsequent fast re-authentications allowed before a full + authentication needs to be performed. Because a 16-bit counter is + used in fast re-authentication, the theoretical maximum number of + re-authentications is reached when the counter value reaches FFFF + hexadecimal. In order to use fast re-authentication, the peer and + the EAP server need to store the following values: Master Key, latest + counter value and the next fast re-authentication identity. K_aut + and K_encr may either be stored or derived again from MK. The server + may also need to store the permanent identity of the user. + +5.2. Comparison to AKA + + When analyzing the fast re-authentication exchange, it may be helpful + to compare it with the 3rd generation Authentication and Key + Agreement (AKA) exchange used on full authentication. The counter + corresponds to the AKA sequence number, NONCE_S corresponds to RAND, + the AT_MAC in EAP-Request/AKA-Reauthentication corresponds to AUTN, + the AT_MAC in EAP-Response/AKA-Reauthentication corresponds to RES, + AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter + corresponds to the usage of the Anonymity Key. Also, the key + generation on fast re-authentication, with regard to random or fresh + material, is similar to AKA -- the server generates the NONCE_S and + counter values, and the peer only verifies that the counter value is + fresh. + + It should also be noted that encrypting the AT_NONCE_S, AT_COUNTER, + or AT_COUNTER_TOO_SMALL attributes is not important to the security + of the fast re-authentication exchange. + +5.3. Fast Re-Authentication Identity + + The fast re-authentication procedure makes use of separate + re-authentication user identities. Pseudonyms and the permanent + identity are reserved for full authentication only. If a fast + re-authentication identity is lost and the network does not recognize + it, the EAP server can fall back on full authentication. If the EAP + server supports fast re-authentication, it MAY include the skippable + AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP- Request/- + AKA-Challenge message. This attribute contains a new + re-authentication identity for the next fast re-authentication. The + attribute also works as a capability flag that indicates that the + server supports fast re-authentication and that the server wants to + continue using fast re-authentication within the current context. + The peer MAY ignore this attribute, in which case it will use full + authentication next time. If the peer wants to use fast + re-authentication, it uses this fast re-authentication identity on + next authentication. Even if the peer has a fast re-authentication + + + +Arkko & Haverinen Informational [Page 33] + +RFC 4187 EAP-AKA Authentication January 2006 + + + identity, the peer MAY discard the re-authentication identity and use + a pseudonym or the permanent identity instead, in which case full + authentication MUST be performed. If the EAP server does not include + the AT_NEXT_REAUTH_ID in the encrypted data of + EAP-Request/AKA-Challenge or EAP-Request/AKA-Reauthentication, then + the peer MUST discard its current fast re-authentication state + information and perform a full authentication next time. + + In environments where a realm portion is needed in the peer identity, + the fast re-authentication identity received in AT_NEXT_REAUTH_ID + MUST contain both a username portion and a realm portion, as per the + NAI format. The EAP Server can choose an appropriate realm part in + order to have the AAA infrastructure route subsequent fast + re-authentication-related requests to the same AAA server. For + example, the realm part MAY include a portion that is specific to the + AAA server. Hence, it is sufficient to store the context required + for fast re-authentication in the AAA server that performed the full + authentication. + + The peer MAY use the fast re-authentication identity in the + EAP-Response/Identity packet or, in response to the server's + AT_ANY_ID_REQ attribute, the peer MAY use the fast re-authentication + identity in the AT_IDENTITY attribute of the EAP-Response/ + AKA-Identity packet. + + The peer MUST NOT modify the username portion of the fast + re-authentication identity, but the peer MAY modify the realm portion + or replace it with another realm portion. The peer might need to + modify the realm in order to influence the AAA routing, for example, + to make sure that the correct server is reached. It should be noted + that sharing the same fast re-authentication key among several + servers may have security risks, so changing the realm portion of the + NAI in order to change the EAP server is not desirable. + + Even if the peer uses a fast re-authentication identity, the server + may want to fall back on full authentication, for example, because + the server does not recognize the fast re-authentication identity or + does not want to use fast re-authentication. If the server was able + to decode the fast re-authentication identity to the permanent + identity, the server issues the EAP-Request/AKA-Challenge packet to + initiate full authentication. If the server was not able to recover + the peer's identity from the fast re-authentication identity, the + server starts the full authentication procedure by issuing an + EAP-Request/AKA-Identity packet. This packet always starts a full + authentication sequence if it does not include the AT_ANY_ID_REQ + attribute. + + + + + +Arkko & Haverinen Informational [Page 34] + +RFC 4187 EAP-AKA Authentication January 2006 + + +5.4. Fast Re-Authentication Procedure + + Figure 10 illustrates the fast re-authentication procedure. In this + example, the optional protected success indication is not used. + Encrypted attributes are denoted with '*'. The peer uses its fast + re-authentication identity in the EAP-Response/Identity packet. As + discussed above, an alternative way to communicate the fast + re-authentication identity to the server is for the peer to use the + AT_IDENTITY attribute in the EAP-Response/AKA-Identity message. This + latter case is not illustrated in the figure below, and it is only + possible when the server requests that the peer send its identity by + including the AT_ANY_ID_REQ attribute in the EAP-Request/AKA-Identity + packet. + + If the server recognizes the identity as a valid fast + re-authentication identity, and if the server agrees to use fast + re-authentication, then the server sends the EAP- Request/AKA- + Reauthentication packet to the peer. This packet MUST include the + encrypted AT_COUNTER attribute, with a fresh counter value, the + encrypted AT_NONCE_S attribute that contains a random number chosen + by the server, the AT_ENCR_DATA and the AT_IV attributes used for + encryption, and the AT_MAC attribute that contains a message + authentication code over the packet. The packet MAY also include an + encrypted AT_NEXT_REAUTH_ID attribute that contains the next fast + re-authentication identity. + + Fast re-authentication identities are one-time identities. If the + peer does not receive a new fast re-authentication identity, it MUST + use either the permanent identity or a pseudonym identity on the next + authentication to initiate full authentication. + + The peer verifies that AT_MAC is correct and that the counter value + is fresh (greater than any previously used value). The peer MAY save + the next fast re-authentication identity from the encrypted + AT_NEXT_REAUTH_ID for next time. If all checks are successful, the + peer responds with the EAP-Response/AKA-Reauthentication packet, + including the AT_COUNTER attribute with the same counter value and + the AT_MAC attribute. + + The server verifies the AT_MAC attribute and also verifies that the + counter value is the same that it used in the + EAP-Request/AKA-Reauthentication packet. If these checks are + successful, the fast re-authentication has succeeded and the server + sends the EAP-Success packet to the peer. + + If protected success indications (Section 6.2) were used, the + EAP-Success packet would be preceded by an EAP-AKA notification + round. + + + +Arkko & Haverinen Informational [Page 35] + +RFC 4187 EAP-AKA Authentication January 2006 + + + Peer Authenticator + | | + | EAP-Request/Identity | + |<------------------------------------------------------| + | | + | EAP-Response/Identity | + | (Includes a fast re-authentication identity) | + |------------------------------------------------------>| + | +--------------------------------+ + | | Server recognizes the identity | + | | and agrees on using fast | + | | re-authentication | + | +--------------------------------+ + | EAP-Request/AKA-Reauthentication | + | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, | + | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) | + |<------------------------------------------------------| + | | + : : + : : + + + : : + : : + | | + +-----------------------------------------------+ | + | Peer verifies AT_MAC and the freshness of | | + | the counter. Peer MAY store the new re- | | + | authentication identity for next re-auth. | | + +-----------------------------------------------+ | + | | + | EAP-Response/AKA-Reauthentication | + | (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, | + | AT_MAC) | + |------------------------------------------------------>| + | +--------------------------------+ + | | Server verifies AT_MAC and | + | | the counter | + | +--------------------------------+ + | EAP-Success | + |<------------------------------------------------------| + | | + + Figure 10: Reauthentication + + + + + + + +Arkko & Haverinen Informational [Page 36] + +RFC 4187 EAP-AKA Authentication January 2006 + + +5.5. Fast Re-Authentication Procedure when Counter is Too Small + + If the peer does not accept the counter value of EAP-Request/ + AKA-Reauthentication, it indicates the counter synchronization + problem by including the encrypted AT_COUNTER_TOO_SMALL in + EAP-Response/AKA-Reauthentication. The server responds with + EAP-Request/AKA-Challenge to initiate a normal full authentication + procedure. This is illustrated in Figure 11. Encrypted attributes + are denoted with '*'. + + Peer Authenticator + | EAP-Request/AKA-Identity | + | (AT_ANY_ID_REQ) | + |<------------------------------------------------------| + | | + | EAP-Response/AKA-Identity | + | (AT_IDENTITY) | + | (Includes a fast re-authentication identity) | + |------------------------------------------------------>| + | | + | EAP-Request/AKA-Reauthentication | + | (AT_IV, AT_ENCR_DATA, *AT_COUNTER, | + | *AT_NONCE_S, *AT_NEXT_REAUTH_ID, AT_MAC) | + |<------------------------------------------------------| + +-----------------------------------------------+ | + | AT_MAC is valid but the counter is not fresh. | | + +-----------------------------------------------+ | + | EAP-Response/AKA-Reauthentication | + | (AT_IV, AT_ENCR_DATA, *AT_COUNTER_TOO_SMALL, | + | *AT_COUNTER, AT_MAC) | + |------------------------------------------------------>| + | +----------------------------------------------+ + | | Server verifies AT_MAC but detects | + | | That peer has included AT_COUNTER_TOO_SMALL| + | +----------------------------------------------+ + | EAP-Request/AKA-Challenge | + |<------------------------------------------------------| + +---------------------------------------------------------------+ + | Normal full authentication follows. | + +---------------------------------------------------------------+ + | | + + Figure 11: Fast re-authentication counter too small + + In the figure above, the first three messages are similar to the + basic fast re-authentication case. When the peer detects that the + counter value is not fresh, it includes the AT_COUNTER_TOO_SMALL + attribute in EAP-Response/AKA-Reauthentication. This attribute + + + +Arkko & Haverinen Informational [Page 37] + +RFC 4187 EAP-AKA Authentication January 2006 + + + doesn't contain any data but it is a request for the server to + initiate full authentication. In this case, the peer MUST ignore the + contents of the server's AT_NEXT_REAUTH_ID attribute. + + On receipt of AT_COUNTER_TOO_SMALL, the server verifies AT_MAC and + verifies that AT_COUNTER contains the same counter value as in the + EAP-Request/AKA-Reauthentication packet. If not, the server + terminates the authentication exchange by sending the + EAP-Request/AKA-Notification packet with AT_NOTIFICATION code + "General failure" (16384). If all checks on the packet are + successful, the server transmits an EAP-Request/AKA-Challenge packet + and the full authentication procedure is performed as usual. Because + the server already knows the subscriber identity, it MUST NOT use the + EAP-Request/AKA-Identity packet to request the identity. + + It should be noted that in this case, peer identity is only + transmitted in the AT_IDENTITY attribute at the beginning of the + whole EAP exchange. The fast re-authentication identity used in this + AT_IDENTITY attribute will be used in key derivation (see Section 7). + +6. EAP-AKA Notifications + +6.1. General + + EAP-AKA does not prohibit the use of the EAP Notifications as + specified in [RFC3748]. EAP Notifications can be used at any time in + the EAP-AKA exchange. It should be noted that EAP-AKA does not + protect EAP Notifications. EAP-AKA also specifies method-specific + EAP-AKA notifications, which are protected in some cases. + + The EAP server can use EAP-AKA notifications to convey notifications + and result indications (Section 6.2) to the peer. + + The server MUST use notifications in cases discussed in + Section 6.3.2. When the EAP server issues an + EAP-Request/AKA-Notification packet to the peer, the peer MUST + process the notification packet. The peer MAY show a notification + message to the user and the peer MUST respond to the EAP server with + an EAP-Response/AKA-Notification packet, even if the peer did not + recognize the notification code. + + An EAP-AKA full authentication exchange or a fast re-authentication + exchange MUST NOT include more than one EAP-AKA notification round. + + The notification code is a 16-bit number. The most significant bit + is called the Success bit (S bit). The S bit specifies whether the + notification implies failure. The code values with the S bit set to + zero (code values 0...32767) are used on unsuccessful cases. The + + + +Arkko & Haverinen Informational [Page 38] + +RFC 4187 EAP-AKA Authentication January 2006 + + + receipt of a notification code from this range implies failed EAP + exchange, so the peer can use the notification as a failure + indication. After receiving the EAP-Response/AKA-Notification for + these notification codes, the server MUST send the EAP-Failure + packet. + + The receipt of a notification code with the S bit set to one (values + 32768...65536) does not imply failure. Notification code "Success" + (32768) has been reserved as a general notification code to indicate + successful authentication. + + The second most significant bit of the notification code is called + the Phase bit (P bit). It specifies at which phase of the EAP-AKA + exchange the notification can be used. If the P bit is set to zero, + the notification can only be used after a successful EAP/AKA- + Challenge round in full authentication or a successful EAP/AKA- + Reauthentication round in re-authentication. A re-authentication + round is considered successful only if the peer has successfully + verified AT_MAC and AT_COUNTER attributes, and does not include the + AT_COUNTER_TOO_SMALL attribute in EAP-Response/AKA-Reauthentication. + + If the P bit is set to one, the notification can only by used before + the EAP/AKA-Challenge round in full authentication or before the + EAP/AKA-Reauthentication round in reauthentication. These + notifications can only be used to indicate various failure cases. In + other words, if the P bit is set to one, then the S bit MUST be set + to zero. + + Section 9.10 and Section 9.11 specify what other attributes must be + included in the notification packets. + + Some of the notification codes are authorization related and hence + not usually considered as part of the responsibility of an EAP + method. However, they are included as part of EAP-AKA because there + are currently no other ways to convey this information to the user in + a localizable way, and the information is potentially useful for the + user. An EAP-AKA server implementation may decide never to send + these EAP-AKA notifications. + +6.2. Result Indications + + As discussed in Section 6.3, the server and the peer use explicit + error messages in all error cases. If the server detects an error + after successful authentication, the server uses an EAP-AKA + notification to indicate failure to the peer. In this case, the + result indication is integrity and replay protected. + + + + + +Arkko & Haverinen Informational [Page 39] + +RFC 4187 EAP-AKA Authentication January 2006 + + + By sending an EAP-Response/AKA-Challenge packet or an + EAP-Response/AKA-Reauthentication packet (without + AT_COUNTER_TOO_SMALL), the peer indicates that it has successfully + authenticated the server and that the peer's local policy accepts the + EAP exchange. In other words, these packets are implicit success + indications from the peer to the server. + + EAP-AKA also supports optional protected success indications from the + server to the peer. If the EAP server wants to use protected success + indications, it includes the AT_RESULT_IND attribute in the + EAP-Request/AKA-Challenge or the EAP-Request/AKA-Reauthentication + packet. This attribute indicates that the EAP server would like to + use result indications in both successful and unsuccessful cases. If + the peer also wants this, the peer includes AT_RESULT_IND in + EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication. The + peer MUST NOT include AT_RESULT_IND if it did not receive + AT_RESULT_IND from the server. If both the peer and the server used + AT_RESULT_IND, then the EAP exchange is not complete yet, but an + EAP-AKA notification round will follow. The following EAP-AKA + notification may indicate either failure or success. + + Success indications with the AT_NOTIFICATION code "Success" (32768) + can only be used if both the server and the peer indicate they want + to use them with AT_RESULT_IND. If the server did not include + AT_RESULT_IND in the EAP-Request/AKA-Challenge or + EAP-Request/AKA-Reauthentication packet, or if the peer did not + include AT_RESULT_IND in the corresponding response packet, then the + server MUST NOT use protected success indications. + + Because the server uses the AT_NOTIFICATION code "Success" (32768) to + indicate that the EAP exchange has completed successfully, the EAP + exchange cannot fail when the server processes the EAP-AKA response + to this notification. Hence, the server MUST ignore the contents of + the EAP-AKA response it receives to the EAP-Request/AKA-Notification + with this code. Regardless of the contents of the EAP-AKA response, + the server MUST send EAP-Success as the next packet. + +6.3. Error Cases + + This section specifies the operation of the peer and the server in + error cases. The subsections below require the EAP-AKA peer and + server to send an error packet (EAP-Response/AKA-Client-Error, + EAP-Response/AKA-Authentication-Reject or + EAP-Response/AKA-Synchronization-Failure from the peer and + EAP-Request/AKA-Notification from the server) in error cases. + However, implementations SHOULD NOT rely upon the correct error + reporting behavior of the peer, authenticator, or server. It is + possible for error messages and other messages to be lost in transit, + + + +Arkko & Haverinen Informational [Page 40] + +RFC 4187 EAP-AKA Authentication January 2006 + + + or for a malicious participant to attempt to consume resources by not + issuing error messages. Both the peer and the EAP server SHOULD have + a mechanism to clean up state even if an error message or EAP-Success + is not received after a timeout period. + +6.3.1. Peer Operation + + Two special error messages have been specified for error cases that + are related to the processing of the AKA AUTN parameter, as described + in Section 3: (1) if the peer does not accept AUTN, the peer responds + with EAP-Response/AKA-Authentication-Reject (Section 9.5), and the + server issues EAP-Failure, and (2) if the peer detects that the + sequence number in AUTN is not correct, the peer responds with + EAP-Response/AKA-Synchronization-Failure (Section 9.6), and the + server proceeds with a new EAP-Request/AKA-Challenge. + + In other error cases, when an EAP-AKA peer detects an error in a + received EAP-AKA packet, the EAP-AKA peer responds with the + EAP-Response/AKA-Client-Error packet. In response to the + EAP-Response/AKA-Client-Error, the EAP server MUST issue the + EAP-Failure packet, and the authentication exchange terminates. + + By default, the peer uses the client error code 0, "unable to process + packet". This error code is used in the following cases: + + o EAP exchange is not acceptable according to the peer's local + policy. + o The peer is not able to parse the EAP request, i.e., the EAP + request is malformed. + o The peer encountered a malformed attribute. + o Wrong attribute types or duplicate attributes have been included + in the EAP request. + o A mandatory attribute is missing. + o Unrecognized non-skippable attribute. + o Unrecognized or unexpected EAP-AKA Subtype in the EAP request. + o Invalid AT_MAC. The peer SHOULD log this event. + o Invalid AT_CHECKCODE. The peer SHOULD log this event. + o Invalid pad bytes in AT_PADDING. + o The peer does not want to process AT_PERMANENT_ID_REQ. + +6.3.2. Server Operation + + If an EAP-AKA server detects an error in a received EAP-AKA response, + the server MUST issue the EAP-Request/AKA-Notification packet with an + AT_NOTIFICATION code that implies failure. By default, the server + uses one of the general failure codes ("General failure after + authentication" (0) or "General failure" (16384)). The choice + + + + +Arkko & Haverinen Informational [Page 41] + +RFC 4187 EAP-AKA Authentication January 2006 + + + between these two codes depends on the phase of the EAP-AKA exchange, + see Section 6. The error cases when the server issues an + EAP-Request/AKA-Notification that implies failure include the + following: + + o The server is not able to parse the peer's EAP response. + o The server encounters a malformed attribute, a non-recognized + non-skippable attribute, or a duplicate attribute. + o A mandatory attribute is missing or an invalid attribute was + included. + o Unrecognized or unexpected EAP-AKA Subtype in the EAP Response. + o Invalid AT_MAC. The server SHOULD log this event. + o Invalid AT_CHECKCODE. The server SHOULD log this event. + o Invalid AT_COUNTER. + +6.3.3. EAP-Failure + + The EAP-AKA server sends EAP-Failure in three cases: + + 1. In response to an EAP-Response/AKA-Client-Error packet the server + has received from the peer, or + + 2. In response to an EAP-Response/AKA-Authentication-Reject packet + the server has received from the peer, or + + 3. Following an EAP-AKA notification round, when the AT_NOTIFICATION + code implies failure. + + The EAP-AKA server MUST NOT send EAP-Failure in other cases than + these three. However, it should be noted that even though the + EAP-AKA server would not send an EAP-Failure, an authorization + decision that happens outside EAP-AKA, such as in the AAA server or + in an intermediate AAA proxy, may result in a failed exchange. + + The peer MUST accept the EAP-Failure packet in case 1), case 2), and + case 3) above. The peer SHOULD silently discard the EAP-Failure + packet in other cases. + +6.3.4. EAP-Success + + On full authentication, the server can only send EAP-Success after + the EAP/AKA-Challenge round. The peer MUST silently discard any + EAP-Success packets if they are received before the peer has + successfully authenticated the server and sent the + EAP-Response/AKA-Challenge packet. + + + + + + +Arkko & Haverinen Informational [Page 42] + +RFC 4187 EAP-AKA Authentication January 2006 + + + If the peer did not indicate that it wants to use protected success + indications with AT_RESULT_IND (as discussed in Section 6.2) on full + authentication, then the peer MUST accept EAP-Success after a + successful EAP/AKA-Challenge round. + + If the peer indicated that it wants to use protected success + indications with AT_RESULT_IND (as discussed in Section 6.2), then + the peer MUST NOT accept EAP-Success after a successful EAP/ + AKA-Challenge round. In this case, the peer MUST only accept + EAP-Success after receiving an EAP-AKA Notification with the + AT_NOTIFICATION code "Success" (32768). + + On fast re-authentication, EAP-Success can only be sent after the + EAP/AKA-Reauthentication round. The peer MUST silently discard any + EAP-Success packets if they are received before the peer has + successfully authenticated the server and sent the + EAP-Response/AKA-Reauthentication packet. + + If the peer did not indicate that it wants to use protected success + indications with AT_RESULT_IND (as discussed in Section 6.2) on fast + re-authentication, then the peer MUST accept EAP-Success after a + successful EAP/AKA-Reauthentication round. + + If the peer indicated that it wants to use protected success + indications with AT_RESULT_IND (as discussed in Section 6.2), then + the peer MUST NOT accept EAP-Success after a successful EAP/AKA- + Reauthentication round. In this case, the peer MUST only accept + EAP-Success after receiving an EAP-AKA Notification with the + AT_NOTIFICATION code "Success" (32768). + + If the peer receives an EAP-AKA notification (Section 6) that + indicates failure, then the peer MUST no longer accept the + EAP-Success packet, even if the server authentication was + successfully completed. + +7. Key Generation + + This section specifies how keying material is generated. + + On EAP-AKA full authentication, a Master Key (MK) is derived from the + underlying AKA values (CK and IK keys), and the identity, as follows. + + MK = SHA1(Identity|IK|CK) + + In the formula above, the "|" character denotes concatenation. + Identity denotes the peer identity string without any terminating + null characters. It is the identity from the last AT_IDENTITY + attribute sent by the peer in this exchange, or, if AT_IDENTITY was + + + +Arkko & Haverinen Informational [Page 43] + +RFC 4187 EAP-AKA Authentication January 2006 + + + not used, the identity from the EAP-Response/Identity packet. The + identity string is included as-is, without any changes. As discussed + in Section 4.1.2.2, relying on EAP-Response/Identity for conveying + the EAP-AKA peer identity is discouraged, and the server SHOULD use + the EAP-AKA method-specific identity attributes. The hash function + SHA-1 is specified in [SHA-1]. + + The Master Key is fed into a Pseudo-Random number Function (PRF), + which generates separate Transient EAP Keys (TEKs) for protecting + EAP-AKA packets, as well as a Master Session Key (MSK) for link layer + security and an Extended Master Session Key (EMSK) for other + purposes. On fast re-authentication, the same TEKs MUST be used for + protecting EAP packets, but a new MSK and a new EMSK MUST be derived + from the original MK and from new values exchanged in the fast + re-authentication. + + EAP-AKA requires two TEKs for its own purposes: the authentication + key K_aut, to be used with the AT_MAC attribute, and the encryption + key K_encr, to be used with the AT_ENCR_DATA attribute. The same + K_aut and K_encr keys are used in full authentication and subsequent + fast re-authentications. + + Key derivation is based on the random number generation specified in + NIST Federal Information Processing Standards (FIPS) Publication + 186-2 [PRF]. The pseudo-random number generator is specified in the + change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As + specified in the change notice (page 74), when Algorithm 1 is used as + a general-purpose pseudo-random number generator, the "mod q" term in + step 3.3 is omitted. The function G used in the algorithm is + constructed via Secure Hash Standard as specified in Appendix 3.3 of + the standard. It should be noted that the function G is very similar + to SHA-1, but the message padding is different. Please refer to + [PRF] for full details. For convenience, the random number algorithm + with the correct modification is cited in Annex A. + + 160-bit XKEY and XVAL values are used, so b = 160. On each full + authentication, the Master Key is used as the initial secret seed-key + XKEY. The optional user input values (XSEED_j) in step 3.1 are set + to zero. + + On full authentication, the resulting 320-bit random numbers x_0, + x_1, ..., x_m-1 are concatenated and partitioned into suitable-sized + chunks and used as keys in the following order: K_encr (128 bits), + K_aut (128 bits), Master Session Key (64 bytes), Extended Master + Session Key (64 bytes). + + + + + + +Arkko & Haverinen Informational [Page 44] + +RFC 4187 EAP-AKA Authentication January 2006 + + + On fast re-authentication, the same pseudo-random number generator + can be used to generate a new Master Session Key and a new Extended + Master Session Key. The seed value XKEY' is calculated as follows: + + XKEY' = SHA1(Identity|counter|NONCE_S| MK) + + In the formula above, the Identity denotes the fast re-authentication + identity, without any terminating null characters, from the + AT_IDENTITY attribute of the EAP-Response/AKA-Identity packet, or, if + EAP-Response/AKA-Identity was not used on fast re-authentication, it + denotes the identity string from the EAP-Response/Identity packet. + The counter denotes the counter value from the AT_COUNTER attribute + used in the EAP-Response/AKA-Reauthentication packet. The counter is + used in network byte order. NONCE_S denotes the 16-byte random + NONCE_S value from the AT_NONCE_S attribute used in the + EAP-Request/AKA-Reauthentication packet. The MK is the Master Key + derived on the preceding full authentication. + + On fast re-authentication, the pseudo-random number generator is run + with the new seed value XKEY', and the resulting 320-bit random + numbers x_0, x_1, ..., x_m-1 are concatenated and partitioned into + 64-byte chunks and used as the new 64-byte Master Session Key and the + new 64-byte Extended Master Session Key. Note that because K_encr + and K_aut are not derived on fast re-authentication, the Master + Session Key and the Extended Master Session key are obtained from the + beginning of the key stream x_0, x_1, .... + + The first 32 bytes of the MSK can be used as the Pairwise Master Key + (PMK) for IEEE 802.11i. + + When the RADIUS attributes specified in [RFC2548] are used to + transport keying material, then the first 32 bytes of the MSK + correspond to MS-MPPE-RECV-KEY and the second 32 bytes to + MS-MPPE-SEND-KEY. In this case, only 64 bytes of keying material + (the MSK) are used. + +8. Message Format and Protocol Extensibility + +8.1. Message Format + + As specified in [RFC3748], EAP packets begin with the Code, + Identifiers, Length, and Type fields, which are followed by + EAP-method-specific Type-Data. The Code field in the EAP header is + set to 1 for EAP requests, and to 2 for EAP Responses. The usage of + the Length and Identifier fields in the EAP header is also specified + in [RFC3748]. In EAP-AKA, the Type field is set to 23. + + + + + +Arkko & Haverinen Informational [Page 45] + +RFC 4187 EAP-AKA Authentication January 2006 + + + In EAP-AKA, the Type-Data begins with an EAP-AKA header that consists + of a 1-octet Subtype field, and a 2-octet reserved field. The + Subtype values used in EAP-AKA are defined in Section 11. The + formats of the EAP header and the EAP-AKA header are shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Subtype | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The rest of the Type-Data, immediately following the EAP-AKA header, + consists of attributes that are encoded in Type, Length, Value + format. The figure below shows the generic format of an attribute. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |Attribute Type | Length | Value... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Attribute Type + + Indicates the particular type of attribute. The attribute type + values are listed in Section 11. + + Length + + Indicates the length of this attribute in multiples of 4 bytes. + The maximum length of an attribute is 1024 bytes. The length + includes the Attribute Type and Length bytes. + + Value + + The particular data associated with this attribute. This field + is always included and it is two or more bytes in length. The + type and length fields determine the format and length of the + value field. + + Attributes numbered within the range 0 through 127 are called + non-skippable attributes. When an EAP-AKA peer encounters a + non-skippable attribute type that the peer does not recognize, the + peer MUST send the EAP-Response/AKA-Client-Error packet, and the + authentication exchange terminates. If an EAP-AKA server encounters + a non-skippable attribute that the server does not recognize, then + the server sends EAP-Request/AKA-Notification packet with an + + + +Arkko & Haverinen Informational [Page 46] + +RFC 4187 EAP-AKA Authentication January 2006 + + + AT_NOTIFICATION code that implies general failure ("General failure + after authentication" (0), or "General failure" (16384), depending on + the phase of the exchange), and the authentication exchange + terminates. + + When an attribute numbered in the range 128 through 255 is + encountered but not recognized, that particular attribute is ignored, + but the rest of the attributes and message data MUST still be + processed. The Length field of the attribute is used to skip the + attribute value when searching for the next attribute. These + attributes are called skippable attributes. + + Unless otherwise specified, the order of the attributes in an EAP-AKA + message is insignificant, and an EAP-AKA implementation should not + assume a certain order will be used. + + Attributes can be encapsulated within other attributes. In other + words, the value field of an attribute type can be specified to + contain other attributes. + +8.2. Protocol Extensibility + + EAP-AKA can be extended by specifying new attribute types. If + skippable attributes are used, it is possible to extend the protocol + without breaking old implementations. As specified in Section 10.13, + if new attributes are specified for EAP-Request/AKA-Identity or + EAP-Response/AKA-Identity, then the AT_CHECKCODE MUST be used to + integrity protect the new attributes. + + When specifying new attributes, it should be noted that EAP-AKA does + not support message fragmentation. Hence, the sizes of the new + extensions MUST be limited so that the maximum transfer unit (MTU) of + the underlying lower layer is not exceeded. According to [RFC3748], + lower layers must provide an EAP MTU of 1020 bytes or greater, so any + extensions to EAP-AKA SHOULD NOT exceed the EAP MTU of 1020 bytes. + + EAP-AKA packets do not include a version field. However, should + there be a reason to revise this protocol in the future, new + non-skippable or skippable attributes could be specified in order to + implement revised EAP-AKA versions in a backward-compatible manner. + It is possible to introduce version negotiation in the + EAP-Request/AKA-Identity and EAP-Response/AKA-Identity messages by + specifying new skippable attributes. + + + + + + + + +Arkko & Haverinen Informational [Page 47] + +RFC 4187 EAP-AKA Authentication January 2006 + + +9. Messages + + This section specifies the messages used in EAP-AKA. It specifies + when a message may be transmitted or accepted, which attributes are + allowed in a message, which attributes are required in a message, and + other message-specific details. Message format is specified in + Section 8.1. + +9.1. EAP-Request/AKA-Identity + + The EAP/AKA-Identity roundtrip MAY be used for obtaining the peer + identity from the server. As discussed in Section 4.1, several + AKA-Identity rounds may be required in order to obtain a valid peer + identity. + + The server MUST include one of the following identity requesting + attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, AT_ANY_ID_REQ. + These three attributes are mutually exclusive, so the server MUST NOT + include more than one of the attributes. + + If the server has previously issued an EAP-Request/AKA-Identity + message with the AT_PERMANENT_ID_REQ attribute, and if the server has + received a response from the peer, then the server MUST NOT issue a + new EAP-Request/AKA-Identity packet. + + If the server has previously issued an EAP-Request/AKA-Identity + message with the AT_FULLAUTH_ID_REQ attribute, and if the server has + received a response from the peer, then the server MUST NOT issue a + new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ or + AT_FULLAUTH_ID_REQ attributes. + + If the server has previously issued an EAP-Request/AKA-Identity + message with the AT_ANY_ID_REQ attribute, and if the server has + received a response from the peer, then the server MUST NOT issue a + new EAP-Request/AKA-Identity packet with the AT_ANY_ID_REQ. + + This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA. + +9.2. EAP-Response/AKA-Identity + + The peer sends EAP-Response/AKA-Identity in response to a valid + EAP-Request/AKA-Identity from the server. + + The peer MUST include the AT_IDENTITY attribute. The usage of + AT_IDENTITY is defined in Section 4.1. + + This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA. + + + + +Arkko & Haverinen Informational [Page 48] + +RFC 4187 EAP-AKA Authentication January 2006 + + +9.3. EAP-Request/AKA-Challenge + + The server sends the EAP-Request/AKA-Challenge on full authentication + after successfully obtaining the subscriber identity. + + The AT_RAND attribute MUST be included. + + AT_MAC MUST be included. In EAP-Request/AKA-Challenge, there is no + message-specific data covered by the MAC, see Section 10.15. + + The AT_RESULT_IND attribute MAY be included. The usage of this + attribute is discussed in Section 6.2. + + The AT_CHECKCODE attribute MAY be included, and in certain cases + specified in Section 10.13, it MUST be included. + + The EAP-Request/AKA-Challenge packet MAY include encrypted attributes + for identity privacy and for communicating the next re-authentication + identity. In this case, the AT_IV and AT_ENCR_DATA attributes are + included (Section 10.12). + + The plaintext of the AT_ENCR_DATA value field consists of nested + attributes. The nested attributes MAY include AT_PADDING (as + specified in Section 10.12). If the server supports identity privacy + and wants to communicate a pseudonym to the peer for the next full + authentication, then the nested encrypted attributes include the + AT_NEXT_PSEUDONYM attribute. If the server supports + re-authentication and wants to communicate a fast re-authentication + identity to the peer, then the nested encrypted attributes include + the AT_NEXT_REAUTH_ID attribute. Later versions of this protocol MAY + specify additional attributes to be included within the encrypted + data. + + When processing this message, the peer MUST process AT_RAND and + AT_AUTN before processing other attributes. Only if these attributes + are verified to be valid, the peer derives keys and verifies AT_MAC. + The operation in case an error occurs is specified in Section 6.3.1. + +9.4. EAP-Response/AKA-Challenge + + The peer sends EAP-Response/AKA-Challenge in response to a valid + EAP-Request/AKA-Challenge. + + Sending this packet indicates that the peer has successfully + authenticated the server and that the EAP exchange will be accepted + by the peer's local policy. Hence, if these conditions are not met, + then the peer MUST NOT send EAP-Response/AKA-Challenge, but the peer + MUST send EAP-Response/AKA-Client-Error. + + + +Arkko & Haverinen Informational [Page 49] + +RFC 4187 EAP-AKA Authentication January 2006 + + + The AT_MAC attribute MUST be included. In + EAP-Response/AKA-Challenge, there is no message-specific data covered + by the MAC, see Section 10.15. + + The AT_RES attribute MUST be included. + + The AT_CHECKCODE attribute MAY be included, and in certain cases + specified in Section 10.13, it MUST be included. + + The AT_RESULT_IND attribute MAY be included, if it was included in + EAP-Request/AKA-Challenge. The usage of this attribute is discussed + in Section 6.2. + + Later versions of this protocol MAY make use of the AT_ENCR_DATA and + AT_IV attributes in this message to include encrypted (skippable) + attributes. The EAP server MUST process EAP-Response/AKA-Challenge + messages that include these attributes even if the server did not + implement these optional attributes. + +9.5. EAP-Response/AKA-Authentication-Reject + + The peer sends the EAP-Response/AKA-Authentication-Reject packet if + it does not accept the AUTN parameter. This version of the protocol + does not specify any attributes for this message. Future versions of + the protocol MAY specify attributes for this message. + + The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in + this message. + +9.6. EAP-Response/AKA-Synchronization-Failure + + The peer sends the EAP-Response/AKA-Synchronization-Failure, when the + sequence number in the AUTN parameter is incorrect. + + The peer MUST include the AT_AUTS attribute. Future versions of the + protocol MAY specify other additional attributes for this message. + + The AT_MAC, AT_ENCR_DATA, or AT_IV attributes MUST NOT be used in + this message. + +9.7. EAP-Request/AKA-Reauthentication + + The server sends the EAP-Request/AKA-Reauthentication message if it + wants to use fast re-authentication, and if it has received a valid + fast re-authentication identity in EAP-Response/Identity or + EAP-Response/AKA-Identity. + + + + + +Arkko & Haverinen Informational [Page 50] + +RFC 4187 EAP-AKA Authentication January 2006 + + + The AT_MAC attribute MUST be included. No message-specific data is + included in the MAC calculation, see Section 10.15. + + The AT_RESULT_IND attribute MAY be included. The usage of this + attribute is discussed in Section 6.2. + + The AT_CHECKCODE attribute MAY be included, and in certain cases + specified in Section 10.13, it MUST be included. + + The AT_IV and AT_ENCR_DATA attributes MUST be included. The + plaintext consists of the following nested encrypted attributes, + which MUST be included: AT_COUNTER and AT_NONCE_S. In addition, the + nested encrypted attributes MAY include the following attributes: + AT_NEXT_REAUTH_ID and AT_PADDING. + +9.8. EAP-Response/AKA-Reauthentication + + The client sends the EAP-Response/AKA-Reauthentication packet in + response to a valid EAP-Request/AKA-Reauthentication. + + The AT_MAC attribute MUST be included. For + EAP-Response/AKA-Reauthentication, the MAC code is calculated over + the following data: EAP packet| NONCE_S. The EAP packet is + represented as specified in Section 8.1. It is followed by the + 16-byte NONCE_S value from the server's AT_NONCE_S attribute. + + The AT_CHECKCODE attribute MAY be included, and in certain cases + specified in Section 10.13, it MUST be included. + + The AT_IV and AT_ENCR_DATA attributes MUST be included. The nested + encrypted attributes MUST include the AT_COUNTER attribute. The + AT_COUNTER_TOO_SMALL attribute MAY be included in the nested + encrypted attributes, and it is included in cases specified in + Section 5. The AT_PADDING attribute MAY be included. + + The AT_RESULT_IND attribute MAY be included, if it was included in + EAP-Request/AKA-Reauthentication. The usage of this attribute is + discussed in Section 6.2. + + Sending this packet without AT_COUNTER_TOO_SMALL indicates that the + peer has successfully authenticated the server and that the EAP + exchange will be accepted by the peer's local policy. Hence, if + these conditions are not met, then the peer MUST NOT send + EAP-Response/AKA-Reauthentication, but the peer MUST send + EAP-Response/ AKA-Client-Error. + + + + + + +Arkko & Haverinen Informational [Page 51] + +RFC 4187 EAP-AKA Authentication January 2006 + + +9.9. EAP-Response/AKA-Client-Error + + The peer sends EAP-Response/AKA-Client-Error in error cases, as + specified in Section 6.3.1. + + The AT_CLIENT_ERROR_CODE attribute MUST be included. The AT_MAC, + AT_IV, or AT_ENCR_DATA attributes MUST NOT be used with this packet. + +9.10. EAP-Request/AKA-Notification + + The usage of this message is specified in Section 6. + + The AT_NOTIFICATION attribute MUST be included. + + The AT_MAC attribute MUST be included if the P bit of the + AT_NOTIFICATION code is set to zero, and MUST NOT be included if the + P bit is set to one. The P bit is discussed in Section 6. + + No message-specific data is included in the MAC calculation. See + Section 10.15. + + If EAP-Request/AKA-Notification is used on a fast re-authentication + exchange, and if the P bit in AT_NOTIFICATION is set to zero, then + AT_COUNTER is used for replay protection. In this case, the + AT_ENCR_DATA and AT_IV attributes MUST be included, and the + encapsulated plaintext attributes MUST include the AT_COUNTER + attribute. The counter value included in AT_COUNTER MUST be the same + as in the EAP-Request/AKA-Reauthentication packet on the same fast + re-authentication exchange. + +9.11. EAP-Response/AKA-Notification + + The usage of this message is specified in Section 6. This packet is + an acknowledgement of EAP-Request/AKA-Notification. + + The AT_MAC attribute MUST be included in cases when the P bit of the + notification code in AT_NOTIFICATION of EAP-Request/AKA-Notification + is set to zero, and MUST NOT be included in cases when the P bit is + set to one. The P bit is discussed in Section 6. + + If EAP-Request/AKA-Notification is used on a fast re-authentication + exchange, and if the P bit in AT_NOTIFICATION is set to zero, then + AT_COUNTER is used for replay protection. In this case, the + AT_ENCR_DATA and AT_IV attributes MUST be included, and the + encapsulated plaintext attributes MUST include the AT_COUNTER + attribute. The counter value included in AT_COUNTER MUST be the same + as in the EAP-Request/AKA-Reauthentication packet on the same fast + re-authentication exchange. + + + +Arkko & Haverinen Informational [Page 52] + +RFC 4187 EAP-AKA Authentication January 2006 + + +10. Attributes + + This section specifies the format of message attributes. The + attribute type numbers are specified in Section 11. + +10.1. Table of Attributes + + The following table provides a guide to which attributes may be found + in which kinds of messages, and in what quantity. Messages are + denoted with numbers in parentheses as follows: (1) EAP-Request/ + AKA-Identity, (2) EAP-Response/AKA-Identity, (3) EAP-Request/ + AKA-Challenge, (4) EAP-Response/AKA-Challenge, (5) EAP-Request/ + AKA-Notification, (6) EAP-Response/AKA-Notification, (7) EAP- + Response/AKA-Client-Error (8) EAP-Request/AKA-Reauthentication, (9) + EAP-Response/AKA-Reauthentication, (10) EAP-Response/AKA- + Authentication-Reject, and (11) EAP-Response/AKA-Synchronization- + Failure. The column denoted with "E" indicates whether the attribute + is a nested attribute that MUST be included within AT_ENCR_DATA. + + "0" indicates that the attribute MUST NOT be included in the message, + "1" indicates that the attribute MUST be included in the message, + "0-1" indicates that the attribute is sometimes included in the + message, and "0*" indicates that the attribute is not included in the + message in cases specified in this document, but MAY be included in + the future versions of the protocol. + + Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) (10)(11) E + AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N + AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N + AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 0 0 N + AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 0 0 N + AT_RAND 0 0 1 0 0 0 0 0 0 0 0 N + AT_AUTN 0 0 1 0 0 0 0 0 0 0 0 N + AT_RES 0 0 0 1 0 0 0 0 0 0 0 N + AT_AUTS 0 0 0 0 0 0 0 0 0 0 1 N + AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 0 0 Y + AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 0 0 Y + AT_IV 0 0 0-1 0* 0-1 0-1 0 1 1 0 0 N + AT_ENCR_DATA 0 0 0-1 0* 0-1 0-1 0 1 1 0 0 N + AT_PADDING 0 0 0-1 0* 0-1 0-1 0 0-1 0-1 0 0 Y + AT_CHECKCODE 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N + AT_RESULT_IND 0 0 0-1 0-1 0 0 0 0-1 0-1 0 0 N + AT_MAC 0 0 1 1 0-1 0-1 0 1 1 0 0 N + AT_COUNTER 0 0 0 0 0-1 0-1 0 1 1 0 0 Y + AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 0 0 Y + AT_NONCE_S 0 0 0 0 0 0 0 1 0 0 0 Y + AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 0 0 N + AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 0 0 N + + + +Arkko & Haverinen Informational [Page 53] + +RFC 4187 EAP-AKA Authentication January 2006 + + + It should be noted that attributes AT_PERMANENT_ID_REQ, + AT_ANY_ID_REQ, and AT_FULLAUTH_ID_REQ are mutually exclusive, so that + only one of them can be included at the same time. If one of the + attributes AT_IV or AT_ENCR_DATA is included, then both of the + attributes MUST be included. + +10.2. AT_PERMANENT_ID_REQ + + The format of the AT_PERMANENT_ID_REQ attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |AT_PERM..._REQ | Length = 1 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The use of the AT_PERMANENT_ID_REQ is defined in Section 4.1. The + value field only contains two reserved bytes, which are set to zero + on sending and ignored on reception. + +10.3. AT_ANY_ID_REQ + + The format of the AT_ANY_ID_REQ attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |AT_ANY_ID_REQ | Length = 1 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The use of the AT_ANY_ID_REQ is defined in Section 4.1. The value + field only contains two reserved bytes, which are set to zero on + sending and ignored on reception. + +10.4. AT_FULLAUTH_ID_REQ + + The format of the AT_FULLAUTH_ID_REQ attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |AT_FULLAUTH_...| Length = 1 | Reserved | + +---------------+---------------+-------------------------------+ + + The use of the AT_FULLAUTH_ID_REQ is defined in Section 4.1. The + value field only contains two reserved bytes, which are set to zero + on sending and ignored on reception. + + + + +Arkko & Haverinen Informational [Page 54] + +RFC 4187 EAP-AKA Authentication January 2006 + + +10.5. AT_IDENTITY + + The format of the AT_IDENTITY attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_IDENTITY | Length | Actual Identity Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . Identity . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The use of the AT_IDENTITY is defined in Section 4.1. The value + field of this attribute begins with 2-byte actual identity length, + which specifies the length of the identity in bytes. This field is + followed by the subscriber identity of the indicated actual length. + The identity is the permanent identity, a pseudonym identity or a + fast re-authentication identity. The identity format is specified in + Section 4.1.1. The same identity format is used in the AT_IDENTITY + attribute and the EAP-Response/Identity packet, with the exception + that the peer MUST NOT decorate the identity it includes in + AT_IDENTITY. The identity does not include any terminating null + characters. Because the length of the attribute must be a multiple + of 4 bytes, the sender pads the identity with zero bytes when + necessary. + +10.6. AT_RAND + + The format of the AT_RAND attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_RAND | Length = 5 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | RAND | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The value field of this attribute contains two reserved bytes + followed by the AKA RAND parameter, 16 bytes (128 bits). The + reserved bytes are set to zero when sending and ignored on reception. + + + + +Arkko & Haverinen Informational [Page 55] + +RFC 4187 EAP-AKA Authentication January 2006 + + +10.7. AT_AUTN + + The format of the AT_AUTN attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_AUTN | Length = 5 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | AUTN | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The value field of this attribute contains two reserved bytes + followed by the AKA AUTN parameter, 16 bytes (128 bits). The + reserved bytes are set to zero when sending and ignored on reception. + +10.8. AT_RES + + The format of the AT_RES attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_RES | Length | RES Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + | RES | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The value field of this attribute begins with the 2-byte RES Length, + which identifies the exact length of the RES in bits. The RES length + is followed by the AKA RES parameter. According to [TS33.105], the + length of the AKA RES can vary between 32 and 128 bits. Because the + length of the AT_RES attribute must be a multiple of 4 bytes, the + sender pads the RES with zero bits where necessary. + + + + + + + + + + + +Arkko & Haverinen Informational [Page 56] + +RFC 4187 EAP-AKA Authentication January 2006 + + +10.9. AT_AUTS + + The format of the AT_AUTS attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| + | AT_AUTS | Length = 4 | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + | AUTS | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The value field of this attribute contains the AKA AUTS parameter, + 112 bits (14 bytes). + +10.10. AT_NEXT_PSEUDONYM + + The format of the AT_NEXT_PSEUDONYM attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_NEXT_PSEU..| Length | Actual Pseudonym Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . Next Pseudonym . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The value field of this attribute begins with a 2-byte actual + pseudonym length, which specifies the length of the following + pseudonym in bytes. This field is followed by a pseudonym username + that the peer can use in the next authentication. The username MUST + NOT include any realm portion. The username does not include any + terminating null characters. Because the length of the attribute + must be a multiple of 4 bytes, the sender pads the pseudonym with + zero bytes when necessary. The username encoding MUST follow the + UTF-8 transformation format [RFC3629]. This attribute MUST always be + encrypted by encapsulating it within the AT_ENCR_DATA attribute. + + + + + + + + + +Arkko & Haverinen Informational [Page 57] + +RFC 4187 EAP-AKA Authentication January 2006 + + +10.11. AT_NEXT_REAUTH_ID + + The format of the AT_NEXT_REAUTH_ID attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_NEXT_REAU..| Length | Actual Re-Auth Identity Length| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . Next Fast Re-Authentication Username . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The value field of this attribute begins with a 2-byte actual + re-authentication identity length which specifies the length of the + following fast re-authentication identity in bytes. This field is + followed by a fast re-authentication identity that the peer can use + in the next fast re-authentication, as described in Section 5. In + environments where a realm portion is required, the fast + re-authentication identity includes both a username portion and a + realm name portion. The fast re-authentication identity does not + include any terminating null characters. Because the length of the + attribute must be a multiple of 4 bytes, the sender pads the fast + re-authentication identity with zero bytes when necessary. The + identity encoding MUST follow the UTF-8 transformation format + [RFC3629]. This attribute MUST always be encrypted by encapsulating + it within the AT_ENCR_DATA attribute. + +10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING + + AT_IV and AT_ENCR_DATA attributes can be used to transmit encrypted + information between the EAP-AKA peer and server. + + The value field of AT_IV contains two reserved bytes followed by a + 16-byte initialization vector required by the AT_ENCR_DATA attribute. + The reserved bytes are set to zero when sending and ignored on + reception. The AT_IV attribute MUST be included if and only if the + AT_ENCR_DATA is included. Section 6.3 specifies the operation if a + packet that does not meet this condition is encountered. + + The sender of the AT_IV attribute chooses the initialization vector + at random. The sender MUST NOT reuse the initialization vector value + from previous EAP-AKA packets. The sender SHOULD use a good source + of randomness to generate the initialization vector. Please see + [RFC4086] for more information about generating random numbers for + security applications. The format of AT_IV is shown below. + + + +Arkko & Haverinen Informational [Page 58] + +RFC 4187 EAP-AKA Authentication January 2006 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_IV | Length = 5 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Initialization Vector | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The value field of the AT_ENCR_DATA attribute consists of two + reserved bytes followed by cipher text bytes. The cipher text bytes + are encrypted using the Advanced Encryption Standard (AES) [AES] with + a 128-bit key in the Cipher Block Chaining (CBC) mode of operation, + which uses the initialization vector from the AT_IV attribute. The + reserved bytes are set to zero when sending and ignored on reception. + Please see [CBC] for a description of the CBC mode. The format of + the AT_ENCR_DATA attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_ENCR_DATA | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + . Encrypted Data . + . . + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The derivation of the encryption key (K_encr) is specified in + Section 7. + + The plaintext consists of nested EAP-AKA attributes. + + The encryption algorithm requires the length of the plaintext to be a + multiple of 16 bytes. The sender may need to include the AT_PADDING + attribute as the last attribute within AT_ENCR_DATA. The AT_PADDING + attribute is not included if the total length of other nested + attributes within the AT_ENCR_DATA attribute is a multiple of 16 + bytes. As usual, the Length of the Padding attribute includes the + Attribute Type and Attribute Length fields. The length of the + Padding attribute is 4, 8, or 12 bytes. It is chosen so that the + length of the value field of the AT_ENCR_DATA attribute becomes a + multiple of 16 bytes. The actual pad bytes in the value field are + set to zero (00 hexadecimal) on sending. The recipient of the + message MUST verify that the pad bytes are set to zero. If this + + + +Arkko & Haverinen Informational [Page 59] + +RFC 4187 EAP-AKA Authentication January 2006 + + + verification fails on the peer, then it MUST send the + EAP-Response/AKA-Client-Error packet with the error code "unable to + process packet" to terminate the authentication exchange. If this + verification fails on the server, then the server sends the + EAP-Response/AKA-Notification packet with an AT_NOTIFICATION code + that implies failure to terminate the authentication exchange. The + format of the AT_PADDING attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_PADDING | Length | Padding... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +10.13. AT_CHECKCODE + + The AT_MAC attribute is not used in the very first EAP-AKA messages + during the AKA-Identity round, because keying material has not been + derived yet. The peer and the server may exchange one or more pairs + of EAP-AKA messages of the Subtype AKA-Identity before keys are + derived and before the AT_MAC attribute can be applied. The EAP/- + AKA-Identity messages may also be used upon fast re-authentication. + + The AT_CHECKCODE attribute MAY be used to protect the EAP/ + AKA-Identity messages. In full authentication, the server MAY + include the AT_CHECKCODE in EAP-Request/AKA-Challenge, and the peer + MAY include AT_CHECKCODE in EAP-Response/AKA-Challenge. In fast + re-authentication, the server MAY include AT_CHECKCODE in + EAP-Request/ AKA-Reauthentication, and the peer MAY include + AT_CHECKCODE in EAP-Response/AKA-Reauthentication. The fact that the + peer receives an EAP-Request with AT_CHECKCODE does not imply that + the peer would have to include AT_CHECKCODE in the corresponding + response. The peer MAY include AT_CHECKCODE even if the server did + not include AT_CHECKCODE in the EAP request. Because the AT_MAC + attribute is used in these messages, AT_CHECKCODE will be integrity + protected with AT_MAC. The format of the AT_CHECKCODE attribute is + shown below. + + + + + + + + + + + +Arkko & Haverinen Informational [Page 60] + +RFC 4187 EAP-AKA Authentication January 2006 + + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_CHECKCODE | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Checkcode (0 or 20 bytes) | + | | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The value field of AT_CHECKCODE begins with two reserved bytes, which + may be followed by a 20-byte checkcode. If the checkcode is not + included in AT_CHECKCODE, then the attribute indicates that no EAP/- + AKA-Identity messages were exchanged. This may occur in both full + authentication and fast re-authentication. The reserved bytes are + set to zero when sending and ignored on reception. + + The checkcode is a hash value, calculated with SHA1 [SHA-1], over all + EAP-Request/AKA-Identity and EAP-Response/AKA-Identity packets + exchanged in this authentication exchange. The packets are included + in the order that they were transmitted, that is, starting with the + first EAP-Request/AKA-Identity message, followed by the corresponding + EAP-Response/AKA-Identity, followed by the second + EAP-Request/AKA-Identity (if used), etc. + + EAP packets are included in the hash calculation "as-is" (as they + were transmitted or received). All reserved bytes, padding bytes, + etc., that are specified for various attributes are included as such, + and the receiver must not reset them to zero. No delimiter bytes, + padding, or any other framing are included between the EAP packets + when calculating the checkcode. + + Messages are included in request/response pairs; in other words, only + full "round trips" are included. Packets that are silently discarded + are not included, and retransmitted packets (that have the same + Identifier value) are only included once. (The base EAP protocol + [RFC3748] ensures that requests and responses "match".) The EAP + server must only include an EAP-Request/AKA-Identity in the + calculation after it has received a corresponding response with the + same Identifier value. + + The peer must include the EAP-Request/AKA-Identity and the + corresponding response in the calculation only if the peer receives a + subsequent EAP-Request/AKA-Challenge or a follow-up EAP-Request/ + AKA-Identity with a different Identifier value than in the first + EAP-Request/AKA-Identity. + + + +Arkko & Haverinen Informational [Page 61] + +RFC 4187 EAP-AKA Authentication January 2006 + + + The AT_CHECKCODE attribute is optional to implement. It is specified + in order to allow protection of the EAP/AKA-Identity messages and any + future extensions to them. The implementation of AT_CHECKCODE is + RECOMMENDED. + + If the receiver of AT_CHECKCODE implements this attribute, then the + receiver MUST check that the checkcode is correct. If the checkcode + is invalid, the receiver must operate as specified in Section 6.3. + + If the EAP/AKA-Identity messages are extended with new attributes, + then AT_CHECKCODE MUST be implemented and used. More specifically, + if the server includes any attributes other than AT_PERMANENT_ID_REQ, + AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ in the EAP-Request/AKA-Identity + packet, then the server MUST include AT_CHECKCODE in EAP-Request/ + AKA-Challenge or EAP-Request/AKA-Reauthentication. If the peer + includes any attributes other than AT_IDENTITY in the EAP-Response/ + AKA-Identity message, then the peer MUST include AT_CHECKCODE in + EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication. + + If the server implements the processing of any other attribute than + AT_IDENTITY for the EAP-Response/AKA-Identity message, then the + server MUST implement AT_CHECKCODE. In this case, if the server + receives any attribute other than AT_IDENTITY in the + EAP-Response/AKA-Identity message, then the server MUST check that + AT_CHECKCODE is present in EAP-Response/AKA-Challenge or + EAP-Response/ AKA-Reauthentication. The operation when a mandatory + attribute is missing is specified in Section 6.3. + + Similarly, if the peer implements the processing of any attribute + other than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ + for the EAP-Request/AKA-Identity packet, then the peer MUST implement + AT_CHECKCODE. In this case, if the peer receives any attribute other + than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ in the + EAP-Request/AKA-Identity packet, then the peer MUST check that + AT_CHECKCODE is present in EAP-Request/AKA-Challenge or + EAP-Request/AKA-Reauthentication. The operation when a mandatory + attribute is missing is specified in Section 6.3. + +10.14. AT_RESULT_IND + + The format of the AT_RESULT_IND attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_RESULT_...| Length = 1 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Arkko & Haverinen Informational [Page 62] + +RFC 4187 EAP-AKA Authentication January 2006 + + + The value field of this attribute consists of two reserved bytes, + which are set to zero upon sending and ignored upon reception. This + attribute is always sent unencrypted, so it MUST NOT be encapsulated + within the AT_ENCR_DATA attribute. + +10.15. AT_MAC + + The AT_MAC attribute is used for EAP-AKA message authentication. + Section 9 specifies in which messages AT_MAC MUST be included. + + The value field of the AT_MAC attribute contains two reserved bytes + followed by a keyed message authentication code (MAC). The MAC is + calculated over the whole EAP packet and concatenated with optional + message-specific data, with the exception that the value field of the + MAC attribute is set to zero when calculating the MAC. The EAP + packet includes the EAP header that begins with the Code field, the + EAP-AKA header that begins with the Subtype field, and all the + attributes, as specified in Section 8.1. The reserved bytes in + AT_MAC are set to zero when sending and ignored on reception. The + contents of the message-specific data that may be included in the MAC + calculation are specified separately for each EAP-AKA message in + Section 9. + + The format of the AT_MAC attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_MAC | Length = 5 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | MAC | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value. (The + HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by + truncating the output to 16 bytes. Hence, the length of the MAC is + 16 bytes.) The derivation of the authentication key (K_aut) used in + the calculation of the MAC is specified in Section 7. + + When the AT_MAC attribute is included in an EAP-AKA message, the + recipient MUST process the AT_MAC attribute before looking at any + other attributes, except when processing EAP-Request/AKA-Challenge. + The processing of EAP-Request/AKA-Challenge is specified in + + + + + +Arkko & Haverinen Informational [Page 63] + +RFC 4187 EAP-AKA Authentication January 2006 + + + Section 9.3. If the message authentication code is invalid, then the + recipient MUST ignore all other attributes in the message and operate + as specified in Section 6.3. + +10.16. AT_COUNTER + + The format of the AT_COUNTER attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_COUNTER | Length = 1 | Counter | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The value field of the AT_COUNTER attribute consists of a 16-bit + unsigned integer counter value, represented in network byte order. + This attribute MUST always be encrypted by encapsulating it within + the AT_ENCR_DATA attribute. + +10.17. AT_COUNTER_TOO_SMALL + + The format of the AT_COUNTER_TOO_SMALL attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_COUNTER...| Length = 1 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The value field of this attribute consists of two reserved bytes, + which are set to zero upon sending and ignored upon reception. This + attribute MUST always be encrypted by encapsulating it within the + AT_ENCR_DATA attribute. + + + + + + + + + + + + + + + + + + +Arkko & Haverinen Informational [Page 64] + +RFC 4187 EAP-AKA Authentication January 2006 + + +10.18. AT_NONCE_S + + The format of the AT_NONCE_S attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AT_NONCE_S | Length = 5 | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | | + | NONCE_S | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The value field of the AT_NONCE_S attribute contains two reserved + bytes followed by a random number (16 bytes) that is freshly + generated by the server for this EAP-AKA fast re-authentication. The + random number is used as challenge for the peer and also as a seed + value for the new keying material. The reserved bytes are set to + zero upon sending and ignored upon reception. This attribute MUST + always be encrypted by encapsulating it within the AT_ENCR_DATA + attribute. + + The server MUST NOT reuse the NONCE_S value from a previous EAP-AKA + fast re-authentication exchange. The server SHOULD use a good source + of randomness to generate NONCE_S. Please see [RFC4086] for more + information about generating random numbers for security + applications. + +10.19. AT_NOTIFICATION + + The format of the AT_NOTIFICATION attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |AT_NOTIFICATION| Length = 1 |S|P| Notification Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The value field of this attribute contains a two-byte notification + code. The first and second bit (S and P) of the notification code + are interpreted as described in Section 6. + + + + + + + +Arkko & Haverinen Informational [Page 65] + +RFC 4187 EAP-AKA Authentication January 2006 + + + The notification code values listed below have been reserved. The + descriptions below illustrate the semantics of the notifications. + The peer implementation MAY use different wordings when presenting + the notifications to the user. The "requested service" depends on + the environment where EAP-AKA is applied. + + 0 - General failure after authentication. (Implies failure, used + after successful authentication.) + + 16384 - General failure. (Implies failure, used before + authentication.) + + 32768 - Success. User has been successfully authenticated. (Does + not imply failure, used after successful authentication.) The usage + of this code is discussed in Section 6.2. + + 1026 - User has been temporarily denied access to the requested + service. (Implies failure, used after successful authentication.) + + 1031 - User has not subscribed to the requested service. (Implies + failure, used after successful authentication.) + +10.20. AT_CLIENT_ERROR_CODE + + The format of the AT_CLIENT_ERROR_CODE attribute is shown below. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |AT_CLIENT_ERR..| Length = 1 | Client Error Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + The value field of this attribute contains a two-byte client error + code. The following error code values have been reserved. + + 0 "unable to process packet": a general error code + +11. IANA and Protocol Numbering Considerations + + IANA has assigned the EAP type number 23 for EAP-AKA authentication. + + EAP-AKA shares most of the protocol design, such as attributes and + message Subtypes, with EAP-SIM [EAP-SIM]. EAP-AKA protocol numbers + should be administered in the same IANA registry with EAP-SIM. This + document establishes the registries and lists the initial protocol + numbers for both protocols. + + + + + +Arkko & Haverinen Informational [Page 66] + +RFC 4187 EAP-AKA Authentication January 2006 + + + EAP-AKA and EAP-SIM messages include a Subtype field. The Subtype is + a new numbering space for which IANA administration is required. The + Subtype is an 8-bit integer. The following Subtypes are specified in + this document and in [EAP-SIM]: + + AKA-Challenge...................................1 + AKA-Authentication-Reject.......................2 + AKA-Synchronization-Failure.....................4 + AKA-Identity....................................5 + SIM-Start......................................10 + SIM-Challenge..................................11 + AKA-Notification and SIM-Notification..........12 + AKA-Reauthentication and SIM-Reauthentication..13 + AKA-Client-Error and SIM-Client-Error..........14 + + The messages are composed of attributes, which have 8-bit attribute + type numbers. Attributes numbered within the range 0 through 127 are + called non-skippable attributes, and attributes within the range of + 128 through 255 are called skippable attributes. The EAP-AKA and + EAP-SIM attribute type number is a new numbering space for which IANA + administration is required. The following attribute types are + specified in this document in [EAP-SIM]: + + AT_RAND.........................................1 + AT_AUTN.........................................2 + AT_RES..........................................3 + AT_AUTS.........................................4 + AT_PADDING......................................6 + AT_NONCE_MT.....................................7 + AT_PERMANENT_ID_REQ............................10 + AT_MAC.........................................11 + AT_NOTIFICATION................................12 + AT_ANY_ID_REQ..................................13 + AT_IDENTITY....................................14 + AT_VERSION_LIST................................15 + AT_SELECTED_VERSION............................16 + AT_FULLAUTH_ID_REQ.............................17 + AT_COUNTER.....................................19 + AT_COUNTER_TOO_SMALL...........................20 + AT_NONCE_S.....................................21 + AT_CLIENT_ERROR_CODE...........................22 + AT_IV.........................................129 + AT_ENCR_DATA..................................130 + AT_NEXT_PSEUDONYM.............................132 + AT_NEXT_REAUTH_ID.............................133 + AT_CHECKCODE..................................134 + AT_RESULT_IND.................................135 + + + + +Arkko & Haverinen Informational [Page 67] + +RFC 4187 EAP-AKA Authentication January 2006 + + + The AT_NOTIFICATION attribute contains a 16-bit notification code + value. The most significant bit of the notification code is called + the S bit (success) and the second most significant bit is called the + P bit (phase). If the S bit is set to zero, then the notification + code indicates failure; notification codes with the S bit set to one + do not indicate failure. If the P bit is set to zero, then the + notification code can only be used before authentication has + occurred. If the P bit is set to one, then the notification code can + only be used after authentication. The notification code is a new + numbering space for which IANA administration is required. The + following values have been specified in this document and in + [EAP-SIM]. + + General failure after authentication......................0 + User has been temporarily denied access................1026 + User has not subscribed to the requested service.......1031 + General failure.......................................16384 + Success...............................................32768 + + The AT_VERSION_LIST and AT_SELECTED_VERSION attributes, specified in + [EAP-SIM], contain 16-bit EAP method version numbers. The EAP method + version number is a new numbering space for which IANA administration + is required. Value 1 for "EAP-SIM Version 1" has been specified in + [EAP-SIM]. Version numbers are not currently used in EAP-AKA. + + The AT_CLIENT_ERROR_CODE attribute contains a 16-bit client error + code. The client error code is a new numbering space for which IANA + administration is required. Values 0, 1, 2, and 3 have been + specified in this document and in [EAP-SIM]. + + All requests for value assignment from the various number spaces + described in this document require proper documentation, according to + the "Specification Required" policy described in [RFC2434]. Requests + must be specified in sufficient detail so that interoperability + between independent implementations is possible. Possible forms of + documentation include, but are not limited to, RFCs, the products of + another standards body (e.g., 3GPP), or permanently and readily + available vendor design notes. + +12. Security Considerations + + The EAP specification [RFC3748] describes the security + vulnerabilities of EAP, which does not include its own security + mechanisms. This section discusses the claimed security properties + of EAP-AKA as well as vulnerabilities and security recommendations. + + + + + + +Arkko & Haverinen Informational [Page 68] + +RFC 4187 EAP-AKA Authentication January 2006 + + +12.1. Identity Protection + + EAP-AKA includes optional Identity privacy support that protects the + privacy of the subscriber identity against passive eavesdropping. + This document only specifies a mechanism to deliver pseudonyms from + the server to the peer as part of an EAP-AKA exchange. Hence, a peer + that has not yet performed any EAP-AKA exchanges does not typically + have a pseudonym available. If the peer does not have a pseudonym + available, then the privacy mechanism cannot be used, and the + permanent identity will have to be sent in the clear. The terminal + SHOULD store the pseudonym in non-volatile memory so that it can be + maintained across reboots. An active attacker that impersonates the + network may use the AT_PERMANENT_ID_REQ attribute (Section 4.1.2) to + learn the subscriber's IMSI. However, as discussed in Section 4.1.2, + the terminal can refuse to send the cleartext IMSI if it believes + that the network should be able to recognize the pseudonym. + + If the peer and server cannot guarantee that the pseudonym will be + maintained reliably, and Identity privacy is required then additional + protection from an external security mechanism (such as Protected + Extensible Authentication Protocol (PEAP) [PEAP]) may be used. The + benefits and the security considerations of using an external + security mechanism with EAP-AKA are beyond the scope of this + document. + +12.2. Mutual Authentication + + EAP-AKA provides mutual authentication via the 3rd generation AKA + mechanisms [TS33.102] and [S.S0055-A]. + + Note that this mutual authentication is with the EAP server. In + general, EAP methods do not authenticate the identity or services + provided by the EAP authenticator (if distinct from the EAP server) + unless they provide the so-called channel bindings property. The + vulnerabilities related to this have been discussed in [RFC3748], + [EAPKeying], [ServiceIdentity]. + + EAP-AKA does not provide the channel bindings property, so it only + authenticates the EAP server. However, ongoing work such as + [ServiceIdentity] may provide such support as an extension to popular + EAP methods such as EAP-TLS, EAP-SIM, or EAP-AKA. + +12.3. Flooding the Authentication Centre + + The EAP-AKA server typically obtains authentication vectors from the + Authentication Centre (AuC). EAP-AKA introduces a new usage for the + AuC. The protocols between the EAP-AKA server and the AuC are out of + the scope of this document. However, it should be noted that a + + + +Arkko & Haverinen Informational [Page 69] + +RFC 4187 EAP-AKA Authentication January 2006 + + + malicious EAP-AKA peer may generate a lot of protocol requests to + mount a denial-of-service attack. The EAP-AKA server implementation + SHOULD take this into account and SHOULD take steps to limit the + traffic that it generates towards the AuC, preventing the attacker + from flooding the AuC and from extending the denial-of-service attack + from EAP-AKA to other users of the AuC. + +12.4. Key Derivation + + EAP-AKA supports key derivation with 128-bit effective key strength. + The key hierarchy is specified in Section 7. + + The Transient EAP Keys used to protect EAP-AKA packets (K_encr, + K_aut), the Master Session Keys, and the Extended Master Session Keys + are cryptographically separate. An attacker cannot derive any + non-trivial information about any of these keys based on the other + keys. An attacker also cannot calculate the pre-shared secret from + AKA IK, AKA CK, EAP-AKA K_encr, EAP-AKA K_aut, the Master Session + Key, or the Extended Master Session Key. + +12.5. Brute-Force and Dictionary Attacks + + The effective strength of EAP-AKA values is 128 bits, and there are + no known, computationally feasible brute-force attacks. Because AKA + is not a password protocol (the pre-shared secret is not a + passphrase, or derived from a passphrase), EAP-AKA is not vulnerable + to dictionary attacks. + +12.6. Protection, Replay Protection, and Confidentiality + + AT_MAC, AT_IV, AT_ENCR_DATA, and AT_COUNTER attributes are used to + provide integrity, replay, and confidentiality protection for EAP-AKA + Requests and Responses. Integrity protection with AT_MAC includes + the EAP header. Integrity protection (AT_MAC) is based on a keyed + message authentication code. Confidentiality (AT_ENCR_DATA and + AT_IV) is based on a block cipher. + + Because keys are not available in the beginning of the EAP methods, + the AT_MAC attribute cannot be used for protecting EAP/AKA-Identity + messages. However, the AT_CHECKCODE attribute can optionally be used + to protect the integrity of the EAP/AKA-Identity roundtrip. + + Confidentiality protection is applied only to a part of the protocol + fields. The table of attributes in Section 10.1 summarizes which + fields are confidentiality protected. It should be noted that the + error and notification code attributes AT_CLIENT_ERROR_CODE and + AT_NOTIFICATION are not confidential, but they are transmitted in the + clear. Identity protection is discussed in Section 12.1. + + + +Arkko & Haverinen Informational [Page 70] + +RFC 4187 EAP-AKA Authentication January 2006 + + + On full authentication, replay protection of the EAP exchange is + provided by RAND and AUTN values from the underlying AKA scheme. + Protection against replays of EAP-AKA messages is also based on the + fact that messages that can include AT_MAC can only be sent once with + a certain EAP-AKA Subtype, and on the fact that a different K_aut key + will be used for calculating AT_MAC in each full authentication + exchange. + + On fast re-authentication, a counter included in AT_COUNTER and a + server random nonce is used to provide replay protection. The + AT_COUNTER attribute is also included in EAP-AKA notifications, if + they are used after successful authentication in order to provide + replay protection between re-authentication exchanges. + + The contents of the user identity string are implicitly integrity + protected by including them in key derivation. + + Because EAP-AKA is not a tunneling method, EAP-Request/Notification, + EAP-Response/Notification, EAP-Success, or EAP-Failure packets are + not confidential, integrity protected, or replay protected. On + physically insecure networks, this may enable an attacker to mount + denial-of-service attacks by spoofing these packets. As discussed in + Section 6.3, the peer will only accept EAP-Success after the peer + successfully authenticates the server. Hence, the attacker cannot + force the peer to believe successful mutual authentication has + occurred before the peer successfully authenticates the server or + after the peer failed to authenticate the server. + + The security considerations of EAP-AKA result indications are covered + in Section 12.8 + + An eavesdropper will see the EAP Notification, EAP_Success and + EAP-Failure packets sent in the clear. With EAP-AKA, confidential + information MUST NOT be transmitted in EAP Notification packets. + +12.7. Negotiation Attacks + + EAP-AKA does not protect the EAP-Response/Nak packet. Because + EAP-AKA does not protect the EAP method negotiation, EAP method + downgrading attacks may be possible, especially if the user uses the + same identity with EAP-AKA and other EAP methods. + + As described in Section 8, EAP-AKA allows the protocol to be extended + by defining new attribute types. When defining such attributes, it + should be noted that any extra attributes included in + EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are not + + + + + +Arkko & Haverinen Informational [Page 71] + +RFC 4187 EAP-AKA Authentication January 2006 + + + included in the MACs later on, and thus some other precautions must + be taken to avoid modifications to them. + + EAP-AKA does not support ciphersuite negotiation or EAP-AKA protocol + version negotiation. + +12.8. Protected Result Indications + + EAP-AKA supports optional protected success indications, and + acknowledged failure indications. If a failure occurs after + successful authentication, then the EAP-AKA failure indication is + integrity and replay protected. + + Even if an EAP-Failure packet is lost when using EAP-AKA over an + unreliable medium, then the EAP-AKA failure indications will help + ensure that the peer and EAP server will know the other party's + authentication decision. If protected success indications are used, + then the loss of Success packet will also be addressed by the + acknowledged, integrity, and replay protected EAP-AKA success + indication. If the optional success indications are not used, then + the peer may end up believing the server completed successful + authentication, when actually it failed. Because access will not be + granted in this case, protected result indications are not needed + unless the client is not able to realize it does not have access for + an extended period of time. + +12.9. Man-in-the-Middle Attacks + + In order to avoid man-in-the-middle attacks and session hijacking, + user data SHOULD be integrity protected on physically insecure + networks. The EAP-AKA Master Session Key or keys derived from it MAY + be used as the integrity protection keys, or, if an external security + mechanism such as PEAP is used, then the link integrity protection + keys MAY be derived by the external security mechanism. + + There are man-in-the-middle attacks associated with the use of any + EAP method within a tunneled protocol. For instance, an early + version of PEAP [PEAP-02] was vulnerable to this attack. This + specification does not address these attacks. If EAP-AKA is used + with a tunneling protocol, there should be cryptographic binding + provided between the protocol and EAP-AKA to prevent + man-in-the-middle attacks through rogue authenticators being able to + setup one-way authenticated tunnels. For example, newer versions of + PEAP include such cryptographic binding. The EAP-AKA Master Session + Key MAY be used to provide the cryptographic binding. However, the + mechanism that provides the binding depends on the tunneling protocol + and is beyond the scope of this document. + + + + +Arkko & Haverinen Informational [Page 72] + +RFC 4187 EAP-AKA Authentication January 2006 + + +12.10. Generating Random Numbers + + An EAP-AKA implementation SHOULD use a good source of randomness to + generate the random numbers required in the protocol. Please see + [RFC4086] for more information on generating random numbers for + security applications. + +13. Security Claims + + This section provides the security claims required by [RFC3748]. + + Auth. Mechanism: EAP-AKA is based on the AKA mechanism, which is an + authentication and key agreement mechanism based on a symmetric + 128-bit pre-shared secret. + + Ciphersuite negotiation: No + + Mutual authentication: Yes (Section 12.2) + + Integrity protection: Yes (Section 12.6) + + Replay protection: Yes (Section 12.6) + + Confidentiality: Yes, except method-specific success and failure + indications (Section 12.1, Section 12.6) + + Key derivation: Yes + + Key strength: EAP-AKA supports key derivation with 128-bit effective + key strength. + + Description of key hierarchy: Please see Section 7. + + Dictionary attack protection: N/A (Section 12.5) + + Fast reconnect: Yes + + Cryptographic binding: N/A + + Session independence: Yes (Section 12.4) + + Fragmentation: No + + Channel binding: No + + Indication of vulnerabilities. Vulnerabilities are discussed in + Section 12. + + + + +Arkko & Haverinen Informational [Page 73] + +RFC 4187 EAP-AKA Authentication January 2006 + + +14. Acknowledgements and Contributions + + The authors wish to thank Rolf Blom of Ericsson, Bernard Aboba of + Microsoft, Arne Norefors of Ericsson, N.Asokan of Nokia, Valtteri + Niemi of Nokia, Kaisa Nyberg of Nokia, Jukka-Pekka Honkanen of Nokia, + Pasi Eronen of Nokia, Olivier Paridaens of Alcatel, and Ilkka + Uusitalo of Ericsson for interesting discussions in this problem + space. + + Many thanks to Yoshihiro Ohba for reviewing the document. + + This protocol has been partly developed in parallel with EAP-SIM + [EAP-SIM], and hence this specification incorporates many ideas from + EAP-SIM, and many contributions from the reviewer's of EAP-SIM. + + The attribute format is based on the extension format of Mobile IPv4 + [RFC3344]. + +15. References + +15.1. Normative References + + [TS33.102] 3rd Generation Partnership Project, "3GPP Technical + Specification 3GPP TS 33.102 V5.1.0: "Technical + Specification Group Services and System Aspects; 3G + Security; Security Architecture (Release 5)"", + December 2002. + + [S.S0055-A] 3rd Generation Partnership Project 2, "3GPP2 + Enhanced Cryptographic Algorithms", September 2003. + + [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, + "The Network Access Identifier", RFC 4282, December + 2005. + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., + and H. Levkowetz, "Extensible Authentication + Protocol (EAP)", RFC 3748, June 2004. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [TS23.003] 3rd Generation Partnership Project, "3GPP Technical + Specification 3GPP TS 23.003 V6.8.0: "3rd + Generation Parnership Project; Technical + Specification Group Core Network; Numbering, + addressing and identification (Release 6)"", + December 2005. + + + +Arkko & Haverinen Informational [Page 74] + +RFC 4187 EAP-AKA Authentication January 2006 + + + [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", + RFC 2104, February 1997. + + [AES] National Institute of Standards and Technology, + "Federal Information Processing Standards (FIPS) + Publication 197, "Advanced Encryption Standard + (AES)"", November 2001, + http://csrc.nist.gov/publications/fips/fips197/ + fips-197.pdf. + + [CBC] National Institute of Standards and Technology, + "NIST Special Publication 800-38A, "Recommendation + for Block Cipher Modes of Operation - Methods and + Techniques"", December 2001, + http://csrc.nist.gov/publications/ + nistpubs/800-38a/sp800-38a.pdf. + + [SHA-1] National Institute of Standards and Technology, + U.S. Department of Commerce, "Federal Information + Processing Standard (FIPS) Publication 180-1, + "Secure Hash Standard"", April 1995. + + [PRF] National Institute of Standards and Technology, + "Federal Information Processing Standards (FIPS) + Publication 186-2 (with change notice); Digital + Signature Standard (DSS)", January 2000, + http://csrc.nist.gov/publications/ + fips/fips186-2/fips186-2-change1.pdf. + + [TS33.105] 3rd Generation Partnership Project, "3GPP Technical + Specification 3GPP TS 33.105 4.1.0: "Technical + Specification Group Services and System Aspects; 3G + Security; Cryptographic Algorithm Requirements + (Release 4)"", June 2001. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for + Writing an IANA Considerations Section in RFCs", + BCP 26, RFC 2434, October 1998. + + + + + + + + + +Arkko & Haverinen Informational [Page 75] + +RFC 4187 EAP-AKA Authentication January 2006 + + +15.2. Informative References + + [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS + Attributes", RFC 2548, March 1999. + + [PEAP] Palekar, A., Simon, D., Zorn, G., Salowey, J., + Zhou, H., and S. Josefsson, "Protected EAP Protocol + (PEAP) Version 2", work in progress, October 2004. + + [PEAP-02] Anderson, H., Josefsson, S., Zorn, G., Simon, D., + and A. Palekar, "Protected EAP Protocol (PEAP)", + work in progress, February 2002. + + [EAPKeying] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. + Levkowetz, "Extensible Authentication Protocol + (EAP) Key Management Framework", work in progress, + October 2005. + + [ServiceIdentity] Arkko, J. and P. Eronen, "Authenticated Service + Information for the Extensible Authentication + Protocol (EAP)", Work in Progress, October 2004. + + [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, + RFC 4086, June 2005. + + [RFC3344] Perkins, C., "IP Mobility Support for IPv4", + RFC 3344, August 2002. + + [EAP-SIM] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible + Authentication Protocol Method for Global System + for Mobile Communications (GSM) Subscriber Identity + Modules (EAP-SIM)", RFC 4186, January 2006. + + + + + + + + + + + + + + + + + + +Arkko & Haverinen Informational [Page 76] + +RFC 4187 EAP-AKA Authentication January 2006 + + +Appendix A. Pseudo-Random Number Generator + + The "|" character denotes concatenation, and "^" denotes + exponentiation. + + Step 1: Choose a new, secret value for the seed-key, XKEY + + Step 2: In hexadecimal notation let + t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0 + This is the initial value for H0|H1|H2|H3|H4 + in the FIPS SHS [SHA-1] + + Step 3: For j = 0 to m - 1 do + 3.1. XSEED_j = 0 /* no optional user input */ + 3.2. For i = 0 to 1 do + a. XVAL = (XKEY + XSEED_j) mod 2^b + b. w_i = G(t, XVAL) + c. XKEY = (1 + XKEY + w_i) mod 2^b + 3.3. x_j = w_0|w_1 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arkko & Haverinen Informational [Page 77] + +RFC 4187 EAP-AKA Authentication January 2006 + + +Authors' Addresses + + Jari Arkko + Ericsson + FIN-02420 Jorvas + Finland + + EMail: jari.Arkko@ericsson.com + + + Henry Haverinen + Nokia Enterprise Solutions + P.O. Box 12 + FIN-40101 Jyvaskyla + Finland + + EMail: henry.haverinen@nokia.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Arkko & Haverinen Informational [Page 78] + +RFC 4187 EAP-AKA Authentication January 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Arkko & Haverinen Informational [Page 79] + |