RFC 4763
Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)
RFC 4763 📜💖 Extensible Authentication Protocol Method for Shared-secret Authentication and Key Establishment (EAP-SAKE)
Title block tea ☕: The Network Working Group RFC is RFC 4763, and the category is Informational 🌸. It's written by M. Vanderveen and H. Soliman from Qualcomm Flarion Technologies 🦋, and it dropped in November 2006 ✨. The title block doesn't list anything it obsoletes or updates, so there's no drama there 💅.
Status of This Memo 🎀
Okay so this memo is just giving information to the Internet community 💁♀️. It is NOT a formal Internet standard, not even a little bit 🙈. Distribution of this memo is unlimited, so share it with everyone you know 🌈.
Copyright Notice ©️
Copyright (C) The IETF Trust (2006). The vibes are protected 🔒.
IESG Note 📢
⚠️ Read this part carefully, bestie.
This RFC is not a candidate for any level of Internet Standard 🚫. The IETF disclaims any knowledge of the fitness of this RFC for any purpose 🙅♀️. It notes that the decision to publish wasn't based on IETF review for stuff like security, congestion control, or inappropriate interaction with deployed protocols 😬. The RFC Editor chose to publish this at its discretion 💜. So readers should exercise caution when they're deciding whether it's worth implementing or deploying 🥺. See RFC 3932 for more information 📚.
Abstract ✨
So this document specifies an Extensible Authentication Protocol (EAP) mechanism for Shared-secret Authentication and Key Establishment (SAKE) 🔐. It's published as documentation for the IANA assignment of an EAP Type for a vendor's EAP method per RFC 3748 🎁. The specification has passed Designated Expert review for this IANA assignment 👑.
Table of Contents 🗂️
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Protocol Description ............................................4
3.1. Overview and Motivation of EAP-SAKE ........................4
3.2. Protocol Operation .........................................5
3.2.1. Successful Exchange .................................5
3.2.2. Authentication Failure ..............................7
3.2.3. Identity Management ................................11
3.2.4. Obtaining Peer Identity ............................11
3.2.5. Key Hierarchy ......................................13
3.2.6. Key Derivation .....................................15
3.2.7. Ciphersuite Negotiation ............................17
3.2.8. Message Integrity and Encryption ...................17
3.2.9. Fragmentation ......................................21
3.2.10. Error Cases .......................................21
3.3. Message Formats ...........................................22
3.3.1. Message Format Summary .............................22
3.3.2. Attribute Format ...................................23
3.3.3. Use of AT_ENCR_DATA Attribute ......................25
3.3.4. EAP.Request/SAKE/Challenge Format ..................26
3.3.5. EAP.Response/SAKE/Challenge Format .................28
3.3.6. EAP.Request/SAKE/Confirm Format ....................30
3.3.7. EAP.Response/SAKE/Confirm Format ...................32
3.3.8. EAP.Response/SAKE/Auth-Reject Format ...............33
3.3.9. EAP.Request/SAKE/Identity Format ...................34
3.3.10. EAP.Response/SAKE/Identity Format .................36
3.3.11. Other EAP Messages Formats ........................37
4. IANA Considerations ............................................37
5. Security Considerations ........................................38
5.1. Denial-of-Service Attacks .................................38
5.2. Root Secret Considerations ................................38
5.3. Mutual Authentication .....................................39
5.4. Integrity Protection ......................................39
5.5. Replay Protection .........................................39
5.6. Confidentiality ...........................................40
5.7. Key Derivation, Strength ..................................40
5.8. Dictionary Attacks ........................................41
5.9. Man-in-the-Middle Attacks .................................41
5.10. Result Indication Protection .............................41
5.11. Cryptographic Separation of Keys .........................41
5.12. Session Independence .....................................41
5.13. Identity Protection ......................................42
5.14. Channel Binding ..........................................42
5.15. Ciphersuite Negotiation ..................................42
5.16. Random Number Generation .................................43
6. Security Claims ................................................43
7. Acknowledgements ...............................................44
8. References .....................................................44
8.1. Normative References ......................................44
8.2. Informative References ....................................451. Introduction 🧚
Okay so the Extensible Authentication Protocol (EAP), described in [EAP], is the standard way to plug in lots of different authentication methods 🔑. EAP is also used inside IEEE 802 networks through the IEEE 802.11i [IEEE802.11i] framework 📶.
EAP supports a bunch of authentication schemes, like smart cards, Kerberos, Public Key, One Time Passwords, TLS, and more 🃏. This document defines one of those schemes, called EAP-SAKE ✨. EAP-SAKE supports mutual authentication and session key derivation, and it's built on a static pre-shared secret 🤝. This RFC is published as documentation for the IANA assignment of an EAP Type for a vendor's EAP method per RFC 3748 🎀. The specification has passed Designated Expert review for this IANA assignment 💅.
2. Terminology 📖
In this document, a few words are used to signify the requirements of the specification 🫶. They're often capitalized, and the key words "MUST", "MUST NOT", "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [KEYWORDS] 🌸.
The document also uses the terms from [EAP], plus a few abbreviations 🍓:
MIC Message Integrity Check
SMS SAKE Master Secret
NAI Network Access Identifier3. Protocol Description 🦋
3.1. Overview and Motivation of EAP-SAKE 💖
Okay this part is the main character intro 👑. The EAP-SAKE authentication protocol is a native EAP authentication method 🌈. That means a stand-alone version of EAP-SAKE outside of EAP is not defined 🙅♀️. EAP-SAKE is designed for mutual authentication, based on pre-shared keys and well-known public cryptographic algorithms 🔐. It's ideal for subscription-based public access networks, like cellular networks 📱.
EAP-SAKE assumes a long-term or pre-shared secret known only to the Peer and the Server 🤫. This pre-shared secret is called the Root Secret 🗝️. The Root Secret is made of two 16-byte parts: Root-Secret-A and Root-Secret-B 🧩. Root-Secret-A is reserved for use local to the EAP-SAKE method, which means it's there to mutually authenticate the EAP Peer and EAP Server 🫂. Root-Secret-B is used to derive other stuff like the Master Session Key (MSK) and Extended Master Session Key (EMSK) ✨. Root-Secret-B and Root-Secret-A MUST be cryptographically separate 🔒. That one's non-negotiable, periodt 💅.
When a Backend Authentication Server is used, the Server typically talks to the Authenticator over an AAA protocol 📡. Those AAA communications are outside the scope of this document 🚪.
Some of the advantages of EAP-SAKE are:
- It is based on the well-established Bellare-Rogaway mutual authentication protocol 🏆.
- It supports key derivation for local EAP method use, and for export to other third parties so they can use the keys independently of EAP 🎁.
- It employs only two request/response exchanges 🙌.
- It relies on the (corrected) IEEE 802.11i function for key derivation and message integrity 🔥. This way, a device implementing a lower-layer secure association protocol compliant with the IEEE 802.11i standard won't need additional cryptographic code 🥳.
- Its encryption algorithm is securely negotiated (with no extra messages), yet encryption use is optional 🧁.
- Keys used for authentication and keys used for encryption are cryptographically separate 💜.
- User identity anonymity can be optionally supported 🙈.
- No synchronization (for example, of counters) is needed between server and peer ⭐.
- There is no one-time key pre-processing step 🌷.
3.2. Protocol Operation 🎀
EAP-SAKE uses four messages, made of two EAP request/response exchanges 💫. The EAP.Success and EAP.Failure messages shown in the figures are NOT part of the EAP-SAKE method 🙅♀️. Just a convention for you: method attributes are named AT_XX, where XX is the name of the parameter the attribute value is set to 🧚♀️.
3.2.1. Successful Exchange ✨
okay bestie, let's talk about the happy path 🦋 Figure 1 shows a successful EAP-SAKE run with ciphersuite negotiation, and it's giving full choreography 💅
Peer Server
| |
| EAP.Request/SAKE/Challenge |
| (AT_RAND_S, AT_SERVERID) |
1 |<---------------------------------------------------------|
| |
| EAP.Response/SAKE/Challenge |
| (AT_RAND_P, AT_PEERID, AT_SPI_P, AT_MIC_P) |
2 |--------------------------------------------------------->|
| |
| EAP.Request/SAKE/Confirm |
| (AT_SPI_S, AT_ENCR_DATA, AT_MIC_S)|
3 |<---------------------------------------------------------|
| |
| EAP.Response/SAKE/Confirm |
| (AT_MIC_P) |
4 |--------------------------------------------------------->|
| |
| |
| EAP-Success |
5 |<---------------------------------------------------------|
| |
Figure 1. EAP-SAKE Authentication Procedure (with ciphersuite
negotiation)Here's the play-by-play 🎀
- The EAP server starts the whole exchange with the first message. It's an EAP.Request message of type SAKE and subtype Challenge, and it carries AT_RAND_S (a nonce the Server freshly generates 🌸) and AT_SERVERID, which holds an identifier for the Server. That identifier is a fully qualified domain name, like the realm of the user NAI [NAI]. AT_SERVERID is OPTIONAL but SHOULD be included in this message ✨ Its whole job is to help the Peer pick the right security association (so, Root-Secret, PEERID, and SERVERID) for this EAP phase. Main character energy for that attribute, honestly 👑
- The Peer replies with an EAP.Response message of type SAKE and subtype Challenge. This one carries AT_RAND_P (a nonce the Peer freshly generates 💜), AT_PEERID (a Peer identifier 🧚), AT_SPI_P (a list of one or more ciphersuites the Peer supports), and AT_MIC_P (a message integrity check). The AT_SPI_P and AT_PEERID attributes are OPTIONAL. AT_PEERID SHOULD be included, though, to cover multi-homed hosts 🍓 A supported ciphersuite is shown as a value that's local to the EAP-SAKE method, which is the "Security Parameter Index" (see section 3.2.8.3). The Peer uses both nonces along with the Root-Secret-A key to derive a SAKE Master Secret (SMS) and Temporary EAP Keys (TEKs), and those TEKs include TEK-Auth and TEK-Cipher. The MIC_P value is computed from both nonces, RAND_S and RAND_P, plus the entire EAP packet, using TEK-Auth (see Section 3.2.6). It's giving math, but make it cute 🙈
- When the Server gets the EAP.Response/SAKE/Challenge message, it uses both nonces, RAND_S and RAND_P, and the Root-Secret-A key to compute the SMS and TEK in exactly the same way the Peer did 🔥 Then it computes the Peer's MIC_P the same way the Peer did, and compares that with the MIC_P it actually received. If they match, the Server considers the Peer authenticated ✅ If encryption is needed, the Server picks the strongest ciphersuite from the Peer's SPI_P list. If the Peer didn't include AT_SPI_P, it picks a suitable ciphersuite instead 💅 Next, the Server sends an EAP.Request message of type SAKE and subtype Confirm. It carries AT_SPI_S (the ciphersuite the Server chose), AT_ENCR_DATA (encrypted data), and AT_MIC_S (a message integrity check). AT_SPI_S and AT_ENCR_DATA are OPTIONAL attributes, and they show up when confidentiality and/or user identity anonymity is wanted 🫶 The other OPTIONAL attributes that MAY be included are AT_NEXT_TMPID and AT_MSK_LIFE. Same as before, MIC_S gets computed from both nonces, RAND_S and RAND_P, plus the entire EAP packet, using TEK-Auth 🦋
- If the Peer gets the EAP.Request/SAKE/Confirm message that says the Server authenticated successfully, the Peer works out MIC_S the same way the Server did and compares it with the MIC_S it received. If they match, the Peer considers the Server authenticated 🥹 Then it sends an EAP.Response message of type SAKE and subtype Confirm, with AT_MIC_P in it. That MIC_P is computed in the same manner as before 🌈
- After a successful exchange, the Server wraps up the EAP conversation by sending an EAP.Success message to the Peer. Done and dusted 🎉
Okay, now the Session ID, which is seriously important 🔐 Every EAP-SAKE message has a Session ID. The Server chooses it, sends it in the first message, and then copies it into every message after that until an EAP.Success or EAP.Failure goes out. When either side gets an EAP-SAKE message, both Peer and Server MUST check the format of that message, to make sure it's well-formed and has a valid Session ID 💖
Session IDs are mainly there for replay protection. They help uniquely identify a session between a Peer and a Server, so it's giving security with a capital S 🙈 In most cases, there's a one-to-one relationship between the Session ID and the Peer/Server pair.
And here's the cheat sheet for the parameters EAP-SAKE uses 📋
Name Length (bytes) Description
---------+---------------+-------------
RAND_P 16 Peer nonce
RAND_S 16 Server nonce
MIC_P 16 Peer MIC
MIC_S 16 Server MIC
SPI_P variable Peer ciphersuite preference(s)
SPI_S variable Server chosen ciphersuite
PEERID variable Peer identifier
SERVERID variable Server identifier (FQDN)3.2.2. Authentication Failure 💔✨
okay so if the Authenticator gets an EAP.Failure message from the Server, it MUST terminate the connection with the Peer immediately 🛑 no waiting around, bestie
the Server decides the Peer has failed authentication if either of the two received MIC_P values doesn't match the computed MIC_P 🙅♀️
the Server SHOULD deny authorization for a Peer that doesn't advertise any of the ciphersuites that are considered acceptable (e.g., by local system policy) and send an EAP.Failure message 💅
if authentication fails, the Server MUST send an EAP.Failure message to the Peer as in Figure 2. here's how the drama goes down 🎭
Peer Server
| |
| EAP.Request/SAKE/Challenge |
| (AT_RAND_S, AT_SERVERID) |
1 |<---------------------------------------------------------|
| |
| EAP.Response/SAKE/Challenge |
| (AT_RAND_P, AT_PEERID, AT_SPI_P, AT_MIC_P) |
2 |--------------------------------------------------------->|
| |
| +-------------------------------------------+
| | Server finds MIC_P invalid. |
| +-------------------------------------------+
| |
| EAP-Failure |
3 |<---------------------------------------------------------|
Figure 2. EAP-SAKE Authentication Procedure, Peer Fails
Authentication- same as step 1 of Figure 1 🌸
- same as step 2 of Figure 1 🌸
- once the Server gets the EAP.Response/SAKE/Challenge message, it uses both nonces
RAND_SandRAND_P, plus theRoot-Secret-Akey, to compute theSMSandTEKin exactly the same way the Peer did 🔐. then it computes the Peer's MIC in exactly the same way the Peer did, and compares the computedMIC_Pwith theMIC_Pit got from the Peer. they don't match, so the Server calls it: the Peer failed authentication, and it sends an EAP.Failure message back 💀
if the AT_SPI_S attribute doesn't contain one of the SPI values the Peer listed in the previous message, or if the Peer didn't include an AT_SPI_P attribute and still doesn't accept the ciphersuite the Server chose, then the Peer SHOULD silently discard this message 🤫. alternatively, the Peer MAY send a SAKE/Auth-Reject message back to the Server, and in response to that, the Server MUST send an EAP.Failure message to the Peer 🙈
the AT_SPI_S attribute MUST be included if encryption is to be used 🔒. the Server knows whether encryption is happening, because it's usually the Server that needs to protect some data meant for the Peer (like a temporary ID, group keys, etc) 🗝️. if the Peer receives an AT_SPI_S attribute but there's no AT_ENCR_DATA attribute, the Peer SHOULD process the message and skip the AT_SPI_S attribute 💖
the Peer considers the Server to have failed authentication if the received and computed MIC_S values don't match. in that case, the Peer MUST send the Server an EAP.Response message of type SAKE and subtype Auth-Reject, saying authentication failed 🙅♀️. then the Server MUST send an EAP.Failure message to the Peer as in Figure 3 🎬
Peer Server
| |
| EAP.Request/SAKE/Challenge |
| (AT_RAND_S, AT_SERVERID) |
1 |<---------------------------------------------------------|
| |
| EAP.Response/SAKE/Challenge |
| (AT_RAND_P, AT_PEERID, AT_SPI_P, AT_MIC_P) |
2 |--------------------------------------------------------->|
| |
| EAP.Request/SAKE/Confirm |
| (AT_SPI_S, AT_ENCR_DATA, AT_MIC_S)|
3 |<---------------------------------------------------------|
| |
+-----------------------------------------------+ |
| Peer finds MIC_S invalid. | |
+-----------------------------------------------+ |
| |
| EAP.Response/SAKE/Auth-Reject |
4 |--------------------------------------------------------->|
| |
| EAP-Failure |
5 |<---------------------------------------------------------|
| |
Figure 3. EAP-SAKE Authentication Procedure, Server Fails
Authentication- same as step 1 of Figure 1 🌸
- same as step 2 of Figure 1 🌸
- same as step 3 of Figure 1 🌸
- the Peer gets an
a EAP.Request/SAKE/Confirmmessage saying the Server authenticated successfully 🥳. the Peer computes theMIC_Sin the same way the Server did, then compares the receivedMIC_Swith the one it computed. they don't match, so the Peer decides the Server failed authentication 😤. the Peer responds with an EAP.Response message of type SAKE and subtype Auth-Reject, showing authentication failed - once the Server gets an
a EAP.Response/SAKE/Auth-Rejectmessage, it sends an EAP.Failure message back to the Peer 👋
3.2.3. Identity Management 🎀
it may be advisable to give a Peer a temporary identifier (TempID) when user anonymity is desired 🦋. the TempID gets delivered to the Peer in the EAP.Request/SAKE/Confirm message. it follows the format of any NAI [NAI] and is generated by the EAP Server that's doing the EAP-SAKE authentication with the Peer ✨. EAP servers SHOULD be configurable with TempID spaces that can be told apart from the permanent identity space. for instance, a specific realm could be set aside for TempIDs (e.g., tmp.example.biz) 🧚
a TempID doesn't get an explicit lifetime 🕰️. it stays valid until the Server asks for the permanent identifier, or until the Peer starts a new EAP session by sending its permanent identifier. a Peer MUST be able to trigger an EAP session at any time using its permanent identifier 👑. a new TempID assigned during a successful EAP session MUST replace the existing TempID for future transactions between the Peer and the Server 💜
delivering a TempID does NOT mean the Server thinks the Peer is authenticated, bestie 🚫. the Server still has to check the MIC in the EAP.Response/SAKE/Confirm message. if the EAP phase ends with an EAP.Failure message, then the Server and the Peer MUST consider the TempID that was just delivered as invalid. so the Peer MUST NOT use that TempID the next time it tries to authenticate with the Server 💀✋
3.2.4. Obtaining Peer Identity 🔍
Okay so, a Peer can have two kinds of identity 🪪. A PermID is the permanent, long-lived one, and it can be an NAI tied to the Root Secret. A TempID is generated during the EAP method, and the Peer can use it to introduce itself in later EAP sessions with the Server. TempIDs are all about user anonymity 🦋, and using them is totally optional in EAP-SAKE 💖.
The Server MAY request the Peer ID via the EAP.Request/SAKE/Identity message, as shown in Figure 4. This could happen if, say, the Server wants to start an EAP-SAKE session with a Peer it doesn't have a subscriber identifier for 🤔. Here's how it goes:
Peer Server
| |
| +---------------------------------+
| | Server wishes to initiate |
| | an EAP-SAKE session |
| | |
| +---------------------------------+
| |
| EAP.Request/SAKE/Identity |
| (AT_ANY_ID_REQ, AT_SERVERID) |
1 |<---------------------------------------------------------|
| |
| EAP.Response/SAKE/Identity |
| (AT_PEERID) |
2 |--------------------------------------------------------->|
| |
+--------------------------------------------------------------+
| If identity found, normal EAP-SAKE authentication follows. |
+--------------------------------------------------------------+Figure 4. Server Requests Peer Identity
- The Server sends an EAP.Request message of type SAKE and subtype Identity, with the attribute AT_ANY_ID_REQ, indicating a request for any Peer identifier 📨.
- The Peer constructs an EAP.Response message of type SAKE and subtype Identity, with the attribute AT_PEER_ID containing any Peer identifier (PermID or TempID) 🙌.
If the Server can't find the Peer identity reported in the EAP.Response/SAKE/Identity message, or it doesn't recognize the format of the Peer identifier, the Server MAY send an EAP.Failure message to the Peer 💀.
If the Server is unable to look up a Peer by its TempID, or if policy says the Peer should now use its permanent id, then the Server may specifically ask for the permanent identifier, as in Figure 5 🎯. The steps go like this:
Peer Server
| |
| +---------------------------------+
1 | | Server obtains TempID but |
| | requires PermID |
| +---------------------------------+
| |
| EAP.Request/SAKE/Identity |
| (AT_PERM_ID_REQ, AT_SERVERID) |
2 |<---------------------------------------------------------|
| |
| EAP.Response/SAKE/Identity |
| (AT_PEERID) |
3 |--------------------------------------------------------->|
| |
| +---------------------------------+
| | Server finds and uses |
| | Peer PermID to start a |
| | EAP-SAKE authentication phase |
| +---------------------------------+
|
+---------------------------------------------------------------+
| Normal EAP-SAKE authentication follows. |
+---------------------------------------------------------------+Figure 5. Server Is Given a TempID as Peer Identity; Server Requires a PermID
- The Peer (or the Authenticator on behalf of the Peer) sends an EAP.Request message of type Identity and includes the TempID 🏷️.
- The Server requires a PermID instead, so it sends an EAP.Request message of type SAKE and subtype Identity with attributes AT_PERM_ID_REQ and AT_SERVERID 🔁.
- The Peer sends an EAP.Response message of type SAKE and subtype Identity containing the attribute AT_PEERID carrying the Peer PermID 🎀.
3.2.5. Key Hierarchy 🗝️
EAP-SAKE uses a three-level key hierarchy, and it's honestly so pretty 😍.
Level 1 is the pre-shared secret called the Root Secret. It's a 32-byte high-entropy string split into the Root-Secret-A part (16 bytes) and the Root-Secret-B part (16 bytes) 🔐.
Level 2 holds the key derivation key called the SAKE Master Secret (SMS). SMS-A is derived from Root-Secret-A plus the Peer and Server nonces using the EAP-SAKE Key-Derivation Function (KDF), and SMS-B is made the same way. The SMS is known only to the Peer and Server, and it's never shared with anyone else 🤫.
Level 3 is where the session keys live, like Transient EAP Keys (TEK), Master Session Key (MSK), and Extended MSK (EMSK) ✨. TEKs are only for use local to the EAP method. They're derived from SMS-A and the nonces with the EAP-SAKE KDF, and they split into a 16-byte TEK-Auth (used to compute the MICs) and a 16-byte TEK-Cipher (used to encrypt selected attributes). Since the SMS is fresh, the derived TEKs are fresh too 🌸.
+--------------------+ +--------------------+
| Root-Secret-A | | Root-Secret-B |
| (pre-shared secret)| | (pre-shared secret)|
+--------------------+ +--------------------+
| |
V V
+-------------------+ +--------------------+
| SAKE Master Secret|<---RAND_S------------->| SAKE Master Secret |
| (SMS-A) | | | (SMS-B) |
| |<-------]---RAND_P----->| |
+-------------------+ | | +--------------------+
| | | |
V | | V
+--------------------+ | | +--------------------+
| Transient EAP Keys |<------+-----+-------->| Session Keys: |
| TEK-Auth,TEK-Cipher|<------------+-------->| MSK, EMSK |
+--------------------+ +--------------------+Figure 6. Key Hierarchy for the EAP-SAKE Method
On another branch of Level 3 are the MSK and EMSK, each mandated to be 64 bytes long 📏. They're derived from SMS-B and the nonces with the EAP-SAKE KDF, and yep, since the SMS is fresh, so are the derived MSK/EMSK 💅. The MSK is meant to be exported and relayed to other parties 📤. The EMSK is reserved for future use, like deriving application-specific keys, and it's not shared with other parties 🙈.
Here's the whole EAP-SAKE key material at a glance 👀:
===================================================================
Key Size Scope Lifetime Use
(bytes)
===================================================================
Root-Secret-A 16 Peer, Server Device Derive TEK
--------------------------------------------------------------------
Root-Secret-B 16 Peer, Server Device Derive MSK, EMSK
--------------------------------------------------------------------
TEK-Auth 16 Peer, Server MSK Life Compute MICs
--------------------------------------------------------------------
TEK-Cipher 16 Peer, Server MSK Life Encrypt attribute
--------------------------------------------------------------------
MSK 64 Peer, Server, MSK Life Derive keys for
Authenticator lower-layer use
--------------------------------------------------------------------
EMSK 64 Peer, Server MSK Life Reserved
--------------------------------------------------------------------A key name format is not provided in this version 🤷♀️.
Since this version of EAP-SAKE doesn't support fast re-authentication, the lifetime of the TEKs only goes until the next EAP mutual authentication 🔄. The MSK lifetime tells you when that next mutual authentication should happen ⏰. The Server MAY convey the MSK lifetime to the Peer in the AT_MSK_LIFE attribute. Note that EAP-SAKE does not support key lifetime negotiation, so no bargaining here, bestie 🙅♀️.
The EAP-SAKE Method-Id is the contents of the RAND_S field from the AT_RAND_S attribute, followed by the contents of the RAND_P field in the AT_RAND_P attribute 🆔.
3.2.6. Key Derivation 🧮
3.2.6.1. Key-Derivation Function
For the rest of this document, KDF-X denotes the EAP-SAKE Key-Derivation Function whose output is X bytes ✨. This function is the pseudo-random function of [IEEE802.11i], so it's giving reliable 💫.
The function takes three strings of bytes of arbitrary lengths: a Key, a Label, and a Msg, and outputs a string Out of length X bytes, like this:
Out = KDF-X (Key, Label, Msg)The KDF is a keyed hash function with key "Key" that operates on the input "Label | Msg". Here's the convention: concatenation is denoted by |, FLOOR denotes the floor function, and [x...y] denotes bytes x through y 🧠.
The label is an ASCII character string. It's included in the exact form it's given, without a length byte or trailing null character 🔤.
Below, "Length" denotes a single unsigned octet with values between 0 and 255 (bytes). The following functions are defined (see [HMAC], [SHA1]) 📚:
H-SHA1(Key, Label, Msg, Length) := HMAC-SHA1(Key, Label|Y|Msg|Length)
where Y := 0x00
KDF-16(Key, Label, Msg) := KDF(Key, Label, Msg, 16)
KDF-32(Key, Label, Msg) := KDF(Key, Label, Msg, 32)
KDF-128(Key, Label, Msg) := KDF(Key, Label, Msg, 128)
KDF(Key, Label, Msg, Length)
R := [] ;; null string
for i := 0 to FLOOR(Length/20)-1 do
R := R | H-SHA1(Key, Label, Msg, i)
return R[0...(Length-1)]3.2.6.2. Transient EAP Keys Derivation
The Peer and Server derive the SMS and then the TEK as follows 🥰:
SMS-A = KDF-16 (Root-Secret-A, "SAKE Master Secret A", RAND_P|RAND_S)
TEK = KDF-32 (SMS-A, "Transient EAP Key", RAND_S | RAND_P)
TEK-Auth = TEK[0...15]
TEK-Cipher = TEK[16...31]3.2.6.3. Extended/Master Session Key Derivation ✨
okay so the Peer and the Server both derive the MSK/EMSK like this 🔑
SMS-B = KDF-16 (Root-Secret-B, "SAKE Master Secret B", RAND_P|RAND_S)
Session-Key-Block=KDF-128(SMS-B, "Master Session Key", RAND_S|RAND_P)
MSK = Session-Key-Block[0...63]
EMSK = Session-Key-Block[64...127]this derivation gives you the required cryptographic separation between the MSK and EMSK 🦋 knowing the EMSK doesn't immediately get you the MSK, and knowing the MSK doesn't immediately get you the EMSK. iconic, honestly 💅
3.2.7. Ciphersuite Negotiation 🎀
so a ciphersuite is identified by a numeric value called the Security Parameter Index (SPI) 🔢 EAP-SAKE uses the SPI to negotiate a ciphersuite between the Peer and the Server, but only for EAP data protection. and obviously this ciphersuite can only be used late in the EAP conversation, after both the Peer and the Server have agreed on it 🫶
the method may or may not need this ciphersuite, since attribute encryption is optional ✨ for example, if the temporary identifier needs to be delivered to the Peer and needs to be encrypted, then the negotiated ciphersuite gets used for that job. if there are no attributes that need encryption as they're passed to the Peer, then this ciphersuite is never used 🙈
like most other methods that do ciphersuite negotiation, it goes like this 💜 the Peer sends an ordered list of one or more supported ciphersuites, most preferred first, in a field called SPI_P. then the Server sends back the one ciphersuite it chose, in a field called SPI_S. the Server SHOULD choose the strongest ciphersuite supported by both of them 👑
ciphersuite negotiation for data protection happens through SAKE Signaling like this: in the EAP.Response/SAKE/Challenge, the Peer sends a list of supported ciphersuites, SPI_P, and protects that with a MIC 🔒 in the EAP.Request/SAKE/Confirm, the Server sends one selected ciphersuite, SPI_S, and signs that with a MIC ✍️ finally, the Peer confirms the selected ciphersuite and that it's ready to use it, in a signed EAP.Response/SAKE/Confirm message 🌸 the negotiation is secure because of the Message Integrity Checks that cover the entire EAP message. no cap, that's the whole point 🔥
3.2.8. Message Integrity and Encryption 🛡️
this section specifies the EAP/SAKE attributes used for message integrity and attribute encryption: AT_MIC_S, AT_MIC_P, AT_IV, AT_ENCR_DATA, and AT_PADDING 🧚 only the AT_MIC_S and AT_MIC_P are mandatory to use during the EAP-SAKE exchange 💖
the TEKs needed to protect the attributes and for message authentication are derived using the nonces RAND_S and RAND_P, so the AT_MIC_S and AT_MIC_P attributes can only be used in the EAP.Response/SAKE/Challenge message and any messages sent after that 🦋
3.2.8.1. The AT_MIC_S and AT_MIC_P Attributes 💅
the AT_MIC_S and AT_MIC_P attributes are used for EAP-SAKE message integrity 🔐 okay, rules time, bestie:
- the
AT_MIC_Sattribute MUST be included in all EAP-SAKE packets that the Server sends whenever key material (TEK) has been derived. that means theAT_MIC_Sattribute MUST be included in theEAP.Request/SAKE/Confirmmessage. - the
AT_MIC_SMUST NOT be included inEAP.Request/SAKE/Challengemessages, orEAP.Request/SAKE/Identitymessages. - the
AT_MIC_Pattribute MUST be included in all EAP-SAKE packets the Peer sends whenever key material (TEK) has been derived. so theAT_MIC_Pattribute MUST be included in theEAP.Response/SAKE/ChallengeandEAP.Response/SAKE/Confirmmessages. - the
AT_MIC_Pattribute MUST NOT be included in theEAP.Response/SAKE/Auth-Rejectmessage, since the Peer hasn't confirmed that it has the same TEK as the Server 🙈
messages that don't meet the conditions above MUST be silently discarded upon reception 💀
the value field of the AT_MIC_S and AT_MIC_P attributes holds a message integrity check (MIC) ✨ the MIC gets calculated over the entire EAP packet, prepended with the Server nonce and identifier and the Peer nonce and identifier. the value field of the MIC attribute is set to zero when the MIC is calculated. including the Server and Peer nonces and identifiers helps detect replay and man-in-the-middle attacks, and that's so important 🌈
the Peer computes its MIC like this:
MIC_P = KDF-16 (TEK-Auth, "Peer MIC", RAND_S | RAND_P |
PEERID | 0x00 | SERVERID | 0x00 | <EAP-packet>),while the Server computes its MIC as:
MIC_S = KDF-16 (TEK-Auth, "Server MIC", RAND_P |RAND_S |
SERVERID | 0x00 | PEERID | 0x00 | <EAP-packet>).here, <EAP-packet> means the entire EAP packet, used as a string of bytes, with the MIC value field set to zero 🧁 0x00 is a single octet used to delimit SERVERID and PEERID. the PEERID and SERVERID are the ones carried in the matching attributes in the SAKE/Challenge messages 🎀
if the SAKE/Challenge exchange was preceded by an EAP.Request/SAKE/Identity message containing the AT_SERVERID attribute, then the SERVERID value used in the MIC_P and MIC_S computation MUST be set to the value of that attribute 🫶
if the AT_SERVERID wasn't included in either the SAKE/Challenge message or the SAKE/Identity message, then the SERVERID value used in computing MIC_P and MIC_S MUST be empty. and if the AT_PEERID wasn't included in the SAKE/Challenge message, and there was no EAP.Response/SAKE/Identity message before the SAKE/Challenge messages, then the PEERID value used in computing MIC_P and MIC_S MUST be empty 🌸
the Server and Peer identities go into the signed responses so the Peer and Server can verify each other's identities, and that they share a secret, the TEK-Auth 🤝 however, since the AT_SERVERID isn't explicitly signed with a MIC by the Server, EAP-SAKE does not claim channel binding 😭
3.2.8.2. The AT_IV, AT_ENCR_DATA, and AT_PADDING Attributes 🌷
the AT_IV and AT_ENCR_DATA attributes can be used to send encrypted info between the Server and the Peer 🔒 the value field of AT_IV holds an initialization vector (IV) if the encryption algorithm needs one. it's not mandatory to include AT_IV whenever AT_ENCR_DATA is included.
BUT, AT_IV MUST NOT be included unless AT_ENCR_DATA is included. messages that don't meet this condition MUST be silently discarded 🚫
attributes can only be encrypted after a ciphersuite has been agreed on, which means in any message starting with the Server's EAP.Request/SAKE/Confirm message 💜 the attributes MUST be encrypted using algorithms matching the SPI value in the AT_SPI_S attribute. they MUST be encrypted using the TEK-Cipher key, whose derivation is specified in Section 3.2.6.2 ✨
if the encryption algorithm needs an IV, then the sender of the AT_IV attribute MUST NOT reuse the IV value from previous EAP-SAKE packets. the sender MUST choose a new value for each AT_IV attribute. the sender SHOULD use a good random number generator to generate the initialization vector (see [RFC4086] for guidelines) 🎲
the value field of the AT_ENCR_DATA attribute is made of bytes encrypted with the ciphersuite specified in the AT_SPI_S attribute. the encryption key is the TEK-Cipher, and the plaintext is one or more concatenated EAP-SAKE attributes 🧚
the default encryption algorithm, described in Section 3.2.8.3, needs the plaintext length to be a multiple of 16 bytes 📏 the sender MAY need to include the AT_PADDING attribute as the last attribute within the value field of the AT_ENCR_DATA attribute. the padding length is chosen so the length of the AT_ENCR_DATA value field becomes a multiple of 16 bytes. the AT_PADDING attribute SHOULD NOT be included if the total length of the other attributes inside AT_ENCR_DATA is already a multiple of 16 bytes 🙃 the length of AT_PADDING includes the Attribute Type and Attribute Length fields. the actual pad bytes in the value field are set to zero (0x00) when sending 🍓 the recipient of the message MUST verify that the pad bytes are zero after decryption, and MUST silently discard the message otherwise 💀
the MIC computed over the entire EAP message can be used so you don't need special integrity protection or message authentication for the encrypted attributes 🫶
an example of the AT_ENCR_DATA attribute is shown in Section 3.3.3 🦋
3.2.8.3. Security Parameter Index (SPI) Considerations 🎀
an SPI value is a variable-length string that identifies at least an encryption algorithm, and possibly a "security association" 🔑 EAP-SAKE doesn't mandate the format of the SPI. it only mandates that the default encryption algorithm be supported if encryption is supported. so, if a compliant implementation supports encryption, it MUST support the AES-CBC cipher 👑
the default encryption algorithm, AES-CBC, uses the AES block cipher [AES] in the Cipher-Block-Chaining (CBC) mode of operation [CBC] 🧠
the Peer in the EAP-SAKE method can send up to four SPI values in its SPI_P field 🌈 the length of the AT_SPI_P and AT_SPI_S attributes must each be a multiple of 2 bytes, so the sender pads the value field with zero bytes when needed (the AT_PADDING attribute isn't used here). for example, the value field of AT_SPI_S holds one byte with the chosen SPI, followed by one byte of zeros 🌸
3.2.9. Fragmentation 🧁
the EAP-SAKE method doesn't require fragmentation, because the messages don't get excessively long 💫 EAP packets fit well within the maximum transmission unit of other layers (link, network). the only variable fields are the ones carrying NAIs, which the length field limits to 256 bytes 📦
3.2.10. Error Cases 🚨
okay, this part is so important, bestie 😭
- Malformed messages: as a general rule, if a Peer or Server receives an EAP-SAKE packet that has an error, the implementation SHOULD silently discard this packet, not change state, and not send any EAP messages to the other party. examples of these errors include a missing mandatory attribute, an attribute that isn't allowed in this type of message, and unrecognized subtypes or attributes 🙅♀️
- Non-matching Session Id: if a Peer or Server receives an EAP-SAKE packet whose Session Id field doesn't match the Session Id from the previous packet in this session, that entity SHOULD silently discard this packet (not applicable for the first message of an EAP-SAKE session) 🧚
- Peer Authorization Failure: a Peer may not be authorized for services, such as when the terminal device is reported stolen 🚫 in that case, the Server SHOULD send an EAP.Failure message 🥀
- Unexpected EAP.Success: a Server MUST NOT send an EAP-Success message before the SAKE/Challenge and SAKE/Confirm rounds. the Peer MUST silently discard any EAP.Success packets before it has successfully authenticated the Server via the
EAP.Response/SAKE/Confirmpacket 🙈
the Peer and Server SHOULD log all error cases 📝
3.3. Message Formats 🦋
3.3.1. Message Format Summary ✨
okay so first up, the EAP packet format [EAP] 🎀 I'm including it here so you can see the whole layout at once. Fields go left to right, obviously 💅
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=EAP-SAKE | Version=2 | Session ID | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Code 🌸
1 - Request2 - Response
- Identifier 🦋: one octet, and it's what helps match responses up with their requests.
- Length 📏: two octets. It's the total number of octets in an EAP message, counting the Code, Identifier, Length, Type, and Data fields.
- Type 🧚: To be assigned.
- Version 💜: the EAP-SAKE method described here is version 2.
- Session ID 🔥: a 1-byte random number that MUST be freshly generated by the Server. It has to match across all EAP messages in one particular EAP conversation, no exceptions bestie.
- Subtype 👑: the EAP-SAKE subtypes are SAKE/Challenge, SAKE/Confirm, SAKE/Auth-Reject, and SAKE/Identity. Any message of type "EAP-SAKE" that isn't one of these subtypes MUST silently discarded. 💀
Message Name Subtype Value (decimal)
=============================================
SAKE/Challenge 1
SAKE/Confirm 2
SAKE/Auth-Reject 3
SAKE/Identity 43.3.2. Attribute Format 🌈
okay the EAP-SAKE attributes that live inside the EAP-SAKE packet use Type-Length-Value format. That's a 1-byte Type, a 1-byte Length, and a Value that can be variable-length (up to 255 bytes) 🫶 The Length counts octets and includes the Type and Length fields themselves. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 🍓: a 1-byte unsigned integer. Check the Table below.
- Length 📐: the total number of octets in the attribute, including Type and Length.
- Value 🎀: attribute-specific.
The following attribute types are allocated. It's the whole cast list, so get ready 💖
-----------------------------------------------------------------
Attr. Name Length
(bytes) Skippable Description
-----------------------------------------------------------------
AT_RAND_S 18 No Server Nonce RAND_S
AT_RAND_P 18 No Peer Nonce RAND_P
AT_MIC_S 10 No Server MIC
AT_MIC_P 10 No Peer MIC
AT_SERVERID variable No Server FQDN
AT_PEERID variable No Peer NAI (tmp, perm)
AT_SPI_S variable No Server chosen SPI SPI_S
AT_SPI_P variable No Peer SPI list SPI_P
AT_ANY_ID_REQ 4 No Requires any Peer Id (tmp, perm)
AT_PERM_ID_REQ 4 No Requires Peer's permanent Id/NAI
AT_ENCR_DATA Variable Yes Contains encrypted attributes
AT_IV Variable Yes IV for encrypted attributes
AT_PADDING 2 to 18 Yes Padding for encrypted attributes
AT_NEXT_TMPID variable Yes TempID for next EAP-SAKE phase
AT_MSK_LIFE 6 Yes MSK Lifetime in seconds
-----------------------------------------------------------------3.3.3. Use of AT_ENCR_DATA Attribute 🔐
Here's an example of the AT_ENCR_DATA attribute as it shows up in the EAP.Request/SAKE/Confirm message. It's a lot of nested boxes, so take a breath 🙈
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 = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| Initialization Vector |
| |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |AT_ENCR_DATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+}e
| AT_NEXT_TMPID | Length | |}n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |}c
| |}r
. Peer TempID |}y
. |}p
. |}t
| |}e
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+}d
| AT_MIC_S | Length = 10 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIC_S |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| |AT_PADDING | Length=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+3.3.4. EAP.Request/SAKE/Challenge Format 🦋
This is what the EAP.Request/SAKE/Challenge packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=EAP-SAKE | Version=2 | Session ID | Subtype=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_RAND_S | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| RAND_S |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | AT_SERVERID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: :
| Server ID |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The semantics of the fields go like this 🧚
- Code 🌸:
1for Request. - Identifier 🌈: a random number. Check [EAP] for the details.
- Length 📏: the length of the entire EAP packet in octets.
- Type 💜: EAP-SAKE.
- Version 👑:
2. - Session ID 🔥: a random number chosen by the server to identify this EAP-Session.
- Subtype 🎀:
1for SAKE/Challenge. - AT_RAND_S 💖: the value field of this attribute holds the Server nonce RAND_S parameter. The RAND_S attribute MUST be present in EAP.Request/SAKE/Challenge. Not optional, not negotiable, lowkey iconic 👑
- AT_SERVERID ⭐: the value field holds the Server identifier (for example, a non-null terminated string). The AT_SERVERID attribute SHOULD be present in EAP.Request/SAKE Challenge. 🍓
3.3.5. EAP.Response/SAKE/Challenge Format 🌸
And here's the EAP.Response/SAKE/Challenge packet, which is the peer's reply 🫶
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=EAP-SAKE | Version=2 | Session ID | Subtype=1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_RAND_P | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
| RAND_P |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | AT_PEERID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Peer NAI :
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| | AT_SPI_P | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPIP | AT_MIC_P | Length = 18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MIC_P |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The semantics of the fields go like this 💅
- Code 🌷:
2for Response. - Identifier 🦋: a number that MUST match the Identifier field from the corresponding Request.
- Length 📏: the length of the entire EAP packet in octets.
- Type 💜: EAP-SAKE.
- Version 👑:
2. - Session ID 🔥: a number matching all other EAP messages in this EAP session.
- Subtype 🎀:
1for SAKE/Challenge. - AT_RAND_P 💖: the value field holds the Peer nonce RAND_P parameter. The AT_RAND_P attribute MUST be present in the EAP.Response/SAKE/Challenge.
- AT_PEERID 🧚: the value field holds the NAI of the Peer. The Peer identity uses the same Network Access Identifier format as EAP.Response/Identity, which means it includes the NAI realm portion. The identity is either the permanent identity or a temporary identity, and it doesn't include any terminating null characters. The AT_PEERID attribute is optional in the EAP.Response/SAKE/Challenge. 🌈
- AT_SPI_P 🍓: the value field holds the Peer's ciphersuite list SPI_P parameter. The AT_SPI_P attribute is optional in the EAP.Response/SAKE/Challenge. ✨
- AT_MIC_P 🔐: the value field holds the Peer MIC_P parameter. The AT_MIC_P attribute MUST be present in the EAP.Response/SAKE/Challenge. 👑
3.3.6. EAP.Request/SAKE/Confirm Format 🎀
okay bestie, this is the EAP.Request/SAKE/Confirm packet 💅 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=EAP-SAKE | Version=2 | Session ID | Subtype=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_SPI_S | Length | SPI_S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_IV | Length | Initialization Vector ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_ENCR_DATA | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Data... |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_MSK_LIFE | Length=6 | MSK Lifetime... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_MIC_S | Length=18 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MIC_S |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here's what each field means ✨
Code: 1 for Request
Identifier: a random number 🎲 see [EAP]
Length: the length of the whole EAP packet in octets
Type: EAP-SAKE
Version: 2
Session ID: a number that matches every other EAP message in this EAP session 🫶
Subtype: 2 for SAKE Confirm
AT_SPI_S: the value field holds the Server's chosen ciphersuite SPI_S parameter. this attribute is optional in the EAP.Request/SAKE/Confirm 🌸
AT_IV: optional to use in this message. the value field holds the Initialization Vector that's used with the encrypted data that comes after it 🔐
AT_ENCR_DATA: optional to use in this message. the encrypted data (if it's there) may contain an AT_NEXT_TMPID attribute, which holds the NAI the Peer should use for the next EAP authentication 🦋
AT_MSK_LIFE: optional to use in this message. the value field holds the MSK Lifetime in seconds ⏳
AT_MIC_S: the value field holds the Server MIC_S parameter. the AT_MIC_S attribute MUST be present in the EAP.Request/SAKE/Confirm. no skipping this one, periodt 👑
3.3.7. EAP.Response/SAKE/Confirm Format 💖
here's the EAP.Response/SAKE/Confirm packet 🧚
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=EAP-SAKE | Version=2 | Session ID | Subtype=2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_MIC_P | Length = 18 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| MIC_P |
| |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AT_PADDING | Length = 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the fields, bestie 🍓
Code: 2 for Response
Identifier: a number that MUST match the Identifier field from the corresponding Request 🙈
Length: the length of the whole EAP packet in octets
Type: EAP-SAKE
Version: 2
Session ID: a number that matches every other EAP message in this EAP session
Subtype: 2 for SAKE Confirm
AT_MIC_P: the value field holds the Peer's MIC_P parameter. the AT_MIC_P attribute MUST be present in the EAP.Response/SAKE/Confirm 🥹
AT_PADDING: the value field is set to zero. it's only there to get the EAP-SAKE packet to 32-bit alignment ✨
3.3.8. EAP.Response/SAKE/Auth-Reject Format 🥀
this is the EAP.Response/SAKE/Auth-Reject packet, and honestly it's the simplest one in the bunch 😌
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=EAP-SAKE | Version=2 | Session ID | Subtype=3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code: 2 for Response
Identifier: a number that MUST match the Identifier field from the corresponding Request
Length: the length of the whole EAP packet in octets
Type: EAP-SAKE
Version: 2
Session ID: a number that matches every other EAP message in this EAP session
Subtype: 3 for SAKE/Auth-Reject
3.3.9. EAP.Request/SAKE/Identity Format 🪞
the EAP.Request/SAKE/Identity packet is up next, and it's giving identity crisis in the best way 🦋
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=EAP-SAKE | Version=2 | Session ID | Subtype=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_PERM_ID_REQ | Length = 4 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_ANY_ID_REQ | Length = 4 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|AT_SERVERID | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| Server ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+field by field 💅
Code: 1 for Request
Identifier: a random number. see [EAP]
Length: the length of the whole EAP packet in octets
Type: EAP-SAKE
Version: 2
Session ID: a number that matches every other EAP message in this EAP session
Subtype: 4 for SAKE/Identity
AT_PERM_ID_REQ: optional. include it when the Server needs the Peer to give its permanent identifier (aka PermID). the AT_PERM_ID_REQ MUST NOT be included if the AT_ANY_ID_REQ attribute is included. its value field only has two reserved bytes, which get set to zero when sending and ignored when receiving 🫧
AT_ANY_ID_REQ: optional. include it when the Server wants the Peer to send any identifier (for example PermID or TempID). the AT_ANY_ID_REQ MUST NOT be included if AT_PERM_ID_REQ is included. its value field also only has two reserved bytes, set to zero when sending and ignored when receiving. one of the AT_PERM_ID_REQ and AT_ANY_ID_REQ MUST be included 🚨
one of the two ID request attributes has to show up, no exceptions. the two can't show up together either. it's giving rules, bestie 📜
AT_SERVERID: the value field holds the identifier/realm of the Server. this attribute is optional but RECOMMENDED to include in the EAP.Request/SAKE/Identity 🌈
3.3.10. EAP.Response/SAKE/Identity Format 🌷
here's the EAP.Response/SAKE/Identity packet, which is the Peer answering back with its own identity 💌
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=EAP-SAKE | Version=2 | Session ID | Subtype=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_PEERID | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :
| Peer NAI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Code: 2 for Response
Identifier: a number that MUST match the Identifier field from the corresponding Request
Length: the length of the whole EAP packet
Type: EAP-SAKE
Version: 2
Session ID: a number that matches every other EAP message in this EAP session
Subtype: 4 for SAKE/Identity
AT_PEERID: the value field holds the NAI of the Peer. the AT_PEERID attribute MUST be present in EAP.Response/SAKE/Identity 🎀
3.3.11. Other EAP Messages Formats 🧁
quick one to finish this part ✨ the format of the EAP.Request/Identity and EAP.Response/Identity packets is described in [EAP]. the user ID (like an NAI) SHOULD be present in this packet 🫶
the format of the EAP-Success and EAP-Failure packets is also shown in [EAP] 🌟
4. IANA Considerations ✨
okay so IANA gave EAP-SAKE its very own EAP Type 💅 bestie, that's the whole thing, it's officially its own method now 🎀
EAP-SAKE messages carry an 8-bit Subtype field 🌸. The Subtype is its own brand new numbering space, and IANA administration is required for it. This memo specifies the following subtypes:
SAKE/Challenge.................1
SAKE/Confirm...................2
SAKE/Auth-Reject...............3
SAKE/Identity..................4The Subtype-specific data is made up of attributes, and each attribute has an 8-bit type number 🦋 Attributes numbered 0 through 127 are called non-skippable attributes, and attributes numbered 128 through 255 are called skippable attributes. The EAP-SAKE attribute type number is also a brand new numbering space that IANA has to administer. This memo specifies these attribute types:
AT_RAND_S.......................................1
AT_RAND_P.......................................2
AT_MIC_S........................................3
AT_MIC_P........................................4
AT_SERVERID.....................................5
AT_PEERID.......................................6
AT_SPI_S........................................7
AT_SPI_P........................................8
AT_ANY_ID_REQ...................................9
AT_PERM_ID_REQ.................................10
AT_ENCR_DATA..................................128
AT_IV.........................................129
AT_PADDING....................................130
AT_NEXT_TMPID.................................131
AT_MSK_LIFE...................................132Any request for a value from those two number spaces needs proper documentation, following the "Specification Required" policy described in [IANA] 📝 And any value assigned from either of the two number spaces in this memo needs IETF consensus 🫶
5. Security Considerations 🔥
okay this section is where it gets serious, so buckle up 😭 The EAP specification [EAP] covers the security vulnerabilities of EAP itself, but NOT the method-specific security mechanisms. This section talks about the security properties EAP-SAKE claims to have, plus its vulnerabilities and security recommendations 💜
5.1. Denial-of-Service Attacks
EAP-SAKE is not a tunneling method 🙈 So the EAP.Response/SAKE/Auth-Reject, EAP.Success, and EAP.Failure packets are NOT integrity or replay protected. That means an attacker can spoof those messages. Also, EAP.Response/SAKE/Auth-Reject can't be protected with a MIC, because an authentication failure means the Server and Peer don't agree on a common key 💀
The biggest one: an attacker can't make a Peer accept an EAP.Success packet as proof that the Server thinks mutual authentication worked. A Peer doesn't accept EAP.Success packets before it has authenticated the Server, or after it has decided the Server failed authentication ✨
5.2. Root Secret Considerations
If anyone other than the Server and Peer knows the Root Secret, then the mutual authentication and key establishment in EAP-SAKE is compromised 😭
EAP-SAKE doesn't say how the Root Secret is generated or distributed to the Server and Peer 🧚 It is RECOMMENDED that the entropy of the Root Secret be maximized. The Root Secret SHOULD be machine-generated.
If the Root Secret is derived from something low-entropy and guessable, like a human-picked password, then the EAP-SAKE key derivation is open to on-line and off-line dictionary attacks 🙈 To help spot whether a password has been compromised, implementations SHOULD keep a log of how many EAP-SAKE messages arrive with invalid MIC fields. In those cases, a procedure for updating the Root Secret securely SHOULD be in place 🔐
5.3. Mutual Authentication
Mutual authentication happens through the SAKE/Challenge and SAKE/Confirm messages 🤝 The EAP.Request/SAKE/Challenge carries the Server nonce RAND_S. The EAP.Response/SAKE/Challenge carries the Peer nonce RAND_P, along with the Peer MIC (MIC_P). The EAP.Request/SAKE/Confirm carries the Server MIC (MIC_S). Both MICs (MIC_S and MIC_P) are computed using both nonces, RAND_S and RAND_P, and they're keyed by the TEK, a shared secret derived from the Root Secret 🔑
The Server considers the Peer authenticated if the MIC_P it computes matches the one the Peer sends. In the same way, the Peer considers the Server authenticated if the MIC_S it computes matches the one the Server sends. The MICs are computed with a keyed one-way hash function, which makes it computationally hard for an attacker to produce a correct MIC without knowing the shared secret 💅
5.4. Integrity Protection
Integrity protection for EAP-SAKE messages comes from the Message Integrity Checks (MIC). They're present in every message as soon as a common shared secret (TEK) is available, which means any message after the EAP.Request/SAKE/Challenge 🛡️ An adversary can't modify any MIC-protected message without the recipient hitting a MIC failure. How strong the integrity protection is depends on the security of the KDF used to derive the MIC, the length and entropy of the shared secret the KDF uses, and the length of the MIC 📊
5.5. Replay Protection
The first message of most session establishment protocols, EAP-SAKE included, can be replayed 🔁 If a replayed EAP.Request/SAKE/Challenge shows up, the Peer sends back an EAP.Response/SAKE/Challenge containing a MIC computed with the attacker's chosen nonce. That's a minimal risk to the TEK-Auth key, and this EAP Session can't go through successfully, because the Peer will find the Server's MIC invalid 🙅♀️
Replay protection comes from the RAND_S and RAND_P values together with the Session ID field. These get included in the MIC calculation for every packet after the EAP-SAKE/Challenge request packet 💖 The Session ID MUST be generated anew by the Server for each EAP session. Session IDs also help identify multiple EAP sessions between a Peer and a Server 🪪 Within the same session, an attacker can still replay messages, but the state machine SHOULD be able to handle those cases. A replay inside a session looks exactly like a network malfunction to the recipient, like when a message gets lost and then retransmitted so the recipient thinks it's a duplicate 🫠
Replay protection between EAP sessions, and within one, is also handled by the MIC. It covers the entire EAP packet (including the Session ID) and also the nonces RAND_S and RAND_P 🎯 So the recipient of an EAP message can be sure the message it just got is the one the other Peer just sent, not a replay, because it contains a valid MIC over the recipient's nonce and the other Peer's nonce. Again, how strong the replay protection is depends on the security of the KDF used to derive the MIC, the length and entropy of the shared secret the KDF uses, and the length of the MIC 💜
5.6. Confidentiality
Confidentiality for EAP-SAKE attributes comes from the AT_ENCR_DATA and AT_IV attributes 🔒 A ciphersuite is negotiated securely (see Section 3.2.7) and can be used to encrypt any attributes as needed. The default ciphersuite includes a strong cipher based on AES 🌈
5.7. Key Derivation, Strength
EAP-SAKE derives a Master Key (for EAP use) and a Master Session Key, plus other lower-level keys like TEKs ✨ Some of those lower-level keys may or may not be used. The strength (entropy) of all of these keys is at most the strength of the Root Secret 📉
Assuming the Server and Peer 128-bit nonces come from good random number generators, the entropy of the MSK and of the EMSK is at most 256 bits 🔢
5.8. Dictionary Attacks
Dictionary attacks aren't feasible to pull off against EAP-SAKE, because passwords aren't used 🙌 Instead, the Root Secret is machine-generated. That doesn't necessarily cause provisioning problems 🎀
5.9. Man-in-the-Middle Attacks
Resistance to man-in-the-middle attacks comes from the integrity protection every EAP message carries (the Message Integrity Check field), as soon as a common key for this EAP session has been derived through mutual authentication 🕵️♀️ Like before, how strong this resistance is depends on the strength of the MIC itself. Man-in-the-middle attacks tied to using any EAP method inside a tunneling or sequencing protocol are out of scope for this document 🚫
5.10. Result Indication Protection
EAP-SAKE gives result indication protection, because it provides result indications, integrity protection, and replay protection all together 👑 The Server says it has successfully authenticated the Peer by sending the EAP.Request/SAKE/Confirm message, which is integrity and replay protected. The Peer says it has successfully authenticated the Server by sending the EAP.Response/SAKE/Confirm message, which is also integrity and replay protected 💅
5.11. Cryptographic Separation of Keys
The TEKs used to protect EAP-SAKE packets (TEK-Auth, TEK-Cipher), the Master Session Key, and the Extended Master Session Key are cryptographically separate 🧩 Information about any one of these keys doesn't reveal information about any other key. It's also infeasible to calculate the Root Secret from any or all of the TEKs, the MSK, or the EMSK 🙅♀️
5.12. Session Independence
Within each EAP-SAKE session, fresh keying material gets generated 🌸 The keying material this method exports from two independent EAP-SAKE sessions is cryptographically separate, as explained below.
Both the Server and the Peer SHOULD generate fresh random numbers (nonces) for the EAP-SAKE exchange 🎲 If either entity re-uses a random number from a previous session, the fact that the other one does use a freshly generated random number still means the TEKs, MSK, and EMSK derived in this session are cryptographically separate from the matching keys in the previous exchange 🦋
So compromising the MSK or EMSK in one exchange doesn't compromise the MSK and EMSK of previous or later exchanges between a Peer and a Server 🙌
5.13. Identity Protection
As noted in Section 3.2.3., the Server may assign a temporary NAI to a Peer for user anonymity 🥷 The Peer can use this identifier the next time it runs an EAP-SAKE authentication phase with the Server. The TempID is protected by sending it encrypted, inside an AT_ENCR_DATA attribute, and signed by the Server with a MIC 🔐 So an eavesdropper can't link the original PermID the Peer first sends (for example, on power-up) to any later TempID values sent in the clear to the Server 👀
The Server and Peer MAY be configured so that only TempID identities are exchanged after one initial EAP-SAKE phase that uses the Peer's permanent identity 🧚 In that case, for maximum identity protection, the TempID SHOULD be stored in non-volatile memory in the Peer and Server. So compliance with this document doesn't prevent or require Peer identity protection across the Peer's whole lifetime 🌈
5.14. Channel Binding 🔗
Okay so the Server identifier and Peer identifier MAY be sent in the SAKE/Challenge messages. 🫶 But here's the tea: there's no established authentication key yet at the time of that very first message, so the Server identifier is not integrity-protected here. 😭
All the later EAP-SAKE messages exchanged during a successful EAP-SAKE phase are integrity-protected, because they contain a Message Integrity Check (MIC). ✨ The MIC is computed over the EAP message and over the Server and Peer identities, so both EAP endpoints can verify the identity of the other party. Main character energy for real 💜
5.15. Ciphersuite Negotiation 🎀
EAP-SAKE does not support negotiation of the ciphersuite used to integrity-protect the EAP conversation. 🙈 However, negotiation of a ciphersuite for data protection is supported. This ciphersuite negotiation is protected to minimize the risk of down-negotiation or man-in-the-middle attacks. 💅
This negotiation is secure because of the Message Integrity Checks (MICs) that cover the entire EAP messages used for ciphersuite negotiation (see Section 3.2.7.). The extent of the security of the negotiation is commensurate with the security of the KDF used to derive the MICs, the length and entropy of the shared secret used by the KDF, and the length of the MICs. 🔥
5.16. Random Number Generation 🌈
EAP-SAKE supports key derivation from a 32-byte Root Secret. The entropy of all other keys derived from it is reduced somewhat through the use of keyed hash functions (e.g. KDF). So, assuming optimistically that the effective key strength of the Root Secret is 32 bytes, the effective key strengths of the derived keys is at most the effective key strength of the Root Secret quantities they are derived from:
- EMSK, at most 16 bytes
- MSK, at most 16 bytes
6. Security Claims 💖
This section provides the security claims as required by [EAP]. 🧚
[a]Mechanism: EAP-SAKE is a challenge/response authentication and key establishment mechanism based on a symmetric pre-shared secret.[b]Security claims. EAP-SAKE provides:- Mutual authentication (Section 5.3)
- Integrity protection (Section 5.4)
- Replay protection (Section 5.5)
- Confidentiality (optional, Section 5.6 and Section 5.13)
- Key derivation (Section 5.7)
- Dictionary attack protection (Section 5.8)
- Protected result indication of successful authentication from Server and from Peer (Section 5.10)
- Session independence (Section 5.12)
[c]Key strength. EAP-SAKE supports key derivation with 256-bit effective key strength (Section 5.7)[d]Description of key hierarchy: see Section 3.2.5.[e]Indication of vulnerabilities: EAP-Make does not provide:- Fast reconnect
- Fragmentation
- Channel binding
- Cryptographic binding
7. Acknowledgements 🫶
Thanks to R. Dynarski for his helpful comments. 🌸
8. References 📚
8.1. Normative References
[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/drafts/Draft-NIST_SP800-38D_Public_Comment.pdf[EAP]Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.[HMAC]Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.[IANA]Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.[IEEE802.11i]"IEEE Standard for Information Technology- Telecommunications and Information Exchange between Systems - LAN/MAN Specific Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications: Amendment 6: Medium Access Control (MAC) Security Enhancements", June 2004.[KEYWORDS]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[SHA1]National Institute of Standards and Technology, U.S. Department of Commerce, Federal Information Processing Standard (FIPS) Publication 180-1, "Secure Hash Standard", April 1995.
8.2. Informative References
[NAI]Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.[RFC4086]Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
Authors' Addresses 🌸
Michaela Vanderveen
Qualcomm Flarion Technologies
135 Rte. 202/206 South
Bedminster, NJ 07921
USA
EMail: mvandervn@yahoo.comHesham Soliman
Qualcomm Flarion Technologies
135 Rte. 202/206 South
Bedminster, NJ 07921
USA
EMail: solimanhs@gmail.comFull Copyright Statement ©
Copyright (C) The IETF Trust (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔐
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
Acknowledgement 💜
Funding for the RFC Editor function is currently provided by the Internet Society. 🌈
📦 where this page comes from
- ietf: rfc4763 2006-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms