RFC 4187
Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)
Okay bestie, let's get into RFC 4187 🎀 The header says it's from the Network Working Group 🌸 and the title is Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA). It's an Informational doc, so it's info for the community and not an Internet standard. It was written by J. Arkko of Ericsson and H. Haverinen of Nokia, and it's dated January 2006. The header doesn't list any RFCs it obsoletes or updates, so there's no drama there 💅
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 🔥
Okay so the EAP-AKA protocol was developed by 3GPP, and this doc is just here to give the Internet community the info 📖 The EAP Working Group checked that EAP-AKA is compatible with EAP as defined in RFC 3748 ✅ but nobody else has reviewed it yet, and that includes the security claims 👀 The IETF also hasn't reviewed the security of the underlying UMTS AKA algorithms. Lowkey a big deal, so keep that in mind 💀
Abstract 💜
This doc specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution. It uses the Authentication and Key Agreement (AKA) mechanism, which 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 either a UMTS Subscriber Identity Module (USIM) or a (Removable) User Identity Module ((R)UIM). Basically it's giving smart card energy 🧚
EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. The optional stuff is the main character here ✨
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
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 .......................771. Introduction and Motivation ✨
Okay bestie, so this doc specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution. It uses the 3rd generation Authentication and Key Agreement (AKA) mechanism from [TS33.102] for UMTS and [S.S0055-A] for CDMA2000. UMTS and CDMA2000 are global 3rd generation mobile network standards that use the same AKA mechanism 🌸
2nd generation 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] is an EAP mechanism based on the GSM authentication and key agreement primitives 💜
AKA is based on challenge-response mechanisms and symmetric cryptography. It typically runs in a UMTS Subscriber Identity Module (USIM) or a CDMA2000 (Removable) User Identity Module ((R)UIM). In this document, both of these are called identity modules. Compared to 2nd generation mechanisms like GSM AKA, 3rd generation AKA gives you substantially longer key lengths and mutual authentication 🔥
Putting AKA inside EAP unlocks some new applications, and they're honestly iconic 👑 These include the following:
- The use of AKA also as a secure PPP authentication method in devices that already contain an identity module
- The use of the 3rd generation mobile network authentication infrastructure in the context of wireless LANs
- 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:
- 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.)
- 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.
- The RAND and the AUTN are delivered to the identity module.
- 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.
- 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]. Those are the official rule words, so read them as written 🎀
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. Here's the glossary, bestie:
- 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. Skipping the full AKA dance, so efficient 🍓
- 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.
- 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. Random only, no counters, got it 🔥
- Permanent Identity: The permanent identity of the peer, including an NAI realm portion in environments where a realm is used. The permanent identity is usually based on the IMSI. Used on full authentication only.
- Permanent Username: The username portion of permanent identity, i.e., not including any realm portions.
- Pseudonym Identity: A pseudonym identity of the peer, including an NAI realm portion in environments where a realm is used. Used on full authentication only.
- Pseudonym Username: The username portion of pseudonym identity, i.e., not including any realm portions.
- 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.
- 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. Never reuse a vector, periodt 💀
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. 👑
Okay so now the EAP server officially kicks off the AKA part by sending an EAP-Request/AKA-Challenge message 🔐✨. EAP-AKA packets stash their parameters in attributes, and each one is encoded in a Type, Length, Value format 🎀. The packet format and how attributes work are all spelled out in Section 8 💅.
The EAP-Request/AKA-Challenge message carries a RAND random number (AT_RAND), a network authentication token (AT_AUTN), and a message authentication code (AT_MAC) 🦋. It MAY optionally include encrypted data too 🫶. That data is there for identity privacy and fast re-authentication support, as explained in Section 4.1 🙈. The AT_MAC attribute holds a message authentication code that covers the whole EAP packet 🔥. Also, the encrypted data isn't drawn in any of the figures in this section, so don't go looking for it 💀.
The peer then runs the AKA algorithm (usually on an identity module 📱) and checks the AUTN 🧐. If that checks out, the peer knows it's really talking to a legit EAP server, and it sends back an EAP-Response/AKA-Challenge 💖. That response has a result parameter so the EAP server can authenticate the peer in return, plus the AT_MAC attribute to protect the EAP message's integrity 🔒.
The EAP server then verifies that the RES and the MAC in that EAP-Response/AKA-Challenge are correct ✅. Protected success indications aren't used in this example, so the server just sends an EAP-Success packet to say the authentication worked 🎉. (Protected success indications get their own discussion in Section 6.2 🌸.) The EAP server may also include derived keying material in the message it sends to the authenticator 🗝️. The peer has already derived the same keying material, so the authenticator doesn't pass that keying material on to the peer along with EAP-Success 💜.
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
Figure 2 shows what happens when the EAP server rejects the peer because the authentication failed 🙅♀️.
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
Figure 3 shows the peer turning down the AUTN from the EAP server 🙅.
The peer sends an explicit error message (EAP-Response/AKA-Authentication-Reject) to the EAP server 📣. That's just what AKA usually does when AUTN is incorrect 🤓. It lets the EAP server produce the same error statistics that AKA normally 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
AKA runs on shared secrets between the Peer and the Peer's home operator, together with a sequence number, so it can actually authenticate anyone 🗝️. Sometimes, as Figure 4 shows, those sequence numbers can fall out of sync 😬.
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
Once resynchronization has happened on the server and AAA side, the server sends a fresh EAP-Request/AKA-Challenge message to keep things going 🔄.
Beyond the full authentication flows above, EAP-AKA also has a fast re-authentication procedure, which is covered in Section 5 🚀. Fast re-authentication builds on keys derived during full authentication 🔑. If the peer has kept state information for re-authentication and wants to use fast re-authentication, it signals that by using a specific fast re-authentication identity instead of its permanent identity or a pseudonym identity 🆔✨.
4. Operation 🎀
4.1. Identity Management
4.1.1. Format, Generation, and Usage of Peer Identities
4.1.1.1. General 💖
Okay so, bestie, at the very start of EAP auth, the Authenticator or the EAP server usually sends an EAP-Request/Identity packet to the peer 🫶. The peer answers with EAP-Response/Identity, which carries the user's identity. The formats of these packets are specified in [RFC3748] ✨
Mobile network subscribers get identified with the International Mobile Subscriber Identity (IMSI) [TS23.003] 📱. The IMSI is a string of not more than 15 digits. It's made 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. The MCC and MNC uniquely identify the GSM operator and help figure out which AuC the authentication vectors need to be pulled from for this subscriber 🔥
Internet AAA protocols identify users with the Network Access Identifier (NAI) [RFC4282] 🌸. In a roaming environment, the NAI is a username and a realm glued together 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, "identity" or "peer identity" means the whole identity string 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, so the username does not include the realm portion 🦋
4.1.1.2. Identity Privacy Support 🙈
EAP-AKA includes optional identity privacy (anonymity) support 🫣. It can be used to hide the cleartext permanent identity, which makes the subscriber's EAP exchanges untraceable to eavesdroppers. The permanent identity never changes, so revealing it would help observers track the user. It's usually based on the IMSI, which can make tracking even easier, because the same identifier may be used in other contexts as well 😭. Identity privacy is based on temporary identities, or pseudonyms. They're equivalent to, but separate from, the Temporary Mobile Subscriber Identities (TMSI) 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 👑:
- Permanent usernames. For example,
0123456789098765@myoperator.commight be a valid permanent identity. Here,0123456789098765is the permanent username 💜. - Pseudonym usernames. For example,
2s7ah6n9q@myoperator.commight be a valid pseudonym identity. Here,2s7ah6n9qis the pseudonym username 🌈. - Fast re-authentication usernames. For example,
43953754@myoperator.commight be a valid fast re-authentication identity. In this case,43953754is the fast re-authentication username. Unlike permanent and pseudonym usernames, fast re-authentication usernames are one-time identifiers that are not re-used across EAP exchanges. Main character energy, no cap ⭐
The first two types of identities are used only on full authentication, and the last type is used 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, so it can indicate supplementary AAA routing information on top of the NAI realm. (Using an NAI realm portion doesn't count as decoration, btw 💅.) Username decoration is out of the scope of this document. Still, it should be noted that username decoration might stop the server from recognizing a valid username 😬. So, although the peer MAY use username decoration in the identities that it 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 🚫
4.1.1.5. NAI Realm Portion 🌸
The peer MAY include a realm portion in the peer identity, as per the NAI format. Using 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 that 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 🔥. A reserved NAI realm like that may be useful as a hint for the first authentication method to try during method negotiation. When the peer uses a pseudonym username instead of the permanent username, it picks the realm name portion the same way it would 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 the IMSI, ".mcc", the MCC digits of the IMSI, and ".owlan.org". For example, if the IMSI is 123456789098765 and the MNC is three digits long, the derived realm name is mnc456.mcc123.owlan.org. Since 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 tell 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 the MSIN. So when configuring AAA networks for operators that have 2-digit MNCs, the network SHOULD also be prepared for realm names with incorrect 3-digit MNCs 🧩.
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 of not more than 15 decimal digits (ASCII values between 30 and 39 hexadecimal), one character per IMSI digit, in the order 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 are out of the scope of this document. Even so, 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 ✨
Okay bestie, the EAP server is the one cooking up pseudonym usernames and fast re-authentication identities 👑. It makes them in an implementation-dependent manner, so each implementation gets to do its own thing 💅. Only the EAP server needs to be able to map a pseudonym username back to the permanent identity, or recognize a fast re-authentication identity 🦋.
EAP-AKA has zero provisions making sure the same EAP server that made a pseudonym username is the one handling it when it shows up again 😭. So it is recommended that EAP servers have some centralized mechanism that lets all the EAP servers of the home operator map pseudonyms made by other servers back to the permanent identity 🫶. If there's no such mechanism, a server that doesn't understand a pseudonym issued by another server can just ask the peer to send the permanent identity instead 🙈.
When issuing a fast re-authentication identity, the EAP server may include a realm name in it, which makes sure the fast re-authentication request gets forwarded to the same EAP server 🧚.
Now the fresh-identity drama 🔥. When generating fast re-authentication identities, the server SHOULD choose a fresh, new one that's different from the previous ones used after the same full authentication exchange. A full authentication exchange and its associated fast re-authentication exchanges together make up the same "full authentication context" 🌸. The fast re-authentication identity SHOULD include a random component, and that random bit works as a full authentication context identifier 💜. A context-specific fast re-authentication identity can help the server figure out whether its fast re-authentication state information matches the peer's (aka whether that state came from the same full authentication exchange) 🍓. The random component also makes the fast re-authentication identities unpredictable, so an attacker can't start a fast re-authentication exchange just to get the server's EAP-Request/AKA-Reauthentication packet. Main character energy, the attacker is locked out 😤✨.
Transmitting pseudonyms and fast re-authentication identities from the server to the peer is covered in Section 4.1.1.8 🎀. The pseudonym gets sent as a username without an NAI realm, while the fast re-authentication identity gets sent as a complete NAI, including a realm portion if a realm is required. The realm is in the fast re-authentication identity so the server can include a server-specific realm 🌈.
Regardless of how it's built, the pseudonym username MUST conform to the grammar specified for the username portion of an NAI. The fast re-authentication identity MUST conform to the NAI grammar too 📜. The EAP servers that an operator's subscribers can use MUST ensure that the pseudonym usernames and the username portions used in the fast re-authentication identities they generate are unique 🔑. No duplicates, babe.
Permanent usernames, pseudonym usernames, and fast re-authentication usernames have to be separate and recognizable from each other. 🌈 It's also desirable that EAP-SIM and EAP-AKA usernames be recognizable from each other, so the server can easily tell which method to offer 🦋.
It's the EAP server's job, plus its administrator's policies, to keep the usernames sufficiently separated 👑. Pseudonym usernames and fast re-authentication usernames are both produced and used by the EAP server, so the EAP server MUST compose them in a way that lets it recognize whether an NAI username is an EAP-AKA pseudonym username or an EAP-AKA fast re-authentication username 🧠. For example, if the usernames were derived from the IMSI, the server could use different leading characters for pseudonyms and fast re-authentication usernames (like a pseudonym starting with a leading 2 character) ✨. When mapping a fast re-authentication identity to a permanent identity, the server SHOULD only look at the username portion and ignore the realm portion 🫶.
One more thing 🥺. The peer might fail to save a pseudonym username that was sent in an EAP-Request/AKA-Challenge (say, due to a malfunction), so the EAP server SHOULD keep, at minimum, the most recently used pseudonym username in addition to the most recently issued one 💖. And if the authentication exchange doesn't complete successfully, the server SHOULD NOT overwrite the pseudonym username issued during the most recent successful exchange 😭🔥.
4.1.1.8. Transmitting Pseudonyms and Fast Re-Authentication Identities to the Peer ✨
The server sends pseudonym usernames and fast re-authentication identities to the peer encrypted, 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 🎀. Identity privacy support and fast re-authentication are both optional to implement, so the peer MAY ignore the AT_ENCR_DATA attribute and always use the permanent identity 🙈. On fast re-authentication (more on that in Section 5), the server MAY include a new, encrypted fast re-authentication identity in the EAP-Request/AKA-Reauthentication message 🦋.
When the peer gets the EAP-Request/AKA-Challenge, it MAY decrypt the encrypted data in AT_ENCR_DATA. 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, the peer MAY save it together with its other fast re-authentication state information (see Section 5) for the next fast re-authentication 💜.
If the peer doesn't receive a new pseudonym username in the EAP-Request/AKA-Challenge, it MAY use an old pseudonym username instead of the permanent username on the 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, it MUST discard that identity and not re-use it in another EAP authentication exchange, even if the exchange didn't complete 🗑️💀. One and done!
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 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 it 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 pick the realm portion the same way whether it's using 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 it 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 then, 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 📨. That 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 that the server can map to the permanent identity, then the authentication proceeds as described in the overview in Section 3 🧚. If the peer uses a fast re-authentication identity that matches a valid one maintained by the server, then a fast re-authentication exchange is performed, as described in Section 5 🔁✨.
The peer identity can also be sent from the peer to the server using EAP-AKA messages instead of EAP-Response/Identity 🦋. In that 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 🎀. AT_ANY_ID_REQ is the general one, which the server uses if it doesn't specify which kind of identity the peer should return in AT_IDENTITY 🤷♀️. AT_FULLAUTH_ID_REQ is used to request either the permanent identity or a pseudonym identity 💜. AT_PERMANENT_ID_REQ is used 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 lets the protocol peers make sure the AKA-Identity packets haven't been tampered with 🔍. 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 🧐: only the EAP-AKA peer and the EAP-AKA server process the AT_IDENTITY attribute. The entities in between don't process it, since EAP packets don't process this attribute 🙈. So the authenticator and other intermediate AAA elements (like possible AAA proxy servers) will keep referring to the peer by the original identity from the EAP-Response/Identity packet, unless the identity authenticated in AT_IDENTITY gets communicated to them some other way within the AAA protocol 🫶💅.
4.1.2.2. Relying on EAP-Response/Identity Discouraged
okay bestie, so the EAP-Response/Identity packet isn't specific to any one method 🫶. That means lots of implementations let an EAP Framework handle it 🧚. That adds an extra layer of processing between the EAP peer and the EAP server 💅. The layer might cache identity responses or add decorations to the identity ✨. And here's the tea: if the identity gets modified, the EAP peer and EAP server end up using different identities in the key derivation, and the protocol fails 😭💀.
So it is RECOMMENDED that the EAP peer and server use the method-specific identity attributes in EAP-AKA 💖. The server is also strongly discouraged from relying on EAP-Response/Identity 🙈.
In particular, if the EAP server gets a decorated identity in EAP-Response/Identity, then the EAP server MUST use the identity-requesting attributes to ask the peer for an unmodified and undecorated copy of the identity in AT_IDENTITY 👑.
4.1.3. Choice of Identity for the EAP-Response/Identity
If the 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 does the following steps.
If the peer has maintained fast re-authentication state information and 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. That tells the peer the server wants 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, then the server MUST request an identity from the peer using one of the methods below. The same goes if the EAP server received an EAP-Response/Identity packet but the contents don't appear to be a valid permanent identity, pseudonym identity, or re-authentication identity 🚨.
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:
- The server does not support fast re-authentication or identity privacy.
- 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:
- The server does not support fast re-authentication and the server supports identity privacy.
- 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 🦋. The server does not indicate any preferred type for the identity here. 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. So in this case, the peer MUST either respond with EAP-Response/AKA-Identity and include the permanent identity in AT_IDENTITY, or respond with the 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 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 it receives complies 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 the peer can use with regard to AT_PERMANENT_ID_REQ 🧠. A "conservative" peer assumes that the network is able to maintain pseudonyms robustly. So 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 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 🕵️♀️
Okay so this is where the server finally reads the AT_IDENTITY it got back, and it's giving detective energy 🔍✨. When the server receives an EAP-Response/AKA-Identity message with the AT_IDENTITY (replying 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) 🦋. Bestie, this is the fast lane 🏎️💨.
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 the server recognizes as a fast re-authentication identity, but the server is not able to map that 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) 🧚
Heads up, this section is non-normative 🌸, so it's just examples. It shows 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_REQ4.2.2. Fall Back on Full Authentication 🔄
Figure 6 shows the case when the server doesn't 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 authenticationIf 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 ✨.
4.2.3. Requesting the Permanent Identity 1 🪪
Figure 7 shows 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 1If the server recognizes the permanent identity, then the authentication sequence proceeds as usual, with the EAP Server issuing the EAP-Request/AKA-Challenge message 💜.
4.2.4. Requesting the Permanent Identity 2 🌈
Figure 8 shows 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 24.2.5. Three EAP/AKA-Identity Round Trips 🦋
okay so Figure 9 shows the case with three EAP/AKA-Identity round trips 😭 The server has no Subscriber identity available when EAP-AKA starts, so it keeps asking nicely until it gets what it needs. 💅
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 roundsAfter the last EAP-Response/AKA-Identity message, the full authentication sequence proceeds as usual. ✨
5. Fast Re-Authentication 💜
5.1. General 🌸
In some environments, EAP authentication may be performed frequently. Full EAP-AKA authentication uses the AKA algorithms, so it needs fresh authentication vectors from the Authentication Centre. Doing that very often can mean a lot of network operations, which is a vibe-killer 💀 So EAP-AKA includes a cheaper fast re-authentication procedure. It doesn't use the AKA algorithms and doesn't need new vectors from the Authentication Centre. 🫶
Fast re-authentication is optional to implement for both the EAP-AKA server and the peer. On each EAP authentication, either entity may fall back on full authentication if it doesn't want to use fast re-authentication.
Fast re-authentication is based on the keys derived during the previous full authentication. The same K_aut and K_encr keys used in full authentication protect EAP-AKA packets and attributes. 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 uses an unsigned 16-bit counter, carried in the AT_COUNTER attribute. The counter has three jobs:
- It can limit how many successive re-authentication exchanges happen without full authentication.
- It contributes to the keying material.
- It protects the peer and the server from replays.
On full authentication, both the server and the peer set 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. So the second fast re-authentication uses a counter value of two or greater, and so on. The AT_COUNTER attribute is encrypted. 🎀
Both the peer and the EAP server keep 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, which gives you a challenge/response authentication scheme. NONCE_S also contributes to the new Master Session Key. 🧚
Both the peer and the server SHOULD have an upper limit for the number of subsequent fast re-authentications allowed before a full authentication has to happen. The counter is 16 bits, so the theoretical maximum number of re-authentications is reached when the counter hits FFFF in hexadecimal.
To use fast re-authentication, the peer and the EAP server need to store the Master Key, the latest counter value, and the next fast re-authentication identity. K_aut and K_encr can either be stored or derived again from MK. The server may also need to store the user's permanent identity. 💾
5.2. Comparison to AKA 🎀
When you analyze the fast re-authentication exchange, it helps to compare it with the 3rd generation Authentication and Key Agreement (AKA) exchange used in full authentication. Here's how the pieces line up:
- The counter corresponds to the AKA sequence number.
NONCE_Scorresponds to RAND.- The
AT_MACin EAP-Request/AKA-Reauthentication corresponds to AUTN. - The
AT_MACin EAP-Response/AKA-Reauthentication corresponds to RES. AT_COUNTER_TOO_SMALLcorresponds to AUTS.- Encrypting the counter corresponds to the usage of the Anonymity Key.
Key generation on fast re-authentication is also similar to AKA when it comes to random or fresh material. 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 uses 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 doesn't 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 an EAP-Request/AKA-Challenge message. This attribute carries a new re-authentication identity for the next fast re-authentication. It also works as a capability flag, saying the server supports fast re-authentication and wants to keep using it 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 the next authentication. Even if the peer has a fast re-authentication identity, the peer MAY discard it and use a pseudonym or the permanent identity instead, and then 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, 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, following the NAI format. The EAP server can choose an appropriate realm part so the AAA infrastructure routes later fast re-authentication requests to the same AAA server. For example, the realm part MAY include a portion that is specific to the AAA server. So it's enough to store the context needed for fast re-authentication in the AAA server that did 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 change the realm to influence AAA routing, for example to make sure 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 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, the server might not recognize the identity or might not want to use fast re-authentication. If the server can decode the fast re-authentication identity to the permanent identity, it issues an EAP-Request/AKA-Challenge packet to start full authentication. If it can't recover the peer's identity from the fast re-authentication identity, it starts full authentication 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. 🦋
5.4. Fast Re-Authentication Procedure 💖
okay so bestie, here's how fast re-auth actually goes 🦋 In this example the optional protected success indication isn't used 🙈 Encrypted attributes get a little '*' tag so you can spot them, like a VIP sticker 🎀 The peer sends its fast re-auth identity in the EAP-Response/Identity packet. Earlier we mentioned another option: the peer can send it in AT_IDENTITY inside EAP-Response/AKA-Identity instead. That version isn't drawn below, and it only works when the server asked for it with AT_ANY_ID_REQ in the EAP-Request/AKA-Identity packet 🧚
If the server recognizes the identity as a valid fast re-auth identity and agrees to use fast re-auth, it sends the EAP-Request/AKA-Reauthentication packet to the peer ✨ This packet MUST include the encrypted AT_COUNTER with a fresh counter value, the encrypted AT_NONCE_S holding a random number the server picked, the AT_ENCR_DATA and AT_IV used for encryption, and AT_MAC with a message authentication code over the packet. It MAY also include an encrypted AT_NEXT_REAUTH_ID with the next fast re-auth identity 🌸
Fast re-auth identities are one-time identities, so use them once and move on 🙅♀️ If the peer doesn't get a new one, it MUST use either the permanent identity or a pseudonym identity on the next authentication to start full authentication 💅
Next, the peer checks that AT_MAC is correct and that the counter is fresh, meaning greater than any value used before 🔥 It MAY save the next fast re-auth identity from the encrypted AT_NEXT_REAUTH_ID for next time 🌈 If everything checks out, the peer replies with EAP-Response/AKA-Reauthentication, including AT_COUNTER with the same counter value and AT_MAC 🫶
Then the server verifies AT_MAC and checks that the counter matches the one it sent in EAP-Request/AKA-Reauthentication. If both checks pass, fast re-auth has succeeded and the server sends EAP-Success to the peer 👑
If protected success indications (Section 6.2) were used, EAP-Success would come after an EAP-AKA notification round 💜
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
5.5. Fast Re-Authentication Procedure when Counter is Too Small 🙈
If the peer doesn't accept the counter value from EAP-Request/AKA-Reauthentication, it flags the counter synchronization problem by including the encrypted AT_COUNTER_TOO_SMALL in EAP-Response/AKA-Reauthentication 💀 The server then replies with EAP-Request/AKA-Challenge to start a normal full authentication procedure. Figure 11 shows this. Encrypted attributes are marked with '*', same as before 🎀
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 look a lot like the basic fast re-auth case 🦋 When the peer notices the counter isn't fresh, it adds AT_COUNTER_TOO_SMALL to EAP-Response/AKA-Reauthentication. That attribute carries no data. It's just a request for the server to kick off full authentication 🙌 In this case the peer MUST ignore the contents of the server's AT_NEXT_REAUTH_ID attribute 🙅♀️
When the server gets AT_COUNTER_TOO_SMALL, it verifies AT_MAC and checks that AT_COUNTER holds the same counter value as in EAP-Request/AKA-Reauthentication. If that doesn't hold, the server ends the exchange by sending EAP-Request/AKA-Notification with the AT_NOTIFICATION code "General failure" (16384) 😭 If every check passes, the server sends an EAP-Request/AKA-Challenge packet and full authentication runs as usual ✨ Since the server already knows the subscriber identity, it MUST NOT use the EAP-Request/AKA-Identity packet to ask for the identity again 💅
It's worth noting that in this case the peer identity is only sent in the AT_IDENTITY attribute at the very start of the whole EAP exchange 🧚 The fast re-auth identity inside that AT_IDENTITY attribute gets used in key derivation (see Section 7) 🔐
6. EAP-AKA Notifications ✨
6.1. General ✨
Okay so EAP-AKA doesn't ban the EAP Notifications from [RFC3748] 💅 They can pop up at any point in the EAP-AKA exchange. Heads up though: EAP-AKA does not protect EAP Notifications 🙈 It also has its own method-specific EAP-AKA notifications, and those are protected in some cases 🔐
The EAP server can use EAP-AKA notifications to send notifications and result indications (Section 6.2) to the peer 🎀
The server MUST use notifications in the cases discussed in Section 6.3.2. When the EAP server sends an EAP-Request/AKA-Notification packet to the peer, the peer MUST process that notification packet 🫶 The peer MAY show the notification message to the user, and the peer MUST respond to the EAP server with an EAP-Response/AKA-Notification packet, even if it didn't 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), and it tells you whether the notification implies failure. Code values with the S bit set to zero (0...32767) are used in unsuccessful cases. Getting a code from this range means the EAP exchange failed, so the peer can treat the notification as a failure indication 💀 After the server gets the EAP-Response/AKA-Notification for these notification codes, the server MUST send the EAP-Failure packet.
A notification with the S bit set to one (32768...65536) does not imply failure. The notification code "Success" (32768) is reserved as a general notification code to indicate successful authentication ✨
The second most significant bit of the notification code is the Phase bit (P bit). It tells you 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 only counts as successful if the peer has successfully verified AT_MAC and AT_COUNTER, and the EAP-Response/AKA-Reauthentication does not include AT_COUNTER_TOO_SMALL.
If the P bit is set to one, the notification can only be used before the EAP/AKA-Challenge round in full authentication, or before the EAP/AKA-Reauthentication round in re-authentication. These notifications are only for signalling various failure cases. In other words, if the P bit is set to one, then the S bit MUST be set to zero. Big brain rule, bestie 🧠
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, so they aren't usually considered the job of an EAP method 🤷♀️ They're included in EAP-AKA anyway, because there are currently no other ways to convey this information to the user in a localizable way, and it's 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 🔒
By sending an EAP-Response/AKA-Challenge packet or an EAP-Response/AKA-Reauthentication packet (without AT_COUNTER_TOO_SMALL), the peer shows it has successfully authenticated the server and that its 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 AT_RESULT_IND in the EAP-Request/AKA-Challenge or the EAP-Request/AKA-Reauthentication packet. This attribute says the EAP server would like result indications in both successful and unsuccessful cases. If the peer wants this too, it 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, the EAP exchange isn't complete yet, but an EAP-AKA notification round will follow. That following 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 say the EAP exchange has completed successfully, the EAP exchange can't fail when the server processes the EAP-AKA response to this notification. So the server MUST ignore the contents of the EAP-AKA response it receives to the EAP-Request/AKA-Notification with this code. No matter what's in that response, the server MUST send EAP-Success as the next packet 🎉EAP-Success, periodt!
6.3. Error Cases 🧯
This section specifies how the peer and the server behave in error cases. The subsections below require the EAP-AKA peer and server to send an error packet in error cases: 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 📨 However, implementations SHOULD NOT rely upon the correct error reporting behavior of the peer, authenticator, or server. Error messages and other messages can get lost in transit, or a malicious participant might try to eat up 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 🙋♀️
There are two special error messages for error cases related to processing 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 issuesEAP-Failure. - (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 newEAP-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:
- EAP exchange is not acceptable according to the peer's local policy.
- The peer is not able to parse the EAP request, i.e., the EAP request is malformed.
- The peer encountered a malformed attribute.
- Wrong attribute types or duplicate attributes have been included in the EAP request.
- A mandatory attribute is missing.
- Unrecognized non-skippable attribute.
- Unrecognized or unexpected EAP-AKA Subtype in the EAP request.
- Invalid
AT_MAC. The peer SHOULD log this event. - Invalid
AT_CHECKCODE. The peer SHOULD log this event. - Invalid pad bytes in
AT_PADDING. - 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 between these two codes depends on the phase of the EAP-AKA exchange, see Section 6. The error cases where the server issues an EAP-Request/AKA-Notification that implies failure include the following:
- The server is not able to parse the peer's EAP response.
- The server encounters a malformed attribute, a non-recognized non-skippable attribute, or a duplicate attribute.
- A mandatory attribute is missing, or an invalid attribute was included.
- Unrecognized or unexpected EAP-AKA Subtype in the EAP Response.
- Invalid
AT_MAC. The server SHOULD log this event. - Invalid
AT_CHECKCODE. The server SHOULD log this event. - Invalid
AT_COUNTER.
6.3.3. EAP-Failure 🥀
The EAP-AKA server sends EAP-Failure in three cases:
- In response to an
EAP-Response/AKA-Client-Errorpacket the server has received from the peer, or - In response to an
EAP-Response/AKA-Authentication-Rejectpacket the server has received from the peer, or - Following an EAP-AKA notification round, when the
AT_NOTIFICATIONcode 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 still 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. Accept the failures that matter, ignore the rest, main character energy 💅👑
6.3.4. EAP-Success ✨
Okay so, on full authentication the server can only send EAP-Success after the EAP/AKA-Challenge round 🎀. If the peer gets an EAP-Success packet before it has successfully authenticated the server and sent the EAP-Response/AKA-Challenge packet, the peer MUST silently discard it 🙈. Not ngl, that's a super important safety check.
If the peer did NOT ask for protected success indications with AT_RESULT_IND (see Section 6.2) during full authentication, then the peer MUST accept EAP-Success after a successful EAP/AKA-Challenge round 💖.
If the peer DID ask for protected success indications with AT_RESULT_IND (see Section 6.2), it's a whole different vibe 💅. The peer MUST NOT accept EAP-Success after a successful EAP/AKA-Challenge round. Instead, the peer MUST only accept EAP-Success after it receives 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 🔥. Same deal as before: if the peer gets an EAP-Success packet before it has successfully authenticated the server and sent the EAP-Response/AKA-Reauthentication packet, the peer MUST silently discard it 🙈.
If the peer did NOT ask for protected success indications with AT_RESULT_IND (see Section 6.2) on fast re-authentication, then the peer MUST accept EAP-Success after a successful EAP/AKA-Reauthentication round 🌸.
If the peer DID ask for protected success indications with AT_RESULT_IND (see Section 6.2), the peer MUST NOT accept EAP-Success after a successful EAP/AKA-Reauthentication round. The peer MUST only accept EAP-Success after receiving an EAP-AKA Notification with the AT_NOTIFICATION code "Success" (32768) 👑.
Last but not least, if the peer gets an EAP-AKA notification (see Section 6) that signals failure, the peer MUST no longer accept the EAP-Success packet 💀. That's true even if the server authentication was completed successfully. No takebacks ❌.
7. Key Generation 🔑
This is where the keys get cooked 🍓. Here's how the keying material is generated.
On EAP-AKA full authentication, a Master Key (MK) is derived from the underlying AKA values (the CK and IK keys) plus the identity, like this:
MK = SHA1(Identity|IK|CK)In that formula, the "|" character means concatenation 🧚. Identity is the peer identity string without any terminating null characters. It's the identity from the last AT_IDENTITY attribute the peer sent in this exchange. If AT_IDENTITY wasn't used, it's the identity from the EAP-Response/Identity packet instead. The identity string gets included as-is, with no changes at all 🙅♀️. Remember from Section 4.1.2.2 that relying on EAP-Response/Identity to convey the EAP-AKA peer identity is discouraged 🙈, so the server SHOULD use the EAP-AKA method-specific identity attributes. The hash function SHA-1 is specified in [SHA-1] 📜.
Next, the Master Key gets fed into a Pseudo-Random number Function (PRF) 🎰. The PRF spits out separate Transient EAP Keys (TEKs) for protecting EAP-AKA packets, plus a Master Session Key (MSK) for link layer security and an Extended Master Session Key (EMSK) for other purposes ✨. During 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 during the fast re-authentication 🦋. Iconic 👑.
EAP-AKA needs two TEKs for its own stuff: the authentication key K_aut, which goes with the AT_MAC attribute, and the encryption key K_encr, which goes with the AT_ENCR_DATA attribute 💜. The same K_aut and K_encr keys are used in full authentication and in every fast re-authentication after that 🫶.
Key derivation is based on the random number generation in NIST Federal Information Processing Standards (FIPS) Publication 186-2 [PRF] 🌈. The pseudo-random number generator comes from change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As the change notice says (page 74), when Algorithm 1 is used as a general-purpose pseudo-random number generator, the "mod q" term in step 3.3 is left out. The function G used in the algorithm is built using the Secure Hash Standard, as in Appendix 3.3 of that standard. Heads up: G is very similar to SHA-1, but the message padding is different 🤓. For full details, check out [PRF]. 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 get concatenated and chopped into suitably sized chunks. They're then used as keys in this order: K_encr (128 bits), K_aut (128 bits), Master Session Key (64 bytes), Extended Master Session Key (64 bytes) 🍰.
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' gets calculated like this:
XKEY' = SHA1(Identity|counter|NONCE_S| MK)In that formula, Identity is the fast re-authentication identity, without any terminating null characters. It comes from the AT_IDENTITY attribute in the EAP-Response/AKA-Identity packet. If EAP-Response/AKA-Identity wasn't used during fast re-authentication, it's the identity string from the EAP-Response/Identity packet instead 🪄. The counter is 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 is the 16-byte random NONCE_S value from the AT_NONCE_S attribute used in the EAP-Request/AKA-Reauthentication packet 🎲. MK is the Master Key derived during the preceding full authentication 👑.
On fast re-authentication, the pseudo-random number generator runs with the new seed value XKEY'. The resulting 320-bit random numbers x_0, x_1, ..., x_m-1 get concatenated and partitioned into 64-byte chunks, which become the new 64-byte Master Session Key and the new 64-byte Extended Master Session Key 🎀. Note that K_encr and K_aut aren't derived on fast re-authentication, so the Master Session Key and the Extended Master Session key come from the very beginning of the key stream x_0, x_1, .... Smart, right? 🧠
The first 32 bytes of the MSK can be used as the Pairwise Master Key (PMK) for IEEE 802.11i 📶.
When the RADIUS attributes from [RFC2548] are used to carry keying material, the first 32 bytes of the MSK correspond to MS-MPPE-RECV-KEY, and the second 32 bytes correspond 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 [RFC3748] explains, EAP packets start with the Code, Identifier, Length, and Type fields, and those 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 🦋.
In EAP-AKA, the Type-Data starts with an EAP-AKA header made of a 1-octet Subtype field and a 2-octet reserved field 💜. The Subtype values used in EAP-AKA are defined in Section 11. Here are the formats of the EAP header and the EAP-AKA header:
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, right after the EAP-AKA header, is made of attributes encoded in Type, Length, Value format. Here's the generic attribute format 🎀:
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each part means:
- 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 0 through 127 are called non-skippable attributes 🚫. When an EAP-AKA peer runs into a non-skippable attribute type it doesn't recognize, the peer MUST send the EAP-Response/AKA-Client-Error packet, and the authentication exchange terminates 💀. If an EAP-AKA server runs into a non-skippable attribute it doesn't recognize, the server sends an EAP-Request/AKA-Notification packet. That packet carries an AT_NOTIFICATION code implying 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 128 through 255 shows up but isn't recognized, that attribute gets ignored. The rest of the attributes and message data MUST still be processed 🫶. The Length field of the attribute is used to skip over the attribute value when searching for the next attribute. These are called skippable attributes 🦋.
Unless otherwise specified, the order of the attributes in an EAP-AKA message doesn't matter, and an EAP-AKA implementation should not assume a certain order will be used 🌈.
Last one! 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 🧩
okay so EAP-AKA can grow by adding new attribute types 🌱 and if those new attributes are skippable, you can extend the protocol without breaking old implementations 🫶 that's the whole glow-up trick. As Section 10.13 spells out, if you add new attributes to EAP-Request/AKA-Identity or EAP-Response/AKA-Identity, then AT_CHECKCODE MUST be used to integrity protect those new attributes 🔐 no skipping that step, bestie.
Heads up before you get too creative ✨ EAP-AKA does not support message fragmentation, so the sizes of any new extensions MUST be limited so 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 don't have a version field 🙈 but if there's ever a good reason to revise the protocol, new non-skippable or skippable attributes could be specified to roll out revised EAP-AKA versions in a backward-compatible way 🦋 You could even introduce version negotiation in EAP-Request/AKA-Identity and EAP-Response/AKA-Identity messages by specifying new skippable attributes. Future-proofing, periodt 💜
9. Messages 💌
This section is the messages menu for EAP-AKA 📨 It spells out when each message can be sent or accepted, which attributes are allowed in it, which attributes are required in it, and other message-specific details. The message format itself lives in Section 8.1, so go check that if you need the byte-level tea ☕
9.1. EAP-Request/AKA-Identity 🪪
The EAP/AKA-Identity roundtrip MAY be used to get the peer identity from the server 🕵️♀️ As discussed in Section 4.1, several AKA-Identity rounds can be needed before you end up with a valid peer identity, so don't panic if it takes a few tries 😭
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 are mutually exclusive, so the server MUST NOT include more than one of them 🚫 one at a time, queen 👑
If the server has previously issued an EAP-Request/AKA-Identity message with AT_PERMANENT_ID_REQ, and it 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 AT_FULLAUTH_ID_REQ, and it has received a response from the peer, then the server MUST NOT issue a new EAP-Request/AKA-Identity packet with AT_ANY_ID_REQ or AT_FULLAUTH_ID_REQ 🙅♀️
If the server has previously issued an EAP-Request/AKA-Identity message with AT_ANY_ID_REQ, and it has received a response from the peer, then the server MUST NOT issue a new EAP-Request/AKA-Identity packet with AT_ANY_ID_REQ 🙃
This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA 💀 we don't do that here.
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 🆔 Section 4.1 explains how AT_IDENTITY is used.
This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA 🚫
9.3. EAP-Request/AKA-Challenge ⚔️
The server sends EAP-Request/AKA-Challenge for full authentication once it has successfully obtained 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, so see Section 10.15 for that.
The AT_RESULT_IND attribute MAY be included 🌸 Section 6.2 has the scoop on how it's used.
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 that case, the AT_IV and AT_ENCR_DATA attributes are included (Section 10.12).
The plaintext of the AT_ENCR_DATA value field is made 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 hand the peer a pseudonym 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 hand the peer a fast re-authentication identity, 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 any other attributes 👀 Only if those attributes are verified to be valid does the peer derive keys and verify AT_MAC. If something goes wrong, the operation 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 says the peer has successfully authenticated the server and that the EAP exchange will be accepted by the peer's local policy ✅ So if those conditions aren't met, the peer MUST NOT send EAP-Response/AKA-Challenge, and instead the peer MUST send EAP-Response/AKA-Client-Error 🙅♀️➡️🆘
The AT_MAC attribute MUST be included 🔏 In EAP-Response/AKA-Challenge, there is no message-specific data covered by the MAC, so 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, but only if it was included in EAP-Request/AKA-Challenge 🌈 Section 6.2 covers its usage.
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 those 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 doesn't specify any attributes for this message. Future versions of the protocol MAY specify attributes for it ✨
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 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 EAP-Request/AKA-Reauthentication 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 🏃♀️💨
The AT_MAC attribute MUST be included 🔏 No message-specific data is included in the MAC calculation, so see Section 10.15.
The AT_RESULT_IND attribute MAY be included 🌸 Section 6.2 has the details.
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 is made of the following nested encrypted attributes, which MUST be included: AT_COUNTER and AT_NONCE_S. On top of that, 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 EAP-Response/AKA-Reauthentication 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, and 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 the cases specified in Section 5 🙃 The AT_PADDING attribute MAY be included too 🎀
The AT_RESULT_IND attribute MAY be included, but only if it was included in EAP-Request/AKA-Reauthentication 🌈 Section 6.2 explains how it's used.
Sending this packet without AT_COUNTER_TOO_SMALL says the peer has successfully authenticated the server and that the EAP exchange will be accepted by the peer's local policy ✅ So if those conditions aren't met, the peer MUST NOT send EAP-Response/AKA-Reauthentication, and instead the peer MUST send EAP-Response/ AKA-Client-Error 🆘
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 🔀 Section 6 discusses the P bit.
No message-specific data is included in the MAC calculation, so see Section 10.15 🧘♀️
If EAP-Request/AKA-Notification is used on a fast re-authentication exchange, and 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 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 when the P bit is set to one 🔀 Section 6 discusses the P bit.
If EAP-Request/AKA-Notification is used on a fast re-authentication exchange, and 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 🔢💅
10. Attributes 🎀
This section specifies the format of the message attributes 🧁 The attribute type numbers are specified in Section 11 🔢
10.1. Table of Attributes
okay bestie, this table is basically your cheat sheet 📋✨ it tells you which attributes can show up in which messages and how many of each you can get. the messages are numbered in parentheses: (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 marked "E" tells you whether the attribute is a nested one that MUST be included within AT_ENCR_DATA 🔒
so the codes work like this: "0" means the attribute MUST NOT be in that message 🚫, "1" means it MUST be there 💯, "0-1" means it's sometimes there 🤷♀️, and "0*" means it's left out in the cases this document spells out, but it MAY show up in 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 Nngl, the attributes AT_PERMANENT_ID_REQ, AT_ANY_ID_REQ, and AT_FULLAUTH_ID_REQ are mutually exclusive 🙅♀️ so only one of them can be in a message at a time. and if either AT_IV or AT_ENCR_DATA shows up, then both of them MUST be included 👯♀️
10.2. AT_PERMANENT_ID_REQ
here's the layout for AT_PERMANENT_ID_REQ 🧩
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+this one gets used the way Section 4.1 explains 🌸 its value field is just two reserved bytes. you set them to zero when you send, and you ignore them when you receive 🫧
10.3. AT_ANY_ID_REQ
same energy, new name ✨ here's the layout:
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 AT_ANY_ID_REQ is also defined in Section 4.1 💅 and the value field is, you guessed it, two reserved bytes. zero on sending, ignored on reception 🎀
10.4. AT_FULLAUTH_ID_REQ
this is the AT_FULLAUTH_ID_REQ layout 🦋
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 |
+---------------+---------------+-------------------------------+it's defined in Section 4.1 too, and the value field is two reserved bytes again. set to zero on sending, ignored on reception 🫶
10.5. AT_IDENTITY
the AT_IDENTITY attribute is the one that actually carries a subscriber identity 🪪 here's the shape:
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+its use is defined in Section 4.1. the value field starts with a 2-byte actual identity length, which tells you how many bytes the identity is 📏 right after that comes the subscriber identity at exactly that length. the identity can be the permanent identity, a pseudonym identity, or a fast re-authentication identity 🕵️♀️ its format is in Section 4.1.1, and it's the same format used in the AT_IDENTITY attribute and the EAP-Response/Identity packet. the one twist is that the peer MUST NOT decorate the identity it puts in AT_IDENTITY 🙅♀️ the identity doesn't include any terminating null characters either. and since the attribute length has to be a multiple of 4 bytes, the sender pads the identity with zero bytes when it's needed 🧸
10.6. AT_RAND
now AT_RAND 🎲
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 has two reserved bytes, then the AKA RAND parameter, which is 16 bytes (128 bits) 🔢 the reserved bytes get set to zero when sending and ignored on reception.
10.7. AT_AUTN
AT_AUTN is basically RAND's bestie 👯♀️
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 has two reserved bytes followed by the AKA AUTN parameter, 16 bytes (128 bits) 💜 same deal as before: zero them on sending, ignore them on reception.
10.8. AT_RES
here's AT_RES 🧁
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 starts with a 2-byte RES Length, which tells you the exact length of the RES in bits 📐 the RES length is followed by the AKA RES parameter. according to [TS33.105], the AKA RES can be anywhere from 32 to 128 bits 🌈 and because the AT_RES attribute length has to be a multiple of 4 bytes, the sender pads the RES with zero bits where it's needed.
10.9. AT_AUTS
AT_AUTS next 🫧
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 has the AKA AUTS parameter, which is 112 bits (14 bytes) 💖
10.10. AT_NEXT_PSEUDONYM
last one for this part, and it's a whole vibe 🌙 here's the layout:
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 starts with a 2-byte actual pseudonym length, which tells you how many bytes the pseudonym is 📏 after that comes a pseudonym username the peer can use in its next authentication 🕵️♀️ the username MUST NOT include any realm portion 🙅♀️ it doesn't include any terminating null characters either. the length of the attribute must be a multiple of 4 bytes, so the sender pads the pseudonym with zero bytes when needed 🧸 and the username encoding MUST follow the UTF-8 transformation format [RFC3629] 🌸 finally, this attribute MUST always be encrypted by encapsulating it within the AT_ENCR_DATA attribute 🔒💅
10.11. AT_NEXT_REAUTH_ID ✨
okay so this is the attribute that hands your bestie her next fast re-auth name 🦋 here's the layout, bestie:
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 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+so the value field starts with a 2-byte actual re-authentication identity length 🎀 that tells you how many bytes the fast re-auth identity is. right after that comes the identity itself, the name the peer can use for the next fast re-auth (more on that in Section 5 🌸). if a realm part is required in your environment, the identity has both a username portion and a realm name portion, no cap 💅
the identity does not include any terminating null characters, and since the attribute length has to be a multiple of 4 bytes, the sender pads the identity with zero bytes when needed 🫶 the identity encoding MUST follow the UTF-8 transformation format [RFC3629] 😭 and this attribute MUST always be encrypted by wrapping it inside the AT_ENCR_DATA attribute 🔥 no skipping the encryption, periodt ✨
10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING 🧚
okay this section is the encryption squad 💜 AT_IV and AT_ENCR_DATA are how the EAP-AKA peer and server send encrypted stuff to each other, iykyk 🔐
the value field of AT_IV is two reserved bytes followed by a 16-byte initialization vector that AT_ENCR_DATA needs. the reserved bytes get set to zero when sending and get ignored on reception 🌸 the AT_IV attribute MUST be included if and only if AT_ENCR_DATA is included 💖 and if you ever run into a packet that breaks this rule, Section 6.3 tells you what to do 👑
the sender picks the initialization vector at random 🎲 the sender MUST NOT reuse the IV from previous EAP-AKA packets (no repeats, bestie, that's the whole vibe 😭) and the sender SHOULD use a good source of randomness to make it 🍓 if you want the deets on random numbers for security stuff, go check [RFC4086] 🦋 here's the AT_IV layout:
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 |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+now the AT_ENCR_DATA value field is two reserved bytes followed by cipher text bytes 🌈 the cipher text is encrypted with AES [AES] using a 128-bit key in CBC mode, which uses the IV from AT_IV 💅 the reserved bytes get zeroed when sending and ignored on reception, same energy as before ✨ want a refresher on CBC? check [CBC] 📚 here's the layout:
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 key for encryption (K_encr) gets derived in Section 7 🗝️ the plaintext is a bunch of nested EAP-AKA attributes, like a matryoshka doll 🪆
the encryption needs the plaintext length to be a multiple of 16 bytes 😭 so the sender might need to add AT_PADDING as the very last attribute inside AT_ENCR_DATA. you DON'T include AT_PADDING if the nested attributes already add up to a multiple of 16 bytes 🙈 the Length of the Padding attribute counts the Attribute Type and Attribute Length fields too (as usual, bestie 💀). the padding is 4, 8, or 12 bytes, picked so the AT_ENCR_DATA value field lands on a multiple of 16 bytes ✨ the pad bytes get set to zero (00 hexadecimal) when sending.
the recipient MUST verify that the pad bytes are zero 🚨 if that check fails on the peer, the peer MUST send the EAP-Response/AKA-Client-Error packet with the error code "unable to process packet" to end the authentication exchange 💀 if it fails on the server instead, the server sends the EAP-Response/AKA-Notification packet with an AT_NOTIFICATION code that implies failure, which also ends the exchange 😭
here's the AT_PADDING layout 🌸
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+and that's the attribute crew wrapped for this part 🦋 the encryption trio are the bosses of keeping things private 🔐
10.13. AT_CHECKCODE 🎀
Okay bestie, the tea is that the AT_MAC attribute is not used in the very first EAP-AKA messages during the AKA-Identity round 🫖. That's because the keying material hasn't been derived yet, so there's nothing to MAC with 🔑. The peer and the server may swap one or more pairs of EAP-AKA messages of the Subtype AKA-Identity before keys get derived and before AT_MAC can be applied. The EAP/AKA-Identity messages may also show up during fast re-authentication 🔁.
The AT_CHECKCODE attribute MAY be used to protect the EAP/AKA-Identity messages 🛡️. In full authentication, the server MAY include 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. Getting an EAP-Request with AT_CHECKCODE does not mean the peer has to include it in the matching response 🙅♀️. The peer MAY include AT_CHECKCODE even if the server did not include it in the EAP request. Since AT_MAC is used in these messages, AT_CHECKCODE gets integrity protected with AT_MAC 💜. The format of the AT_CHECKCODE 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_CHECKCODE | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Checkcode (0 or 20 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The value field of AT_CHECKCODE starts with two reserved bytes, which may be followed by a 20-byte checkcode 🧩. If the checkcode is not included in AT_CHECKCODE, the attribute is telling you that no EAP/AKA-Identity messages were exchanged. That can happen 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 go in the order they were transmitted: first EAP-Request/AKA-Identity, then the corresponding EAP-Response/AKA-Identity, then the second EAP-Request/AKA-Identity (if used), and so on ⭐.
EAP packets go into the hash calculation "as-is" (exactly 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 gets added between the EAP packets when calculating the checkcode.
Messages are included in request/response pairs, so only full "round trips" count 🔄. Packets that are silently discarded are not included, and retransmitted packets (the ones with the same Identifier value) only get included once. (The base EAP protocol [RFC3748] makes sure 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 the first EAP-Request/AKA-Identity 👑.
The AT_CHECKCODE attribute is optional to implement. It is specified so that the EAP/AKA-Identity messages, and any future extensions to them, can be protected 🦋. 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 attribute other 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The value field of this attribute is 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 has two reserved bytes followed by a keyed message authentication code (MAC) 🎀. The MAC gets calculated over the whole EAP packet and concatenated with optional message-specific data, except that the value field of the MAC attribute is set to zero while the MAC is being calculated. 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 the HMAC-SHA1-128 [RFC2104] keyed hash value 🧮. (The HMAC-SHA1-128 value is made by taking the 20-byte HMAC-SHA1 value and truncating the output to 16 bytes, so the MAC is 16 bytes long.) The derivation of the authentication key (K_aut) used in the MAC calculation 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 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 is a 16-bit unsigned integer counter value, written 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 is 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 🫶.
10.18. AT_NONCE_S ✨
okay so this one is the fresh random number the server cooks up for every EAP-AKA fast re-auth 🎀 Here's the layout:
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 starts with two reserved bytes, then a 16-byte random number that the server freshly generates for this EAP-AKA fast re-authentication 🦋 That number does double duty: the peer uses it as a challenge, and it also seeds the new keying material 🔑 The reserved bytes get set to zero when sent and simply ignored when received. This attribute MUST always be encrypted, which means 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 🎲 For more on generating random numbers for security applications, check out [RFC4086] 📚
10.19. AT_NOTIFICATION 🦋
the AT_NOTIFICATION attribute is the little "hey, here's what happened" message 💌 Layout first:
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 holds a two-byte notification code. The first and second bits of that code, S and P, get read the way Section 6 describes 🧚
These notification codes are reserved, and the descriptions below show what each one means ✨ The peer implementation MAY use different wording when it shows these to the user 💬 The "requested service" part depends on where EAP-AKA is being used.
0: general failure after authentication 💀 It implies failure, and it's used after a successful authentication.16384: general failure 😬 It implies failure, and it's used before authentication.32768: success 🎉 The user has been successfully authenticated. It does not imply failure, and it's used after successful authentication. The way this code gets used is discussed in Section 6.2.1026: the user has been temporarily denied access to the requested service 🚫 It implies failure, and it's used after successful authentication.1031: the user hasn't subscribed to the requested service 📭 It implies failure, and it's used after successful authentication.
10.20. AT_CLIENT_ERROR_CODE 🌸
the AT_CLIENT_ERROR_CODE attribute is how the client says something went sideways on its end 🙈 Here's the layout:
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 holds a two-byte client error code, and these error code values have been reserved 🍓
0: "unable to process packet", which is 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 its protocol design with EAP-SIM [EAP-SIM], including attributes and message Subtypes 👯♀️ EAP-AKA protocol numbers should be administered in the same IANA registry as EAP-SIM. This document sets up the registries and lists the initial protocol numbers for both protocols 📋
EAP-AKA and EAP-SIM messages include a Subtype field. The Subtype is a new numbering space that needs IANA administration. It's an 8-bit integer. These 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..........14The messages are made up of attributes, which have 8-bit attribute type numbers 🧩 Attributes numbered 0 through 127 are called non-skippable attributes, and attributes in the range 128 through 255 are called skippable attributes 🦘 The EAP-AKA and EAP-SIM attribute type number is a new numbering space that needs IANA administration. 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.................................135The AT_NOTIFICATION attribute carries a 16-bit notification code value 💌 The most significant bit is the S bit (for success), and the second most significant bit is the P bit (for phase) 🌈 If the S bit is zero, the code means failure. Codes with the S bit set to one don't mean failure. If the P bit is zero, the code can only be used before authentication has happened. If the P bit is one, the code can only be used after authentication. The notification code is a new numbering space that needs IANA administration. These 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...............................................32768The AT_VERSION_LIST and AT_SELECTED_VERSION attributes, specified in [EAP-SIM], carry 16-bit EAP method version numbers 🔢 The EAP method version number is a new numbering space that needs IANA administration. Value 1 for "EAP-SIM Version 1" has been specified in [EAP-SIM]. Version numbers aren't currently used in EAP-AKA 🙃
The AT_CLIENT_ERROR_CODE attribute carries a 16-bit client error code 🚨 The client error code is a new numbering space that needs IANA administration. 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, following the "Specification Required" policy described in [RFC2434] 📝 Requests must be specified in enough detail that independent implementations can interoperate 🤝 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 💀
okay this is the serious part, bestie 😭 The EAP specification [RFC3748] describes the security vulnerabilities of EAP, and EAP doesn't come with its own security mechanisms 🫠 This section talks about the security properties EAP-AKA claims to have, plus its vulnerabilities and security recommendations 🛡️
12.1. Identity Protection 🫶
EAP-AKA includes optional Identity privacy support that protects the subscriber identity from passive eavesdropping 👀 This document only specifies a mechanism for delivering pseudonyms from the server to the peer during an EAP-AKA exchange. So a peer that hasn't done any EAP-AKA exchanges yet usually doesn't have a pseudonym 🥺 If the peer has no pseudonym, the privacy mechanism can't be used, and the permanent identity has to be sent in the clear 😱 The terminal SHOULD store the pseudonym in non-volatile memory so it survives 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 Section 4.1.2 explains, 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 can't guarantee that the pseudonym will be kept reliably, and Identity privacy is required, then extra protection from an external security mechanism (such as Protected Extensible Authentication Protocol (PEAP) [PEAP]) may be used 🔒 The benefits and 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 don't authenticate the identity or services provided by the EAP authenticator (if it's separate from the EAP server) unless they provide the so-called channel bindings property 🙅♀️ The vulnerabilities related to this have been discussed in [RFC3748], [EAPKeying], and [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 that support as an extension to popular EAP methods such as EAP-TLS, EAP-SIM, or EAP-AKA ✨
12.3. Flooding the Authentication Centre 🏰
okay so the EAP-AKA server usually gets its authentication vectors from the Authentication Centre (AuC) 📦. EAP-AKA gives the AuC a brand new job 💅. The protocols between the EAP-AKA server and the AuC are out of scope for this doc, so we're skipping them 🙅♀️. But ngl, a sneaky EAP-AKA peer could send a ton of protocol requests to pull off a denial-of-service attack 😤. The EAP-AKA server implementation SHOULD take this into account and SHOULD take steps to limit the traffic it sends to the AuC, so the attacker can't flood the AuC or spread the denial-of-service from EAP-AKA to the AuC's other users 🛡️✨
12.4. Key Derivation 🔑
EAP-AKA supports key derivation with 128-bit effective key strength 💪. The key hierarchy lives in Section 7 🗺️
The Transient EAP Keys that protect EAP-AKA packets (K_encr, K_aut), the Master Session Keys, and the Extended Master Session Keys are all cryptographically separate 🧁. An attacker can't work out any non-trivial info about one of these keys from the others 🙅♀️. An attacker also can't 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 🔐 zero leaks, iconic 🌸
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 💅. AKA isn't a password protocol, because the pre-shared secret isn't a passphrase and isn't derived from one 🙌. So EAP-AKA is not vulnerable to dictionary attacks 🎀 no passwords, no problem
12.6. Protection, Replay Protection, and Confidentiality 🛡️
The AT_MAC, AT_IV, AT_ENCR_DATA, and AT_COUNTER attributes are the squad that gives integrity, replay, and confidentiality protection to EAP-AKA Requests and Responses 👯♀️. Integrity protection with AT_MAC covers the EAP header too 📮. It's based on a keyed message authentication code 🔏. Confidentiality (AT_ENCR_DATA and AT_IV) is based on a block cipher 🧩
Keys aren't around at the very start of the EAP methods, so AT_MAC can't protect EAP/AKA-Identity messages 🙈. However, AT_CHECKCODE can optionally be used to protect the integrity of the EAP/AKA-Identity roundtrip 🎁
Confidentiality only covers some of the protocol fields 👀. The table of attributes in Section 10.1 sums up 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, they're sent in the clear 😬. Identity protection is covered in Section 12.1 🫶
On full authentication, replay protection of the EAP exchange comes from the RAND and AUTN values of the underlying AKA scheme 🔁. Replays of EAP-AKA messages are also blocked because messages that can include AT_MAC can only be sent once with a certain EAP-AKA Subtype, and because a different K_aut key is used to calculate AT_MAC in each full authentication exchange 🗝️ double lock, very secure
On fast re-authentication, a counter in AT_COUNTER plus a server random nonce provide replay protection ⏱️. The AT_COUNTER attribute is also included in EAP-AKA notifications if they're used after successful authentication, so replays between re-authentication exchanges are covered too ✨
The contents of the user identity string are implicitly integrity protected, since they're included in key derivation 🪪
EAP-AKA is not a tunneling method 🚫🚇. So EAP-Request/Notification, EAP-Response/Notification, EAP-Success, and EAP-Failure packets are NOT confidential, integrity protected, or replay protected 😭. On physically insecure networks, an attacker could use spoofed versions of these packets to mount denial-of-service attacks 💀. As Section 6.3 explains, the peer will only accept EAP-Success after it successfully authenticates the server 🙌. So an attacker can't convince the peer that mutual authentication succeeded before the peer authenticated 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, since they go out in the clear 👁️. With EAP-AKA, confidential information MUST NOT be transmitted in EAP Notification packets 🚨 this one is a hard no, bestie
12.7. Negotiation Attacks 🕵️♀️
EAP-AKA does not protect the EAP-Response/Nak packet 😬. Because EAP-AKA doesn't protect the EAP method negotiation, EAP method downgrading attacks may be possible 📉. This is especially true if the user uses the same identity with EAP-AKA and other EAP methods 🪞
As Section 8 describes, EAP-AKA can be extended by defining new attribute types 🧩. When you define one, it should be noted that any extra attributes in EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are NOT included in the MACs later on 🙈. So other precautions have to be taken to avoid anyone modifying them 🛠️
EAP-AKA doesn't 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 happens after successful authentication, the EAP-AKA failure indication is integrity and replay protected 💖
Even if an EAP-Failure packet gets lost over an unreliable medium, the EAP-AKA failure indications help the peer and EAP server know each other's authentication decision 🤝. If protected success indications are used, losing a Success packet is also handled by the acknowledged, integrity, and replay protected EAP-AKA success indication 🙌. If the optional success indications aren't used, the peer might think the server completed successful authentication when it actually failed 😱. Since access isn't granted in that case, protected result indications are only needed if the client can't tell it lacks access for an extended period 🕰️
12.9. Man-in-the-Middle Attacks 👀
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, the link integrity protection keys MAY be derived by that external mechanism 🧁
Man-in-the-middle attacks come with using any EAP method inside a tunneled protocol 🚇😈. For instance, an early version of PEAP [PEAP-02] was vulnerable to this 💀. This specification does NOT address these attacks 🙅♀️. If EAP-AKA is used with a tunneling protocol, there should be cryptographic binding between the protocol and EAP-AKA 🔗. That stops rogue authenticators from setting up one-way authenticated tunnels 🚫. For example, newer versions of PEAP include this kind of 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 🧭
12.10. Generating Random Numbers 🎲
An EAP-AKA implementation SHOULD use a good source of randomness to generate the random numbers the protocol needs 🌈. For more on generating random numbers for security applications, check out [RFC4086] 📖
13. Security Claims 📋
This section lists 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.14. Acknowledgements and Contributions 🫶
The authors want 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 the interesting discussions in this problem space 💜
Many thanks to Yoshihiro Ohba for reviewing the document 🌸
This protocol was partly developed in parallel with EAP-SIM [EAP-SIM], so this specification takes in lots of ideas from EAP-SIM, plus 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 📚✨
Okay bestie, these are the docs this spec literally can't function without, so they're basically the VIP list 👑
- [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.
- [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.
15.2. Informative References 🧠🫶
These are the extra-credit reads. Not required, but super helpful for context 💜
- [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.
Appendix A. Pseudo-Random Number Generator 🎲💖
Quick decoder ring first: | means concatenation (smooshing things together) and ^ means exponentiation. Now the vibe-check steps:
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_1Authors' 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
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 in it are provided on an "AS IS" basis. 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 on whether 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 are valid or in scope, or whether a license under such rights might or might not be available. It also doesn't claim to have made any independent effort to find such rights. Information on how rights work for RFC documents lives in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission to use such proprietary rights by implementers or users of this specification can be found in 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 required to implement this standard. Please send that 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). Thank you to everyone keeping the lights on 💅
📦 where this page comes from
- ietf: rfc4187 2006-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms