RFC 4186
Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)
RFC 4186: EAP-SIM 🎀
Part 1 of 20 🦋
Okay bestie, this is RFC 4186, and it's all about EAP-SIM 📱✨. Its full title is "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)." It's from the Network Working Group 🌸.
Two authors wrote it. H. Haverinen, Ed. is from Nokia, and J. Salowey, Ed. is from Cisco Systems. It came out in January 2006 🗓️. It's classed as Informational 💅, which means it's shared as info for the Internet community and isn't an Internet standard. The title block doesn't list any RFCs that it obsoletes or updates, so there's nothing to chase there 🫶.
Status of This Memo ✨
Quick vibe check: this memo provides information for the Internet community 💜. It does not specify an Internet standard of any kind, so don't treat it as one 🙈. Distribution of this memo is unlimited 🌈, so share it with your whole group chat.
Copyright Notice 💖
Copyright (C) The Internet Society (2006). 📝
IESG Note 🔥
Real talk, this part matters 😭. The EAP-SIM protocol was developed by 3GPP, and this document just gives the info to the Internet community 🧚. The EAP WG checked that EAP-SIM is compatible with EAP, as defined in RFC 3748 ✅. But that's the only review it got. Nobody else has looked at it, including the security claims 💀. The IETF also hasn't reviewed how secure the cryptographic algorithms are.
Translation: compatibility with EAP was checked, but the security side hasn't been independently reviewed. Keep that in mind before you trust anything here 🔥.
Abstract 🌸
This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM) 📱. GSM is a second generation mobile network standard 🍓.
The EAP-SIM mechanism improves on GSM authentication and key agreement 💅. It lets multiple authentication triplets get combined to create authentication responses and session keys that are stronger than the individual GSM triplets 💪. It also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure 👑. Iconic, honestly ✨.
Table of Contents 🧚
Here's the full table of contents, exactly as it appears in the original 💜:
1. Introduction ....................................................4
2. Terms ...........................................................5
3. Overview ........................................................8
4. Operation ......................................................10
4.1. Version Negotiation .......................................10
4.2. Identity Management .......................................11
4.2.1. Format, Generation and Usage of Peer Identities ....11
4.2.2. Communicating the Peer Identity to the Server ......17
4.2.3. Choice of Identity for the EAP-Response/Identity ...19
4.2.4. Server Operation in the Beginning of
EAP-SIM Exchange ...................................19
4.2.5. Processing of EAP-Request/SIM/Start by the Peer ....20
4.2.6. Attacks Against Identity Privacy ...................21
4.2.7. Processing of AT_IDENTITY by the Server ............22
4.3. Message Sequence Examples (Informative) ...................23
4.3.1. Full Authentication ................................24
4.3.2. Fast Re-authentication .............................25
4.3.3. Fall Back to Full Authentication ...................26
4.3.4. Requesting the Permanent Identity 1 ................27
4.3.5. Requesting the Permanent Identity 2 ................28
4.3.6. Three EAP-SIM/Start Roundtrips .....................28
5. Fast Re-Authentication .........................................30
5.1. General ...................................................30
5.2. Comparison to UMTS AKA ....................................31
5.3. Fast Re-authentication Identity ...........................31
5.4. Fast Re-authentication Procedure ..........................33
5.5. Fast Re-authentication Procedure when Counter Is
Too Small .................................................36
6. EAP-SIM Notifications ..........................................37
6.1. General ...................................................37
6.2. Result Indications ........................................39
6.3. Error Cases ...............................................40
6.3.1. Peer Operation .....................................40
6.3.2. Server Operation ...................................41
6.3.3. EAP-Failure ........................................42
6.3.4. EAP-Success ........................................42
7. Key Generation .................................................43
8. Message Format and Protocol Extensibility ......................45
8.1. Message Format ............................................45
8.2. Protocol Extensibility ....................................47
9. Messages .......................................................48
9.1. EAP-Request/SIM/Start .....................................48
9.2. EAP-Response/SIM/Start ....................................49
9.3. EAP-Request/SIM/Challenge .................................49
9.4. EAP-Response/SIM/Challenge ................................50
9.5. EAP-Request/SIM/Re-authentication .........................51
9.6. EAP-Response/SIM/Re-authentication ........................51
9.7. EAP-Response/SIM/Client-Error .............................52
9.8. EAP-Request/SIM/Notification ..............................52
9.9. EAP-Response/SIM/Notification .............................53
10. Attributes ....................................................53
10.1. Table of Attributes ......................................53
10.2. AT_VERSION_LIST ..........................................54
10.3. AT_SELECTED_VERSION ......................................55
10.4. AT_NONCE_MT ..............................................55
10.5. AT_PERMANENT_ID_REQ ......................................56
10.6. AT_ANY_ID_REQ ............................................56
10.7. AT_FULLAUTH_ID_REQ .......................................57
10.8. AT_IDENTITY ..............................................57
10.9. AT_RAND ..................................................58
10.10. AT_NEXT_PSEUDONYM .......................................59
10.11. AT_NEXT_REAUTH_ID .......................................59
10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING .....................60
10.13. AT_RESULT_IND ...........................................62
10.14. AT_MAC ..................................................62
10.15. AT_COUNTER ..............................................63
10.16. AT_COUNTER_TOO_SMALL ....................................63
10.17. AT_NONCE_S ..............................................64
10.18. AT_NOTIFICATION .........................................64
10.19. AT_CLIENT_ERROR_CODE ....................................65
11. IANA Considerations ...........................................66
12. Security Considerations .......................................66
12.1. A3 and A8 Algorithms .....................................66
12.2. Identity Protection ......................................66
12.3. Mutual Authentication and Triplet Exposure ...............67
12.4. Flooding the Authentication Centre .......................69
12.5. Key Derivation ...........................................69
12.6. Cryptographic Separation of Keys and Session
Independence .............................................70
12.7. Dictionary Attacks .......................................71
12.8. Credentials Re-use .......................................71
12.9. Integrity and Replay Protection, and Confidentiality .....72
12.10. Negotiation Attacks .....................................73
12.11. Protected Result Indications ............................73
12.12. Man-in-the-Middle Attacks ...............................74
12.13. Generating Random Numbers ...............................74
13. Security Claims ...............................................74
14. Acknowledgements and Contributions ............................75
14.1. Contributors .............................................75
14.2. Acknowledgements .........................................75
14.2.1. Contributors' Addresses ...........................77
15. References ....................................................78
15.1. Normative References .....................................78
15.2. Informative References ...................................79
Appendix A. Test Vectors .........................................81
A.1. EAP-Request/Identity .....................................81
A.2. EAP-Response/Identity ....................................81
A.3. EAP-Request/SIM/Start ....................................82
A.4. EAP-Response/SIM/Start ...................................82
A.5. EAP-Request/SIM/Challenge ................................83
A.6. EAP-Response/SIM/Challenge ...............................86
A.7. EAP-Success ..............................................86
A.8. Fast Re-authentication ...................................86
A.9. EAP-Request/SIM/Re-authentication ........................87
A.10. EAP-Response/SIM/Re-authentication ......................89
Appendix B. Pseudo-Random Number Generator .......................90Next up: Section 1, Introduction 🦋
1. Introduction ✨
okay so bestie, this doc is all about an Extensible Authentication Protocol (EAP) [RFC3748] mechanism that does authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM) 📱💖
GSM is a second generation mobile network standard. Second generation and third generation mobile networks use different authentication and key agreement mechanisms, so it's a whole vibe 🌈 EAP-AKA [EAP-AKA] is the EAP method based on the Authentication and Key Agreement (AKA) mechanism used in 3rd generation mobile networks, and it's literally the newer sibling 👑
GSM authentication is based on a challenge-response mechanism 🎀 The A3/A8 authentication and key derivation algorithms that run on the SIM can be given a 128-bit random number (RAND) as a challenge. The SIM runs operator-specific algorithms, which take the RAND and a secret key Ki (stored on the SIM) as input, and produce a 32-bit response (SRES) and a 64-bit long key Kc as output. The Kc key was originally meant to be an encryption key over the air interface, but in this protocol it's used for deriving keying material and is not directly used 🦋 Hence, the secrecy of Kc is critical to the security of this protocol, so guard it like your diary 🔒 For more information about GSM authentication, see [GSM-03.20]. See Section 12.1 for more discussion about the GSM algorithms used in EAP-SIM 💅
The lack of mutual authentication is a weakness in GSM authentication 😭 The derived 64-bit cipher key (Kc) is not strong enough for data networks where stronger and longer keys are required. So in EAP-SIM, several RAND challenges are used to generate several 64-bit Kc keys, which get combined into stronger keying material 🧚 In EAP-SIM, the client issues a random number NONCE_MT to the network to contribute to key derivation and to prevent replays of EAP-SIM requests from previous exchanges. You can think of NONCE_MT as the client's challenge to the network 🍓 EAP-SIM also extends the combined RAND challenges and other messages with a message authentication code, which gives message integrity protection along with mutual authentication. Iconic 👑
EAP-SIM specifies optional support for protecting the privacy of subscriber identity, using the same concept as GSM, which uses pseudonyms and temporary identifiers 🙈 It also specifies an optional fast re-authentication procedure ⭐
The security of EAP-SIM builds on underlying GSM mechanisms. The security properties are documented in Section 11 of this document. Implementers and users are advised to carefully study the security considerations in Section 11, to figure out whether those properties are sufficient for their environment, especially since the secrecy of Kc keys is essential to EAP-SIM's security 🚨 In brief, EAP-SIM is in no sense weaker than the GSM mechanisms. In some cases it actually provides better security properties than the underlying GSM mechanisms, particularly if the SIM credentials are only used for EAP-SIM and aren't reused from GSM/GPRS 🫶 Many of EAP-SIM's security features rely on the secrecy of the Kc values in the SIM triplets, so protecting these values is key, periodt 💜
The 3rd Generation Partnership Project (3GPP) specified an enhanced Authentication and Key Agreement (AKA) architecture for the Universal Mobile Telecommunications System (UMTS) 🌸 The 3rd generation AKA mechanism includes mutual authentication, replay protection, and derivation of longer session keys. EAP-AKA [EAP-AKA] is the EAP method based on 3rd generation AKA. EAP-AKA is the more secure protocol, so it may be used instead of EAP-SIM if 3rd generation identity modules and 3G network infrastructures are available ✨
2. Terms 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📖
The terms and abbreviations "authenticator", "backend authentication server", "EAP server", "peer", "Silently Discard", "Master Session Key (MSK)", and "Extended Master Session Key (EMSK)" in this document are to be interpreted as described in [RFC3748] 💅
This document frequently uses the following terms and abbreviations 🦋
AAA protocol : Authentication, Authorization, and Accounting protocol
AuC : Authentication Centre. The GSM network element that provides the authentication triplets for authenticating the subscriber.
Authentication vector : GSM triplets can be alternatively called authentication vectors.
EAP : Extensible Authentication Protocol
Fast re-authentication : An EAP-SIM authentication exchange that is based on keys derived upon a preceding full authentication exchange. The GSM authentication and key exchange algorithms are not used in the fast re-authentication procedure. 🚀
Fast Re-authentication Identity : A fast re-authentication identity of the peer, including an NAI realm portion in environments where a realm is used. Used on fast re-authentication only.
Fast Re-authentication Username : The username portion of fast re-authentication identity, i.e., not including any realm portions.
Full authentication : An EAP-SIM authentication exchange based on the GSM authentication and key agreement algorithms. 💫
GSM : Global System for Mobile communications.
GSM Triplet : The tuple formed by the three GSM authentication values RAND, Kc, and SRES.
IMSI : International Mobile Subscriber Identifier, used in GSM to identify subscribers.
MAC : Message Authentication Code
NAI : Network Access Identifier
Nonce : A value that is used at most once or that is never repeated within the same cryptographic context. In general, a nonce can be predictable (e.g., a counter) or unpredictable (e.g., a random value). Since some cryptographic properties may depend on the randomness of the nonce, attention should be paid to whether a nonce is required to be random or not. In this document, the term nonce is only used to denote random nonces, and it is not used to denote counters. 🎲
Permanent Identity : The permanent identity of the peer, including an NAI realm portion in environments where a realm is used. The permanent identity is usually based on the IMSI. Used on full authentication only.
Permanent Username : The username portion of permanent identity, i.e., not including any realm portions.
Pseudonym Identity : A pseudonym identity of the peer, including an NAI realm portion in environments where a realm is used. Used on full authentication only.
Pseudonym Username : The username portion of pseudonym identity, i.e., not including any realm portions.
SIM : Subscriber Identity Module. The SIM is traditionally a smart card distributed by a GSM operator. 🌈
3. Overview ✨
okay so bestie, here's the big picture 🦋 Figure 1 shows the EAP-SIM full authentication flow, and this version skips the optional protected success indications 💅 The authenticator usually talks to an EAP server sitting on a backend authentication server through an AAA protocol. The authenticator in the figure is often just relaying EAP messages back and forth to that server, but those backend AAA messages aren't drawn in 🧚
Peer Authenticator
| EAP-Request/Identity |
|<---------------------------------------------------------|
| |
| EAP-Response/Identity |
|--------------------------------------------------------->|
| |
| EAP-Request/SIM/Start (AT_VERSION_LIST) |
|<---------------------------------------------------------|
| |
| EAP-Response/SIM/Start (AT_NONCE_MT, AT_SELECTED_VERSION)|
|--------------------------------------------------------->|
| |
| EAP-Request/SIM/Challenge (AT_RAND, AT_MAC) |
|<---------------------------------------------------------|
+-------------------------------------+ |
| Peer runs GSM algorithms, verifies | |
| AT_MAC and derives session keys | |
+-------------------------------------+ |
| EAP-Response/SIM/Challenge (AT_MAC) |
|--------------------------------------------------------->|
| |
| EAP-Success |
|<---------------------------------------------------------|
| |
Figure 1: EAP-SIM full authentication procedureThe very first EAP Request the authenticator sends is EAP-Request/Identity 🌸 On full authentication, the peer replies with either its IMSI (International Mobile Subscriber Identity) or a temporary pseudonym if identity privacy is turned on, as covered in Section 4.2.
After the peer's EAP-Response/Identity, the peer keeps getting EAP Requests of Type 18 (SIM) from the EAP server and answering them 💖 SIM packets also carry a Subtype field. On full authentication, the very first EAP-Request/SIM is Subtype 10 (Start) ✨ EAP-SIM packets wrap their parameters in attributes that use a Type, Length, Value format. The packet format and how attributes work are in Section 8.
EAP-Request/SIM/Start carries the list of EAP-SIM versions the EAP server supports, inside the AT_VERSION_LIST attribute. This packet may also include attributes for asking for the subscriber identity, as described in Section 4.2.
The peer answers EAP-Request/SIM/Start with EAP-Response/SIM/Start 🎀 That packet has AT_NONCE_MT, a random number NONCE_MT picked by the peer, plus AT_SELECTED_VERSION, which holds the version the peer picked. Version negotiation is protected because the version list and the selected version both feed into the calculation of keying material (Section 7). Very secure, very iconic 👑
Once the EAP server gets EAP-Response/SIM/Start, it collects n GSM triplets to authenticate the subscriber, where n = 2 or n = 3 🔥 It derives the keying material from those triplets, as specified in Section 7. The triplets can come from an Authentication Centre (AuC) on the GSM network. Per GSM specifications, you can get between 1 and 5 triplets at a time. The EAP server is allowed to store triplets for later, but triplets MUST NOT be re-used, except in some error cases specified in Section 10.9. No re-using triplets, bestie 🙅♀️
The next request from the EAP server is SIM with Subtype Challenge (11) 🦋 It carries the RAND challenges and an AT_MAC message authentication code attribute that covers those challenges. AT_MAC is a general MAC attribute that shows up in lots of EAP-SIM messages.
When the peer gets EAP-Request/SIM/Challenge, it runs the GSM authentication algorithm and works out its own copy of the MAC. Then it checks that its calculated MAC matches the one it received. If the MACs don't match, the peer sends EAP-Response/SIM/Client-Error and the authentication exchange ends 💀
Here's the vibe check 💜 The RANDs come with AT_MAC, and the peer's NONCE_MT goes into AT_MAC too. So the peer can confirm that the EAP-SIM message is fresh (not a replay) and that the sender actually has valid GSM triplets for the subscriber. Literally so safe.
If everything checks out, the peer replies with EAP-Response/SIM/Challenge, which includes an AT_MAC covering the peer's SRES response values (Section 9.4). The EAP server verifies the MAC is correct 🫶 Since protected success indications aren't used in this example, the EAP server sends EAP-Success to say the authentication worked. (Protected success indications are discussed in Section 6.2.) The EAP server may also include derived keying material in the message it sends to the authenticator. The peer already derived the same keying material, so the authenticator doesn't forward the keying material to the peer along with EAP-Success ✨
EAP-SIM also has a separate fast re-authentication procedure 🌈 This one doesn't use the A3/A8 algorithms or the GSM infrastructure at all. It's based on keys derived during full authentication. If the peer has kept state for fast re-authentication and wants to use it, it signals that by sending a specific fast re-authentication identity instead of the permanent identity or a pseudonym identity. The fast re-authentication procedure is in Section 5.
4. Operation 🎀
4.1. Version Negotiation 🧚
EAP-SIM has version negotiation built in so the protocol can grow in the future 🌸 Version negotiation happens on full authentication and uses two attributes. AT_VERSION_LIST is one, and the server always includes it in EAP-Request/SIM/Start. AT_SELECTED_VERSION is the other, and the peer includes it in EAP-Response/SIM/Start on full authentication.
AT_VERSION_LIST lists the EAP-SIM versions the server supports. If AT_VERSION_LIST doesn't include a version that the peer implements and that its security policy allows, then the peer MUST send the EAP-Response/SIM/Client-Error packet (Section 9.7) to the server with the error code "unsupported version" 🙅♀️ If there's a suitable version, the peer includes AT_SELECTED_VERSION with that version in the EAP-Response/SIM/Start packet. The peer MUST only indicate a version that is included in the AT_VERSION_LIST. If several versions are acceptable, the peer SHOULD choose the version that occurs first in the version list 💖
The version list in AT_VERSION_LIST and the selected version in AT_SELECTED_VERSION both go into the key derivation procedure (Section 7). If an attacker changes either one of those attributes, the peer and the server end up deriving different keying material 😭 Because the K_aut keys are different, the server and peer calculate different AT_MAC values. So the peer notices that AT_MAC, which is in EAP-Request/SIM/Challenge, is wrong and sends EAP-Response/SIM/Client-Error. The authentication procedure then terminates. Caught in 4K 📸
4.2. Identity Management 🦋
4.2.1. Format, Generation and Usage of Peer Identities 🍓
4.2.1.1. General
At the start of EAP authentication, the Authenticator or the EAP server usually sends the 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].
GSM subscribers are identified by the International Mobile Subscriber Identity (IMSI) [GSM-03.03] 🌸 The IMSI is a string of no more than 15 digits. It's made of a three-digit Mobile Country Code (MCC), a two- or three-digit Mobile Network Code (MNC), and a Mobile Subscriber Identification Number (MSIN) of no more than 10 digits. The MCC and MNC together uniquely identify the GSM operator and help find the AuC where the authentication vectors for this subscriber should be fetched from 🧚
Internet AAA protocols identify users with a Network Access Identifier (NAI) [RFC4282] ✨ In a roaming setup, the NAI is a username and a realm joined by "@" (username@realm). The username part identifies the subscriber within the realm 💅
This section defines the peer identity format used in EAP-SIM 💜 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 part of the peer identity that identifies the user, so the username does NOT include the realm portion. (Yes, I'm yelling about the realm, but it's just the way it reads 🙈)
4.2.1.2. Identity Privacy Support
EAP-SIM includes optional identity privacy (anonymity) support 🔥 It can hide the cleartext permanent identity, which keeps the subscriber's EAP exchanges untraceable to eavesdroppers. The permanent identity never changes, so revealing it would help observers track the user, which is not a vibe 😭 The permanent identity is usually based on the IMSI, and that can help tracking even more, since the same identifier might be used in other contexts too. Identity privacy runs on temporary identities, called pseudonyms. These are equivalent to, but separate from, the Temporary Mobile Subscriber Identities (TMSI) used on cellular networks 🎀 For security considerations around identity privacy, see Section 12.2.
4.2.1.3. Username Types in EAP-SIM identities
There are three types of usernames in EAP-SIM peer identities 🌈
- Permanent usernames. For example,
1123456789098765@myoperator.commight be a valid permanent identity. In this example,1123456789098765is the permanent username. - Pseudonym usernames. For example,
3s7ah6n9q@myoperator.commight be a valid pseudonym identity. In this example,3s7ah6n9qis the pseudonym username. - Fast re-authentication usernames. For example,
53953754@myoperator.commight be a valid fast re-authentication identity. In this case,53953754is 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 🧚♀️
The first two types are only used on full authentication, and the last one is only used on fast re-authentication 💖 When the optional identity privacy support isn't used, the non-pseudonym permanent identity is used on full authentication. The fast re-authentication exchange is specified in Section 5 ✨
4.2.1.4. Username Decoration
okay so sometimes the peer wants to glow up its identity 💅 by sticking a little string on the front or back of the username, to add extra AAA routing info on top of the NAI realm 🎀. (using the NAI realm portion doesn't count as decoration, btw 🙄) username decoration is totally out of scope for this doc 🙈, but heads up: decorating might make the server not recognize a valid username 😭. so the peer MAY decorate the identity it puts in EAP-Response/Identity, and the EAP server MAY accept a decorated peer username in that message 🦋. however, the peer or the EAP server MUST NOT decorate any other peer identities used in the various EAP-SIM attributes 🚫. only the identity in EAP-Response/Identity can be decorated ✨
4.2.1.5. NAI Realm Portion
the peer MAY include a realm portion in the peer identity, following the NAI format 🌸. adding a realm is totally optional, 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-SIM peer implementation 🍓. usually the peer is configured with the NAI realm of the home operator. operators MAY reserve a specific realm name for EAP-SIM users, which makes it super easy to recognize that the NAI belongs to a GSM subscriber 👑. a reserved NAI realm may be a useful hint for which authentication method to try first during method negotiation 🧚. when the peer is using a pseudonym username instead of the permanent username, it picks the realm name the same way it would with 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, is specified in [3GPP-TS-23.003] ✨
some old implementations derive the realm name 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. there are no DNS servers running at owlan.org, so these realm names can only be used with manually configured AAA routing 😬. New implementations SHOULD use the mechanism specified in [3GPP-TS-23.003] instead of owlan.org 💅
the IMSI is a string of digits with no explicit structure, so the peer may not be able to tell how long the MNC portion is 🤷♀️. if the peer can't determine whether the MNC is two or three digits long, the peer MAY use a 3-digit MNC. if the correct MNC length is two, then the MNC used in the realm name includes the first digit of the MSIN 💀. so when configuring AAA networks for operators with 2-digit MNCs, the network SHOULD also be prepared for realm names with incorrect, 3-digit MNCs 🫶
4.2.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 "1" | IMSI, where | means concatenation. so basically, the first character is the digit one (ASCII value 31 hexadecimal), followed by the IMSI 🌸. the IMSI is encoded as an ASCII string of no more than 15 decimal digits (ASCII values 30 to 39 hexadecimal), one character per IMSI digit, in the order specified in [GSM-03.03] ✨. for example, a permanent username derived from the IMSI 295023820005424 gets encoded as the ASCII string "1295023820005424", which in hex is:
31 32 39 35 30 32 33 38 32 30 30 30 35 34 32 34the EAP server MAY use the leading "1" as a hint to try EAP-SIM as the first authentication method during method negotiation, instead of something like EAP/AKA 🦋. the EAP-SIM server MAY propose EAP-SIM even if the leading character wasn't "1" 💖
alternatively, an implementation MAY choose a permanent username that isn't based on the IMSI 🧚. in that case, how the username gets selected, its format, and how it's processed are all out of scope for this document 🙈. and in that case the peer implementation MUST NOT prepend any leading characters to the username 🚫
4.2.1.7. Generating Pseudonyms and Fast Re-authentication Identities by the Server
pseudonym usernames and fast re-authentication identities are generated by the EAP server 🏭. the EAP server makes them in an implementation-dependent manner 🌈. 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-SIM has no provisions to make sure the same EAP server that generated a pseudonym username is the one used when that pseudonym shows up again 😭. it is recommended that EAP servers implement some centralized mechanism so all EAP servers of the home operator can map pseudonyms generated by other servers back to the permanent identity 🫶. if there's no such mechanism, an EAP server that fails to understand a pseudonym issued by another server can request that the peer send the permanent identity 🙏
when issuing a fast re-authentication identity, the EAP server may include a realm name in it, so the fast re-authentication request gets forwarded to the same EAP server 🧭
when generating fast re-authentication identities, the server SHOULD choose a fresh, new one that's different from the ones previously used after the same full authentication exchange ✨. a full authentication exchange plus its associated fast re-authentication exchanges are called the same "full authentication context" 🦋. the fast re-authentication identity SHOULD include a random component 🎲. that random component works as a full authentication context identifier. a context-specific fast re-authentication identity helps the server figure out whether its fast re-authentication state information matches its peer's (in other words, whether the state is from the same full authentication exchange) 💅. the random component also makes fast re-authentication identities unpredictable, so an attacker can't start a fast re-authentication exchange to get the server's EAP-Request/SIM/Re-authentication packet 🚫🔥
the random component is the thing that stops attackers from guessing identities and fishing for the server's EAP-Request/SIM/Re-authentication packet. keep it unpredictable, bestie 🔐
transmitting pseudonyms and fast re-authentication identities from the server to the peer is covered in Section 4.2.1.8 🎀. the pseudonym is sent as a username with no NAI realm, while the fast re-authentication identity is sent as a complete NAI, including a realm portion if a realm is required 🌸. the realm is included in the fast re-authentication identity so the server can include a server-specific realm 💜
regardless of how it's constructed, the pseudonym username MUST conform to the grammar specified for the username portion of an NAI 📜. the fast re-authentication identity also MUST conform to the NAI grammar 📜. 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 🌈
in any case, it's necessary that permanent usernames, pseudonym usernames, and fast re-authentication usernames are separate and recognizable from each other 🙌. it's also desirable that EAP-SIM and EAP-AKA [EAP-AKA] usernames can be told apart, which helps the server figure out which method to offer 🧚
it's generally the EAP server's job, along with 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. the EAP server MUST compose pseudonym usernames and fast re-authentication usernames so it can tell whether an NAI username is an EAP-SIM pseudonym username or an EAP-SIM fast re-authentication username 🧩. for example, when the usernames are derived from the IMSI, the server could use different leading characters for pseudonym usernames and fast re-authentication usernames (like a pseudonym starting with a "3" character) 🍓. when mapping a fast re-authentication identity to a permanent identity, the server SHOULD only examine the username portion of the fast re-authentication identity and ignore the realm portion 🫶
because the peer might fail to save a pseudonym username sent in an EAP-Request/SIM/Challenge (for example, due to a malfunction), the EAP server SHOULD keep at least the most recently used pseudonym username, in addition to the most recently issued one 🛟. if the authentication exchange doesn't complete successfully, the server SHOULD NOT overwrite the pseudonym username that was issued during the most recent successful authentication exchange 🔒
4.2.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 in cipher, using the AT_ENCR_DATA attribute 🔐✨
the EAP-Request/SIM/Challenge message MAY include an encrypted pseudonym username and/or an encrypted fast re-authentication identity in the value field of the AT_ENCR_DATA attribute 🎀. because identity privacy support and fast re-authentication are optional implementations, the peer MAY ignore the AT_ENCR_DATA attribute and always use the permanent identity 🙈. on fast re-authentication (discussed in Section 5), the server MAY include a new, encrypted fast re-authentication identity in the EAP-Request/SIM/Re-authentication message 🦋
on receipt of the EAP-Request/SIM/Challenge, the peer MAY decrypt the encrypted data in AT_ENCR_DATA 🔓. if the authentication exchange is successful and the encrypted data includes a pseudonym username, the peer may use that pseudonym username on the next full authentication 🌸. if a fast re-authentication identity is included, the peer MAY save it along with other fast re-authentication state information (as discussed in Section 5) for the next fast re-authentication 💾. if the authentication exchange does not complete successfully, the peer MUST ignore the received pseudonym username and the fast re-authentication identity 🚫
if the peer doesn't receive a new pseudonym username in the EAP-Request/SIM/Challenge message, the peer 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, and the peer MUST NOT re-use them 🔥. when the peer uses a fast re-authentication identity in an EAP exchange, the peer MUST discard that fast re-authentication identity and not re-use it in another EAP authentication exchange, even if the authentication exchange wasn't completed 💀💖
4.2.1.9. Usage of the Pseudonym by the Peer ✨
okay so when the optional identity privacy support gets used on full authentication, the peer MAY use a pseudonym username it got during an earlier full authentication sequence as the username portion of its NAI 🫶. The peer MUST NOT modify the pseudonym username it received in AT_NEXT_PSEUDONYM 🙅♀️. BUT (and this is the lowkey tricky bit) the peer MAY need to decorate the username in some environments by adding a string to the front or back that carries supplementary AAA routing info 🧚.
When you're using a pseudonym username somewhere a realm portion is used, the peer glues the pseudonym onto the "@" character plus an NAI realm portion 💜. We talked about how the realm gets picked above, and the peer picks it the same way whether it's using the permanent username or a pseudonym 🌸.
4.2.1.10. Usage of the Fast Re-authentication Identity by the Peer 🦋
On fast re-authentication, the peer just uses the fast re-authentication identity it got during the previous authentication sequence 💅. A new re-authentication identity MAY be handed out during full authentication AND during fast re-authentication, so expect a fresh one either way ✨. The peer MUST NOT modify the username part of the fast re-authentication identity it got in AT_NEXT_REAUTH_ID, except when username decoration is needed 🙈. Even then, the "root" fast re-authentication username must not be changed, but you're allowed to stick another string on the front or back of it 🎀.
4.2.2. Communicating the Peer Identity to the Server 🌈
4.2.2.1. General 🍓
The peer identity MAY be sent to the server in an EAP-Response/Identity message 💌. That message MAY hold 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 back to the permanent identity, then the authentication carries on the way Section 3's overview describes 🔥. If the peer uses a fast re-authentication identity, AND that identity matches a valid one the server is holding, AND the server agrees to do fast re-authentication, then a fast re-authentication exchange happens, as described in Section 5 💖.
The peer identity can also go from the peer to the server inside EAP-SIM messages instead of EAP-Response/Identity 💜. When that happens, the server puts an identity-requesting attribute (AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the EAP-Request/SIM/Start message, and the peer answers with the AT_IDENTITY attribute, holding its identity, in the EAP-Response/SIM/Start message 👑. AT_ANY_ID_REQ is the general one, and the server uses it when it doesn't say what kind of identity it wants back in AT_IDENTITY ✨. The server uses AT_FULLAUTH_ID_REQ to ask for either the permanent identity or a pseudonym identity 🧚. And AT_PERMANENT_ID_REQ is the server asking for the peer's permanent identity, full stop 🔥.
The identity format in AT_IDENTITY is the same as in the EAP-Response/Identity packet (except identity decoration is not allowed 🙅♀️). AT_IDENTITY holds a permanent identity, a pseudonym identity, or a fast re-authentication identity 💖.
Okay, pay attention to this one, bestie 🚨. The EAP-SIM peer and the EAP-SIM server are the only ones that process AT_IDENTITY; entities that just pass EAP packets along don't process it 💀. 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 passed to them some other way within the AAA protocol 😭.
4.2.2.2. Relying on EAP-Response/Identity Discouraged 🙈
The EAP-Response/Identity packet isn't method-specific, so lots of implementations let an EAP Framework handle it 🧁. That adds an extra layer of processing between the EAP peer and the EAP server 🫠. That extra layer might cache identity responses or add decorations to the identity, and if the identity response gets changed, the EAP peer and EAP server end up using different identities in the key derivation, and the protocol breaks 💀.
So, for this reason, it is RECOMMENDED that the EAP peer and server use the method-specific identity attributes in EAP-SIM, and the server is strongly discouraged from relying on EAP-Response/Identity 🙅♀️✨.
Specifically, 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 to send an unmodified and undecorated copy of the identity in AT_IDENTITY 🔥.
4.2.3. Choice of Identity for the EAP-Response/Identity 🦋
If the EAP-SIM peer gets started by an EAP-Request/Identity message, then the peer MAY use an EAP-SIM identity in the EAP-Response/Identity packet 💌. When that happens, the peer does the following steps 👇.
If the peer has fast re-authentication state saved AND wants to use fast re-authentication, then the peer sends the fast re-authentication identity in EAP-Response/Identity 💜.
Else, if the peer has a pseudonym username available, then the peer sends the pseudonym identity in EAP-Response/Identity 🌸.
In other cases, the peer sends the permanent identity in EAP-Response/Identity 🫶.
4.2.4. Server Operation in the Beginning of EAP-SIM Exchange 👑
As Section 4.2.2.2 talked about, the server SHOULD NOT rely on an identity string received in EAP-Response/Identity 🙈. So the RECOMMENDED way to start an EAP-SIM exchange is to ignore any identity strings that came in 🧚. The server SHOULD begin the EAP-SIM exchange by sending the EAP-Request/SIM/Start packet with an identity-requesting attribute, so it can tell the peer to put an identity in AT_IDENTITY of its EAP-Response/SIM/Start message ✨. There are three ways to ask the peer for an identity, and we'll go through them below 💅.
If the server decides NOT to ignore the contents of EAP-Response/Identity, then the server might already have an EAP-SIM identity from that packet 🎀. BUT, if the EAP server hasn't gotten any EAP-SIM peer identity (permanent, pseudonym, or fast re-authentication) from the peer when it sends the first EAP-SIM request, OR if it got an EAP-Response/Identity packet whose contents don't look like a valid permanent, pseudonym or re-authentication identity, then the server MUST request an identity from the peer using one of the methods below 😭.
The server sends EAP-Request/SIM/Start with the AT_PERMANENT_ID_REQ attribute, so the peer puts its permanent identity in AT_IDENTITY of the EAP-Response/SIM/Start message 💖. It does this in these cases:
- The server doesn't support fast re-authentication or identity privacy.
- The server decided to process a received identity, AND it recognizes that identity as a pseudonym identity, BUT it can't map the pseudonym identity to a permanent identity.
The server issues EAP-Request/SIM/Start with the AT_FULLAUTH_ID_REQ attribute, so the peer puts a full authentication identity (pseudonym identity or permanent identity) in AT_IDENTITY of the EAP-Response/SIM/Start message 🌈. It does this in these cases:
- The server doesn't support fast re-authentication, AND the server does support identity privacy.
- The server decided to process a received identity, AND it recognizes that identity as a re-authentication identity, BUT it can't map that re-authentication identity to a permanent identity.
The server issues EAP-Request/SIM/Start with the AT_ANY_ID_REQ attribute, so the peer puts an identity in AT_IDENTITY of the EAP-Response/SIM/Start message, and the server doesn't say what kind of identity it prefers 🦋. This happens in other cases too, like when the server ignores a received EAP-Response/Identity, when the server doesn't have any identity, or when it doesn't recognize the format of a received identity 🍓.
4.2.5. Processing of EAP-Request/SIM/Start by the Peer ✨
Okay so, when the peer gets an EAP-Request/SIM/Start message, it MUST do the following steps. 🎀
If the EAP-Request/SIM/Start doesn't include an identity request attribute, the peer replies with EAP-Response/SIM/Start without AT_IDENTITY. It includes AT_SELECTED_VERSION and AT_NONCE_MT, because this is a full authentication exchange. 💅
If the EAP-Request/SIM/Start includes AT_PERMANENT_ID_REQ, and the peer does not have a pseudonym available, then the peer MUST respond with EAP-Response/SIM/Start and put the permanent identity in AT_IDENTITY. If the peer does have 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/SIM/Start and include the permanent identity in AT_IDENTITY, or respond with EAP-Response/SIM/Client-Error packet with the code "unable to process packet".
If the EAP-Request/SIM/Start includes AT_FULL_AUTH_ID_REQ, and the peer has a pseudonym available, then the peer SHOULD respond with EAP-Response/SIM/Start and put the pseudonym identity in AT_IDENTITY. If the peer doesn't have a pseudonym when it gets this message, then the peer MUST respond with EAP-Response/SIM/Start and include the permanent identity in AT_IDENTITY. The Peer MUST NOT use a re-authentication identity in the AT_IDENTITY attribute. Main character rules, no exceptions 👑.
If the EAP-Request/SIM/Start includes AT_ANY_ID_REQ, and the peer has maintained fast re-authentication state information and wants to use fast re-authentication, then the peer responds with EAP-Response/SIM/Start and includes the fast re-authentication identity in AT_IDENTITY. Else, if the peer has a pseudonym identity available, it responds with EAP-Response/SIM/Start and includes the pseudonym identity in AT_IDENTITY. Else, it responds with EAP-Response/SIM/Start and includes the permanent identity in AT_IDENTITY. 🦋
An EAP-SIM exchange can include several EAP/SIM/Start rounds. The server might send a second EAP-Request/SIM/Start if it couldn't recognize the identity the peer used in the previous AT_IDENTITY attribute. But there's a cap: at most, three EAP/SIM/Start rounds can be used, so the peer MUST NOT respond to more than three EAP-Request/SIM/Start messages within an EAP exchange. 🛑
The peer MUST also check that the sequence of EAP-Request/SIM/Start packets it receives follows the sequencing rules in this document. Basically, AT_ANY_ID_REQ can only be used in the first EAP-Request/SIM/Start. In other words, AT_ANY_ID_REQ MUST NOT be used in the second or third EAP-Request/SIM/Start. And AT_FULLAUTH_ID_REQ MUST NOT be used if the previous EAP-Request/SIM/Start included AT_PERMANENT_ID_REQ. 🧚 What the peer does when it gets an unexpected attribute or an unexpected message is specified in Section 6.3.1.
4.2.6. Attacks Against Identity Privacy 🕵️♀️
Okay, this one is serious bestie. The section above lays out two possible ways the peer can react when it gets AT_PERMANENT_ID_REQ. That's because a received AT_PERMANENT_ID_REQ doesn't necessarily come from the valid network. An active attacker can send an EAP-Request/SIM/Start packet with an AT_PERMANENT_ID_REQ attribute to the peer, just trying to figure out the true identity of the user 😭. So if the peer doesn't want to reveal its permanent identity, it sends the EAP-Response/SIM/Client-Error packet with the error code "unable to process packet", and the authentication exchange ends.
Basically, there are two different policies the peer can use for AT_PERMANENT_ID_REQ. A "conservative" peer assumes the network can keep pseudonyms robustly 🌸. So if a conservative peer has a pseudonym username, it responds with EAP-Response/SIM/Client-Error to the EAP packet with AT_PERMANENT_ID_REQ, because it trusts that the valid network can map the pseudonym identity back 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 win here 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 win for this policy is that it still works even if the valid network sometimes loses pseudonyms and can't map them to the permanent identity 💖.
4.2.7. Processing of AT_IDENTITY by the Server 🖥️
When the server gets an EAP-Response/SIM/Start message with the AT_IDENTITY (in response to the server's identity requesting attribute), the server MUST operate as follows. ✨
If the server used AT_PERMANENT_ID_REQ, and the AT_IDENTITY doesn't contain a valid permanent identity, then the server sends EAP-Request/SIM/Notification with AT_NOTIFICATION code "General failure" (16384), and the EAP exchange terminates 💀. If the server recognizes the permanent identity and is able to continue, it proceeds with full authentication by sending EAP-Request/SIM/Challenge.
If the server used AT_FULLAUTH_ID_REQ, and AT_IDENTITY contains a valid permanent identity, or a pseudonym identity the server can map to a valid permanent identity, then the server proceeds with full authentication by sending EAP-Request/SIM/Challenge. If AT_IDENTITY contains a pseudonym identity the server can't map to a valid permanent identity, or an identity the server can't recognize or classify, then the server sends EAP-Request/SIM/Start with AT_PERMANENT_ID_REQ. 🫶
If the server used AT_ANY_ID_REQ, and the AT_IDENTITY contains a valid permanent identity, or a pseudonym identity the server can map to a valid permanent identity, then the server proceeds with full authentication by sending EAP-Request/SIM/Challenge. 🌈
If the server used AT_ANY_ID_REQ, and 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/SIM/Re-authentication (Section 5). 🔥
If the server used AT_ANY_ID_REQ, and the peer sent an EAP-Response/SIM/Start with only AT_IDENTITY (indicating re-authentication), but the server can't map the identity to a permanent identity, then the server sends EAP-Request/SIM/Start with AT_FULLAUTH_ID_REQ. 🙈
If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains a valid fast re-authentication identity the server can map to a permanent identity, and the server doesn't want to use fast re-authentication, then the server sends EAP-Request/SIM/Start without any identity requesting attributes. 🍓
If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an identity the server recognizes as a pseudonym identity but can't map the pseudonym identity to a permanent identity, then the server sends EAP-Request/SIM/Start with AT_PERMANENT_ID_REQ. 🧃
If the server used AT_ANY_ID_REQ, and AT_IDENTITY contains an identity the server can't recognize or classify, then the server sends EAP-Request/SIM/Start with AT_FULLAUTH_ID_REQ. 💜
4.3. Message Sequence Examples (Informative) 📖
This section has non-normative message sequence examples, just to show how the peer identity can be communicated to the server. Think of it as the pictures before the chapter 🌷.
4.3.1. Full Authentication
This full authentication case is shown below in Figure 2. In this case, AT_IDENTITY contains either the permanent identity or a pseudonym identity. The same sequence is also used when the server uses AT_FULLAUTH_ID_REQ in EAP-Request/SIM/Start.
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |Figure 2: Requesting any identity, full authentication
If the peer uses its full authentication identity and AT_IDENTITY contains a valid permanent identity or a valid pseudonym identity the EAP server can map to the permanent identity, the full authentication sequence carries on as usual, with the EAP Server issuing the EAP-Request/SIM/Challenge message. 🎉
4.3.2. Fast Re-authentication
The case where the server uses AT_ANY_ID_REQ and the peer wants to do fast re-authentication is shown below in Figure 3. ⚡
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY containing a fast re-auth. identity) |
|------------------------------------------------------>|
| |Figure 3: Requesting any identity, fast re-authentication
On fast re-authentication, if AT_IDENTITY contains a valid fast re-authentication identity and the server agrees on using fast re-authentication, then the server runs the fast re-authentication sequence and issues the EAP-Request/SIM/Re-authentication packet, as specified in Section 5. 🦋
4.3.3. Fall Back to Full Authentication 🔁
Okay so Figure 4 shows the situation where the server doesn't recognize the fast re-auth identity the peer put in AT_IDENTITY, so it sends a second EAP-Request/SIM/Start. Main character plot twist 😭✨
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY containing a fast re-auth. identity) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server does not recognize |
| | The fast re-auth. |
| | Identity |
| +------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with a full-auth. identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |Figure 4: Fall back to full authentication
4.3.4. Requesting the Permanent Identity 1 🪪
Next up is Figure 5, which covers the case where the EAP server can't map the pseudonym in the EAP-Response/Identity packet to a valid permanent identity. Not the vibe 💀
Peer Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes a pseudonym) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server fails to map the |
| | Pseudonym to a permanent id. |
| +------------------------------+
| EAP-Request/SIM/Start |
| (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with permanent identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |Figure 5: Requesting the permanent identity
If the server does recognize the permanent identity, the authentication sequence carries on as usual, with the EAP Server sending the EAP-Request/SIM/Challenge message ✨
4.3.5. Requesting the Permanent Identity 2 🙃
Figure 6 is the case where the EAP server can't map the pseudonym in the AT_IDENTITY attribute to a valid permanent identity. This one takes an extra round of EAP-SIM Start, so buckle up 🎢
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
|EAP-Response/SIM/Start |
|(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| +-------------------------------+
| | Server fails to map the |
| | Pseudonym in AT_IDENTITY |
| | to a valid permanent identity |
| +-------------------------------+
| |
| EAP-Request/SIM/Start |
| (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with permanent identity, |
| AT_NONCE_MT, AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |Figure 6: Requesting a permanent identity (two EAP-SIM Start rounds)
4.3.6. Three EAP-SIM/Start Roundtrips 🎡
Okay, the worst case is three EAP/SIM/Start round trips before the server finally gets an identity it's happy with. Figure 7 shows the whole thing 🌈
Peer Authenticator
| |
| +------------------------------+
| | Server does not have a |
| | Subscriber identity available|
| | When starting EAP-SIM |
| +------------------------------+
| EAP-Request/SIM/Start |
| (Includes AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with fast re-auth. identity) |
|------------------------------------------------------>|
| |
| +------------------------------+
| | Server does not accept |
| | The fast re-auth. |
| | Identity |
| +------------------------------+
| EAP-Request/SIM/Start |
| (AT_FULLAUTH_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
: :
: :
: :
: :
|EAP-Response/SIM/Start |
|(AT_IDENTITY with a pseudonym identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |
| +-------------------------------+
| | Server fails to map the |
| | Pseudonym in AT_IDENTITY |
| | to a valid permanent identity |
| +-------------------------------+
| EAP-Request/SIM/Start |
| (AT_PERMANENT_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY with permanent identity, AT_NONCE_MT, |
| AT_SELECTED_VERSION) |
|------------------------------------------------------>|
| |Figure 7: Three EAP-SIM Start rounds
Once the last EAP-Response/SIM/Start message is sent, the full authentication sequence carries on as usual. If the EAP Server recognizes the permanent identity and is able to proceed, the server sends the EAP-Request/SIM/Challenge message 💖
5. Fast Re-Authentication ⚡
5.1. General ✨
okay so bestie, in some environments EAP authentication happens super often 🔄. Full EAP-SIM authentication uses the GSM SIM A3/A8 algorithms, which means it needs 2 or 3 fresh triplets from the Authentication Centre every single time 😩. So full auth isn't really built for doing it on repeat. That's why EAP-SIM has a cheaper fast re-authentication procedure that skips the SIM A3/A8 algorithms and doesn't need new triplets from the Authentication Centre 💖. It can also finish in fewer roundtrips than full auth, which is so iconic 🙌.
Fast re-auth is optional to implement for both the EAP-SIM server and peer 🎀. On any EAP authentication, either entity may also fall back on full authentication if it doesn't want to use fast re-auth 🫶.
Fast re-auth is based on the keys from the previous full authentication 🔑. The same K_aut and K_encr keys from full auth protect EAP-SIM packets and attributes, and the original Master Key from full auth is used to make a fresh Master Session Key, as specified in Section 7 ✨.
The fast re-auth exchange uses an unsigned 16-bit counter, carried in the AT_COUNTER attribute 🔢. The counter has three jobs:
- it can be used to limit the number of successive reauthentication exchanges without full authentication,
- it contributes to the keying material, and
- it protects the peer and the server from replays.
On full authentication, both the server and the peer set the counter to one 1️⃣. The counter value of at least one is used on the first fast re-auth. On later fast re-auths, the counter MUST be greater than on any of the previous re-authentications 📈. So on the second fast re-auth, the counter value is two or greater. AT_COUNTER 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-auth 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-auth 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 feeds into the new Master Session Key 🍓.
Both the peer and the server SHOULD have an upper limit on how many subsequent fast re-auths are allowed before full auth has to be performed 🚧. Because a 16-bit counter is used, the theoretical maximum number of re-auths is hit when the counter reaches FFFF hexadecimal 💀.
To do fast re-auth, the peer and the EAP server need to store the Master Key, the latest counter value, and the next fast re-auth identity 📝. K_aut and K_encr may either be stored or derived again from MK. The server may also need to store the permanent identity of the user.
5.2. Comparison to UMTS AKA 💅
Comparing this with UMTS AKA is super helpful when you're analyzing fast re-auth, because they're basically lookalikes 👯♀️. The counter corresponds to the UMTS AKA sequence number. NONCE_S corresponds to RAND. AT_MAC in EAP-Request/SIM/Re-authentication corresponds to AUTN, and the AT_MAC in EAP-Response/SIM/Re-authentication corresponds to RES. AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter corresponds to the usage of the Anonymity Key 🤌. Also, the key generation on fast re-auth, with regard to random or fresh material, is similar to UMTS AKA: the server generates the NONCE_S and counter values, and the peer only verifies that the counter value is fresh ✨.
It should also be noted that encrypting the AT_NONCE_S, AT_COUNTER, or AT_COUNTER_TOO_SMALL attributes is not important to the security of the fast re-auth exchange 🙈.
5.3. Fast Re-authentication Identity 🦋
Fast re-auth makes use of separate re-authentication user identities 🪪. Pseudonyms and the permanent identity are reserved for full authentication only. If a re-authentication identity is lost and the network doesn't recognize it, the EAP server can fall back on full auth 😬.
If the EAP server supports fast re-auth, it MAY include the skippable AT_NEXT_REAUTH_ID attribute in the encrypted data of EAP-Request/SIM/Challenge message (Section 9.3). This attribute holds a new fast re-auth identity for the next fast re-auth. It also works as a capability flag, indicating that the server supports fast re-auth and wants to keep using it within the current context 🚩. The peer MAY ignore this attribute, in which case it MUST use full authentication next time. If the peer wants to use re-auth, it uses this fast re-auth identity on the next authentication 🔁. Even if the peer has a fast re-auth identity, the peer MAY discard it and use a pseudonym or the permanent identity instead, in which case full authentication MUST be performed. If the EAP server does not include AT_NEXT_REAUTH_ID in the encrypted data of EAP-Request/SIM/Challenge or EAP-Request/SIM/Re-authentication, then the peer MUST discard its current fast re-auth state information and perform a full authentication next time 🧹.
In environments where a realm portion is needed in the peer identity, the fast re-auth identity received in AT_NEXT_REAUTH_ID MUST contain both a username portion and a realm portion, as per the NAI format 🌐. The EAP Server can choose an appropriate realm part so the AAA infrastructure routes subsequent fast re-auth requests to the same AAA server 🗺️. For example, the realm part MAY include a portion that is specific to the AAA server. Hence, it is sufficient to store the context required for fast re-auth in the AAA server that performed the full authentication 🧠.
The peer MAY use the fast re-auth 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-auth identity in the AT_IDENTITY attribute of the EAP-Response/SIM/Start packet 📦.
The peer MUST NOT modify the username portion of the fast re-auth identity, but the peer MAY modify the realm portion or replace it with another realm portion 🙅♀️. The peer might need to modify the realm in order to influence the AAA routing, for example, to make sure that the correct server is reached. It should be noted that sharing the same fast re-auth key among several servers may have security risks, so changing the realm portion of the NAI in order to change the EAP server is not desirable 🚨.
Even if the peer uses a fast re-auth identity, the server may want to fall back on full auth, for example because the server does not recognize the fast re-auth identity or does not want to use fast re-auth. In this case, the server starts the full authentication procedure by issuing an EAP-Request/SIM/Start packet. This packet always starts a full authentication sequence if it does not include the AT_ANY_ID_REQ attribute. If the server was not able to recover the peer's identity from the fast re-auth identity, the server includes either the AT_FULLAUTH_ID_REQ or the AT_PERMANENT_ID_REQ attribute in this EAP request 🏁.
5.4. Fast Re-authentication Procedure 🦋
Okay so here's the fast re-auth flow, and it's giving smooth 💅. In this example, the optional protected success indication is not used. Encrypted attributes are denoted with '*'. The peer sends its re-authentication identity inside the EAP-Response/Identity packet. Earlier we covered another way to share that identity with the server: the peer can use the AT_IDENTITY attribute in the EAP-Response/SIM/Start message instead. That version isn't in the figure below, and it only works when the server asks for the peer's identity by including the AT_ANY_ID_REQ attribute in the EAP-Request/SIM/Start packet 🎀
If the server recognizes the identity as a valid fast re-authentication identity, and it agrees to use fast re-authentication, it sends the EAP-Request/SIM/Re-authentication packet to the peer. This packet MUST include the encrypted AT_COUNTER attribute with a fresh counter value, the encrypted AT_NONCE_S attribute holding a random number the server picked, the AT_ENCR_DATA and AT_IV attributes used for encryption, and the AT_MAC attribute with a message authentication code over the packet. It MAY also include an encrypted AT_NEXT_REAUTH_ID attribute with the next fast re-authentication identity ✨
Fast re-authentication identities are one-time identities, so they're not reusable 🙈 If the peer doesn't get a new fast re-authentication identity, it MUST use either the permanent identity or a pseudonym identity on the next authentication to start full authentication. No cap, that's the rule 💀
The peer checks that AT_MAC is correct and that the counter value is fresh, meaning greater than any value it used before. The peer MAY save the next fast re-authentication identity from the encrypted AT_NEXT_REAUTH_ID for next time 🧚 If every check passes, the peer replies with the EAP-Response/SIM/Re-authentication packet, which includes the AT_COUNTER attribute with the same counter value and the AT_MAC attribute.
The server then verifies the AT_MAC attribute and checks that the counter value matches the one it used in the EAP-Request/SIM/Re-authentication packet. If those checks pass, the re-authentication has succeeded and the server sends the EAP-Success packet to the peer. Iconic behavior 👑
If protected success indications (Section 6.2) were used, the EAP-Success packet would be preceded by an EAP-SIM notification round 🌸
Peer Authenticator
| |
| EAP-Request/Identity |
|<------------------------------------------------------|
| |
| EAP-Response/Identity |
| (Includes a fast re-authentication identity) |
|------------------------------------------------------>|
| |
| +--------------------------------+
| | Server recognizes the identity |
| | and agrees to use fast |
| | re-authentication |
| +--------------------------------+
| |
: :
: :
: :
: :
| EAP-Request/SIM/Re-authentication |
| (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 fast re- | |
| authentication identity for next re-auth. | |
+-----------------------------------------------+ |
| |
| EAP-Response/SIM/Re-authentication |
| (AT_IV, AT_ENCR_DATA, *AT_COUNTER with same value, |
| AT_MAC) |
|------------------------------------------------------>|
| +--------------------------------+
| | Server verifies AT_MAC and |
| | the counter |
| +--------------------------------+
| |
| EAP-Success |
|<------------------------------------------------------|
| |Figure 8: Fast Re-authentication
5.5. Fast Re-authentication Procedure when Counter Is Too Small 🙅♀️
Sometimes the peer doesn't accept the counter value in the EAP-Request/SIM/Re-authentication packet. When that happens, it flags the counter sync problem by including the encrypted AT_COUNTER_TOO_SMALL attribute in the EAP-Response/SIM/Re-authentication packet. The server then replies with an EAP-Request/SIM/Start to kick off a normal full authentication procedure. Figure 9 shows the whole thing, with encrypted attributes denoted with '*' 🫶
Peer Authenticator
| EAP-Request/SIM/Start |
| (AT_ANY_ID_REQ, AT_VERSION_LIST) |
|<------------------------------------------------------|
| |
| EAP-Response/SIM/Start |
| (AT_IDENTITY) |
| (Includes a fast re-authentication identity) |
|------------------------------------------------------>|
| |
| EAP-Request/SIM/Re-authentication |
| (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/SIM/Re-authentication |
| (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/SIM/Start |
| (AT_VERSION_LIST) |
|<------------------------------------------------------|
+---------------------------------------------------------------+
| Normal full authentication follows. |
+---------------------------------------------------------------+
| |Figure 9: Fast Re-authentication, counter is not fresh
In the figure above, the first three messages look just like the basic fast re-auth case. When the peer notices the counter isn't fresh, it includes the AT_COUNTER_TOO_SMALL attribute in the EAP-Response/SIM/Re-authentication packet. That attribute carries no data. It's basically the peer asking the server to start full authentication 💖 In this case, the peer MUST ignore the contents of the server's AT_NEXT_REAUTH_ID attribute.
Heads up bestie: the peer MUST ignore the server's AT_NEXT_REAUTH_ID here, so don't go saving it 🙈
When the server gets AT_COUNTER_TOO_SMALL, it verifies AT_MAC and checks that AT_COUNTER holds the same counter value as in the EAP-Request/SIM/Re-authentication packet. If that doesn't line up, the server ends the exchange by sending the EAP-Request/SIM/Notification with the AT_NOTIFICATION code "General failure" (16384) 💀 If every check passes, the server sends a new EAP-Request/SIM/Start packet and the full authentication procedure runs as usual. Since the server already knows the subscriber identity, it MUST NOT include AT_ANY_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_PERMANENT_ID_REQ in the EAP-Request/SIM/Start ✨
It's worth noting that in this case, the peer identity is only sent in the AT_IDENTITY attribute at the very beginning of the whole EAP exchange. The fast re-authentication identity used in that AT_IDENTITY attribute gets used in key derivation (see Section 7) 🦋
6. EAP-SIM Notifications ✨
6.1. General 🎀
Okay so EAP-SIM does not prohibit the use of EAP Notifications as specified in [RFC3748] 💖 They're totally allowed! EAP Notifications can pop up at any time during the EAP-SIM exchange ✨ Heads up though: EAP-SIM does not protect EAP Notifications 💀 That's a whole vibe. EAP-SIM also has its own method-specific EAP-SIM notifications, and those are protected in some cases 🔐
The EAP server can use EAP-SIM 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. Bestie, this one is not optional 😤 When the EAP server sends an EAP-Request/SIM/Notification packet to the peer, the peer MUST process the notification packet 🧚 The peer MAY show a notification message to the user, and the peer MUST respond to the EAP server with an EAP-Response/SIM/Notification packet, even if the peer didn't recognize the notification code 🫶
An EAP-SIM full authentication exchange or a fast re-authentication exchange MUST NOT include more than one EAP-SIM notification round 🙅♀️
The notification code is a 16-bit number 🔢 The most significant bit is called the Success bit (S bit). The S bit tells you whether the notification implies failure. Code values with the S bit set to zero (code values 0...32767) are used in unsuccessful cases 😭 Getting a notification code from this range means the EAP exchange failed, so the peer can treat the notification as a failure indication. After receiving the EAP-Response/SIM/Notification for these codes, the server MUST send the EAP-Failure packet 💀
Receiving a notification code with the S bit set to one (values 32768...65536) does NOT imply failure ✨ The notification code "Success" (32768) has been reserved as a general notification code to indicate successful authentication 🎉
The second most significant bit of the notification code is called the Phase bit (P bit) 🌈 It tells you which phase of the EAP-SIM exchange the notification can be used in. If the P bit is set to zero, the notification can only be used after a successful EAP/SIM/Challenge round in full authentication, or after a successful EAP/SIM/Re-authentication round in re-authentication 🦋 A re-authentication round only counts as successful if the peer has successfully verified the AT_MAC and AT_COUNTER attributes, and the AT_COUNTER_TOO_SMALL attribute is NOT included in EAP-Response/SIM/Re-authentication 👑
If the P bit is set to one, the notification can only be used before the EAP/SIM/Challenge round in full authentication, or before the EAP/SIM/Re-authentication round in re-authentication 🍓 These notifications can only be used to indicate various failure cases. In other words, if the P bit is set to one, then the S bit MUST be set to zero 🙈
Section 9.8 and Section 9.9 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 responsibility of an EAP method 🤷♀️ They're included in EAP-SIM anyway, because there are currently no other ways to convey this information to the user in a localizable way, and the information is potentially useful for the user 💅 An EAP-SIM server implementation may decide never to send these EAP-SIM 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-SIM notification to indicate failure to the peer. In this case, the result indication is integrity and replay protected 🔐✨
By sending an EAP-Response/SIM/Challenge packet or an EAP-Response/SIM/Re-authentication packet (without AT_COUNTER_TOO_SMALL), the peer says it has successfully authenticated the server and that the peer's local policy accepts the EAP exchange 🫶 In other words, these packets are implicit success indications from the peer to the server. Iconic, right? 👑
EAP-SIM also supports optional protected success indications from the server to the peer 💜 If the EAP server wants to use protected success indications, it includes the AT_RESULT_IND attribute in the EAP-Request/SIM/Challenge or EAP-Request/SIM/Re-authentication packet 🎀 That attribute says the EAP server would like to use result indications in both successful and unsuccessful cases. If the peer also wants this, the peer includes AT_RESULT_IND in EAP-Response/SIM/Challenge or EAP-Response/SIM/Re-authentication 🧚 The peer MUST NOT include AT_RESULT_IND if it did not receive AT_RESULT_IND from the server 🙅♀️ If both the peer and the server used AT_RESULT_IND, then the EAP exchange isn't complete yet, but an EAP-SIM notification round will follow ⏳ The following EAP-SIM 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/SIM/Challenge or EAP-Request/SIM/Re-authentication 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 that the EAP exchange has completed successfully, the EAP exchange cannot fail when the server processes the EAP-SIM response to this notification 🎉 So the server MUST ignore the contents of the EAP-SIM response it receives from the EAP-Request/SIM/Notification with this code. Regardless of what's in the EAP-SIM response, the server MUST send EAP-Success as the next packet 🏁
6.3. Error Cases 🚨
This section specifies how the peer and the server behave in error cases 🔍 The subsections below require the EAP-SIM peer and server to send an error packet (EAP-Response/SIM/Client-Error from the peer, or EAP-Request/SIM/Notification from the server) in error cases. However, implementations SHOULD NOT rely upon the correct error reporting behavior of the peer, authenticator, or the server 😬 Error and other messages can get lost in transit, or a malicious participant might try to eat up resources by not sending 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 isn't received after a timeout period ⏰
6.3.1. Peer Operation 🧚
In general, if an EAP-SIM peer detects an error in a received EAP-SIM packet, the EAP-SIM implementation responds with the EAP-Response/SIM/Client-Error packet 📨 In response to the EAP-Response/SIM/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-SIM Subtype in the EAP request.
- A RAND challenge repeated in
AT_RAND. - invalid
AT_MAC. The peer SHOULD log this event. - invalid pad bytes in
AT_PADDING. - the peer does not want to process
AT_PERMANENT_ID_REQ.
Separate error codes have been defined for the following error cases in Section 10.19 🏷️
As specified in Section 4.1, when processing the AT_VERSION_LIST attribute (which lists the EAP-SIM versions supported by the server), if the attribute doesn't include a version that's implemented by the peer and allowed in the peer's security policy, then the peer MUST send the EAP-Response/SIM/Client-Error packet with the error code "unsupported version" 🙅♀️
If the number of RAND challenges is smaller than what the peer's local policy requires when processing the AT_RAND attribute, the peer MUST send the EAP-Response/SIM/Client-Error packet with the error code "insufficient number of challenges" 😭
If the peer believes that the RAND challenges included in AT_RAND are not fresh (e.g., because it can remember some previously used RANDs), the peer MUST send the EAP-Response/SIM/Client-Error packet with the error code "RANDs are not fresh" 🧠
6.3.2. Server Operation 🖥️
If an EAP-SIM server detects an error in a received EAP-SIM response, the server MUST issue the EAP-Request/SIM/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)). Which of these two codes it uses depends on the phase of the EAP-SIM exchange, see Section 6 💅 When the server issues an EAP-Request/SIM/Notification that implies failure, the error cases 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-SIM Subtype in the EAP Response
- invalid
AT_MAC. The server SHOULD log this event. - invalid
AT_COUNTER
6.3.3. EAP-Failure 🏁
The EAP-SIM server sends EAP-Failure in two cases:
- In response to an
EAP-Response/SIM/Client-Errorpacket the server has received from the peer, or - Following an EAP-SIM notification round, when the
AT_NOTIFICATIONcode implies failure.
The EAP-SIM server MUST NOT send EAP-Failure in cases other than these two 🙅♀️ However, it's worth knowing that even though the EAP-SIM server wouldn't send an EAP-Failure, an authorization decision made outside EAP-SIM (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) and case 2) above 🫶 The peer SHOULD silently discard the EAP-Failure packet in other cases 🤫
6.3.4. EAP-Success 🎀
Okay bestie, on full authentication the server can only send EAP-Success after the EAP/SIM/Challenge round is done. Not one second earlier 🙈. The peer MUST silently discard any EAP-Success packets that show up before it has successfully authenticated the server and sent the EAP-Response/SIM/Challenge packet. Ignore the early ones, no drama 💅.
If the peer did not ask for protected success indications with AT_RESULT_IND (we covered this in Section 6.2) on full authentication, the peer MUST accept EAP-Success after a successful EAP/SIM/Challenge round. Simple and sweet 🍓.
If the peer DID ask for protected success indications with AT_RESULT_IND (Section 6.2 again 🔁), the peer MUST NOT accept EAP-Success after a successful EAP/SIM/Challenge round. Instead, the peer MUST only accept EAP-Success after it gets an EAP-SIM Notification with the AT_NOTIFICATION code "Success" (32768). It's giving "wait for the official confirmation" energy 🫶.
On fast re-authentication, EAP-Success can only be sent after the EAP/SIM/Re-authentication round. Same rule as before: the peer MUST silently discard any EAP-Success packets that arrive before it has successfully authenticated the server and sent the EAP-Response/SIM/Re-authentication packet 🌸.
If the peer did not ask for protected success indications with AT_RESULT_IND (Section 6.2) on fast re-authentication, the peer MUST accept EAP-Success after a successful EAP/SIM/Re-authentication round.
If the peer DID ask for protected success indications with AT_RESULT_IND (Section 6.2) on fast re-authentication, the peer MUST NOT accept EAP-Success after a successful EAP/SIM/Re-authentication round. In this case, the peer MUST only accept EAP-Success after receiving an EAP-SIM Notification with the AT_NOTIFICATION code "Success" (32768) ✨.
And here's the plot twist 😭. If the peer gets an EAP-SIM notification (Section 6) that indicates failure, the peer MUST no longer accept the EAP-Success packet, even if the server authentication was successfully completed. Failure notice beats everything, periodt 💀.
7. Key Generation 🔑
This section is the keying-material glow-up. It explains exactly how the keys get made 💜.
On EAP-SIM full authentication, a Master Key (MK) is derived from the underlying GSM authentication values (Kc keys), the NONCE_MT, and some other relevant context, like this:
MK = SHA1(Identity|n*Kc| NONCE_MT| Version List| Selected Version)In that formula, the "|" character means concatenation, so you're just mashing the pieces together in order 🧩. "Identity" is the peer identity string with no 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 zero changes 🙅♀️. Now, quick reminder from Section 4.2.2.2: relying on EAP-Response/Identity for conveying the EAP-SIM peer identity is discouraged, and the server SHOULD use the EAP-SIM method-specific identity attributes. Be the attribute girl, not the packet girl 🎀.
The notation n*Kc means the n Kc values concatenated together. They get used in the same order as the RAND challenges in the AT_RAND attribute. NONCE_MT means just the nonce value, not the AT_NONCE_MT attribute itself 🙃. The Version List includes the 2-byte-supported version numbers from AT_VERSION_LIST, in the same order they appear in that attribute. The Selected Version is the 2-byte selected version from AT_SELECTED_VERSION. Network byte order is used, just like in the attributes 🌐. The hash function SHA-1 is specified in [SHA-1]. If several EAP/SIM/Start roundtrips happen in one EAP-SIM exchange, then only the NONCE_MT, Version List and Selected version from the last EAP/SIM/Start round get used. The earlier EAP/SIM/Start rounds get ignored, bye bye 👋.
The Master Key then goes into a Pseudo-Random number Function (PRF), which makes separate Transient EAP Keys (TEKs) for protecting EAP-SIM packets. It also makes a Master Session Key (MSK) for link layer security and an Extended Master Session Key (EMSK) for other purposes 🦋. On fast re-authentication, the same TEKs MUST be used for protecting EAP packets, but a new MSK and a new EMSK MUST be derived from the original MK and from new values exchanged in the fast re-authentication. Same TEKs, fresh MSK and EMSK, that's the move 💅.
EAP-SIM needs two TEKs for its own stuff. The authentication key K_aut goes with the AT_MAC attribute, and the encryption key K_encr goes with the AT_ENCR_DATA attribute. The same K_aut and K_encr keys get used in full authentication and in every fast re-authentication after it 🔐.
Key derivation is based on the random number generation specified in NIST Federal Information Processing Standards (FIPS) Publication 186-2 [PRF]. The pseudo-random number generator is specified in the change notice 1 (2001 October 5) of [PRF] (Algorithm 1). As 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 omitted. The function G used in the algorithm is constructed via the Secure Hash Standard, as specified in Appendix 3.3 of the standard. It should be noted that the function G is very similar to SHA-1, but the message padding is different. Please refer to [PRF] for full details. For convenience, the random number algorithm with the correct modification is cited in Appendix B 📚.
We're using 160-bit XKEY and XVAL values, 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 0️⃣.
On full authentication, the resulting 320-bit random numbers (x_0, x_1, ..., x_m-1) get concatenated and partitioned into suitable-sized chunks. Then they're 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' is calculated like this:
XKEY' = SHA1(Identity|counter|NONCE_S| MK)In that formula, Identity is the fast re-authentication identity, with no terminating null characters. It comes from the AT_IDENTITY attribute of the EAP-Response/SIM/Start packet. If EAP-Response/SIM/Start wasn't used on 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/SIM/Re-authentication packet, and it's used in network byte order. NONCE_S is the 16-byte NONCE_S value from the AT_NONCE_S attribute used in the EAP-Request/SIM/Re-authentication packet. MK is the Master Key derived on 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 two 64-byte chunks. Those become the new 64-byte Master Session Key and the new 64-byte Extended Master Session Key ✨. Note that because K_encr and K_aut are not derived on fast re-authentication, the Master Session Key and the Extended Master Session key come from the beginning of the key stream (x_0, x_1, ...). Start-of-the-stream girlies only 🌊.
The first 32 bytes of the MSK can be used as the Pairwise Master Key (PMK) for IEEE 802.11i 📶.
When the RADIUS attributes specified in [RFC2548] are used to transport keying material, 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.
Now for the why 🧠. When generating the initial Master Key, the hash function is used as a mixing function. It combines several session keys (Kc's) from the GSM authentication procedure and the random number NONCE_MT into one single session key. Why all this effort? The current GSM session keys are, at most, 64 bits, so you need two or more of them to make a longer key. Using a one-way function to combine the keys means that even if an attacker somehow learned one of the EAP-SIM session keys, it still wouldn't help them learn the original GSM Kc's 🛡️. Also, since NONCE_MT is part of the calculation, the peer can verify that the EAP-SIM packets it gets from the network are fresh and not replays (see Section 11 too) 🙌.
8. Message Format and Protocol Extensibility 🌈
8.1. Message Format 🎀
okay so first things first, EAP packets start with the Code, Identifier, Length, and Type fields, and then the EAP-method-specific Type-Data comes after 💅 all of this is from [RFC3748] btw. Code is 1 for EAP requests and 2 for EAP Responses. The way Length and Identifier get used in the EAP header is also specified in [RFC3748]. For EAP-SIM, the Type field is set to 18 🦋
In EAP-SIM, the Type-Data starts with an EAP-SIM header made of a 1-octet Subtype field and a 2-octet reserved field 🌸 The Subtype values used in EAP-SIM are defined in the IANA considerations section of the EAP-AKA specification [EAP-AKA]. Here's how the EAP header and the EAP-SIM header look:
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-SIM header is made of attributes, and those are encoded in Type, Length, Value format ✨ This is the generic attribute 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Attribute Type
This tells you the particular kind of attribute you're looking at 👀 The attribute type values are listed in the IANA considerations section of the EAP-AKA specification [EAP-AKA].
Length
This tells you how long the attribute is, counted in multiples of four bytes 📏 The biggest an attribute can get is 1024 bytes. The length includes the Attribute Type and Length bytes too.
Value
This is the actual data for the attribute 🍓 It's always included, and it can be two or more bytes long. The type and length fields decide the format and length of the value field.
Okay now the drama 😭 Attributes numbered 0 through 127 are called non-skippable attributes. When an EAP-SIM peer runs into a non-skippable attribute it doesn't recognize, the peer MUST send the EAP-Response/SIM/Client-Error packet, and that terminates the authentication exchange. If an EAP-SIM server runs into a non-skippable attribute it doesn't recognize, the server sends the EAP-Request/SIM/Notification packet with an AT_NOTIFICATION code. That implies general failure ("General failure after authentication" (0), or "General failure" (16384), depending on the phase of the exchange), and it also terminates the authentication exchange 💀
Attributes numbered 128 through 255 are called skippable attributes 🧚 When a skippable attribute shows up and isn't recognized, it gets ignored. The rest of the attributes and message data MUST still be processed. The Length field is what lets you skip over the attribute value when you're searching for the next attribute.
Unless otherwise specified, the order of the attributes in an EAP-SIM message is insignificant, and an EAP-SIM implementation should not assume a certain order to be used 🙈
Attributes can be encapsulated within other attributes. In other words, the value field of an attribute type can be specified to contain other attributes 🪆
8.2. Protocol Extensibility 🌈
okay so EAP-SIM can be extended by specifying new attribute types 💖 If skippable attributes are used, you can extend the protocol without breaking old implementations. Iconic behavior 👑
BUT (and this is a big but 🚨) any new attributes added to the EAP-Request/SIM/Start or EAP-Response/SIM/Start packets would not be integrity-protected. So these messages MUST NOT be extended in the current version of EAP-SIM 🙅♀️ If the list of supported EAP-SIM versions in the AT_VERSION_LIST does not include versions other than 1, then the server MUST NOT include attributes other than those specified in this document in the EAP-Request/SIM/Start message.
Now, future versions of this protocol might specify new attributes for EAP-Request/SIM/Start and still support version 1 of the protocol. In that case, the server might send an EAP-Request/SIM/Start message that includes new attributes and indicates support for protocol version 1 and other versions in the AT_VERSION_LIST attribute. If the peer selects version 1, then the peer MUST ignore any other attributes included in EAP-Request/SIM/Start, other than those specified in this document. And if the selected EAP-SIM version in peer's AT_SELECTED_VERSION is 1, then the peer MUST NOT include other attributes aside from those specified in this document in the EAP-Response/SIM/Start message 🫶
When you're specifying new attributes, it should be noted that EAP-SIM does not support message fragmentation 🥺 So the sizes of the new extensions MUST be limited so that the maximum transfer unit (MTU) of the underlying lower layer is not exceeded. According to [RFC3748], lower layers must provide an EAP MTU of 1020 bytes or greater, so any extensions to EAP-SIM SHOULD NOT exceed the EAP MTU of 1020 bytes ✨
Because EAP-SIM supports version negotiation, new versions of the protocol can also be specified by using a new version number 🦋
9. Messages 💌
This section is where the messages used in EAP-SIM get specified 📬 It covers when a message may be transmitted or accepted, which attributes are allowed in a message, which attributes are required in a message, and other message-specific details. The general message format is specified in Section 8.1.
9.1. EAP-Request/SIM/Start 🚀
In full authentication, the first SIM-specific EAP Request is EAP-Request/SIM/Start. The EAP/SIM/Start roundtrip is used for two purposes 🌸 In full authentication, this packet is used to request the peer to send the AT_NONCE_MT attribute to the server. On top of that, as specified in Section 4.2, the Start round trip may be used by the server for obtaining the peer identity. As discussed in Section 4.2, several Start rounds may be required to obtain a valid peer identity.
The server MUST always include the AT_VERSION_LIST attribute 📋
The server MAY include one of the following identity-requesting attributes: AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ. These three attributes are mutually exclusive, so the server MUST NOT include more than one of the attributes 🙅♀️
If the server has received a response from the peer, it MUST NOT issue a new EAP-Request/SIM/Start packet if it has previously issued an EAP-Request/SIM/Start message either without any identity requesting attributes or with the AT_PERMANENT_ID_REQ attribute 🧠
If the server has received a response from the peer, it MUST NOT issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ or AT_FULLAUTH_ID_REQ attributes if it has previously issued an EAP-Request/SIM/Start message with the AT_FULLAUTH_ID_REQ attribute 🔥
If the server has received a response from the peer, it MUST NOT issue a new EAP-Request/SIM/Start packet with the AT_ANY_ID_REQ attribute if the server has previously issued an EAP-Request/SIM/Start message with the AT_ANY_ID_REQ attribute 💅
This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA 🙈
9.2. EAP-Response/SIM/Start 💜
The peer sends EAP-Response/SIM/Start in response to a valid EAP-Request/SIM/Start from the server 🫶
If and only if the server's EAP-Request/SIM/Start includes one of the identity-requesting attributes, then the peer MUST include the AT_IDENTITY attribute. The usage of AT_IDENTITY is defined in Section 4.2 🪪
The AT_NONCE_MT attribute MUST NOT be included if the AT_IDENTITY with a fast re-authentication identity is present for fast re-authentication. AT_NONCE_MT MUST be included in all other cases (full authentication) 🌷
The AT_SELECTED_VERSION attribute MUST NOT be included if the AT_IDENTITY attribute with a fast re-authentication identity is present for fast re-authentication. In all other cases, AT_SELECTED_VERSION MUST be included (full authentication). This attribute is used in version negotiation, as specified in Section 4.1 🎀
This message MUST NOT include AT_MAC, AT_IV, or AT_ENCR_DATA 🙅♀️
9.3. EAP-Request/SIM/Challenge 🔐
The server sends the EAP-Request/SIM/Challenge after receiving a valid EAP-Response/SIM/Start that contains AT_NONCE_MT and AT_SELECTED_VERSION, and after successfully obtaining the subscriber identity 🔑
The AT_RAND attribute MUST be included 🎲
The AT_RESULT_IND attribute MAY be included. The usage of this attribute is discussed in Section 6.2 ✨
The AT_MAC attribute MUST be included. For EAP-Request/SIM/Challenge, the MAC code is calculated over the following data:
EAP packet| NONCE_MTThe EAP packet is represented as specified in Section 8.1. It is followed by the 16-byte NONCE_MT value from the peer's AT_NONCE_MT attribute 🧮
The EAP-Request/SIM/Challenge packet MAY include encrypted attributes for identity privacy and for communicating the next fast re-authentication identity. In this case, the AT_IV and AT_ENCR_DATA attributes are included (Section 10.12) 🥷
The plaintext of the AT_ENCR_DATA value field consists of nested attributes. The nested attributes MAY include AT_PADDING (as specified in Section 10.12). If the server supports identity privacy and wants to communicate a pseudonym to the peer for the next full authentication, then the nested encrypted attributes include the AT_NEXT_PSEUDONYM attribute. If the server supports re-authentication and wants to communicate a fast re-authentication identity to the peer, then the nested encrypted attributes include the AT_NEXT_REAUTH_ID attribute 💖
When processing this message, the peer MUST process AT_RAND before processing other attributes. Only if AT_RAND is verified to be valid, the peer derives keys and verifies AT_MAC. The operation in case an error occurs is specified in Section 6.3.1 🚨
9.4. EAP-Response/SIM/Challenge 💖
Okay bestie, the peer sends EAP-Response/SIM/Challenge as a reply to a valid EAP-Request/SIM/Challenge 🦋
Sending this packet is basically the peer saying "I've successfully authenticated the server, and the EAP exchange is good by my local policy" 💅 So if those things aren't true, the peer MUST NOT send EAP-Response/SIM/Challenge. Instead, the peer MUST send EAP-Response/SIM/Client-Error. Vibe check failed, not sending the good one 🙈
The AT_MAC attribute MUST be included. For EAP-Response/SIM/Challenge, the MAC code gets calculated over this data:
EAP packet| n*SRESThe EAP packet is represented as specified in Section 8.1. Right after those EAP packet bytes come the two or three SRES values, all concatenated together. That's the n*SRES part 🧚 The SRES values are used in the same order as their matching RAND challenges in the server's AT_RAND attribute.
The AT_RESULT_IND attribute MAY be included if it was included in EAP-Request/SIM/Challenge. Section 6.2 has all the tea on how that one works 🌸
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/SIM/Challenge messages that include these attributes, even if the server didn't implement these optional attributes. Be kind to the future you 🫶
9.5. EAP-Request/SIM/Re-authentication 🔁
The server sends EAP-Request/SIM/Re-authentication 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/SIM/Start. Main character energy for the fast lane 👑
AT_MAC MUST be included. No message-specific data gets included in the MAC calculation. See Section 10.14.
The AT_RESULT_IND attribute MAY be included. Section 6.2 covers how it's used 💜
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 AT_NEXT_REAUTH_ID and AT_PADDING 🎀
9.6. EAP-Response/SIM/Re-authentication 🌈
The client sends EAP-Response/SIM/Re-authentication in response to a valid EAP-Request/SIM/Re-authentication. Respect ✨
The AT_MAC attribute MUST be included. For EAP-Response/SIM/Re-authentication, the MAC code is calculated over this data:
EAP packet| NONCE_SThe EAP packet is represented as specified in Section 8.1. It's followed by the 16-byte NONCE_S value from the server's AT_NONCE_S attribute 🍓
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 if it was included in EAP-Request/SIM/Re-authentication. Section 6.2 has the details 🦋
Sending this packet without AT_COUNTER_TOO_SMALL indicates that the peer has successfully authenticated the server, and that the EAP exchange will be accepted by the peer's local policy. Hence, if these conditions are not met, then the peer MUST NOT send EAP-Response/SIM/Re-authentication. Instead, the peer MUST send EAP-Response/SIM/Client-Error 🙈
9.7. EAP-Response/SIM/Client-Error 😭
The peer sends EAP-Response/SIM/Client-Error in error cases, as specified in Section 6.3.1. It's the "something went wrong, here's the code" message 💀
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. No extra baggage here, bestie 🧳
9.8. EAP-Request/SIM/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 notification code in AT_NOTIFICATION is set to zero, and MUST NOT be included in cases when the P bit is set to one. The P bit is discussed in Section 6 🔥
No message-specific data is included in the MAC calculation. See Section 10.14.
If EAP-Request/SIM/Notification is used on a fast re-authentication exchange, and if the P bit in AT_NOTIFICATION is set to zero, then AT_COUNTER is used for replay protection. In this case, the AT_ENCR_DATA and AT_IV attributes MUST be included, and the encapsulated plaintext attributes MUST include the AT_COUNTER attribute. The counter value included in AT_COUNTER MUST be the same as in the EAP-Request/SIM/Re-authentication packet on the same fast re-authentication exchange. Counters matching, no drama 🧚
9.9. EAP-Response/SIM/Notification 🌸
The usage of this message is specified in Section 6. This packet is an acknowledgement of EAP-Request/SIM/Notification. Basically the "got it, bestie" reply ✨
The AT_MAC attribute MUST be included in cases when the P bit of the notification code in AT_NOTIFICATION of EAP-Request/SIM/Notification is set to zero, and MUST NOT be included in cases when the P bit is set to one. The P bit is discussed in Section 6 💜
No message-specific data is included in the MAC calculation, see Section 10.14.
If EAP-Request/SIM/Notification is used on a fast re-authentication exchange, and if the P bit in AT_NOTIFICATION is set to zero, then AT_COUNTER is used for replay protection. In this case, the AT_ENCR_DATA and AT_IV attributes MUST be included, and the encapsulated plaintext attributes MUST include the AT_COUNTER attribute. The counter value included in AT_COUNTER MUST be the same as in the EAP-Request/SIM/Re-authentication packet on the same fast re-authentication exchange 🫶
10. Attributes 🎀
This section specifies the format of message attributes. The attribute type numbers are specified in the IANA considerations section of the EAP-AKA specification [EAP-AKA]. The numbers live over there, so go check them out 🦋
10.1. Table of Attributes 📋
The following table is a guide to which attributes may be found in which kinds of messages, and in what quantity. Messages are denoted with numbers in parentheses as follows: (1) EAP-Request/SIM/Start, (2) EAP-Response/SIM/Start, (3) EAP-Request/SIM/Challenge, (4) EAP-Response/SIM/Challenge, (5) EAP-Request/SIM/Notification, (6) EAP-Response/SIM/Notification, (7) EAP-Response/SIM/Client-Error, (8) EAP-Request/SIM/Re-authentication, and (9) EAP-Response/SIM/Re-authentication. The column denoted with "Encr" indicates whether the attribute is a nested attribute that MUST be included within AT_ENCR_DATA, and the column denoted with "Skip" indicates whether the attribute is a skippable attribute 🌈
"0" indicates that the attribute MUST NOT be included in the message, "1" indicates that the attribute MUST be included in the message, "0-1" indicates that the attribute is sometimes included in the message, and "0*" indicates that the attribute is not included in the message in cases specified in this document, but MAY be included in future versions of the protocol 🍓
Attribute (1) (2) (3) (4) (5) (6) (7) (8) (9) Encr Skip
AT_VERSION_LIST 1 0 0 0 0 0 0 0 0 N N
AT_SELECTED_VERSION 0 0-1 0 0 0 0 0 0 0 N N
AT_NONCE_MT 0 0-1 0 0 0 0 0 0 0 N N
AT_PERMANENT_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N
AT_ANY_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N
AT_FULLAUTH_ID_REQ 0-1 0 0 0 0 0 0 0 0 N N
AT_IDENTITY 0 0-1 0 0 0 0 0 0 0 N N
AT_RAND 0 0 1 0 0 0 0 0 0 N N
AT_NEXT_PSEUDONYM 0 0 0-1 0 0 0 0 0 0 Y Y
AT_NEXT_REAUTH_ID 0 0 0-1 0 0 0 0 0-1 0 Y Y
AT_IV 0 0 0-1 0* 0-1 0-1 0 1 1 N Y
AT_ENCR_DATA 0 0 0-1 0* 0-1 0-1 0 1 1 N Y
AT_PADDING 0 0 0-1 0* 0-1 0-1 0 0-1 0-1 Y N
AT_RESULT_IND 0 0 0-1 0-1 0 0 0 0-1 0-1 N Y
AT_MAC 0 0 1 1 0-1 0-1 0 1 1 N N
AT_COUNTER 0 0 0 0 0-1 0-1 0 1 1 Y N
AT_COUNTER_TOO_SMALL 0 0 0 0 0 0 0 0 0-1 Y N
AT_NONCE_S 0 0 0 0 0 0 0 1 0 Y N
AT_NOTIFICATION 0 0 0 0 1 0 0 0 0 N N
AT_CLIENT_ERROR_CODE 0 0 0 0 0 0 1 0 0 N NIt should be noted that attributes AT_PERMANENT_ID_REQ, AT_ANY_ID_REQ, and AT_FULLAUTH_ID_REQ are mutually exclusive, so only one of them can be included at the same time. If one of the attributes AT_IV and AT_ENCR_DATA is included, then both of the attributes MUST be included ⚠️
10.2. AT_VERSION_LIST 💫
The format of the AT_VERSION_LIST 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_VERSION_L..| Length | Actual Version List Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Version 1 | Supported Version 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Version N | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This attribute is used in version negotiation, as specified in Section 4.1. It contains the version numbers supported by the EAP-SIM server. The server MUST only include versions that it implements and that are allowed in its security policy. The server SHOULD list the versions in order of preference, with the most preferred versions listed first. At least one version number MUST be included. The version number for the protocol described in this document is one (0001 hexadecimal) 🌟
The value field of this attribute begins with a 2-byte Actual Version List Length, which specifies the length of the Version List in bytes, not including the Actual Version List Length attribute length. This field is followed by the list of versions supported by the server, and each one has a length of 2 bytes. For example, if there is only one supported version, then the Actual Version List Length is 2. Because the length of the attribute must be a multiple of 4 bytes, the sender pads the value field with zero bytes when necessary 🧸
10.3. AT_SELECTED_VERSION 🦄
The format of the AT_SELECTED_VERSION 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_SELECTED...| Length = 1 | Selected Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+This attribute is used in version negotiation, as specified in Section 4.1. The value field of this attribute contains a two-byte version number, which indicates the EAP-SIM version that the peer wants to use ✨
10.4. AT_NONCE_MT ✨
okay so this is the layout for AT_NONCE_MT, 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_NONCE_MT | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NONCE_MT |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the value field of the NONCE_MT attribute is giving two reserved bytes 🦋, followed by a random number that the peer freshly generated (16 bytes long) for this EAP-SIM authentication exchange 💅. that random number is used as a seed value for the new keying material 🔑. the reserved bytes are set to zero upon sending and ignored upon reception 🌸.
the peer MUST NOT re-use the NONCE_MT value from a previous EAP-SIM authentication exchange 🙅♀️. if an EAP-SIM exchange includes several EAP/SIM/Start rounds, then the peer SHOULD use the same NONCE_MT value in all EAP-Response/SIM/Start packets 🍓. the peer SHOULD use a good source of randomness to generate NONCE_MT, and [RFC4086] has the deets on generating random numbers for security applications 🧚.
10.5. AT_PERMANENT_ID_REQ 🌈
here's how AT_PERMANENT_ID_REQ looks 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_PERM..._REQ | Length = 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the use of the AT_PERMANENT_ID_REQ is defined in Section 4.2 ✨. the value field contains only two reserved bytes, which are set to zero on sending and ignored on reception 🫶.
10.6. AT_ANY_ID_REQ 🦋
and now AT_ANY_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_ANY_ID_REQ | Length = 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the use of the AT_ANY_ID_REQ is defined in Section 4.2 👑. the value field contains only two reserved bytes, which are set to zero on sending and ignored on reception 🌷.
10.7. AT_FULLAUTH_ID_REQ 🍓
next up is AT_FULLAUTH_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_FULLAUTH_...| Length = 1 | Reserved |
+---------------+---------------+-------------------------------+the use of the AT_FULLAUTH_ID_REQ is defined in Section 4.2 🧚. the value field contains only two reserved bytes, which are set to zero on sending and ignored on reception 💖.
10.8. AT_IDENTITY 🌸
AT_IDENTITY is the one with the actual identity in it, so pay attention 👀
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 (optional) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the use of the AT_IDENTITY is defined in Section 4.2 ✨. the value field of this attribute begins with a 2-byte actual identity length, which tells you how long the identity is in bytes 📏. that field is followed by the subscriber identity of the indicated actual length 🪪. the identity is the permanent identity, a pseudonym identity, or a fast re-authentication identity 🦋. the identity format is specified in Section 4.2.1 🌈.
the same identity format is used in the AT_IDENTITY attribute and the EAP-Response/Identity packet, with one exception: the peer MUST NOT decorate the identity it includes in AT_IDENTITY 🙅♀️. the identity does not include any terminating null characters 🫶. because the length of the attribute must be a multiple of 4 bytes, the sender pads the identity with zero bytes when necessary 💜.
10.9. AT_RAND 💅
now the AT_RAND 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_RAND | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. n*RAND .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the value field of this attribute contains two reserved bytes followed by n GSM RANDs, each 16 bytes long 🌸. you can work out the value of n from the attribute length 🧮. the reserved bytes are set to zero upon sending and ignored upon reception 🫧.
the number of RAND challenges (n) MUST be two or three 🎯. the peer MUST verify that the number of RAND challenges is sufficient according to the peer's policy 🛡️. the server MUST use different RAND values, which means a RAND value can only be included once in AT_RAND 🚫. when processing the AT_RAND attribute, the peer MUST check that the RANDs are different 🔍.
the EAP server MUST obtain fresh RANDs for each EAP-SIM full authentication exchange 🌈. more specifically, the server MUST consider RANDs it included in AT_RAND to be consumed if the server receives an EAP-Response/SIM/Challenge packet with a valid AT_MAC, or an EAP-Response/SIM/Client-Error with the code "insufficient number of challenges" or "RANDs are not fresh" 💀. however, in other cases (if the server does not receive a response to its EAP-Request/SIM/Challenge packet, or if the server receives a response other than the cases listed above), the server does not need to consider the RANDs to be consumed, and the server MAY re-use the RANDs in the AT_RAND attribute of the next full authentication attempt 🦋.
10.10. AT_NEXT_PSEUDONYM 🧚
AT_NEXT_PSEUDONYM is the next-name-for-next-time attribute 🍓
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_NEXT_PSEU..| Length | Actual Pseudonym Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Next Pseudonym .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the value field of this attribute begins with the 2-byte actual pseudonym length, which specifies the length of the following pseudonym in bytes 📐. this field is followed by a pseudonym username that the peer can use in the next authentication 🎀. the username MUST NOT include any realm portion 🙅♀️. the username does not include any terminating null characters 🌸. because the length of the attribute must be a multiple of 4 bytes, the sender pads the pseudonym with zero bytes when necessary 🫶. the username encoding MUST follow the UTF-8 transformation format [RFC3629] 🌈. this attribute MUST always be encrypted by encapsulating it within the AT_ENCR_DATA attribute 🔐.
10.11. AT_NEXT_REAUTH_ID 👑
last one for this part: AT_NEXT_REAUTH_ID 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_NEXT_REAU..| Length | Actual Re-Auth Identity Length|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Next Fast Re-authentication Username .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the value field of this attribute begins with the 2-byte actual re-authentication identity length, which specifies the length of the following fast re-authentication identity in bytes 📏. this field is followed by a fast re-authentication identity that the peer can use in the next fast re-authentication, as described in Section 5 🦋. in environments where a realm portion is required, the fast re-authentication identity includes both a username portion and a realm name portion 🌍. the fast re-authentication identity does not include any terminating null characters 🫧. because the length of the attribute must be a multiple of 4 bytes, the sender pads the fast re-authentication identity with zero bytes when necessary 🌷. the identity encoding MUST follow the UTF-8 transformation format [RFC3629] ✨. this attribute MUST always be encrypted by encapsulating it within the AT_ENCR_DATA attribute 🔒.
10.12. AT_IV, AT_ENCR_DATA, and AT_PADDING ✨
okay so these three are a little squad 🫶 AT_IV and AT_ENCR_DATA are the attributes that carry encrypted stuff between the EAP-SIM peer and the server 🔐 the vibe is secret-keeping bestie energy 🤫
The value field of AT_IV has two reserved bytes, then a 16-byte initialization vector that AT_ENCR_DATA needs 🎀 the reserved bytes get set to zero when sending and get ignored on reception. Here's the big rule: AT_IV MUST be included if and only if AT_ENCR_DATA is included 💅 Section 6.3 tells you what happens if you ever run into a packet that breaks this rule 🙈
The sender picks the initialization vector at random 🎲 The sender MUST NOT re-use the initialization vector value from previous EAP-SIM packets, so no recycling IVs, periodt 💀 The sender SHOULD use a good source of randomness to make it 🌈 For more on generating random numbers for security stuff, check out [RFC4086] 📚 Here's what AT_IV looks like:
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 for AT_ENCR_DATA 🔥 its value field starts with two reserved bytes (zeroed on send, ignored on receive), followed by cipher text. That cipher text is made with the Advanced Encryption Standard (AES) [AES] using a 128-bit key in Cipher Block Chaining (CBC) mode, with the IV from AT_IV 🧚 Please see [CBC] for how CBC mode works. 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 derivation for the encryption key (K_encr) is in Section 7 🗝️ The plaintext is made of nested EAP-SIM attributes 🪆
Here's a catch: the encryption algorithm needs the plaintext length to be a multiple of 16 bytes 😭 So the sender might need to tack on AT_PADDING as the very last attribute inside AT_ENCR_DATA. AT_PADDING is NOT included if the other nested attributes already add up to a multiple of 16 bytes. And yes, the Length of the Padding attribute counts the Attribute Type and Attribute Length fields too 🙃 Its length is 4, 8, or 12 bytes, picked so the value field of AT_ENCR_DATA ends up a multiple of 16 bytes ✨ The actual pad bytes are set to zero (00 hexadecimal) when sending.
The recipient MUST verify that the pad bytes are set to zero. If that check fails on the peer, the peer MUST send the EAP-Response/SIM/Client-Error packet with the error code "unable to process packet" to end the authentication exchange 🚨 If the check fails on the server, the server sends the peer an EAP-Request/SIM/Notification packet with an AT_NOTIFICATION code that means failure, which ends the exchange too 💀
Here's the AT_PADDING 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_PADDING | Length | Padding... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+10.13. AT_RESULT_IND 🦋
Here's the AT_RESULT_IND 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_RESULT_...| Length = 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Its value field is two reserved bytes, zeroed on sending and ignored on reception 🌸 This attribute is always sent unencrypted, so it MUST NOT be wrapped inside AT_ENCR_DATA 🙅♀️
10.14. AT_MAC 🔑
AT_MAC is the attribute for EAP-SIM message authentication 🫡 Section 8 says which messages AT_MAC MUST be included in, so go check that 📝
Its value field is two reserved bytes followed by a keyed message authentication code (MAC) 🎀 The MAC gets calculated over the whole EAP packet, concatenated with optional message-specific data. The one twist is that the value field of the MAC attribute gets set to zero while the MAC is being calculated 🧮 The EAP packet includes the EAP header (starting at the Code field), the EAP-SIM header (starting at the Subtype field), and all the attributes, as Section 8.1 describes. The reserved bytes in AT_MAC are zeroed on sending and ignored on reception. What message-specific data goes into the MAC is spelled out for each EAP-SIM message in Section 9 ✨
Here's the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_MAC | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MAC |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The MAC algorithm is an HMAC-SHA1-128 [RFC2104] keyed hash value 🧁 You get it by taking the 20-byte HMAC-SHA1 value and truncating it to the first 16 bytes, so the MAC ends up 16 bytes long 📏 The authentication key (K_aut) used for the MAC is derived as described in Section 7 🗝️
When an AT_MAC attribute shows up in an EAP-SIM message, the recipient MUST process AT_MAC before looking at any other attributes. The one exception is EAP-Request/SIM/Challenge, which Section 9.3 covers 🙈 If the message authentication code is invalid, the recipient MUST ignore all the other attributes in the message and operate as Section 6.3 specifies 💔
10.15. AT_COUNTER 🔢
Here's the AT_COUNTER 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_COUNTER | Length = 1 | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The value field holds a 16-bit unsigned integer counter value, in network byte order 🧠 This attribute MUST always be encrypted by wrapping it inside AT_ENCR_DATA 🔐 no peeking, bestie 👀
10.16. AT_COUNTER_TOO_SMALL 🙈
Here's the 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_COUNTER...| Length = 1 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The value field is two reserved bytes, zeroed on sending and ignored on reception 🌼 This attribute MUST always be encrypted by putting it inside the AT_ENCR_DATA attribute 🫶
10.17. AT_NONCE_S 🌈
Here's the AT_NONCE_S 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_NONCE_S | Length = 5 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| NONCE_S |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The value field has two reserved bytes followed by a random number that the server freshly generates (16 bytes) for this EAP-SIM fast re-authentication 🎲 That random number does double duty: it's the challenge for the peer, and it's also the seed for the new keying material 🔑 The reserved bytes are zeroed on sending and ignored on reception. This attribute MUST always be encrypted by wrapping it inside AT_ENCR_DATA 🔐
The server MUST NOT re-use the NONCE_S value from any previous EAP-SIM 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, see [RFC4086] 📚
10.18. AT_NOTIFICATION ✨
okay so here's the layout for AT_NOTIFICATION 💅
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+bestie, the value field holds a two-byte notification code 🫶 The first and second bits (S and P) of that code get read the way Section 6 describes 🦋
The notification code values below are already reserved, and the descriptions show what each notification means. Peer implementations MAY use different wording when they show these notifications to the user 🌈 And "requested service" depends on where EAP-SIM is being used, so it can look different in different setups 🧚
0: General failure after authentication. It implies failure and gets used after a successful authentication 💀16384: General failure. It implies failure and gets used before authentication 😭32768: Success 🎉 The user has been successfully authenticated. It does NOT imply failure, and it gets used after a successful authentication. How this code gets used is covered in Section 6.2 ✨1026: The user has been temporarily denied access to the requested service. It implies failure and gets used after a successful authentication 🙈1031: The user hasn't subscribed to the requested service. It implies failure and gets used after a successful authentication 🍓
10.19. AT_CLIENT_ERROR_CODE 💖
the layout for AT_CLIENT_ERROR_CODE is 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_CLIENT_ERR..| Length = 1 | Client Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the value field is a two-byte client error code, and these error code values are reserved 🌸
0: "unable to process packet". A general error code 🫠1: "unsupported version". The peer doesn't support any of the versions listed inAT_VERSION_LIST🙅♀️2: "insufficient number of challenges". The peer's policy needs more triplets than the server put inAT_RAND🔥3: "RANDs are not fresh". The peer thinks the RAND challenges inAT_RANDweren't fresh 🥀
11. IANA Considerations 🦋
IANA has assigned EAP type number 18 for this protocol, and it's giving official 👑
EAP-SIM shares most of its protocol design with EAP-AKA [EAP-AKA], like attributes and message Subtypes. So EAP-SIM protocol numbers should be administered in the same IANA registry as EAP-AKA ✨ The starting values are listed in [EAP-AKA] for both protocols, which means this document doesn't need any new registries or parameter allocations 💜 Since EAP-SIM and EAP-AKA share one registry, the protocol number allocation policy for both is specified in [EAP-AKA] 🌈
12. Security Considerations 💀
okay this part is SERIOUS bestie 😭🔥 Read it all 🫶
The EAP specification [RFC3748] describes the security vulnerabilities of EAP. EAP doesn't come with its own security mechanisms 🙈 This section talks about the security properties EAP-SIM claims, plus its vulnerabilities and security recommendations 🔐
12.1. A3 and A8 Algorithms 🧚
the GSM A3 and A8 algorithms are used in EAP-SIM 💅 [GSM-03.20] specifies the general GSM authentication procedure and the external interface (inputs and outputs) of the A3 and A8 algorithms. How these functions work falls completely inside each individual operator's domain. So each operator specifies them, and they aren't fully standardised 🍓 The GSM-MILENAGE algorithm, which is publicly specified in [3GPP-TS-55.205], is an example algorithm set for A3 and A8 algorithms ✨
The security of the A3 and A8 algorithms is super important for EAP-SIM's security 🔥 Some A3/A8 algorithms have been compromised. Check [GSM-Cloning] for the discussion about COMP-128 version 1's security 💀 Several revised versions of the COMP-128 A3/A8 algorithm were devised after those weaknesses came out 🙈 The publicly specified GSM-MILENAGE algorithm is NOT vulnerable to any known attacks, so it's the one with main character energy 👑
12.2. Identity Protection 🦋
EAP-SIM includes optional identity privacy support that protects the subscriber identity against passive eavesdropping 🌸 This document only specifies a way to deliver pseudonyms from the server to the peer during an EAP-SIM exchange. So a peer that hasn't done any EAP-SIM exchanges usually doesn't have a pseudonym yet 😭 If the peer doesn't have a 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 can survive reboots 🫶 An active attacker that impersonates the network may use the AT_PERMANENT_ID_REQ attribute to try to learn the subscriber's permanent identity 🙈 However, as Section 4.2.2 explains, the terminal can refuse to send the cleartext permanent identity if it believes the network should be able to recognise the pseudonym 🛡️
If the peer and server can't guarantee the pseudonym will be maintained 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. If an external security mechanism is in use, the identity privacy features of EAP-SIM may not be useful. The security considerations of using an external security mechanism with EAP-SIM are beyond the scope of this document.
12.3. Mutual Authentication and Triplet Exposure 🔐
EAP-SIM provides mutual authentication 💖 The peer believes the network is authentic because the network can calculate a correct AT_MAC value in the EAP-Request/SIM/Challenge packet ✨ To calculate AT_MAC, it's enough to know the RAND and Kc values from the GSM triplets (RAND, SRES, Kc) used in the authentication 🧠
Here's the tea 🍵 The network picks the RAND challenges and the triplets. So an attacker that knows n (2 or 3) GSM triplets for the subscriber can impersonate a valid network to the peer 😱 (Some peers MAY employ an implementation-specific counter-measure against impersonating a valid network by re-using a previously used RAND; see below.) In other words, EAP-SIM's security depends on keeping Kc keys secret, since they're considered secret intermediate results in the EAP-SIM cryptographic calculations 🔒
Given physical access to the SIM card, it's easy to get any number of GSM triplets 💀
Another way to get triplets is to attack the peer platform with a virus or other malicious software 🦠 The peer SHOULD be protected against triplet querying attacks by malicious software 🛡️ Be careful not to expose Kc keys to attackers when they're stored or handled by the peer, or sent between the peer's subsystems 🫠 Take steps to limit how these values are transported, stored, and handled outside a protected environment inside the peer ✨ Virus protection on the peer and the security capabilities of the peer's operating system are outside the scope of this document 🙃
The EAP-SIM server typically gets triplets from the Home Location Register (HLR) 🏠 An attacker might try to get triplets by attacking the network between the EAP-SIM server and the HLR 👀 Be careful not to expose Kc keys to attackers when they're stored or handled by the EAP-SIM server, or sent between the EAP server and the HLR 🔐 Take steps to limit how these values are transported, stored, and handled outside a protected environment 🌸 The protection of communications between the EAP-SIM server and the HLR is outside the scope of this document 💅
If the same SIM credentials are also used for GSM traffic, the triplets could be revealed in the GSM network. See Section 12.8 🚨
In GSM, the network is allowed to re-use the RAND challenge in consecutive authentication exchanges. This is NOT allowed in EAP-SIM 🙅♀️ The EAP-SIM server is mandated to use fresh triplets (RAND challenges) in consecutive authentication exchanges, as Section 3 specifies ✨ EAP-SIM doesn't mandate any way for the peer to check whether the RANDs are fresh, so the scheme's security leans on the secrecy of the triplets 🫶 However, the peer MAY employ implementation-specific mechanisms to remember some previously used RANDs, and the peer MAY check the freshness of the server's RANDs 🧠 What happens when the peer detects that the RANDs aren't fresh is specified in Section 6.3.1 🔍
Preventing authentication vector re-use was part of the design of the UMTS Authentication and Key Agreement (AKA), which EAP-AKA [EAP-AKA] uses 💜 If EAP-SIM's triplet re-use properties aren't considered sufficient, it's advised to use EAP-AKA 🌈
Note that EAP-SIM mutual authentication happens with the EAP server 🧚 In general, EAP methods don't authenticate the identity or services of the EAP authenticator (if it's distinct from the EAP server) unless they have the so-called channel bindings property. The vulnerabilities related to this have been discussed in [RFC3748], [EAP-Keying], and [Service-Identity] 📚
EAP-SIM does NOT have the channel bindings property, so it only authenticates the EAP server 😭 However, ongoing work such as [Service-Identity] may add that support as an extension to popular EAP methods like EAP-TLS, EAP-SIM, or EAP-AKA ✨
12.4. Flooding the Authentication Centre 💥
The EAP-SIM server typically gets authentication vectors from the Authentication Centre (AuC) 🏢 EAP-SIM introduces a new usage for the AuC 🆕 The protocols between the EAP-SIM server and the AuC are out of scope for this document 🙃 It should be noted, though, that a malicious EAP-SIM peer may send lots of protocol requests to mount a denial of service attack 🚨 The EAP-SIM server implementation SHOULD take this into account, and SHOULD take steps to limit the traffic it generates towards the AuC 🛡️ That way, the attacker can't flood the AuC or stretch the denial of service attack from EAP-SIM to other AuC users 🫶
12.5. Key Derivation 🔑✨
okay bestie, EAP-SIM does do key derivation 💅 and the whole key hierarchy is laid out in Section 7 🗂️. EAP-SIM mixes several GSM triplets together to cook up stronger keying material and stronger AT_MAC values 🔥. But how strong the keys actually end up depends on a bunch of operator-specific stuff, like the authentication algorithms, how strong the Ki key is, and how good the RAND challenges are 🧐. Lowkey wild: some SIM cards generate Kc keys with 10 bits set to zero 💀. Restrictions like that can stop the concatenation trick from making strong session keys, so it's not automatic 🙈.
Also, since Ki is 128 bits, the final strength of any derived secret key material is never more than 128 bits 🫶. That's the ceiling, no cap.
Heads up for the policy people 📣: letting n=2 be used might compromise a future policy that requires three triplets, because attackers could exploit the messages exchanged while the weaker policy is active 😬.
Now the good news 🎀. There's no known way to get complete GSM triplets by attacking EAP-SIM 🙌. A passive eavesdropper can learn n*RAND and AT_MAC and might be able to link that info to the subscriber identity 👀. An active attacker who pretends to be a GSM subscriber can easily grab n*RAND and AT_MAC values from the EAP server for any given subscriber identity 😭. Still, working out Kc and SRES from AT_MAC would mean reversing the keyed message authentication code function HMAC-SHA1-128, which is not it 🛡️.
Since EAP-SIM never exposes any values calculated from an individual GSM Kc key 🌸, you can't brute force just one of the Kc keys 🙅♀️. So when you think about brute forcing the values EAP-SIM does expose, the effective length of EAP-SIM session keys isn't hurt by the fact that they're combined from several shorter keys. In other words, the effective 128 bits can still be achieved 💖. For more on this, see Section 12.8 🦋.
12.6. Cryptographic Separation of Keys and Session Independence 🧚
The EAP Transient Keys that protect EAP-SIM packets (K_encr, K_aut), the Master Session Key, and the Extended Master Session Key are cryptographically separate in EAP-SIM 💜. An attacker can't derive any non-trivial info about any of these keys from the others 🙅♀️. And an attacker also can't calculate the pre-shared secret (Ki) from the GSM Kc keys, from EAP-SIM K_encr, from EAP-SIM K_aut, from the Master Session Key, or from the Extended Master Session Key 🔐.
Every EAP-SIM exchange makes fresh keying material 🌈, and the keying material exported from the method across separate EAP-SIM exchanges is cryptographically separate ✨. The EAP-SIM peer adds to the keying material with the NONCE_MT parameter, which must be picked freshly for each full authentication exchange 🎀. The EAP server is mandated to pick the RAND challenges freshly for each full authentication exchange 👑. Here's the slay part 💅: if either the server or the peer picks its random value (NONCE_MT or RAND challenges) freshly, even when the other one re-used its value from a previous exchange, then the EAP Transient Keys, the Master Session Key, and the Extended Master Session Key will all be different and cryptographically separate from the matching values from the previous full authentication exchange 🙌.
On fast re-authentication 🏃♀️, freshness of the Master Session Key and the Extended Master Session Key comes from a counter (AT_COUNTER) 🔢. The same EAP Transient Keys (K_encr, K_aut) used in the full authentication exchange also protect the EAP negotiation 🔁. But replay and integrity protection across all the fast re-authentication exchanges that use the same EAP Transient Keys is handled by AT_COUNTER 🛡️.
[RFC3748] defines session independence as the "demonstration that passive attacks (such as capture of the EAP conversation) or active attacks (including compromise of the MSK or EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs". Since the MSKs and EMSKs are separate between EAP exchanges, EAP-SIM backs up this security claim 💪.
Now a tea moment ☕: [Patel-2003] predates [RFC3748] and uses a slightly different meaning for session independence 🤔. Also, the EAP-SIM protocol doesn't let the peer make sure different Kc key values get used in different exchanges 😬. Only the server can make sure fresh RANDs, and therefore fresh Kc keys, get used 🫤.
So the peer can't guarantee that EAP-SIM sessions are independent with regard to the internal Kc values 🙈. That said, in EAP-SIM the Kc keys count as secret intermediate results that never get exported outside the method 🔒. For more info about RAND re-use, see Section 12.3 📖.
12.7. Dictionary Attacks 🙅♀️
Because EAP-SIM isn't a password protocol, it's not vulnerable to dictionary attacks 🎉. (The pre-shared symmetric secret stored on the SIM card isn't a passphrase, and it isn't derived from a passphrase either 💜.)
12.8. Credentials Re-use 📱
EAP-SIM can't stop attacks over the GSM or GPRS radio networks 😭. If the same SIM credentials are also used in GSM or GPRS, attacks over the cellular interface are possible 📡.
A passive attacker can eavesdrop on GSM or GPRS traffic and collect RAND, SRES pairs 👀. They can then brute force or use other cryptanalysis techniques to get the 64-bit Kc keys used to encrypt GSM or GPRS data 🔓. That makes it possible to attack each 64-bit key separately 💀.
An active attacker can run a "rogue GSM/GPRS base station attack" 📶, replaying previously seen RAND challenges to get SRES values 🎭. They can then brute force the Kc keys 💻. If that works, the attacker can impersonate a valid network or decrypt previously seen traffic 😱, because EAP-SIM doesn't provide perfect forward secrecy (PFS) 🫠.
Also, GSM encryption algorithms have several weaknesses, so the effective key strength of the Kc keys is way less than the expected 64 bits 📉. It's no more than 40 bits if the A5/1 GSM encryption algorithm is used 😵. As documented in [Barkan-2003], an active attacker can force the peer to use the weaker A5/2 algorithm, which can be broken in less than a second ⚡.
Because the A5 encryption algorithm isn't used in EAP-SIM, and because EAP-SIM doesn't expose any values calculated from individual Kc keys, these attacks aren't possible if the SIM credentials used in EAP-SIM aren't shared in GSM/GPRS 🙌. Worth noting, bestie 🫶.
At the time this document was written, the 3rd Generation Partnership Project (3GPP) had started working on fixes for these A5 vulnerabilities 🛠️. One solution proposal discussed in 3GPP is integrity-protected A5 version negotiation 🔏, which would require the base station to prove it knows the Kc key before the terminal sends any values calculated from Kc to the network 🤝. Another proposal is so-called special RANDs 🎀, where some bits of the RAND challenge would be used for cryptographic separation by indicating the allowed use of the triplet, like the allowed A5 algorithm in GSM or the fact that the triplet is meant for EAP-SIM 🦋. This is still a work in progress 🚧, and the mechanisms haven't been selected yet 🤷♀️.
12.9. Integrity and Replay Protection, and Confidentiality 🔐
The AT_MAC, AT_IV, AT_ENCR_DATA, and AT_COUNTER attributes provide integrity, replay, and confidentiality protection for EAP-SIM requests and responses 💅. Integrity protection with AT_MAC covers the EAP header too 🧾. These attributes can't be used during the EAP/SIM/Start roundtrip 🙅♀️. But the protocol values (user identity string, NONCE_MT, and version negotiation parameters) are (implicitly) protected by later EAP-SIM messages, since they get included in key derivation 🫶.
Integrity protection (AT_MAC) is based on a keyed message authentication code 🔑. Confidentiality (AT_ENCR_DATA and AT_IV) is based on a block cipher 🧱.
Confidentiality protection only covers some of the protocol fields 🎯. The table of attributes in Section 10.1 summarizes which fields are confidentiality-protected 📋. Heads up 📣: the error and notification code attributes AT_CLIENT_ERROR_CODE and AT_NOTIFICATION are not confidential, they're sent in the clear 😬.
On full authentication, replay protection of the EAP exchange comes from the RAND values of the underlying GSM authentication scheme and the use of the NONCE_MT value 🎀. Protection against replays of EAP-SIM messages also relies on two things 🛡️: messages that can include AT_MAC can only be sent once with a certain EAP-SIM Subtype, and a different K_aut key gets used to calculate AT_MAC in each full authentication exchange 🔄.
On fast re-authentication, a counter in AT_COUNTER and a server random nonce provide replay protection 🔢. The AT_COUNTER attribute also goes into EAP-SIM notifications if it's used after a successful authentication, so replay protection holds between re-authentication exchanges 🌸.
EAP-SIM isn't a tunneling method 🚫, so EAP-Request/Notification, EAP-Response/Notification, EAP-Success, and EAP-Failure packets aren't confidential, integrity-protected, or replay-protected in EAP-SIM 😳. On physically insecure networks, this could let an attacker send fake notifications to the peer and launch denial of service attacks by spoofing these packets 💀. As discussed in Section 6.3, the peer only accepts EAP-Success after it successfully authenticates the server ✅. So an attacker can't make the peer believe successful mutual authentication happened until the peer successfully authenticates the server, or until after the peer fails to authenticate the server 🙅♀️.
The security considerations of EAP-SIM result indications are covered in Section 12.11 📝.
An eavesdropper will see the EAP-Request/Notification, EAP-Response/Notification, EAP-Success, and EAP-Failure packets sent in the clear 👀. So with EAP-SIM, confidential information MUST NOT be transmitted in EAP Notification packets 🚨. Non-negotiable, bestie 💜.
12.10. Negotiation Attacks 🥊
EAP-SIM doesn't protect the EAP-Response/Nak packet 😬. Because EAP-SIM doesn't protect the EAP method negotiation, EAP method downgrading attacks may be possible 📉, especially if the user uses the same identity with EAP-SIM and other EAP methods 🆔.
EAP-SIM does include a version negotiation procedure 🔢. In EAP-SIM, the keying material derivation includes the version list and the selected version, which makes sure the protocol can't be downgraded and that the peer and server use the same version of EAP-SIM 🔒✨.
EAP-SIM does not support ciphersuite negotiation 🙅♀️.
12.11. Protected Result Indications
okay so EAP-SIM has optional protected success indications and acknowledged failure indications 🎀 If a failure happens after a successful authentication, the EAP-SIM failure indication is integrity- and replay-protected 🔒
even if an EAP-Failure packet gets lost over an unreliable medium, the EAP-SIM failure indications help the peer and the EAP server still know what the other side decided 🫶 if protected success indications are used, then losing a Success packet is handled too, thanks to the acknowledged, integrity- and replay-protected EAP-SIM success indication 💖 but if the optional success indications aren't used, the peer might think the server approved it when it actually failed 😭 access won't be granted in that case, so protected result indications aren't really needed unless the client can't tell it doesn't have access for a long time 🙈
12.12. Man-in-the-Middle Attacks
so to dodge man-in-the-middle attacks and session hijacking 🕵️♀️, user data SHOULD be integrity-protected on physically insecure networks 🔐 the EAP-SIM Master Session Key, or keys derived from it, MAY be used as the integrity protection keys 🗝️ or, if an external security mechanism like PEAP is in use, the link integrity protection keys MAY be derived by that external mechanism 💅
there are man-in-the-middle attacks tied to using any EAP method inside a tunneled protocol 💀 for example, an early version of PEAP [PEAP-02] was vulnerable to this 😬 this specification doesn't deal with these attacks 🙅♀️ if EAP-SIM gets used with a tunneling protocol, there should be cryptographic binding between the protocol and EAP-SIM, so rogue authenticators can't set up one-way authenticated tunnels 🚫 newer versions of PEAP do include that kind of binding, for example ✨ the EAP-SIM Master Session Key MAY be used to provide the cryptographic binding 🔑 however, how the binding actually works depends on the tunneling protocol, and that's beyond the scope of this document 🦋
12.13. Generating Random Numbers
an EAP-SIM implementation SHOULD use a good source of randomness to generate the random numbers the protocol needs 🎲 for more on making random numbers for security stuff, check out [RFC4086] 🌸
13. Security Claims
this section lists the security claims that [RFC3748] requires 📋✨
Auth. mechanism: EAP-SIM is based on the GSM SIM mechanism, which is a challenge/response authentication and key agreement mechanism built on a symmetric 128-bit pre-shared secret 🔐 EAP-SIM also uses a peer challenge to get mutual authentication 🤝Ciphersuite negotiation: NoMutual authentication: Yes (Section 12.3) 💜Integrity protection: Yes (Section 12.9)Replay protection: Yes (Section 12.9)Confidentiality: Yes, except method-specific success and failure indications (Section 12.2, Section 12.9) 👀Key derivation: YesKey strength: EAP-SIM supports key derivation with 128-bit effective key strength (Section 12.5) 💪 BUT, as Section 11 talks about, if the same credentials are used in GSM/GPRS and in EAP-SIM, the key strength can drop a lot, basically down to GSM's level, because of attacks on GSM/GPRS 😱 for example, an active attack using a fake GSM/GPRS base station drops the effective key strength to almost zero 💀Description of key hierarchy: Please see Section 7. 🗂️Dictionary attack protection: N/A (Section 12.7)Fast reconnect: Yes ⚡Cryptographic binding: N/ASession independence: Yes (Section 12.6)Fragmentation: NoChannel binding: NoIndication of vulnerabilities: Vulnerabilities are discussed in Section 12. 🚨
14. Acknowledgements and Contributions 🫶
14.1. Contributors
in addition to the editors, Nora Dabbous, Jose Puthenkulam, and Prasanna Satarasinghe were significant contributors to this document 👑
Pasi Eronen and Jukka-Pekka Honkanen contributed Appendix A 🧚
14.2. Acknowledgements
the people below contributed so many original ideas and concepts to this protocol 💖 Juha Ala-Laurila, N. Asokan, Jan-Erik Ekberg, Patrik Flykt, Jukka-Pekka Honkanen, Antti Kuikka, Jukka Latva, Lassi Lehtinen, Jyri Rinnemaa, Timo Takamaki, and Raimo Vuonnala 🙌
N. Asokan, Pasi Eronen, and Jukka-Pekka Honkanen helped in innumerable ways while the protocol was being developed 🥹
Valtteri Niemi and Kaisa Nyberg contributed heavily to the design of the key derivation and the fast re-authentication procedure, and they also shared their cryptographic expertise in tons of discussions about this protocol 🧠✨
Simon Blake-Wilson gave very helpful comments on key derivation and version negotiation 💅
thanks to Greg Rose for his very valuable comments on an early version of this specification [S3-020125], and for reviewing version 12 and giving super useful feedback 🌈
thanks to Bernard Aboba, Vladimir Alperovich, Florent Bersani, Jacques Caron, Gopal Dommety, Augustin Farrugia, Mark Grayson, Max de Groot, Prakash Iyer, Nishi Kant, Victor Lortz, Jouni Malinen, Sarvar Patel, Tom Porcher, Michael Richardson, Stefan Schroeder, Uma Shankar, Jesse Walker, and Thomas Wieland for their contributions and critiques 🍓 special shoutout to Max for suggesting improvements to the MAC calculation 🔥
thanks to Glen Zorn for reviewing this document and giving very useful comments on the protocol 💜
thanks to Sarvar Patel for his review of the protocol [Patel-2003] 🦋
thanks to Bernard Aboba for reviewing this document for RFC 3748 compliance ✅
the identity privacy support is based on the identity privacy support of [EAP-SRP] 🕶️ and the attribute format is based on the extension format of Mobile IPv4 [RFC3344] 🌸
this protocol was partly developed alongside EAP-AKA [EAP-AKA], so this specification picks up lots of ideas from Jari Arkko 🫶
14.2.1. Contributors' Addresses
Nora Dabbous
Gemplus
34 rue Guynemer
92447 Issy les Moulineaux
France
Phone: +33 1 4648 2000
EMail: nora.dabbous@gemplus.com
Jose Puthenkulam
Intel Corporation
2111 NE 25th Avenue, JF2-58
Hillsboro, OR 97124
USA
Phone: +1 503 264 6121
EMail: jose.p.puthenkulam@intel.com
Prasanna Satarasinghe
Transat Technologies
180 State Street, Suite 240
Southlake, TX 76092
USA
Phone: + 1 817 4814412
EMail: prasannas@transat-tech.com15. References 📚
15.1. Normative References
- [GSM-03.20] European Telecommunications Standards Institute, "GSM Technical Specification GSM 03.20 (ETS 300 534): "Digital cellular telecommunication system (Phase 2); Security related network functions"", August 1997.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [GSM-03.03] European Telecommunications Standards Institute, "GSM Technical Specification GSM 03.03 (ETS 300 523): "Digital cellular telecommunication system (Phase 2); Numbering, addressing and identification"", April 1997.
- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
- [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
- [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. Available on-line at: http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
- [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
- [EAP-AKA] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, January 2006.
15.2. Informative References 📚✨
okay bestie, here are the informative refs 🦋 they're the extra reading that backs up the spec, and they're not strictly required to implement it 💅
- [3GPP-TS-23.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.
- [3GPP-TS-55.205] 3rd Generation Partnership Project, "3GPP Technical Specification 3GPP TS 55.205 V 6.0.0: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Specification of the GSM-MILENAGE Algorithms: An example algorithm set for the GSM Authentication and Key Generation functions A3 and A8 (Release 6)"", December 2002.
- [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.
- [EAP-Keying] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. Levkowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress, October 2005.
- [Service-Identity] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", Work in Progress, October 2004.
- [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
- [S3-020125] Qualcomm, "Comments on draft EAP/SIM, 3rd Generation Partnership Project document 3GPP TSG SA WG3 Security S3#22, S3-020125", February 2002.
- [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002.
- [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes ", RFC 2548, March 1999.
- [EAP-SRP] Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 Authentication Protocol", Work in Progress, July 2001.
- [GSM-Cloning] Wagner, D., "GSM Cloning". Web page about COMP-128 version 1 vulnerabilities, available at
http://www.isaac.cs.berkeley.edu/isaac/gsm.html - [Barkan-2003] Barkan, E., Biham, E., and N. Keller, "Instant Ciphertext-Only Cryptanalysis of GSM Encrypted Communications". available on-line at
http://cryptome.org/gsm-crack-bbk.pdf - [Patel-2003] Patel, S., "Analysis of EAP-SIM Session Key Agreement". Posted to the EAP mailing list 29 May,2003.
http://mail.frascone.com/pipermail/public/eap/2003-May/001267.html
Appendix A. Test Vectors 🧪💜
Test vectors for the NIST FIPS 186-2 pseudo-random number generator [PRF] live at this URL: http://csrc.nist.gov/encryption/dss/Examples-1024bit.pdf 🌸
Next up, the examples show what EAP-SIM packets look like on full authentication and on fast re-authentication. So pretty 🎀
A.1. EAP-Request/Identity
The first packet is a plain Identity Request:
01 ; Code: Request
00 ; Identifier: 0
00 05 ; Length: 5 octets
01 ; Type: IdentityA.2. EAP-Response/Identity
The client's identity is "1244070100000001@eapsim.foo", so it responds with this packet 🫶
02 ; Code: Response
00 ; Identifier: 0
00 20 ; Length: 32 octets
01 ; Type: Identity
31 32 34 34 ; "1244070100000001@eapsim.foo"
30 37 30 31
30 30 30 30
30 30 30 31
40 65 61 70
73 69 6d 2e
66 6f 6fA.3. EAP-Request/SIM/Start
The server's first packet looks like this ✨
01 ; Code: Request
01 ; Identifier: 1
00 10 ; Length: 16 octets
12 ; Type: EAP-SIM
0a ; EAP-SIM subtype: Start
00 00 ; (reserved)
0f ; Attribute type: AT_VERSION_LIST
02 ; Attribute length: 8 octets (2*4)
00 02 ; Actual version list length: 2 octets
00 01 ; Version: 1
00 00 ; (attribute padding)A.4. EAP-Response/SIM/Start
The client picks a nonce and responds with this packet 🍓
02 ; Code: Response
01 ; Identifier: 1
00 20 ; Length: 32 octets
12 ; Type: EAP-SIM
0a ; EAP-SIM subtype: Start
00 00 ; (reserved)
07 ; Attribute type: AT_NONCE_MT
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
01 23 45 67 ; NONCE_MT value
89 ab cd ef
fe dc ba 98
76 54 32 10
10 ; Attribute type: AT_SELECTED_VERSION
01 ; Attribute length: 4 octets (1*4)
00 01 ; Version: 1A.5. EAP-Request/SIM/Challenge
Next, the server selects three authentication triplets 🔥
(RAND1,SRES1,Kc1) = (10111213 14151617 18191a1b 1c1d1e1f,
d1d2d3d4,
a0a1a2a3 a4a5a6a7)
(RAND2,SRES2,Kc2) = (20212223 24252627 28292a2b 2c2d2e2f,
e1e2e3e4,
b0b1b2b3 b4b5b6b7)
(RAND3,SRES3,Kc3) = (30313233 34353637 38393a3b 3c3d3e3f,
f1f2f3f4,
c0c1c2c3 c4c5c6c7)Next, the MK gets calculated as specified in Section 7*. 🧮
MK = e576d5ca 332e9930 018bf1ba ee2763c7 95b3c712And the other keys are derived using the PRNG 🔑
K_encr = 536e5ebc 4465582a a6a8ec99 86ebb620
K_aut = 25af1942 efcbf4bc 72b39434 21f2a974
MSK = 39d45aea f4e30601 983e972b 6cfd46d1
c3637733 65690d09 cd44976b 525f47d3
a60a985e 955c53b0 90b2e4b7 3719196a
40254296 8fd14a88 8f46b9a7 886e4488
EMSK = 5949eab0 fff69d52 315c6c63 4fd14a7f
0d52023d 56f79698 fa6596ab eed4f93f
bb48eb53 4d985414 ceed0d9a 8ed33c38
7c9dfdab 92ffbdf2 40fcecf6 5a2c93b9Next, the server picks a pseudonym and a fast re-authentication identity 🧚 In this case they are "w8w49PexCazWJ&xCIARmxuMKht5S1sxRDqXSEFBEg3DcZP9cIxTe5J4OyIwNGVzxeJOU1G" and "Y24fNSrz8BP274jOJaF17WfxI8YO7QX00pMXk9XMMVOw7broaNhTczuFq53aEpOkk3L0dm@eapsim.foo", respectively.
The following plaintext gets encrypted and stored in the AT_ENCR_DATA attribute 🔐
84 ; Attribute type: AT_NEXT_PSEUDONYM
13 ; Attribute length: 76 octets (19*4)
00 46 ; Actual pseudonym length: 70 octets
77 38 77 34 39 50 65 78 43 61 7a 57 4a 26 78 43
49 41 52 6d 78 75 4d 4b 68 74 35 53 31 73 78 52
44 71 58 53 45 46 42 45 67 33 44 63 5a 50 39 63
49 78 54 65 35 4a 34 4f 79 49 77 4e 47 56 7a 78
65 4a 4f 55 31 47
00 00 ; (attribute padding)
85 ; Attribute type: AT_NEXT_REAUTH_ID
16 ; Attribute length: 88 octets (22*4)
00 51 ; Actual re-auth identity length: 81 octets
59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f
4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30
30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f
61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b
6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f
6f
00 00 00 ; (attribute padding)
06 ; Attribute type: AT_PADDING
03 ; Attribute length: 12 octets (3*4)
00 00 00 00
00 00 00 00
00 00The EAP packet looks like this 💅
01 ; Code: Request
02 ; Identifier: 2
01 18 ; Length: 280 octets
12 ; Type: EAP-SIM
0b ; EAP-SIM subtype: Challenge
00 00 ; (reserved)
01 ; Attribute type: AT_RAND
0d ; Attribute length: 52 octets (13*4)
00 00 ; (reserved)
10 11 12 13 ; first RAND
14 15 16 17
18 19 1a 1b
1c 1d 1e 1f
20 21 22 23 ; second RAND
24 25 26 27
28 29 2a 2b
2c 2d 2e 2f
30 31 32 33 ; third RAND
34 35 36 37
38 39 3a 3b
3c 3d 3e 3f
81 ; Attribute type: AT_IV
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
9e 18 b0 c2 ; IV value
9a 65 22 63
c0 6e fb 54
dd 00 a8 95
82 ; Attribute type: AT_ENCR_DATA
2d ; Attribute length: 180 octets (45*4)
00 00 ; (reserved)
55 f2 93 9b bd b1 b1 9e a1 b4 7f c0 b3 e0 be 4c
ab 2c f7 37 2d 98 e3 02 3c 6b b9 24 15 72 3d 58
ba d6 6c e0 84 e1 01 b6 0f 53 58 35 4b d4 21 82
78 ae a7 bf 2c ba ce 33 10 6a ed dc 62 5b 0c 1d
5a a6 7a 41 73 9a e5 b5 79 50 97 3f c7 ff 83 01
07 3c 6f 95 31 50 fc 30 3e a1 52 d1 e1 0a 2d 1f
4f 52 26 da a1 ee 90 05 47 22 52 bd b3 b7 1d 6f
0c 3a 34 90 31 6c 46 92 98 71 bd 45 cd fd bc a6
11 2f 07 f8 be 71 79 90 d2 5f 6d d7 f2 b7 b3 20
bf 4d 5a 99 2e 88 03 31 d7 29 94 5a ec 75 ae 5d
43 c8 ed a5 fe 62 33 fc ac 49 4e e6 7a 0d 50 4d
0b ; Attribute type: AT_MAC
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
fe f3 24 ac ; MAC value
39 62 b5 9f
3b d7 82 53
ae 4d cb 6aThe MAC is calculated over the EAP packet above (with MAC value set to zero), followed by the NONCE_MT value (a total of 296 bytes). 🙈
A.6. EAP-Response/SIM/Challenge
The client's response looks like this 🦋
02 ; Code: Response
02 ; Identifier: 2
00 1c ; Length: 28 octets
12 ; Type: EAP-SIM
0b ; EAP-SIM subtype: Challenge
00 00 ; (reserved)
0b ; Attribute type: AT_MAC
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
f5 6d 64 33 ; MAC value
e6 8e d2 97
6a c1 19 37
fc 3d 11 54The MAC is calculated over the EAP packet above (with MAC value set to zero), followed by the SRES values (a total of 40 bytes). 🌈
A.7. EAP-Success ✨
The last packet is an EAP-Success, bestie! 🎉
03 ; Code: Success
02 ; Identifier: 2
00 04 ; Length: 4 octetsA.8. Fast Re-authentication 🦋
When we do fast re-authentication, the EAP-Request/Identity packet looks exactly the same as usual 💅. The EAP-Response/Identity carries the fast re-authentication identity, which comes from the AT_ENCR_DATA attribute we looked at above 🫶:
02 ; Code: Response
00 ; Identifier: 0
00 56 ; Length: 86 octets
01 ; Type: Identity
59 32 34 66 4e 53 72 7a 38 42 50 32 37 34 6a 4f
4a 61 46 31 37 57 66 78 49 38 59 4f 37 51 58 30
30 70 4d 58 6b 39 58 4d 4d 56 4f 77 37 62 72 6f
61 4e 68 54 63 7a 75 46 71 35 33 61 45 70 4f 6b
6b 33 4c 30 64 6d 40 65 61 70 73 69 6d 2e 66 6f
6fA.9. EAP-Request/SIM/Re-authentication 👑
Okay so the server recognizes the reauthentication identity 🙌, so it responds with EAP-Request/SIM/Re-authentication. It pulls up the counter value it has stored, generates a nonce, and picks a brand new reauthentication identity. In this case that's uta0M0iyIsMwWp5TTdSdnOLvg2XDVf21OYt1vnfiMcs5dnIDHOIFVavIRzMRyzW6vFzdHW@eapsim.foo 🌸
The plaintext below gets encrypted and stored in the AT_ENCR_DATA attribute. AT_PADDING isn't used here, because the plaintext is already a multiple of 16 bytes, so no padding needed 🙈
13 ; Attribute type: AT_COUNTER
01 ; Attribute length: 4 octets (1*4)
00 01 ; Counter value
15 ; Attribute type: AT_NONCE_S
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
01 23 45 67 ; NONCE_S value
89 ab cd ef
fe dc ba 98
76 54 32 10
85 ; Attribute type: AT_NEXT_REAUTH_ID
16 ; Attribute length: 88 octets (22*4)
00 51 ; Actual re-auth identity length: 81 octets
75 74 61 30 4d 30 69 79 49 73 4d 77 57 70 35 54
54 64 53 64 6e 4f 4c 76 67 32 58 44 56 66 32 31
4f 59 74 31 76 6e 66 69 4d 63 73 35 64 6e 49 44
48 4f 49 46 56 61 76 49 52 7a 4d 52 79 7a 57 36
76 46 7a 64 48 57 40 65 61 70 73 69 6d 2e 66 6f
6f
00 00 00 ; (attribute padding)Here's what the EAP packet looks like 👀:
01 ; Code: Request
01 ; Identifier: 1
00 a4 ; Length: 164 octets
12 ; Type: EAP-SIM
0d ; EAP-SIM subtype: Re-authentication
00 00 ; (reserved)
81 ; Attribute type: AT_IV
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
d5 85 ac 77 ; IV value
86 b9 03 36
65 7c 77 b4
65 75 b9 c4
82 ; Attribute type: AT_ENCR_DATA
1d ; Attribute length: 116 octets (29*4)
00 00 ; (reserved)
68 62 91 a9 d2 ab c5 8c aa 32 94 b6 e8 5b 44 84
6c 44 e5 dc b2 de 8b 9e 80 d6 9d 49 85 8a 5d b8
4c dc 1c 9b c9 5c 01 b9 6b 6e ca 31 34 74 ae a6
d3 14 16 e1 9d aa 9d f7 0f 05 00 88 41 ca 80 14
96 4d 3b 30 a4 9b cf 43 e4 d3 f1 8e 86 29 5a 4a
2b 38 d9 6c 97 05 c2 bb b0 5c 4a ac e9 7d 5e af
f5 64 04 6c 8b d3 0b c3 9b e5 e1 7a ce 2b 10 a6
0b ; Attribute type: AT_MAC
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
48 3a 17 99 ; MAC value
b8 3d 7c d3
d0 a1 e4 01
d9 ee 47 70The MAC gets calculated over the EAP packet above, with the MAC value set to zero. That's 164 bytes total 🧮
Last step, the server derives new keys 🔑. XKEY' gets calculated the way Section 7* describes:
XKEY' = 863dc120 32e08343 c1a2308d b48377f6 801f58d4The new MSK and EMSK come out of the PRNG. K_encr and K_aut stay the same, so no changes there ✨
MSK = 6263f614 973895e1 335f7e30 cff028ee
2176f519 002c9abe 732fe0ef 00cf167c
756d9e4c ed6d5ed6 40eb3fe3 8565ca07
6e7fb8a8 17cfe8d9 adbce441 d47c4f5e
EMSK = 3d8ff786 3a630b2b 06e2cf20 9684c13f
6b82f992 f2b06f1b 54bf51ef 237f2a40
1ef5e0d7 e098a34c 533eaebf 34578854
b7721526 20a777f0 e0340884 a294fb73A.10. EAP-Response/SIM/Re-authentication 💖
The client's response includes the counter too 🙋♀️. This plaintext gets encrypted and stored in the AT_ENCR_DATA attribute:
13 ; Attribute type: AT_COUNTER
01 ; Attribute length: 4 octets (1*4)
00 01 ; Counter value
06 ; Attribute type: AT_PADDING
03 ; Attribute length: 12 octets (3*4)
00 00 00 00
00 00 00 00
00 00And here's the EAP packet 🧚:
02 ; Code: Response
01 ; Identifier: 1
00 44 ; Length: 68 octets
12 ; Type: EAP-SIM
0d ; EAP-SIM subtype: Re-authentication
00 00 ; (reserved)
81 ; Attribute type: AT_IV
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
cd f7 ff a6 ; IV value
5d e0 4c 02
6b 56 c8 6b
76 b1 02 ea
82 ; Attribute type: AT_ENCR_DATA
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
b6 ed d3 82
79 e2 a1 42
3c 1a fc 5c
45 5c 7d 56
0b ; Attribute type: AT_MAC
05 ; Attribute length: 20 octets (5*4)
00 00 ; (reserved)
fa f7 6b 71 ; MAC value
fb e2 d2 55
b9 6a 35 66
c9 15 c6 17The MAC gets calculated over the EAP packet above, with the MAC value set to zero, and then the NONCE_S value gets tacked on the end. That's 84 bytes total 🫧
The next packet is the EAP-Success, and we're done bestie 🎀:
03 ; Code: Success
01 ; Identifier: 1
00 04 ; Length: 4 octetsAppendix B. Pseudo-Random Number Generator 🌈
The "|" character means concatenation, and "^" means exponentiation 🤓.
Step 1: Choose a new, secret value for the seed-key, XKEY 🔐
Step 2: In hexadecimal notation, let:
t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0This is the initial value for H0|H1|H2|H3|H4 in the FIPS SHS [SHA-1].
Step 3: Here's the loop, with j running from 0 to m - 1:
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 🖊️
Henry Haverinen (editor)
Nokia Enterprise Solutions
P.O. Box 12
FIN-40101 Jyvaskyla
Finland
EMail: henry.haverinen@nokia.com
Joseph Salowey (editor)
Cisco Systems
2901 Third Avenue
Seattle, WA 98121
USA
Phone: +1 206 256 3380
EMail: jsalowey@cisco.comFull Copyright Statement 💜
Copyright (C) The Internet Society (2006).
This doc is covered by the rights, licenses, and restrictions in BCP 78. Other than what BCP 78 says, the authors keep all their rights 🦋.
This document and the information in it are provided on an "AS IS" basis, and the legal bit goes like this:
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 doesn't take a position on whether any Intellectual Property Rights (or other rights) that might be claimed to apply to the technology in this document are valid, what their scope is, or whether any license under those rights might be available. It also doesn't say it has done any independent effort to find such rights 🙈. If you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79.
Copies of IPR disclosures sent to the IETF Secretariat, along with any assurances of licenses to be made available (or the results of an attempt to get a general license or permission for implementers or users to use those proprietary rights), can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 📚.
The IETF invites anyone to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌.
Acknowledgement 🌸
Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 🫶.
📦 where this page comes from
- ietf: rfc4186 2006-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms