RFC 8263
Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message
Group Domain of Interpretation (GDOI) GROUPKEY-PUSH Acknowledgement Message 🎀
Okay bestie, let's talk about RFC 8263 💖 It's a Standards Track document from the IETF, dated November 2017, and it's all about letting a GCKS ask its group members to say "got it!" after a rekey 🫶
The authors are B. Weis (Cisco Systems), U. Mangla (Juniper Networks Inc.), T. Karl (Deutsche Telekom), and N. Maheshwari. It's published under ISSN 2070-1721 ✨
Its category is Standards Track 👑 and it does not obsolete or update any other RFCs. It's a brand-new addition, so no drama there 💅
Heads up, this is part 1 of 4 🧚 More parts are coming, so stay tuned!
Abstract ✨
So the Group Domain of Interpretation (GDOI) already lets a Group Controller/Key Server (GCKS) hand a bunch of Group Member (GM) devices extra security associations, like when it needs to rekey ones that are about to expire 🔑 This memo adds a new thing: the GCKS can ask the GMs to send back an acknowledgement that they got its rekey message, and it spells out how that acknowledgement works 🦋
Status of This Memo ✨
This is an Internet Standards Track document 🌸
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 💜 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🙈
For the current status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8263 🌈
Copyright Notice ✨
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 💅
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🎀
Table of Contents ✨
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Acronyms and Abbreviations .................................4
2. Acknowledgement Message Request .................................5
2.1. REKEY_ACK_KEK_SHA256 Type ..................................5
2.2. REKEY_ACK_LKH_SHA256 Type ..................................6
2.3. REKEY_ACK_KEK_SHA512 Type ..................................6
2.4. REKEY_ACK_LKH_SHA512 Type ..................................6
3. GROUPKEY-PUSH Acknowledgement Message ...........................6
3.1. HDR ........................................................7
3.2. HASH .......................................................8
3.3. SEQ ........................................................9
3.4. ID .........................................................9
4. Group Member Operations .........................................9
5. GCKS Operations ................................................10
6. Management Considerations ......................................10
7. Security Considerations ........................................12
7.1. Protection of the GROUPKEY-PUSH ACK .......................12
7.2. Transmitting a GROUPKEY-PUSH ACK ..........................13
7.3. Receiving a GROUPKEY-PUSH ACK .............................13
8. IANA Considerations ............................................14
9. References .....................................................15
9.1. Normative References ......................................15
9.2. Informative References ....................................16
Acknowledgements ..................................................17
Authors' Addresses ................................................171. Introduction 🦋
Okay so, the Group Domain of Interpretation (GDOI) [RFC6407] is a group key management method. A GCKS uses it to hand out security associations (basically the cryptographic policy and keying material) to a set of Group Member (GM) devices 🔐 GDOI meets the requirements in [RFC4046] ("Multicast Security (MSEC) Group Key Management Architecture"), including a Registration Protocol and a Rekey Protocol. GDOI describes the Rekey Protocol as a GROUPKEY-PUSH message 💖
A GDOI GCKS uses a GROUPKEY-PUSH message (Section 4 of [RFC6407]) to tell GMs about policy updates for the group. That includes new policy and keying material, replacement policy and keying material, and indications of deleted policy and keying material ✨ Usually the GCKS doesn't need a notification that the GM actually received the policy. But sometimes it's really useful for the GCKS to hear from each GM that it got the rekey message and, by implication, has reacted to the policy in it 🫶 For example, a GCKS policy can use those acknowledgements to figure out which GMs are receiving the current group policy and which GMs are no longer in the group 👑
This memo brings in a way for a GM to send an Acknowledgement Message back to the GCKS 🌸 First, the GCKS asks a GM to acknowledge GROUPKEY-PUSH messages as part of a distributed group policy. Then, as Figure 1 shows, when the GCKS delivers a GROUPKEY-PUSH message, each GM that honors the GCKS request sends back a GROUPKEY-PUSH Acknowledgement Message. The rest of this memo explains the method in detail 🧚
GCKS GM1 GM2
| | |
| +---------->| |
| GROUPKEY-PUSH | | |
|-----------------+ | |
| | | |
| +-------------------->|
| | |
|<----------------------------| |
| GROUPKEY-PUSH ACK | |
| | |
|<--------------------------------------|
| GROUPKEY-PUSH ACK | |Figure 1: GROUPKEY-PUSH Rekey Event 🌈
Implementing the GROUPKEY-PUSH Acknowledgement Message is OPTIONAL 🙈
1.1. Requirements Notation 💅
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀
1.2. Acronyms and Abbreviations 🌸
The following acronyms and abbreviations are used throughout this document 💜
ACK Acknowledgement Message
D Delete
GCKS Group Controller/Key Server
GDOI Group Domain of Interpretation
GM Group Member
HDR Header
HMAC Hashed Message Authentication Code
IV Initialization Vector
KD Key Download
KDF Key Derivation Function
KEK Key Encryption Key
LKH Logical Key Hierarchy
MSEC Multicast Security
PRF Pseudorandom Function
SA Security Association
SEQ Sequence Number
SIG Signature
SPI Security Parameter Index2. Acknowledgement Message Request 🔥
So when a GM is ready to join a group, it contacts the GCKS with a GROUPKEY-PULL Registration Protocol 🧚 Once the GCKS has authenticated and verified that the GM is an authorized member, it downloads several sets of policy in a Security Association (SA) payload. If the group uses a GROUPKEY-PUSH Rekey Protocol, the SA payload includes an SA Key Encryption Key (KEK) payload (Section 5.3 of [RFC6407]). When necessary, the GROUPKEY-PUSH Rekey Protocol also contains an SA payload that includes the SA KEK policy. The SA KEK policy tells the GM how it will be receiving and handling the GROUPKEY-PUSH Rekey Protocol 💖
When the GCKS policy includes the GROUPKEY-PUSH Acknowledgement Message, the GCKS reports that policy to the GM inside the SA KEK policy. The GCKS adds a new KEK attribute named KEK_ACK_REQUESTED (9), which says the GM is being asked to send back a GROUPKEY-PUSH Acknowledgement Message ✨
As part of the SA KEK policy, the GCKS specifies info about the keying material that protects the GROUPKEY-PUSH Rekey Protocol (for example, whether a KEK management algorithm is present). Some of that info helps a GM derive the ack_key (defined in Section 3.2), which protects the GROUPKEY-PUSH Acknowledgement Message 🦋 There are different types of Rekey Acknowledgement Messages. They all share the same message format, but they differ in the keying material they use 🌈
These are the values of the KEK_ACK_REQUESTED attribute defined in this memo 👑
2.1. REKEY_ACK_KEK_SHA256 Type 🎀
This type of Rekey ACK is used when the KEK Download Type (Section 5.6.2 of [RFC6407]) is part of the group policy. The prf (defined in Section 3.2) is PRF-HMAC-SHA-256 [RFC4868]. The base_key (also defined in Section 3.2) is the KEK_ALGORITHM_KEY used to decrypt the GROUPKEY-PUSH message. Heads up: for some algorithms the KEK_ALGORITHM_KEY includes an explicit Initialization Vector (IV) before the actual key (Section 5.6.2.1 of [RFC6407]), but the IV isn't used in defining the base_key 💅
2.2. REKEY_ACK_LKH_SHA256 Type 🌸
This type of Rekey ACK can be used when the KEK_MANAGEMENT_ALGORITHM KEK attribute, with a value representing the Logical Key Hierarchy (LKH), is part of the group policy (Section 5.3.1.1 of [RFC6407]). The prf is PRF-HMAC-SHA-256. The base_key is the Key Data field value taken from the first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute (see Section 5.6.3.1 of [RFC6407]). This is a secret symmetric key that the GCKS shares with the GM 🔐 Note that for some algorithms the LKH Key structure includes an explicit IV before the actual key (Section 5.6.3.1 of [RFC6407]), but the IV isn't used in defining the base_key 🫶
2.3. REKEY_ACK_KEK_SHA512 Type 💜
This type of Rekey ACK is identical to the REKEY_ACK_KEK_SHA256 Type, except that the prf is PRF-HMAC-SHA-512 (defined in [RFC4868]) 🦋
2.4. REKEY_ACK_LKH_SHA512 Type 🧚
This type of Rekey ACK is identical to the REKEY_ACK_LKH_SHA256 Type, except that the prf is PRF-HMAC-SHA-512 (defined in [RFC4868]) ✨
Part 1 of 4 is done, bestie 🩷 Part 2 is next, so don't go anywhere! 💖
3. GROUPKEY-PUSH Acknowledgement Message ✨
okay so bestie, this section is where the GM says "got it, I did the thing" 💅 The GROUPKEY-PUSH message from [RFC6407] gets reproduced right here in Figure 2 🎀 The SA and Key Download (KD) payloads carry the actual policy and keying material being sent down to the GM 🔑 The Sequence Number (SEQ) payload holds a sequence number the GM uses for replay protection, and that number picks out one unique rekey message for that GM 🦋 One or more Delete (D) payloads can optionally say "hey, delete the existing group policy" 🗑️ And the Signature (SIG) payload is a signature over a hash of the whole GROUPKEY-PUSH message (minus the SIG payload octets) taken before encryption 🔐
GM GCKS
-- ----
<---- HDR*, SEQ, [D,] SA, KD, SIG
* Protected by the Rekey SA KEK; encryption occurs after HDR
Figure 2: GROUPKEY-PUSH Message (from RFC 6407)so when the GM gets a KEK_ACK_REQUESTED attribute inside an SA KEK and decides to respond, it sends back the Sequence Number from the GROUPKEY-PUSH message to the GCKS, along with its identity 🫶 That tuple basically tells the GCKS "I got the message and I actually implemented the policy" ✨ The GROUPKEY-PUSH Acknowledgement Message is shown in Figure 3 💖
GM GCKS
-- ----
HDR, HASH, SEQ, ID ---->
Figure 3: GROUPKEY-PUSH Acknowledgement Messagethe IP header for the ack is built like a reply to the GROUPKEY-PUSH message 🦋 So the source address of the push becomes the destination address of the ack, and the GM uses its own IP address as the source 🌸 The source port from the push's UDP header becomes the destination port of the ack's UDP header, and the push's destination port becomes the ack's source port 🧚 It's giving mirror image, honestly 🙈
The following sections describe the payloads in the GROUPKEY-PUSH Acknowledgement Message 💜
3.1. HDR 🎀
the message starts with a header defined for the GDOI GROUPKEY-PUSH message in Section 4.2 of [RFC6407] 📖 The fields in the HDR MUST be initialized as follows 👑 The cookies from the GROUPKEY-PUSH message act as a Security Parameter Index (SPI) and get copied into the ack ✨ "Next Payload" points to a "Hash (HASH)" payload, value 8 [ISAKMP-NP] 💅 Major Version is 1 and Minor Version is 0 🌈 The Exchange Type is 35 for the GDOI GROUPKEY-PUSH Acknowledgement Message 🔥 Flags are set to 0 💜 Message ID MUST be set to 0 🫶 Length follows Section 4.2 of [RFC6407] 🌸
3.2. HASH 🔐
the HASH payload is the same one used in the GDOI GROUPKEY-PULL exchange from Section 3.2 of [RFC6407] 🦋 The hash data gets created like this:
HASH = prf(ack_key, SEQ | ID)where:
- "prf" is specific to the KEK_ACK_REQUESTED value and gets described as part of that description 🧚
- "|" means concatenation 💖
- "SEQ" and "ID" are the bytes of the Sequence Number and Identification payloads 🎀
the ack_key comes from a Key Derivation Function (KDF) that follows KDF in feedback mode from NIST SP800-108 [SP800-108] 🔑 The derived keying material is the same length as the prf output, there is no IV, and the optional counter is not used ✨ Note: when the derived ack_key is smaller than the prf block size (512 bits for PRF-HMAC-SHA-256), it gets zero-filled to the right, as specified in Section 2.1.2 of [RFC4868] 🌸
ack_key = prf(base_key, "GROUPKEY-PUSH ACK" | SPI | L)where:
- "prf" is specific to the KEK_ACK_REQUESTED value and gets described as part of that description 🦋
- "base_key" is also specific to the KEK_ACK_REQUESTED value and is described as part of that description. If the base_key is smaller than the prf block size (512 bits for PRF-HMAC-SHA-256), it's zero-filled to the right, as specified in Section 2.1.2 of [RFC4868] 💅
- "|" means concatenation 💜
- "GROUPKEY-PUSH ACK" is a label encoded as a null-terminated ASCII string 🌈
- "SPI" (per [RFC6407]) is the Initiator Cookie followed by the Responder Cookie from the GROUPKEY-PUSH message HDR, which describes the context of the key usage 🧚
- "L" is a length field matching the number of bits in the ack_key 👑 L MUST match the length of the base_key (512 bits for PRF-HMAC-SHA-256) 😭 The value L is two octets in network byte order, most significant byte first 🔥
3.3. SEQ 🔢
the Sequence Number payload is defined in Section 5.7 of [RFC6407] 💖 The value in the GROUPKEY-PUSH SEQ payload gets copied to the GROUPKEY-PUSH ACK SEQ payload 🫶
3.4. ID 🪪
the Identification payload is used as defined in Section 5.1 of [RFC6407] 🌸 The ID payload has an ID Type of ID_IPV4_ADDR, ID_IPV6_ADDR, or ID_OID as defined in [RFC8052] for GDOI exchanges 🦋 The Protocol ID and Port fields MUST be set to 0 💅 The address in the ID payload is the IP address of the GM, and it MUST match the source IP address used for the most recent GROUPKEY-PULL exchange 🙈
4. Group Member Operations 🧚
when a GM receives an SA KEK payload (in a GROUPKEY-PULL exchange or GROUPKEY-PUSH message) that includes a KEK_ACK_REQUESTED attribute, it writes down in its group state that it's expected to send back a GROUPKEY-PUSH ACK 📝 A GM that recognizes the attribute MUST honor it by returning Acknowledgements 🔥 Why? Because the GCKS will probably take some policy-specific action against unresponsive GMs, including stop sending GROUPKEY-PUSH messages to them 😭
if a GM can't send the requested type of Acknowledgement, it keeps going with the protocol exchange and stays in the group 💜 Either way, if a GM stops getting GROUPKEY-PUSH messages from a GCKS, it will re-register before existing SAs expire, so skipping the Acknowledgements shouldn't be critical 🌸
when a GM gets a GROUPKEY-PUSH message containing a KEK_ACK_REQUESTED attribute in the SA KEK payload, it processes the message according to RFC 6407 💅 Once it concludes the message was processed successfully, it builds the GROUPKEY-PUSH ACKs as described in Section 3 and sends them back to the GCKS the GROUPKEY-PUSH message came from 🦋 A GROUPKEY-PUSH ACK is sent even if the GROUPKEY-PUSH message has a Delete payload for the KEK used to protect it 🫶
5. GCKS Operations 👑
when a GCKS policy includes requesting a GROUPKEY-PUSH ACK from GMs, it adds the KEK_ACK_REQUESTED attribute to the SA KEK payload ✨ It does this every time the SA KEK is delivered, in both GROUPKEY-PULL exchanges and GROUPKEY-PUSH messages 💖 The value of the KEK_ACK_REQUESTED attribute depends on the type of SA KEK policy, as described in Section 2 🌈
when a GCKS receives a GROUPKEY-PUSH ACK (identified by an Exchange Type of GROUPKEY-PUSH-ACK), it first checks that the group policy includes receiving GROUPKEY-PUSH ACKs 🔍 If not, the message gets discarded 🗑️ GCKS implementations SHOULD keep a record (e.g., a hash value) of recently received GROUPKEY-PUSH Acknowledgement Messages and reject duplicates before doing any cryptographic operations 🧚 This lets them discard replayed messages early, which is so smart 🙌
if the message is expected, the GCKS validates the format and checks that the HASH was properly constructed as described in Section 3.2 💅 If validation fails, the message is discarded ❌ The GCKS pulls the sequence number and the GM's identity out of the SEQ and ID payloads, and records that the GM received the GROUPKEY-PUSH message represented by that sequence number 💜 ✨
6. Management Considerations ✨
okay bestie, the GCKS is basically the group's manager 💅 It keeps track of the group policy AND figures out which GM devices are actually "live" members (aka the ones sending or receiving messages) 🦋 Group policy includes a strategy to make sure rekey messages with the current policy reach every live GM. That's touched on briefly in Section 5.3 of [RFC4046]. The GROUPKEY-PUSH Acknowledgement Message from this memo gives the GCKS an extra way to check if a GM is live and has gotten the current group policy 🔥
But ngl, a rekey message or a GROUPKEY-PUSH Acknowledgement Message can get dropped in the network, so a live GM might look unresponsive even when it's totally fine 💀 A GM also might not be able to reply with a GROUPKEY-PUSH ACK at all, so the GCKS should use caution about treating a missing Acknowledgement Message as the only proof that a GM is live 🙈 The vibe check: a GCKS SHOULD NOT consider a GM to have left the group until it has received at least one ACK from that GM. 🫶
Here are some management considerations for how a GM handles Acknowledgement Messages:
- A GM MUST respond with Acknowledgement Messages when requested, because that's how a GCKS can later tell when a GM unexpectedly goes unresponsive 👀
- A GM receiving a GROUPKEY-PUSH message as a multicast message MAY introduce jitter to the timing of its Acknowledgement Message, which helps the GCKS manage replies from GMs more nicely 🌸 A GM MUST NOT delay sending an Acknowledgement Message for more than 5 seconds. A GCKS SHOULD NOT declare an Acknowledgement Message as missing until it has waited at least 10 seconds. Implementations SHOULD make these timers configurable ⏰
Here are some management considerations for how the GCKS handles Acknowledgement Messages:
- Non-receipt of an Acknowledgement Message is an indication that a GM is unable to respond 🥺 A GCKS SHOULD wait at least several seconds before deciding there was non-receipt, since GMs could add jitter to the response time before sending an Acknowledgement Message.
- If the GCKS knows that GMs are expected to respond, then non-receipt of an Acknowledgement Message SHOULD trigger a logging event 📝 The GCKS MAY be configured with extra policy actions, like sending the GROUPKEY-PUSH message several times in a short period of time (as suggested in [RFC4046]). That helps soften the blow of losing either the GROUPKEY-PUSH message or an Acknowledgement Message 🧚 Another policy action could be alerting GCKS administrators about GMs that don't return several consecutive Acknowledgement Messages, or even removing unresponsive GMs from the group. Just be aware, though: a GCKS that removes GMs has to remember that a GM which hasn't responded won't receive a newer group policy until it reaches out to the GCKS again 😭
- When a GROUPKEY-PUSH message includes a Delete payload for the KEK used to protect the GROUPKEY-PUSH message, the GCKS SHOULD NOT itself delete the KEK until it has given GMs the chance to acknowledge receipt of the GROUPKEY-PUSH message ⏳ That could be several seconds, since GMs could add jitter to the response time before sending an Acknowledgement Message.
- A GCKS SHOULD log failure events, like receiving Acknowledgement Messages for a group where the GCKS hasn't requested Acknowledgements, receiving malformed Acknowledgements, and Acknowledgements that fail validation 🚨
7. Security Considerations 🔐
Okay, this section is serious business, so let's get into it 🫣 There are three areas to think about: protecting the GROUPKEY-PUSH ACK, whether the GM should transmit a GROUPKEY-PUSH ACK, and whether a GCKS should accept a GROUPKEY-PUSH ACK. Each one gets its own subsection below 👑
The HASH defined in this memo is constructed using PRF-HMAC-SHA-256 or PRF-HMAC-SHA-512. Those were unquestioned in strength when this memo was developed 💪 If a HASH construction using a different prf ever becomes necessary, a new KEK_ACK_REQUESTED value will be defined in a new specification 🌈
7.1. Protection of the GROUPKEY-PUSH ACK
The GROUPKEY-PUSH ACK is an Internet Security Association and Key Management Protocol (ISAKMP) message, as discussed in [RFC2408]. (Note: RFC 2408 has been obsoleted by RFC 7296, but only RFC 2408 applies in this context.) Message authentication and protection against man-in-the-middle attacks come from including a HASH payload that holds the output of an HMAC computation over the bytes of the message 🛡️
Because the KEK is a group secret, when the value of REKEY_ACK_KEK is specified, impersonation of a victim GM by another authorized GM is possible 😱 The damage from that is limited, though. The only thing it can do is make a false claim that a victim GM received a GROUPKEY-PUSH when the victim GM actually didn't (for example, because an active attacker discarded the GROUPKEY-PUSH) 🕵️ If a GCKS policy includes sending retransmissions of the GROUPKEY-PUSH message to that victim GM, the victim GM might not receive replacement SAs. However, this doesn't add any extra threats over a use case where the GROUPKEY-PUSH ACK isn't deployed and an active attacker withholds GROUPKEY-PUSH messages from a victim GM anyway. These threats can be mitigated by using a value of REKEY_ACK_LKH, thanks to the secret pairwise key shared between the GCKS and an individual GM 🔑
Confidentiality is NOT provided for the GROUPKEY-PUSH ACK. Wait, let me say it properly: confidentiality is not provided for the GROUPKEY-PUSH ACK 🙃 Its contents (the hash value, the sequence number from the GROUPKEY-PUSH message it's acknowledging, and the identity of the GM) can be observed by a passive attacker 👀 Observing a hash value or a set of hash values won't compromise the hash key ✅ The GM's identity is also visible to a passive attacker as the source IP address of the packet. Now here's the tea: the sequence number in the GROUPKEY-PUSH ACK does reveal the sequence number that was included in the GROUPKEY-PUSH message, which the attacker couldn't see before 😮 But the attacker is assumed not to have the key used to encrypt the message, so they can't create a spoofed GROUPKEY-PUSH message. That means the attacker gets no direct value from learning the sequence number 💅
7.2. Transmitting a GROUPKEY-PUSH ACK
A GM transmits an ACK only when the policy of the most recently received SA KEK includes a request by the GCKS for ACKs, and the ACK is only returned after the GROUPKEY-PUSH message has been processed according to Section 4.4 of [RFC6407] 📬 In other words, the form of the GROUPKEY-PUSH message has been validated, replay protection is complete, and the digital signature has been verified as genuine ✨ So the threat of a GM responding to a spoofed or resent GROUPKEY-PUSH message is mitigated, and so is the possibility of a GM being used to spread a Distributed Denial of Service (DDoS) attack on a GCKS 🛑 For more info, check out the security considerations for a GROUPKEY-PUSH message in Section 7.3 of [RFC6407] 🎀
7.3. Receiving a GROUPKEY-PUSH ACK
A GCKS receiving ACKs will follow the validation steps described in Section 5 before it interprets the contents of the message. After that, the GCKS will be sure to only operate on messages that were sent by an authorized GM 🔍
A GCKS SHOULD be prepared to receive GROUPKEY-PUSH ACKs from each GM it sent a GROUPKEY-PUSH to 🙌 That means it needs enough resources (e.g., a receive queue size) so it doesn't unnecessarily drop ACKs. A GCKS should be aware that a large number of replayed or invalid GROUPKEY-PUSH messages could be sent its way. However, that's no worse a threat than receiving a big pile of other kinds of replayed or invalid GDOI or other messages containing a HASH payload 🧃
How a GCKS processes the sequence number and identity included in an ACK is a matter of local policy and is outside the scope of this memo 🌷
8. IANA Considerations 📚
The following additions have been made to the "Group Domain of Interpretation (GDOI) Payloads" [GDOI-REG] registry 🎉
A new attribute has been added to the "SA KEK Payload Values - KEK Attributes" registry. Its ID Class name is KEK_ACK_REQUESTED, with a value of 9, and it is a Basic attribute 🍓
A new registry defining values for KEK_ACK_REQUESTED, "SA KEK Payload Values - KEK_ACK_REQUESTED", has been added. The initial registrations are shown in the following table. The terms "Reserved", "Unassigned", and "Private Use" are applied as defined in [RFC8126], and the registration procedure is Specification Required 💖
Value Type
------- --------------------
0 Reserved
1 REKEY_ACK_KEK_SHA256
2 REKEY_ACK_LKH_SHA256
3 REKEY_ACK_KEK_SHA512
4 REKEY_ACK_LKH_SHA512
5-128 Unassigned
129-255 Private UseA new registry describing ISAKMP Exchange Types for the GDOI, "GDOI DOI Exchange Types", has been added under the "Group Domain of Interpretation (GDOI) Payloads" registry [GDOI-REG] 🧩 This new registry defines DOI Specific Use values [ISAKMP-EXCH], which are Exchange Type values used with the ISAKMP GDOI DOI. The registration procedure is Specification Required. The terms "Known Unregistered Use" and "Unassigned" are applied as defined in [RFC8126] 🌸
Value Phase Reference
---------------------- ------ ---------
GROUPKEY-PULL 32 RFC 6407
GROUPKEY-PUSH 33 RFC 6407
Known Unregistered Use 34
GROUPKEY-PUSH-ACK 35 RFC 8263
Unassigned 36-2399. References 🦋
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4868] Kelly, S. and S. Frankel, "Using HMAC-SHA-256,
HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868,
DOI 10.17487/RFC4868, May 2007,
<https://www.rfc-editor.org/info/rfc4868>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
October 2011, <https://www.rfc-editor.org/info/rfc6407>.
[RFC8052] Weis, B., Seewald, M., and H. Falk, "Group Domain of
Interpretation (GDOI) Protocol Support for IEC 62351
Security Services", RFC 8052, DOI 10.17487/RFC8052,
June 2017, <https://www.rfc-editor.org/info/rfc8052>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
RFC 2119 Key Words", BCP 14, RFC 8174,
DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.9.2. Informative References 📚
Okay bestie, these are the extra-credit reads 🤓 Not required to implement, but super helpful for the full picture.
[GDOI-REG] is the IANA registry for Group Domain of Interpretation (GDOI) payload type values. It's a registry, so it lives at https://www.iana.org/assignments/gdoi-payloads/. Internet Assigned Numbers Authority, "Group Domain of Interpretation (GDOI) Payload Type Values", IANA Registry, September 2017.
[ISAKMP-EXCH] is the IANA registry for Internet Key Exchange (IKE) Attributes Exchange Type Values, found at https://www.iana.org/assignments/ipsec-registry/. Internet Assigned Numbers Authority, "Internet Key Exchange (IKE) Attributes Exchange Type Values", IANA Registry, May 2013.
[ISAKMP-NP] is the sister registry for Internet Key Exchange (IKE) Attributes Next Protocol Types, also at https://www.iana.org/assignments/ipsec-registry/. Internet Assigned Numbers Authority, "Internet Key Exchange (IKE) Attributes Next Protocol Types", IANA Registry, May 2013.
[RFC2408] is the classic spec for the Internet Security Association and Key Management Protocol (ISAKMP). Maughan, D., Schertler, M., Schneider, M., and J. Turner, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, DOI 10.17487/RFC2408, November 1998, https://www.rfc-editor.org/info/rfc2408.
[RFC4046] is the Multicast Security (MSEC) Group Key Management Architecture doc, very much a foundational vibe ✨ Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "Multicast Security (MSEC) Group Key Management Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005, https://www.rfc-editor.org/info/rfc4046.
[SP800-108] is the key derivation one 🔑 Chen, L., "Recommendation for Key Derivation Using Pseudorandom Functions (Revised)", National Institute of Science and Technology, NIST Special Publication 800-108, DOI 10.6028/NIST.SP.800-108, October 2009, http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-108.pdf.
Acknowledgements 💜
Huge shoutout to Mike Hamada, Adrian Farrel, and Yaron Sheffer 🫶 They gave a bunch of useful technical and editorial comments and suggestions for improvement, and the doc is so much better because of them.
Authors' Addresses 🎀
Brian Weis
Cisco Systems
170 W. Tasman Drive
San Jose, California 95134-1706
United States of America
Phone: +1-408-526-4796
Email: bew@cisco.comUmesh Mangla
Juniper Networks Inc.
1133 Innovation Way
Sunnyvale, California 94089
United States of America
Phone: +1-408-936-1022
Email: umangla@juniper.netThomas Karl
Deutsche Telekom
Landgrabenweg 151
Bonn 53227
Germany
Phone: +49-228-18138122
Email: thomas.karl@telekom.deNilesh Maheshwari
Email: nileshm@gmail.com📦 where this page comes from
- ietf: rfc8263 2017-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms