RFC 3547
The Group Domain of Interpretation
Part 1 of 10 🎀
Okay bestie, so the title block is giving "Network Working Group" energy 💖. This is RFC 3547, called The Group Domain of Interpretation, and it's a Standards Track doc, dated July 2003. The authors are M. Baugher (Cisco), B. Weis (Cisco), T. Hardjono (Verisign), and H. Harney (Sparta). The header doesn't list anything it obsoletes or updates 🧐.
Status of This Memo 📜
So this document specifies an Internet standards track protocol for the Internet community 🫶, and it's literally asking for discussion and suggestions for improvements ✨. If you want the standardization state and status of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. And distribution of this memo is unlimited, so share it with everyone 💅.
Copyright Notice 🔒
Copyright (C) The Internet Society (2003). All Rights Reserved. 🌸
Abstract 💭
Okay so this document introduces an ISAMKP Domain of Interpretation (DOI) for group key management 🔑, and its whole job is to support secure group communications 🫶. GDOI manages group security associations, which IPSEC uses, and potentially other data security protocols running at the IP or application layers 🧚. These security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members 💜. It's giving main character energy 👑.
Table of Contents 🗂️
Network Working Group M. Baugher
Request for Comments: 3547 B. Weis
Category: Standards Track Cisco
T. Hardjono
Verisign
H. Harney
Sparta
July 2003
The Group Domain of Interpretation
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document presents an ISAMKP Domain of Interpretation (DOI) for
group key management to support secure group communications. The
GDOI manages group security associations, which are used by IPSEC and
potentially other data security protocols running at the IP or
application layers. These security associations protect one or more
key-encrypting keys, traffic-encrypting keys, or data shared by group
members.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. GDOI Applications. . . . . . . . . . . . . . . . . . . . 5
1.2. Extending GDOI . . . . . . . . . . . . . . . . . . . . . 5
2. GDOI Phase 1 protocol. . . . . . . . . . . . . . . . . . . . . 6
2.1. ISAKMP Phase 1 protocol. . . . . . . . . . . . . . . . . 6
2.1.1. DOI value. . . . . . . . . . . . . . . . . . . . 6
2.1.2. UDP port . . . . . . . . . . . . . . . . . . . . 6
3. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . . . . 6
3.1. Authorization. . . . . . . . . . . . . . . . . . . . . . 7
3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Perfect Forward Secrecy. . . . . . . . . . . . . 9
3.2.2. ISAKMP Header Initialization . . . . . . . . . . 9
3.3. Initiator Operations . . . . . . . . . . . . . . . . . . 10
3.4. Receiver Operations. . . . . . . . . . . . . . . . . . . 11
4. GROUPKEY-PUSH Message. . . . . . . . . . . . . . . . . . . . . 11
4.1. Perfect Forward Secrecy (PFS). . . . . . . . . . . . . . 12
4.2. Forward and Backward Access Control. . . . . . . . . . . 12
4.2.1. Forward Access Control Requirements. . . . . . . 13
4.3. Delegation of Key Management . . . . . . . . . . . . . . 14
4.4. Use of signature keys. . . . . . . . . . . . . . . . . . 14
4.5. ISAKMP Header Initialization . . . . . . . . . . . . . . 14
4.6. Deletion of SAs. . . . . . . . . . . . . . . . . . . . . 14
4.7. GCKS Operations. . . . . . . . . . . . . . . . . . . . . 15
4.8. Group Member Operations. . . . . . . . . . . . . . . . . 16
5. Payloads and Defined Values. . . . . . . . . . . . . . . . . . 16
5.1. Identification Payload . . . . . . . . . . . . . . . . . 17
5.1.1. Identification Type Values . . . . . . . . . . . 18
5.2. Security Association Payload . . . . . . . . . . . . . . 18
5.2.1. Payloads following the SA payload. . . . . . . . 19
5.3. SA KEK payload . . . . . . . . . . . . . . . . . . . . . 19
5.3.1. KEK Attributes . . . . . . . . . . . . . . . . . 22
5.3.2. KEK_MANAGEMENT_ALGORITHM . . . . . . . . . . . . 22
5.3.3. KEK_ALGORITHM. . . . . . . . . . . . . . . . . . 23
5.3.4. KEK_KEY_LENGTH . . . . . . . . . . . . . . . . . 23
5.3.5. KEK_KEY_LIFETIME . . . . . . . . . . . . . . . . 24
5.3.6. SIG_HASH_ALGORITHM . . . . . . . . . . . . . . . 24
5.3.7. SIG_ALGORITHM. . . . . . . . . . . . . . . . . . 24
5.3.8. SIG_KEY_LENGTH . . . . . . . . . . . . . . . . . 25
5.3.9. KE_OAKLEY_GROUP. . . . . . . . . . . . . . . . . 25
5.4. SA TEK Payload . . . . . . . . . . . . . . . . . . . . . 25
5.4.1. PROTO_IPSEC_ESP. . . . . . . . . . . . . . . . . 26
5.4.2. Other Security Protocols . . . . . . . . . . . . 28
5.5. Key Download Payload . . . . . . . . . . . . . . . . . . 28
5.5.1. TEK Download Type. . . . . . . . . . . . . . . . 30
5.5.2. KEK Download Type. . . . . . . . . . . . . . . . 31
5.5.3. LKH Download Type. . . . . . . . . . . . . . . . 32
5.6. Sequence Number Payload. . . . . . . . . . . . . . . . . 35
5.7. Proof of Possession. . . . . . . . . . . . . . . . . . . 36
5.8. Nonce. . . . . . . . . . . . . . . . . . . . . . . . . . 36
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 36
6.1. ISAKMP Phase 1 . . . . . . . . . . . . . . . . . . . . . 37
6.1.1. Authentication . . . . . . . . . . . . . . . . . 37
6.1.2. Confidentiality. . . . . . . . . . . . . . . . . 37
6.1.3. Man-in-the-Middle Attack Protection. . . . . . . 38
6.1.4. Replay/Reflection Attack Protection. . . . . . . 38
6.1.5. Denial of Service Protection . . . . . . . . . . 38
6.2. GROUPKEY-PULL Exchange . . . . . . . . . . . . . . . . . 38
6.2.1. Authentication . . . . . . . . . . . . . . . . . 38
6.2.2. Confidentiality. . . . . . . . . . . . . . . . . 39
6.2.3. Man-in-the-Middle Attack Protection. . . . . . . 39
6.2.4. Replay/Reflection Attack Protection. . . . . . . 39
6.2.5. Denial of Service Protection . . . . . . . . . . 39
6.2.6. Authorization. . . . . . . . . . . . . . . . . . 40
6.3. GROUPKEY-PUSH Exchange . . . . . . . . . . . . . . . . . 40
6.3.1. Authentication . . . . . . . . . . . . . . . . . 40
6.3.2. Confidentiality. . . . . . . . . . . . . . . . . 40
6.3.3. Man-in-the-Middle Attack Protection. . . . . . . 40
6.3.4. Replay/Reflection Attack Protection. . . . . . . 40
6.3.5. Denial of Service Protection . . . . . . . . . . 41
6.3.6. Forward Access Control . . . . . . . . . . . . . 41
7. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 41
7.1. ISAKMP DOI . . . . . . . . . . . . . . . . . . . . . . . 41
7.2. Payload Types. . . . . . . . . . . . . . . . . . . . . . 42
7.3. New Name spaces. . . . . . . . . . . . . . . . . . . . . 42
7.4. UDP Port . . . . . . . . . . . . . . . . . . . . . . . . 42
8. Intellectual Property Rights Statement . . . . . . . . . . . . 42
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.1. Normative References . . . . . . . . . . . . . . . . . . 43
10.2. Informative References . . . . . . . . . . . . . . . . . 44
Appendix A: Alternate GDOI Phase 1 protocols . . . . . . . . . . . 46
A.1. IKEv2 Phase 1 protocol . . . . . . . . . . . . . . . . . 46
A.2. KINK Protocol. . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 481. Introduction ✨
Alright, so this doc introduces an ISAMKP Domain of Interpretation (DOI) for group key management, and it's called the "Group Domain of Interpretation" (GDOI) 🎀. In this model, the GDOI protocol runs between a group member and a "group controller/key server" (GCKS) 🗝️, and the GCKS establishes security associations [Section 4.6.2 RFC2401] among authorized group members 🫶. ISAKMP defines two "phases" of negotiation [p.16 RFC2408] 🧩. The GDOI MUST be protected by a Phase 1 security association 🔐. This document pulls in the Phase 1 security association (SA) definition from the Internet DOI [RFC2407, RFC2409] 📖. Other possible Phase 1 security association types are noted in Appendix A 🦋. The Phase 2 exchange is defined right here, and it proposes new payloads and exchanges following the ISAKMP standard [p. 14 RFC2408] 💅.
There are six new payloads 🌈:
- GDOI SA
- SA KEK (SAK) which follows the SA payload
- SA TEK (SAT) which follows the SA payload
- Key Download Array (KD)
- Sequence number (SEQ)
- Proof of Possession (POP)
There are two new exchanges 🍓.
- A Phase 2 exchange creates Re-key and Data-Security Protocol SAs.
Okay this one is giving: the new Phase 2 exchange, called "GROUPKEY-PULL," downloads keys for a group's "Re-key" SA and/or "Data-security" SA 🔑. The Re-key SA includes a key encrypting key, or KEK, that's common to the whole group 👑. A Data-security SA includes a data encryption key, or TEK, which a data-security protocol uses to encrypt or decrypt data traffic [Section 2.1 RFC2407] ✨. The SA for the KEK or TEK includes authentication keys, encryption keys, cryptographic policy, and attributes 🧚. GROUPKEY-PULL uses "pull" behavior because the member is the one who starts retrieving these SAs from a GCKS 🙈.
- A datagram subsequently establishes additional Rekey and/or Data-Security Protocol SAs.
The GROUPKEY-PUSH datagram gets "pushed" from the GCKS to the members to create or update a Re-key or Data-security SA 🚀. A Re-key SA protects GROUPKEY-PUSH messages 🛡️. So a GROUPKEY-PULL is necessary to establish at least one Re-key SA, which then protects the GROUPKEY-PUSH messages that come after 💜. The GCKS encrypts the GROUPKEY-PUSH message using the KEK Re-key SA 🔒. GDOI also accommodates arrays of KEKs for group key management algorithms that use the Logical Key Hierarchy (LKH) algorithm, which efficiently adds and removes group members [RFC2627] 🌸. Implementation of the LKH algorithm is OPTIONAL 🫧.
Although the GROUPKEY-PUSH specified by this document can refresh a Re-key SA, the most common use of GROUPKEY-PUSH is establishing a Data-security SA for a data security protocol 💖. GDOI can accommodate future extensions for a variety of data security protocols 🌈. This document only specifies data-security SAs for one security protocol, IPsec ESP 🎀. A separate RFC will specify support for other data security protocols, such as a future secure Real-time Transport Protocol 🦋. A security protocol uses the TEK and "owns" the data-security SA, the same way IPsec ESP uses the IKE Phase 2 keys and owns the Phase 2 SA. For GDOI, IPsec ESP uses the TEK 🧁.
So GDOI is a group security association management protocol: all GDOI messages are used to create, maintain, or delete security associations for a group ✨. As we covered above, these security associations protect one or more key-encrypting keys, traffic-encrypting keys, or data shared by group members for multicast and groups security applications 🫶.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] 📌.
1.1. GDOI Applications ✨
Okay so secure multicast apps are literally everywhere 🎬 think video broadcast and multicast file transfer! In a business setting a lot of these need network security and may use IPsec ESP to lock down their data traffic 🔐. Section 5.4.1 spells out how GDOI carries the SA parameters ESP needs. So GDOI supports multicast ESP with group authentication of ESP packets using the shared, group key (authentication of unique sources of ESP packets is not possible) 🫶
GDOI can also secure group apps that don't use multicast transport, like video-on-demand 📺 For example, the GROUPKEY-PUSH message may establish a pair-wise IPsec ESP SA for a member of a subscription group without the need for key management exchanges and costly asymmetric cryptography. No extra handshakes, no pricey asymmetric math, just vibes 💅
1.2. Extending GDOI
Not every secure multicast or multimedia app can use IPsec ESP 🙈 Lots of Real Time Transport Protocol apps, for example, need security above the IP layer so they keep their RTP header compression efficiencies and transport-independence [RFC3550]. A future RTP security protocol may benefit from using GDOI to establish group SAs 🦋
Now, if you want to add a brand new data security protocol, a new RFC MUST specify the data-security SA parameters conveyed by GDOI for that security protocol. These parameters are listed in section 5.4.2 of this document 📝
Data security protocol SAs MUST protect group traffic 🌸 GDOI doesn't restrict whether that group traffic goes out as unicast or multicast packets. However, GDOI MUST NOT be used as a key management mechanism by a data security protocol when the packets protected by the data-security SA are intended to be private and never become part of group communications. Not for private stuff, bestie 🚫
2. GDOI Phase 1 protocol ✨
Ok the big picture: GDOI is a "phase 2" protocol which MUST be protected by a "phase 1" protocol 🔒 The "phase 1" protocol can be any protocol which provides for the following protections:
- Peer Authentication
- Confidentiality
- Message Integrity
The following sections describe one such "phase 1" protocol. Other protocols which may be potential "phase 1" protocols are described in Appendix A. However, the use of the protocols listed there are not considered part of this document 🧚
2.1. ISAKMP Phase 1 protocol
This document defines how the ISAKMP phase 1 exchanges as defined in [RFC2409] can be used a "phase 1" protocol for GDOI. The following sections define characteristics of the ISAKMP phase 1 protocols that are unique for these exchanges when used for GDOI 💜
Section 6.1 describes how the ISAKMP Phase 1 protocols meet the requirements of a GDOI "phase 1" protocol ⭐
2.1.1. DOI value
The Phase 1 SA payload has a DOI value. That value MUST be the GDOI DOI value as defined later in this document 🎀
2.1.2. UDP port
GDOI MUST NOT run on port 500 (the port commonly used for IKE) 🙅 IANA has assigned port 848 for the use of GDOI 🍓
3. GROUPKEY-PULL Exchange 🌈
The goal of the GROUPKEY-PULL exchange is to establish a Re-key and/or Data-security SAs at the member for a particular group 👑 A Phase 1 SA protects the GROUPKEY-PULL; there MAY be multiple GROUPKEY-PULL exchanges for a given Phase 1 SA. The GROUPKEY-PULL exchange downloads the data security keys (TEKs) and/or group key encrypting key (KEK) or KEK array under the protection of the Phase 1 SA 🔑
3.1. Authorization
There are two alternative means for authorizing the GROUPKEY-PULL message 🪪 First, the Phase 1 identity can be used to authorize the Phase 2 (GROUPKEY-PULL) request for a group key. Second, a new identity can be passed in the GROUPKEY-PULL request. The new identity could be specific to the group and use a certificate that is signed by the group owner to identify the holder as an authorized group member. The Proof-of-Possession payload validates that the holder possesses the secret key associated with the Phase 2 identity ✨
3.2. Messages
The GROUPKEY-PULL is a Phase 2 exchange. Phase 1 computes SKEYID_a which is the "key" in the keyed hash used in the GROUPKEY-PULL HASH payloads. When using the Phase 1 defined in this document, SKEYID_a is derived according to [RFC2409]. As with the IKE HASH payload generation [RFC 2409 section 5.5], each GROUPKEY-PULL message hashes a uniquely defined set of values. Nonces permute the HASH and provide some protection against replay attacks. Replay protection is important to protect the GCKS from attacks that a key management server will attract 🛡️
The GROUPKEY-PULL uses nonces to guarantee "liveliness", or against replay of a recent GROUPKEY-PULL message. The replay attack is only useful in the context of the current Phase 1. If a GROUPKEY-PULL message is replayed based on a previous Phase 1, the HASH calculation will fail due to a wrong SKEYID_a. The message will fail processing before the nonce is ever evaluated. In order for either peer to get the benefit of the replay protection, it must postpone as much processing as possible until it receives the message in the protocol that proves the peer is live. For example, the Responder MUST NOT compute the shared Diffie-Hellman number (if KE payloads were included) or install the new SAs until it receives a message with Nr included properly in the HASH payload 🙅♀️
Nonces require an additional message in the protocol exchange to ensure that the GCKS does not add a group member until it proves liveliness 💖 The GROUPKEY-PULL member-initiator expects to find its nonce, Ni, in the HASH of a returned message. And the GROUPKEY-PULL GKCS responder expects to see its nonce, Nr, in the HASH of a returned message before providing group-keying material as in the following exchange 🔄
Initiator (Member) Responder (GCKS)
------------------ ----------------
HDR*, HASH(1), Ni, ID -->
<-- HDR*, HASH(2), Nr, SA
HDR*, HASH(3) [,KE_I] -->
[,CERT] [,POP_I]
<-- HDR*, HASH(4),[KE_R,][SEQ,]
KD [,CERT] [,POP_R]Hashes are computed as follows:
HASH(1) = prf(SKEYID_a, M-ID | Ni | ID)
HASH(2) = prf(SKEYID_a, M-ID | Ni_b | Nr | SA)
HASH(3) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_I ] [ | CERT ]
[ | POP_I ])
HASH(4) = prf(SKEYID_a, M-ID | Ni_b | Nr_b [ | KE_R ] [ | SEQ | ]
KD [ | CERT ] [ | POP_R])
POP payload is constructed as described in Section 5.7.
* Protected by the Phase 1 SA, encryption occurs after HDRHDR is an ISAKMP header payload that uses the Phase 1 cookies and a message identifier (M-ID) as in IKE [RFC2409]. Note that nonces are included in the first two exchanges, with the GCKS returning only the SA policy payload before liveliness is proven. The HASH payloads [RFC2409] prove that the peer has the Phase 1 secret (SKEYID_a) and the nonce for the exchange identified by message id, M-ID. Once liveliness is established, the last message completes the real processing of downloading the KD payload 🎉
In addition to the Nonce and HASH payloads, the member-initiator identifies the group it wishes to join through the ISAKMP ID payload. The GCKS responder informs the member of the current value of the sequence number in the SEQ payload; the sequence number orders the GROUPKEY-PUSH datagrams (section 4). The member MUST check to see that the sequence number is greater than in the previous SEQ payload the member holds for the group (if it holds any) before installing any new SAs 🔢 The SEQ payload MUST be present if the SA payload contains an SA KEK attribute. The GCKS responder informs the member of the cryptographic policies of the group in the SA payload, which describes the DOI, KEK and/or TEK keying material, and authentication transforms. The SPIs are also determined by the GCKS and downloaded in the SA payload chain (see section 5.2). The SA KEK attribute contains the ISAKMP cookie pair for the Re-key SA, which is not negotiated but downloaded. The SA TEK attribute contains an SPI as defined in section 5.4 of this document. The second message downloads this SA payload. If a Re-key SA is defined in the SA payload, then KD will contain the KEK; if one or more Data-security SAs are defined in the SA payload, KD will contain the TEKs. This is useful if there is an initial set of TEKs for the particular group and can obviate the need for future TEK GROUPKEY-PUSH messages (described in section 4) 🌟
As described above, the member may establish an identity in the GROUPKEY-PULL exchange in an optional CERT payload that is separate from the Phase 1 identity. When the member passes a new CERT, a proof of possession (POP) payload accompanies it. The POP payload demonstrates that the member or GCKS has used the very secret that authenticates it. POP_I is an ISAKMP SIG payload containing a hash including the nonces Ni and Nr signed by the member, when the member passes a CERT, signed by the Group Owner to prove its authorization. POP_R contains the hash including the concatenated nonces Ni and Nr signed by the GCKS, when the GCKS passes a CERT, signed by the group owner, to prove its authority to provide keys for a particular group. The use of the nonce pair for the POP payload, transformed through a pseudo-random function (prf) and encrypted, is designed to withstand compromise of the Phase 1 key. Implementation of the CERT and POP payloads is OPTIONAL 🎀
3.2.1. Perfect Forward Secrecy
If PFS is desired and the optional KE payload is used in the exchange, then both sides compute a DH secret and use it to protect the new keying material contained in KD. The GCKS responder will xor the DH secret with the KD payload and send it to the member Initiator, which recovers the KD by repeating this operation as in the Oakley IEXTKEY procedure [RFC2412]. Implementation of the KE payload is OPTIONAL 🦋
3.2.2. ISAKMP Header Initialization
Cookies are used in the ISAKMP header as a weak form of denial of service protection 🍪 The GDOI GROUPKEY-PULL exchange uses cookies according to ISAKMP [RFC2408].
Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0).
Major Version is 1 and Minor Version is 0 according to ISAKMP [RFC2408, Section 3.1].
The Exchange Type has value 32 for the GDOI GROUPKEY-PULL exchange.
Flags, Message ID, and Length are according to ISAKMP [RFC2408, Section 3.1]
3.3. Initiator Operations
okay so before a group member (the GDOI initiator) even contacts the GCKS, they must figure out the group identifier and an acceptable Phase 1 policy 🗝️. The way to do that is an out-of-band method, like SDP. Phase 1 kicks off using the GDOI DOI in the SA payload, and once it's done, the initiator's state machine moves over to the GDOI protocol. main character energy 💅
To build the first GDOI message, the initiator picks Ni and makes a nonce payload, builds an identity payload with the group identifier in it, and generates HASH(1). ✨
When the second GDOI message shows up, the initiator checks HASH(2), pulls out the nonce Nr, and reads the SA payload. If the policy there is acceptable (for example, the security protocol and cryptographic protocols can be supported by the initiator), the initiator keeps going. 🫶
If the group policy uses certificates for authorization, the initiator makes a hash that includes Ni and Nr and signs it. That signed hash becomes the contents of the POP payload. If it's needed, the initiator also builds a CERT payload holding the public key that matches the private key used to sign the POP payload. 🔐
The initiator then builds the third GDOI message by including the CERT and POP payloads (if needed) and creating HASH(3). 🎀
When the fourth GDOI message arrives, the initiator validates HASH(4). If the responder sent CERT and POP_R payloads, the POP signature gets validated too. 🌸
If an SEQ payload is present, the sequence number in it must be checked against any sequence number previously received for this group. If it's less than the previously received number, it should be considered stale and ignored. 🙈 This could happen if two GROUPKEY-PULL messages ran in parallel and the sequence number changed between the times the results of those two GROUPKEY-PULL messages came back from the GCKS. chaotic but valid 💀
The initiator reads the KD key packets and matches the SPIs in those packets to the SPIs it was previously sent in the SA payloads that identify particular policy. For TEKs, once the keys and policy match up, the initiator is ready to send or receive packets that match the TEK policy. (If policy and keys were already received for this TEK policy, the initiator may decide to ignore this TEK policy instead, in case it's stale.) And if this group has a KEK, the KEK policy and keys get marked as ready for use. 🦋
3.4. Receiver Operations
the GCKS (the responder) just sits there passively listening for incoming requests from group members 👂. Phase 1 is what authenticates the group member and sets up the secure session with them. 🔒
When the first GDOI message comes in, the GCKS validates HASH(1), pulls out Ni and the group identifier from the ID payload, and checks that its database actually has the group information for that group identifier. 🧐
Next, the GCKS builds the second GDOI message. That includes a nonce Nr, plus the policy for the group in an SA payload, followed by SA TEK payloads for traffic SAs, and an SA KEK policy (if the group controller is going to send Re-key messages to the group). 🍓
When the third GDOI message arrives, the GCKS validates HASH(3). If the initiator sent CERT and POP_I payloads, the POP signature gets validated. 🫧
Last but not least, the GCKS builds the fourth GDOI message. It includes the SEQ payload (if the GCKS sends rekey messages), the KD payload containing keys that match the policy previously sent in the SA TEK and SA KEK payloads, and the CERT and POP payloads (if needed). 👑
4. GROUPKEY-PUSH Message
GDOI sends control information securely using group communications 📡. Usually that means IP multicast distribution of a GROUPKEY-PUSH message, but it can also be "pushed" using unicast delivery if IP multicast isn't possible. The GROUPKEY-PUSH message replaces a Re-key SA KEK or KEK array, and/or creates a new Data-security SA. 🌈
Member GCKS or Delegate
------ ----------------
<---- HDR*, SEQ, SA, KD, [CERT,] SIG
* Protected by the Re-key SA KEK; encryption occurs after HDRHDR is defined below. The SEQ payload is defined in the Payloads section. The SA defines the policy (for example, the protection suite) and attributes (for example, the SPI) for Re-key and/or Data-security SAs. The GCKS or delegate can optionally provide a CERT payload so the SIG can be verified. KD is the key download payload, described in the Payloads section. 🧁
The SIG payload is a signature of a hash of the entire message before encryption (including the header and excluding the SIG payload itself), prefixed with the string "rekey". That prefix makes sure the signature on the Rekey datagram can't be used for any other purpose in the GDOI protocol. 🔏
If the SA defines an LKH KEK array or a single KEK, KD contains a KEK or KEK array for a new Re-key SA, which has a new cookie pair. When the KD payload carries a new SA KEK attribute (section 5.3), a Re-key SA gets replaced with a new SA that has the same group identifier (the ID specified in message 1 of section 3.2) and an incremented version of the same sequence counter, which was initialized in message 4 of section 3.2. If the SA defines an SA TEK payload, that tells the member a new Data-security SA has been created, with the keying material carried in KD (Section 5.5). 🗝️✨
If the SA defines a large LKH KEK array (for example, during group initialization and batched rekeying), parts of the array MAY be sent in different unique GROUPKEY-PUSH datagrams. However, each of the GROUPKEY-PUSH datagrams MUST be a fully formed GROUPKEY-PUSH datagram. This means each datagram carries a sequence number and the policy in the SA payload that corresponds to the KEK array portion sent in the KD payload. 🧩
4.1. Perfect Forward Secrecy (PFS)
The GROUPKEY-PUSH message is protected by the group KEK, though in all cases the GROUPKEY-PUSH message carries new key downloads, among other information. A freshly generated secret has to protect the key download for the GROUPKEY-PUSH message to have PFS. This issue is for further study. 🔮
4.2. Forward and Backward Access Control
Through GROUPKEY-PUSH, GDOI supports algorithms such as LKH that have the property of denying access to a new group key by a member removed from the group (forward access control), and to an old group key by a member added to the group (backward access control). This is an unrelated notion to PFS. "Forward access control" and "backward access control" have been called "perfect forward security" and "perfect backward security" in the literature [RFC2627]. 📚
Group management algorithms that provide forward and backward access control other than LKH have been proposed in the literature, including OFT [OFT] and Subset Difference [NNL]. These algorithms could be used with GDOI, but they aren't specified as part of this document. 🤷♀️
Support for group management algorithms is provided via the KEY_MANAGEMENT_ALGORITHM attribute, which is sent in the SA_KEK payload. GDOI specifies one method by which LKH can be used for forward and backward access control. Other methods of using LKH, as well as other group management algorithms such as OFT or Subset Difference, may be added to GDOI as part of a later document. Any such addition MUST be due to a Standards Action as defined in [RFC2434]. 🧾
4.2.1. Forward Access Control Requirements
When group membership is altered using a group management algorithm, new SA_TEKs (and their associated keys) are usually needed too. New SAs and keys make sure that members who were denied access can no longer participate in the group. 🚫
If forward access control is a desired property of the group, new SA_TEKs and the associated key packets in the KD payload MUST NOT be included in a GROUPKEY-PUSH message that changes group membership. This is required because the SA_TEK policy and the associated key packets in the KD payload are not protected with the new KEK. A second GROUPKEY-PUSH message can deliver the new SA_TEKS and their associated keys, because it will be protected with the new KEK, and so it won't be visible to the members who were denied access. 🔐
If the forward access control policy for the group includes keeping group policy changes away from members who are denied access to the group, then two sequential GROUPKEY-PUSH messages that change the group KEK MUST be sent by the GCKS. The first GROUPKEY-PUSH message creates a new KEK for the group. Group members who are denied access won't be able to access the new KEK, but they will see the group policy, since the GROUPKEY-PUSH message is protected under the current KEK. A subsequent GROUPKEY-PUSH message that contains the changed group policy and again changes the KEK allows complete forward access control. A GROUPKEY-PUSH message MUST NOT change the policy without creating a new KEK. 💅
If other methods of using LKH or other group management algorithms are added to GDOI, those methods MAY remove the above restrictions requiring multiple GROUPKEY-PUSH messages, provided those methods specify how forward access control policy is maintained within a single GROUPKEY-PUSH message. ⚠️
4.3. Delegation of Key Management
GDOI supports delegation of GROUPKEY-PUSH datagrams through the delegation capabilities of the PKI. However, GDOI doesn't explicitly specify how the GCKS identifies delegates. That's left to the PKI used by a particular GDOI implementation. 🧚
4.4. Use of signature keys
The GCKS SHOULD NOT use the same key to sign the SIG payload in the GROUPKEY-PUSH message that was used for authorization in the GROUPKEY-PULL POP payload. If the same key must be used, a different hash function SHOULD be used as the base for the POP payload than is used as the base for the SIG payload. 🔑
4.5. ISAKMP Header Initialization
Unlike ISAKMP or IKE, the cookie pair is completely determined by the GCKS. The cookie pair in the GDOI ISAKMP header identifies the Re-key SA, which is how the secure groups managed by a GCKS get told apart. So GDOI uses the cookie fields as an SPI. 🍪
Next Payload identifies an ISAKMP or GDOI payload (see Section 5.0). 🧾
Major Version is 1 and Minor Version is 0, according to ISAKMP [RFC2408, Section 3.1]. 🔢
The Exchange Type has value 33 for the GDOI GROUPKEY-PUSH message. 🎯
Flags MUST have the Encryption bit set, according to [RFC2008, Section 3.1]. All other bits MUST be set to zero. 🚩
Message ID MUST be set to zero. 0️⃣
Length is according to ISAKMP [RFC2408, Section 3.1]. 📏
4.6. Deletion of SAs
Every now and then the GCKS may want to signal to receivers that they should delete SAs, for example at the end of a broadcast. 🧹 Deleting keys can be done by sending an ISAKMP Delete payload [RFC2408, Section 3.15] as part of a GDOI GROUPKEY-PUSH message.
One or more Delete payloads MAY be placed following the SEQ payload in a GROUPKEY-PUSH message. If a GCKS has no further SAs to send to group members, the SA and KD payloads MUST be omitted from the message. 🫥
The following fields of the Delete payload are further defined as follows:
- The
Domain of Interpretationfield contains the GDOI DOI. 🌍 - The
Protocol-Idfield contains TEK protocol id values defined in Section 5.4 of this document. To delete a KEK SA, the value of zero MUST be used as the protocol id. Note that only one protocol id value can be defined in a Delete payload. If a TEK SA and a KEK SA must be deleted, they must be sent in different Delete payloads. 💖
4.7. GCKS Operations ✨
Okay so the GCKS (or its delegate) can kick off a Rekey message for a few reasons, like the group membership changed or the keys are about to expire. ⏰
To start the rekey datagram, the GCKS builds an ISAKMP HDR with the correct cookie pair, plus a SEQ payload whose sequence number is one greater than the previous rekey datagram. 🔢
Next up is the SA payload. It's identical in structure and meaning to the SA payload in a GROUPKEY-PULL exchange, so no surprises there 💅. If the KEK changes (for a static KEK) or the group membership changes (for LKH), an SA_KEK attribute gets added. If there are one or more new TEKs, SA_TEK attributes get added to describe that policy. 🦋
Then comes the KD payload, which is also identical in structure and meaning to the KD payload from GROUPKEY-PULL. If an SA_KEK attribute was in the SA payload, the matching KEK keys (or a KEK array) go in here too. TEK keys get sent for each SA_TEK attribute in the SA payload. 🔑
A CERT payload is added if the initiator needs to provide its certificate. 📜
In the penultimate step, the initiator hashes the string "rekey" followed by the key management message that's already been formed. That hash gets signed, placed in a SIG payload, and added to the datagram. ✍️
Last but not least, every payload after the HDR gets encrypted using the current KEK encryption key. 🔐 Once that's done, the datagram is ready to go! 🚀
4.8. Group Member Operations 🫶
Okay bestie, when a group member gets a GROUPKEY-PUSH datagram, it first matches the cookie pair in the ISAKMP HDR to an existing SA. Then it decrypts the message and checks that the form of the datagram is valid. This weeds out the obviously ill-formed messages, which might get sent as part of a Denial of Service attack on the group. 🛡️
Next, the signature of the decrypted message gets validated, possibly using the CERT payload if one is included. 🕵️♀️
The sequence number in the SEQ payload also gets checked. It has to be greater than the previously received sequence number, and it has to fit within a window of acceptable values. 🔢
Finally, the SA and KD payloads get processed. This can result in a new GDOI Rekey SA (if the SA payload included an SA_KEK attribute) and/or new IPsec SAs being added to the system. 🎉
5. Payloads and Defined Values 🎀
This document uses several ISAKMP payloads, which are defined in accordance with RFC2408. The following payloads are extended or further specified. 💜
Next Payload Type Value
----------------- -----
Security Association (SA) 1
Identification (ID) 5
Nonce (N) 10Several new payload formats are required in the group security exchanges. 🌈
Next Payload Type Value
----------------- -----
SA KEK Payload (SAK) 15
SA TEK Payload (SAT) 16
Key Download (KD) 17
Sequence Number (SEQ) 18
Proof of Possession (POP) 195.1. Identification Payload 🪪
The Identification Payload is used to identify a group identity that will later be associated with Security Associations for the group. A group identity may map to a specific IP multicast group, or it may be a more general identifier, like one that represents a set of related multicast streams. 📡
The Identification Payload is defined like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! ID Type ! RESERVE2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's what each Identification Payload field does:
Next Payload(1 octet) -- Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, this field will be zero (0).RESERVED(1 octet) -- Unused, must be zero (0).Payload Length(2 octets) -- Length, in octets, of the identification data, including the generic header.Identification Type(1 octet) -- Value describing the identity information found in the Identification Data field.RESERVED2(2 octets) -- Unused, must be zero (0).Identification Data(variable length) -- Value, as indicated by the Identification Type.
5.1.1. Identification Type Values 🔤
The following table lists the assigned values for the Identification Type field found in the Identification Payload. 📋
ID Type Value
------- -----
RESERVED 0 - 10
ID_KEY_ID 11
RESERVED 12 - 127
Private Use 128 - 2555.1.1.1. ID_KEY_ID 🗝️
In the context of a GDOI ID payload, ID_KEY_ID specifies a four (4)-octet group identifier. 💖
5.2. Security Association Payload 💼
The Security Association payload is defined in RFC 2408. For the GDOI, the GCKS uses it to assert security attributes for both Re-key and Data-security SAs. ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! DOI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Situation !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SA Attribute Next Payload ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!Here's what each Security Association Payload field does:
Next Payload(1 octet) -- Identifies the next payload for the GROUPKEY-PULL or the GROUPKEY-PUSH message as defined above. The next payload MUST NOT be a SAK Payload or SAT Payload type, but the next non-Security Association type payload. 🚫RESERVED(1 octet) -- must be zero.Payload Length(2 octets) -- Is the octet length of the current payload including the generic header and all TEK and KEK payloads.DOI(4 octets) -- Is the GDOI, which is value 2.Situation(4 octets) -- must be zero.SA Attribute Next Payload(1 octet) -- must be either a SAK Payload or a SAT Payload. See section 5.2.1 for a description of which circumstances are required for each payload type to be present.RESERVED(2 octets) -- must be zero.
5.2.1. Payloads following the SA payload 🧩
Payloads that define specific security association attributes for the KEK and/or TEKs used by the group MUST follow the SA payload. How many of each payload there are depends on the group policy. There may be zero or one SAK Payloads, and zero or more SAT Payloads, where either one SAK or SAT payload MUST be present. 🎯
This flexibility lets all sorts of group policies work. For example, if the group policy doesn't require a Re-key SA, the GCKS wouldn't need to send an SA KEK attribute to the group member, since all SA updates would be done using the Registration SA. 🙌 Or, group policy might use a Re-key SA but only download a KEK to the group member as part of the Registration SA. In that case, the KEK policy (in the SA KEK attribute) wouldn't be needed in the SA payload of the Re-key SA message. 💅
Specifying multiple SATs lets multiple sessions be part of the same group, and lets multiple streams be associated with one session (like video, audio, and text). Each one gets its own individual security association policy. 🎬🎧📝
5.3. SA KEK payload 🔐✨
okay so the SA KEK (SAK) payload is where the group's security attributes for the KEK method live, plus the parameters for the GROUPKEY-PULL operation 💅 the source and destination identities describe who's talking in the GROUPKEY-PULL datagram 🫶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol ! SRC ID Type ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! !
~ SPI ~
! !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! POP Algorithm ! POP Key Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ KEK Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!Here's the SAK payload field rundown 🧚
Next Payload(1 octet) -- Identifies the next payload for the GROUPKEY-PULL or the GROUPKEY-PUSH message. The only valid next payload types for this message are a SAT Payload or zero to indicate there is no SA TEK payload.RESERVED(1 octet) -- Must be zero.Payload Length(2 octets) -- Length of this payload, including the KEK attributes.Protocol(1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP) for the rekey datagram.SRC ID Type(1 octet) -- Value describing the identity information found in the SRC Identification Data field. Defined values are specified by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG].SRC ID Port(2 octets) -- Value specifying a port associated with the source Id. A value of zero means that the SRC ID Port field should be ignored.SRC ID Data Len(1 octet) -- Value specifying the length of the SRC Identification Data field.SRC Identification Data(variable length) -- Value, as indicated by the SRC ID Type.DST ID Type(1 octet) -- Value describing the identity information found in the DST Identification Data field. Defined values are specified by the IPSEC Identification Type section in the IANA isakmpd-registry [ISAKMP-REG].DST ID Prot(1 octet) -- Value describing an IP protocol ID (e.g., UDP/TCP).DST ID Port(2 octets) -- Value specifying a port associated with the source Id.DST ID Data Len(1 octet) -- Value specifying the length of the DST Identification Data field.DST Identification Data(variable length) -- Value, as indicated by the DST ID Type.SPI(16 octets) -- Security Parameter Index for the KEK. The SPI must be the ISAKMP Header cookie pair where the first 8 octets become the "Initiator Cookie" field of the GROUPKEY-PUSH message ISAKMP HDR, and the second 8 octets become the "Responder Cookie" in the same HDR. As described above, these cookies are assigned by the GCKS.POP Algorithm(2 octets) -- The POP payload algorithm. Defined values are specified in the following table. If no POP algorithm is defined by the KEK policy this field must be zero.
Algorithm Type Value
-------------- -----
RESERVED 0
POP_ALG_RSA 1
POP_ALG_DSS 2
POP_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255POP Key Length(2 octets) -- Length of the POP payload key. If no POP algorithm is defined in the KEK policy, this field must be zero.KEK Attributes-- Contains KEK policy attributes associated with the group. The following sections describe the possible attributes. Any or all attributes may be optional, depending on the group policy.
5.3.1. KEK Attributes 🎀
these attributes may show up in a SAK Payload 💖 they have to follow the format defined in ISAKMP [RFC2408] section 3.3. in the table, attributes defined as TV are marked Basic (B), and attributes defined as TLV are marked Variable (V) 🌸
ID Class Value Type
-------- ----- ----
RESERVED 0
KEK_MANAGEMENT_ALGORITHM 1 B
KEK_ALGORITHM 2 B
KEK_KEY_LENGTH 3 B
KEK_KEY_LIFETIME 4 V
SIG_HASH_ALGORITHM 5 B
SIG_ALGORITHM 6 B
SIG_KEY_LENGTH 7 B
KE_OAKLEY_GROUP 8 Bthe following attributes may only be included in a GROUPKEY-PULL message: KEK_MANAGEMENT_ALGORITHM, KE_OAKLEY_GROUP 🧚
5.3.2. KEK_MANAGEMENT_ALGORITHM 🔑
the KEK_MANAGEMENT_ALGORITHM class picks the group KEK management algorithm used to provide forward or backward access control, aka the thing used to kick group members out 🙈 defined values are in the table below.
KEK Management Type Value
------------------- -----
RESERVED 0
LKH 1
RESERVED 2-127
Private Use 128-2555.3.3. KEK_ALGORITHM 🍓
the KEK_ALGORITHM class specifies the encryption algorithm used with the KEK. defined values are in the table below.
Algorithm Type Value
-------------- -----
RESERVED 0
KEK_ALG_DES 1
KEK_ALG_3DES 2
KEK_ALG_AES 3
RESERVED 4-127
Private Use 128-255A GDOI implementation MUST support the KEK_ALG_3DES algorithm attribute. 🚨
if a KEK_MANAGEMENT_ALGORITHM is defined which defines multiple keys (e.g., LKH), and if the management algorithm does not specify the algorithm for those keys, then the algorithm defined by the KEK_ALGORITHM attribute MUST be used for all keys which are included as part of the management 🔥
5.3.3.1. KEK_ALG_DES 💜
this algorithm is DES using Cipher Block Chaining (CBC) mode, as described in [FIPS81] 🌈
5.3.3.2. KEK_ALG_3DES 🦋
this algorithm is 3DES using three independent keys, as described in "Keying Option 1" in [FIPS46-3] ✨
5.3.3.3. KEK_ALG_AES 👑
this algorithm is AES as described in [FIPS197]. the mode of operation for AES is Cipher Block Chaining (CBC), as recommended in [AES-MODES] 💅
5.3.4. KEK_KEY_LENGTH 🌸
the KEK_KEY_LENGTH class specifies the KEK Algorithm key length, in bits 🫶
5.3.5. KEK_KEY_LIFETIME ⏳
the KEK_KEY_LIFETIME class specifies the maximum time the KEK is valid for. the GCKS may refresh the KEK at any time before the end of the valid period 🦋 the value is a four (4) octet number defining a valid time period in seconds 🧚
5.3.6. SIG_HASH_ALGORITHM 🍓
SIG_HASH_ALGORITHM specifies the SIG payload hash algorithm. the following tables define the algorithms for SIG_HASH_ALGORITHM 💖
Algorithm Type Value
-------------- -----
RESERVED 0
SIG_HASH_MD5 1
SIG_HASH_SHA1 2
RESERVED 3-127
Private Use 128-255SIG_HASH_ALGORITHM is not required if the SIG_ALGORITHM is SIG_ALG_DSS or SIG_ALG_ECDSS, which imply SIG_HASH_SHA1 ✨
5.3.7. SIG_ALGORITHM 🔐
the SIG_ALGORITHM class specifies the SIG payload signature algorithm. defined values are in the table below.
Algorithm Type Value
-------------- -----
RESERVED 0
SIG_ALG_RSA 1
SIG_ALG_DSS 2
SIG_ALG_ECDSS 3
RESERVED 4-127
Private Use 128-255A GDOI implementation MUST support the following algorithm attribute: SIG_ALG_RSA. 🔥
5.3.7.1. SIG_ALG_RSA 💙
this algorithm is the RSA digital signature algorithm, as described in [RSA] 🌊
5.3.7.2. SIG_ALG_DSS 🌷
this algorithm is the DSS digital signature algorithm, as described in [FIPS186-2] 🎀
5.3.7.3. SIG_ALG_ECDSS 🧜
this algorithm is the Elliptic Curve digital signature algorithm, as described in [FIPS186-2] ⭐
5.3.8. SIG_KEY_LENGTH 🗝️
the SIG_KEY_LENGTH class specifies the length of the SIG payload key 💅
5.3.9. KE_OAKLEY_GROUP 👑
the KE_OAKLEY_GROUP class defines the OAKLEY Group used to compute the PFS secret in the optional KE payload of the GDOI GROUPKEY-PULL exchange. this attribute uses the values assigned to Group Definitions in the IANA IPsec-registry [IPSEC-REG] 🦋
5.4. SA TEK Payload ✨
okay bestie, the SA TEK (SAT) payload is basically the security attributes for ONE TEK tied to a group 🔐 that's the whole vibe 💜
Here's how the bits are laid out 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol-ID ! TEK Protocol-Specific Payload ~
+-+-+-+-+-+-+-+-+ ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!Now the SAT fields, one by one 💅
- Next Payload (1 octet): tells you what's coming next in the GROUPKEY-PULL or GROUPKEY-PUSH message 📬 The only things that can come next are another SAT Payload, or a zero, which means "that's all the attributes, bye" 👋
- RESERVED (1 octet): Must be zero.
- Payload Length (2 octets): how long this whole payload is, including the TEK Protocol-Specific Payload 📏
- Protocol-ID (1 octet): says which Security Protocol we're talking about. Here's the lineup 🦋
Protocol ID Value
----------- -----
RESERVED 0
GDOI_PROTO_IPSEC_ESP 1
RESERVED 2-127
Private Use 128-255- TEK Protocol-Specific Payload (variable): the stuff that describes the attributes specific to that Protocol-ID 🧚
5.4.1. PROTO_IPSEC_ESP
ESP gets its own little layout 🌸 Here it is.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Protocol ! SRC ID Type ! SRC ID Port !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
!SRC ID Data Len! SRC Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST ID Type ! DST ID Port !DST ID Data Len!
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! DST Identification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Transform ID ! SPI !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI ! RFC 2407 SA Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!And the field breakdown 🎀
- Protocol (1 octet): an IP protocol ID, like UDP or TCP 🌐 A value of zero means you can ignore this field.
- SRC ID Type (1 octet): says what kind of identity info is in the SRC Identification Data field. The defined values come from the IPSEC Identification Type section of the IANA isakmpd-registry [ISAKMP-REG].
- SRC ID Port (2 octets): a port tied to the source ID 🚪 Zero means ignore it.
- SRC ID Data Len (1 octet): how long the SRC Identification Data field is.
- SRC Identification Data (variable length): the value, depending on the SRC ID Type. For multiple-source multicast groups that use one common TEK for every sender, it's set to three bytes of zero 🫶
- DST ID Type (1 octet): says what kind of identity info is in the DST Identification Data field. Same registry as before, [ISAKMP-REG], IPSEC Identification Type section.
- DST ID Prot (1 octet): an IP protocol ID, like UDP or TCP. A value of zero means you can ignore the DST Id Prot field.
- DST ID Port (2 octets): a port tied to the source ID (yes, the original says "source Id" here, it's giving copy-paste 😭). Zero means ignore the DST ID Port field.
- DST ID Data Len (1 octet): how long the DST Identification Data field is.
- DST Identification Data (variable length): the value, depending on the DST ID Type.
- Transform ID (1 octet): picks which ESP transform gets used 🔥 The list of valid values lives in the IPSEC ESP Transform Identifiers section of the IANA isakmpd-registry [ISAKMP-REG].
- SPI (4 octets): the Security Parameter Index for ESP 🧚
- RFC 2407 Attributes: the ESP Attributes from RFC 2407 Section 4.5 💖 GDOI supports every IPSEC DOI SA Attribute for PROTO_IPSEC_ESP, except the Group Description [RFC2407, section 4.5]. That one MUST NOT be sent by a GDOI implementation, and if one shows up, the GDOI implementation ignores it ❌ All mandatory IPSEC DOI attributes are mandatory in GDOI PROTO_IPSEC_ESP. And the Authentication Algorithm attribute of the IPSEC DOI means group authentication in GDOI 🔐
5.4.2. Other Security Protocols
Besides ESP, GDOI should serve to set up SAs for secure groups that other Security Protocols need, the ones working at the transport, application, and internetwork layers 🦋 Those other protocols are still being built, or they don't exist yet 🚧
To hand a Security Protocol over to GDOI, these are the things it needs to provide 🫶
- The Protocol-ID for the particular Security Protocol
- The SPI Size
- The method of SPI generation
- The transforms, attributes and keys needed by the Security Protocol
Every Security Protocol has to supply the bulleted list above, so the GDOI spec for that protocol knows what's up 📝 Definitions for supporting those Security Protocols in GDOI will be written up in separate documents 📄
A Security Protocol MAY protect traffic at any level of the network stack. However, in all cases applications of the Security Protocol MUST protect traffic which MAY be shared by more than two entities. Not optional, bestie 🚨
5.5. Key Download Payload 🔑
The Key Download Payload carries the group keys for the group named in the SA Payload 💜 It can have several security attributes applied to it, depending on the group's security policy, as defined by the associated SA Payload 🌈
When it's part of the Re-key SA with an optional KE payload, the Key Download Payload gets xor'ed with the new Diffie-Hellman shared secret 💅 The xor operation starts at the "Number of Key Packets" field ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! Number of Key Packets ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Packets ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!The Key Download Payload fields, in order 🎀
- Next Payload (1 octet): identifies the payload type of the next payload in the message. If the current payload is the last one in the message, this field is zero.
- RESERVED (1 octet): unused, set to zero.
- Payload Length (2 octets): how many octets the current payload is, including the generic payload header 📏
- Number of Key Packets (2 octets): the total number of TEK and Rekey arrays passed in this data block 📦
- Key Packets: several kinds of key packets are defined 🧩 Every Key Packet has the format below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! KD Type ! RESERVED ! KD Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
! SPI Size ! SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
~ Key Packet Attributes ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!The Key Packet fields 💖
- Key Download (KD) Type (1 octet): identifies the Key Data field of this Key Packet. Here are the values 👑
Key Download Type Value
----------------- -----
RESERVED 0
TEK 1
KEK 2
LKH 3
RESERVED 4-127
Private Use 128-255"KEK" is a single key, whereas LKH is an array of key-encrypting keys 🧠
- RESERVED (1 octet): unused, set to zero.
- Key Download Length (2 octets): how many octets the Key Packet data is, including the Key Packet header.
- SPI Size (1 octet): how long the SPI is in octets, as defined by the Protocol-Id.
- SPI (variable length): the Security Parameter Index, matching an SPI that was sent earlier in an SAK or SAT Payload 🔗
- Key Packet Attributes (variable length): the key info. Its format depends on the KD Type value, and the following sections describe the format for each KD Type 🌸
5.5.1. TEK Download Type
The TEK Download Type can carry the following attributes. Exactly one attribute matching each type sent in the SAT payload MUST be present 🚨 The attributes must follow the format defined in ISAKMP [RFC2408] section 3.3. In the table, attributes defined as TV are marked Basic (B), and attributes defined as TLV are marked Variable (V) 🦋
TEK Class Value Type
--------- ----- ----
RESERVED 0
TEK_ALGORITHM_KEY 1 V
TEK_INTEGRITY_KEY 2 V
TEK_SOURCE_AUTH_KEY 3 VIf no TEK key packets come in a Registration KD payload, the group member can expect to get the TEK as part of a Re-key SA 🔄 At least one TEK must be included in each Re-key KD payload. You can include multiple TEKs if multiple streams tied to the SA need rekeying 💜
5.5.1.1. TEK_ALGORITHM_KEY ✨
okay so TEK_ALGORITHM_KEY is the class that says the encryption key for this SPI is hiding inside the Key Packet Attribute 🔐 The algorithm that actually uses that key was already named in the SAT payload, so the two work together like a bestie duo 💖
if the algorithm needs more than one key (3DES, I'm looking at you 👀), all the keys go into one attribute together 🎀
DES keys are 64 bits (that's the 56 key bits plus the parity bit) 🌸 Triple DES keys are a single 192-bit attribute, parity bits included, and the keys are listed in the order they get used for encryption (DES_KEY1, DES_KEY2, DES_KEY3) 💅
5.5.1.2. TEK_INTEGRITY_KEY 🦋
TEK_INTEGRITY_KEY says the integrity key for this SPI is inside the Key Packet Attribute. The integrity algorithm that uses it was named in the SAT payload. So GDOI assumes both the symmetric encryption key and the integrity key get pushed to the member, which is giving full package energy 🎁 SHA keys are 160 bits and MD5 keys are 128 bits 🧚
5.5.1.3. TEK_SOURCE_AUTH_KEY 💜
TEK_SOURCE_AUTH_KEY means the source authentication key for this SPI is in the Key Packet Attribute. The source authentication algorithm that uses it was named in the SAT payload 🫶
5.5.2. KEK Download Type 🍓
A KEK Download Type can carry the following attributes. Exactly one attribute matching each type sent in the SAK payload MUST be present, no exceptions, bestie 😭 The attributes have to follow the format in section 3.3 of ISAKMP [RFC2408]. In the table below, TV-style attributes are marked Basic (B) and TLV-style attributes are marked Variable (V) 🌈
KEK Class Value Type
--------- ----- ----
RESERVED 0
KEK_ALGORITHM_KEY 1 V
SIG_ALGORITHM_KEY 2 VIf the KEK key packet is included, there MUST be only one present in the KD payload 👑
5.5.2.1. KEK_ALGORITHM_KEY 🔑
KEK_ALGORITHM_KEY says the encryption key for this SPI is in the Key Packet Attribute. The algorithm that uses it was named in the SAK payload 🌷
If the mode of operation needs an Initialization Vector (IV), an explicit IV MUST be included in the KEK_ALGORITHM_KEY before the actual key. The IV goes first, then the key, no skipping 🙈
5.5.2.2. SIG_ALGORITHM_KEY ✍️
SIG_ALGORITHM_KEY means the public key for this SPI is in the Key Packet Attribute. This can be really handy when there's no public key infrastructure around 🧡 The signature algorithm that uses it was named in the SAK payload ⭐
5.5.3. LKH Download Type 🌳
The LKH key packet is built out of attributes, and each one stands for a different leaf in the LKH key tree 🌲
The following attributes pass an LKH KEK array in the KD payload. They follow the format in section 3.3 of ISAKMP [RFC2408]. TV-style attributes are marked Basic (B) and TLV-style attributes are marked Variable (V) in the table 🧁
KEK Class Value Type
--------- ----- ----
RESERVED 0
LKH_DOWNLOAD_ARRAY 1 V
LKH_UPDATE_ARRAY 2 V
SIG_ALGORITHM_KEY 3 V
RESERVED 4-127
Private Use 128-255If an LKH key packet is included in the KD payload, there must be only one present 🫧
5.5.3.1. LKH_DOWNLOAD_ARRAY 📥
This attribute downloads a set of keys to a group member. It MUST NOT be included in a GROUPKEY-PUSH message KD payload if the GROUPKEY-PUSH is sent to more than the group member. Big rule, no exceptions 🚫 If an LKH_DOWNLOAD_ARRAY attribute is in a KD payload, there must be only one present 💖
This attribute is a header block followed by one or more LKH keys 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Version ! # of LKH Keys ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Keys !
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The KEK_LKH attribute fields work like this:
- LKH version (1 octet): the version of the LKH protocol the data is formatted in. It must be one.
- Number of LKH Keys (2 octets): how many distinct LKH keys are in this sequence.
- RESERVED (1 octet): unused, set to zero.
Each LKH Key looks like this 🧩
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH ID ! Key Type ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Creation Date !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key expiration Date !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Key Handle !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! !
~ Key Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The fields inside each LKH Key:
- LKH ID (2 octets): this is the position of this key in the binary tree structure LKH uses.
- Key Type (1 octet): the encryption algorithm this key data is for. The value is specified in Section 5.3.3.
- RESERVED (1 octet): unused, set to zero.
- Key Creation Date (4 octets): when this key data was originally generated. A time value of zero means there's no earlier time before which the key isn't valid.
- Key Expiration Date (4 octets): when this key stops being valid for use. A time value of zero means the key has no expiration time.
- Key Handle (4 octets): a randomly generated value that uniquely identifies a key within an LKH ID.
- Key Data (variable length): the actual key data. Its format depends on the algorithm named by Key Type. If the mode of operation needs an Initialization Vector (IV), an explicit IV MUST be included in the Key Data field before the actual key ✨
The Key Creation Date and Key Expiration Date MAY be zero. That's there for the case where time sync across the group isn't possible ⏰
The first LKH Key structure in an LKH_DOWNLOAD_ARRAY attribute holds the leaf identifier and the key for the group member 🍃 The rest of the LKH Key structures are the keys along the key tree path, in order starting from the leaf and ending with the group KEK 👑
5.5.3.2. LKH_UPDATE_ARRAY 🔄
This attribute updates the keys for a group. It's most likely to show up in a GROUPKEY-PUSH message KD payload, where it rekeys the entire group 🫶 It's a header block followed by one or more LKH keys, as defined in Section 5.5.3.1
There may be any number of UPDATE_ARRAY attributes in a KD payload 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Version ! # of LKH Keys ! RESERVED !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH ID ! RESERVED2 !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Key Handle !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! LKH Keys !
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The fields in this header:
- LKH version (1 octet): the version of the LKH protocol the data is formatted in. It must be one.
- Number of LKH Keys (2 octets): how many distinct LKH keys are in this sequence.
- RESERVED (1 octet): unused, set to zero.
- LKH ID (2 octets): the node identifier tied to the key used to encrypt the first LKH Key.
- RESERVED2 (2 octets): unused, set to zero.
- Key Handle (4 octets): the value that uniquely identifies the key within the LKH ID, which was used to encrypt the first LKH key.
The LKH Keys follow Section 5.5.3.1. They're the keys along the key tree path, in order starting from the LKH ID in the LKH_UPDATE_ARRAY header and ending with the group KEK 🌳 The Key Data field of each LKH Key is encrypted with the LKH key that comes right before it in the LKH_UPDATE_ARRAY attribute. The first LKH Key is encrypted under the key identified by the LKH ID and Key Handle in the LKH_UPDATE_ARRAY header 🔐
5.5.3.3. SIG_ALGORITHM_KEY 💅
SIG_ALGORITHM_KEY means the public key for this SPI is in the Key Packet Attribute. It can be useful when no public key infrastructure is available 🧚 The signature algorithm that uses this key was named in the SAK payload 🎀
5.6. Sequence Number Payload ✨
okay bestie, the Sequence Number Payload (SEQ) is giving anti-replay protection for GROUPKEY-PUSH messages 🛡️ and its whole energy is similar to the Sequence Number field in the IPsec ESP protocol [RFC2406] 💅
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sequence Number !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here's the tea on the fields 🫶
Next Payload(1 octet) -- the identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be zero.RESERVED(1 octet) -- unused, set to zero 🤍Payload Length(2 octets) -- the length in octets of the current payload, including the generic payload header 📏Sequence Number(4 octets) -- a monotonically increasing counter value for the group 🔢 It is initialized to zero by the GCKS, and incremented in each subsequently-transmitted message. So the first packet sent for a given Rekey SA will have a Sequence Number of 1. The GDOI implementation keeps a sequence counter as an attribute for the Rekey SA and increments the counter upon receipt of a GROUPKEY-PUSH message. The current value of the sequence number must be transmitted to group members as a part of the Registration SA SA payload. A group member must keep a sliding receive window. The window must be treated as in the ESP protocol [RFC2406] Section 3.4.3 🪟
5.7. Proof of Possession 🔐
the Proof of Possession Payload is used as part of group membership authorization during a GDOI exchange. It's identical to an ISAKMP SIG payload, but the usage is totally different, so no mixing them up 🙈
the GCKS, GCKS delegate or member signs a hash of the following values:
POP_HASH = hash("pop" | Ni | Nr)where hash() is the hash function used with the signature.
the "pop" prefix ensures that the signature of the POP payload cannot be used for any other purpose in the GDOI protocol 🔒✨
5.8. Nonce 🎲
the data portion of the Nonce payload (i.e., Ni_b and Nr_b included in the HASHs) MUST be a value between 8 and 128 bytes.
6. Security Considerations 🛡️😭
GDOI is a security association (SA) management protocol for groups of senders and receivers. Unlike a data security protocol, SA management includes a key establishment protocol to securely establish keys at communication endpoints. This protocol performs entity authentication of the GDOI member or Group Controller/Key Server (GCKS), it provides confidentiality of key management messages, and it provides source authentication of those messages. This protocol also uses best-known practices for defense against man-in-middle, connection hijacking, replay, reflection, and denial-of-service (DOS) attacks on unsecured networks [STS, RFC2522, SKEME]. GDOI assumes the network is not secure and may be under the complete control of an attacker 👀 yikes.
GDOI assumes that the host computer is secure even though the network is insecure. GDOI ultimately establishes keys among members of a group, which MUST be trusted to use those keys in an authorized manner according to group policy. The security of GDOI, therefore, is as good as the degree to which group members can be trusted to protect authenticators, encryption keys, decryption keys, and message authentication keys 🔑 no pressure, everyone.
There are three phases of GDOI as described in this document: an ISAKMP Phase 1 protocol, a new exchange called GROUPKEY-PULL which is protected by the ISAKMP Phase 1 protocol, and a new message called GROUPKEY-PUSH. Each phase is considered separately below 🧩
6.1. ISAKMP Phase 1 🏰
as described in this document, GDOI uses the Phase 1 exchanges defined in [RFC2409] to protect the GROUPKEY-PULL exchange. Therefore all security properties and considerations of those exchanges (as noted in [RFC2409]) are relevant for GDOI 📚
GDOI may inherit the problems of its ancestor protocols [FS00], such as identity exposure, absence of unidirectional authentication, or stateful cookies [PK01]. GDOI could benefit, however, from improvements to its ancestor protocols just as it benefits from years of experience and work embodied in those protocols. To reap the benefits of future IKE improvements, however, GDOI would need to be revised in a future standards-track RFC, which is beyond the scope of this specification 🌸
6.1.1. Authentication 🪪
authentication is provided via the mechanisms defined in [RFC2409], namely Pre-Shared Keys or Public Key encryption 🔏
6.1.2. Confidentiality 🤫
confidentiality is achieved in Phase 1 through a Diffie-Hellman exchange that provides keying material, and through negotiation of encryption transforms 💜
the Phase 1 protocol will be protecting encryption and integrity keys sent in the GROUPKEY-PULL protocol. The strength of the encryption used for Phase 1 SHOULD exceed that of the keys send in the GROUPKEY-PULL protocol 💪
6.1.3. Man-in-the-Middle Attack Protection 🕵️
a successful man-in-the-middle or connection-hijacking attack foils entity authentication of one or more of the communicating entities during key establishment. GDOI relies on Phase 1 authentication to defeat man-in-the-middle attacks 🚫
6.1.4. Replay/Reflection Attack Protection 🔁
in a replay/reflection attack, an attacker captures messages between GDOI entities and subsequently forwards them to a GDOI entity. Replay and reflection attacks seek to gain information from a subsequent GDOI message response or seek to disrupt the operation of a GDOI member or GCKS entity. GDOI relies on the Phase 1 nonce mechanism in combination with a hash-based message authentication code to protect against the replay or reflection of previous key management messages 🦋
6.1.5. Denial of Service Protection 🚨
a denial of service attacker sends messages to a GDOI entity to cause that entity to perform unneeded message authentication operations. GDOI uses the Phase 1 cookie mechanism to identify spurious messages prior to cryptographic hash processing. This is a "weak" form of denial of service protection in that the GDOI entity must check for good cookies, which can be successfully imitated by a sophisticated attacker. The Phase 1 cookie mechanism is stateful, and commits memory resources for cookies, but stateless cookies are a better defense against denial of service attacks 🍪
6.2. GROUPKEY-PULL Exchange 🙋
the GROUPKEY-PULL exchange allows a group member to request SAs and keys from a GCKS. It runs as a "phase 2" protocol under protection of the Phase 1 security association 🧚
6.2.1. Authentication 🪪
peer authentication is not required in the GROUPKEY-PULL protocol. It is running in the context of the Phase 1 protocol, which has previously authenticated the identity of the peer ✅
message authentication is provided by HASH payloads in each message, where the HASH is defined to be over SKEYID_a (derived in the Phase 1 exchange), the ISAKMP Message-ID, and all payloads in the message. Because only the two endpoints of the exchange know the SKEYID_a value, this provides confidence that the peer sent the message 💌
6.2.2. Confidentiality 🤐
confidentiality is provided by the Phase 1 security association, after the manner described in [RFC2409] 🫧
6.2.3. Man-in-the-Middle Attack Protection 🕵️♀️
message authentication (described above) includes a secret known only to the group member and GCKS when constructing a HASH payload. This prevents man-in-the-middle and connection-hijacking attacks because an attacker would not be able to change the message undetected 🙅♀️
6.2.4. Replay/Reflection Attack Protection 🔁
nonces provide freshness of the GROUPKEY-PULL exchange. The group member and GCKS exchange nonce values first two messages. These nonces are included in subsequent HASH payload calculations. The Group member and GCKS MUST NOT perform any computationally expensive tasks before receiving a HASH with its own nonce included. The GCKS MUST NOT update the group management state (e.g., LKH key tree) until it receives the third message in the exchange with a valid HASH payload including its own nonce 🌳
implementations SHOULD keep a record of recently received GROUPKEY-PULL messages and reject messages that have already been processed. This enables an early discard of the replayed messages 🗑️
6.2.5. Denial of Service Protection 🛡️
a GROUPKEY-PULL message identifies its messages using a cookie pair from the Phase 1 exchange that precedes it. The cookies provide a weak form of denial of service protection as described above, in the sense that a GROUPKEY-PULL message with invalid cookies will be discarded 🍪❌
the replay protection mechanisms described above provide the basis for denial of service protection 🧱
6.2.6. Authorization 📜
the CERT payload in a GROUPKEY-PULL exchange allows a group member or GCKS to submit a certificate containing authorization attributes to the peer as well as identifying a public/private key pair. The GROUPKEY-PULL POP payload enables authorization to be accomplished where the authorization infrastructure is different than the GROUPKEY-PULL authentication infrastructure by proving that it is in possession of the private key 🎟️
6.3. GROUPKEY-PUSH Exchange 📣
the GROUPKEY-PUSH exchange is a single message that allows a GCKS to send SAs and keys to group members. This is likely to be sent to all members using an IP multicast group. This provides an efficient rekey and group membership adjustment capability 🚀
6.3.1. Authentication 🖊️
the GROUPKEY-PULL exchange identifies a public key that is used for message authentication. The GROUPKEY-PUSH message is digitally signed using the corresponding private key held by the GCKS or its delegate. This digital signature provides source authentication for the message. Thus, GDOI protects the GCKS from impersonation in group environments 👑
6.3.2. Confidentiality 🤫
the GCKS encrypts the GROUPKEY-PUSH message with an encryption key that was established by the GROUPKEY-PULL exchange 🔐
6.3.3. Man-in-the-Middle Attack Protection 🕵️
this combination of confidentiality and message authentication services protects the GROUPKEY-PUSH message from man-in-middle and connection-hijacking attacks 🫶
6.3.4. Replay/Reflection Attack Protection 🔁
the GROUPKEY-PUSH message includes a monotonically increasing sequence number to protect against replay and reflection attacks. A group member will recognize a replayed message by comparing the sequence number to a sliding window, in the same manner as the ESP protocol uses sequence numbers 🪟
implementations SHOULD keep a record of recently received GROUPKEY-PUSH messages and reject duplicate messages. This enables an early discard of the replayed messages 💖
6.3.5. Denial of Service Protection 🛡️
okay so the cookie pair tells you which security association a GROUPKEY-PUSH message belongs to 🎀 That means the cookies act as a weak form of denial-of-service protection for the GROUPKEY-PUSH message. Not a bodyguard, but it helps 🫶
ngl the digital signature used for message authentication is way more expensive to compute than a message authentication code 😭 That cost could amplify a denial-of-service attack on GDOI members who process GROUPKEY-PUSH messages. But it's worth it, bestie, because we need to stop GCKS impersonation. If a shared symmetric key were used for GROUPKEY-PUSH message authentication, GCKS source authentication would be impossible, and any member could impersonate the GCKS 💀 Not it!
The good news is the group member controls the order of operations, and it does the least expensive cryptographic work first 💅 Here's the flow:
- The group member first decrypts the message using a symmetric cipher.
- If the message is validly formed, the sequence number is checked against the replay window.
- Only if the sequence number is valid is the digital signature verified.
So for a denial-of-service attack to actually work, an attacker would need to know both the symmetric encryption key used for confidentiality and a valid sequence number 🔥 Generally speaking, that means only current group members can effectively pull off a denial-of-service attack. Main character energy for the security design, honestly 👑
6.3.6. Forward Access Control 🦋
If a group management algorithm (such as LKH) is used, forward access control may not be ensured in some cases 😬 This can happen if some group members are denied access to the group in the same GROUPKEY-PUSH message that delivers new policy and TEKs to the group.
The fix is giving forward access control its own moment ✨ As discussed in Section 4.2.1, forward access control can be maintained by sending multiple GROUPKEY-PUSH messages, where the group membership changes are sent from the GCKS separately from the new policy and TEKs. Iconic 🌈
7. IANA Considerations 🌸
7.1. ISAKMP DOI
An ISAKMP DOI number is needed to identify an SA payload as a GDOI SA payload. The IANA has assigned the value 2 to represent GDOI 🍓
7.2. Payload Types
The present document defines new ISAKMP Next Payload types. See Section 5.0 for the payloads defined in this document, including the Next Payload values defined by the IANA to identify these payloads 🧚
7.3. New Name spaces
The present document describes many new name spaces for use in the GDOI payloads 📚 Those can be found in subsections under Section 5.0. A new GDOI registry has been created for these name spaces.
Portions of name spaces marked "RESERVED" are reserved for IANA allocation. New values MUST be added due to a Standards Action as defined in [RFC2434] 🔒 That part is non-negotiable, bestie.
Portions of name spaces marked "Private Use" may be allocated by implementations for their own purposes 💜
7.4. UDP Port
The IANA has assigned port 848 for use by GDOI 🎀
8. Intellectual Property Rights Statement 💼
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document. It also doesn't say whether any license under such rights might or might not be available, and it doesn't represent that it has made any effort to identify any such rights 🙈 Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication, 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 implementors or users of this specification, can be obtained from the IETF Secretariat 📬
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director 🫶
9. Acknowledgements 🙌
The authors thank Ran Canetti, Cathy Meadows, Andrea Colegrove, and Lakshminath Dondeti 💖 Ran advised the authors on secure group cryptography, which led to changes in the exchanges and payload definitions. Cathy identified several problems in previous versions of this document, including a replay attack against the proof of possession exchange, as well as several man-in-the-middle attacks 😭 Andrea contributed to the group policy section of this document. Lakshminath identified several protocol issues that needed further specification and helped to resolve them ✨
10. References 📖
10.1. Normative References
[AES-MODES] "Recommendation for Block Cipher Modes of Operation",
United States of American, National Institute of Science
and Technology, NIST Special Publication 800-38A 2001
Edition, December 2001.
[FIPS46-3] "Data Encryption Standard (DES)", United States of
American, National Institute of Science and Technology,
Federal Information Processing Standard (FIPS) 46-3,
October 1999.
[FIPS81] "DES Modes of Operation", United States of American,
National Institute of Science and Technology, Federal
Information Processing Standard (FIPS) 81, December
1980.
[FIPS186-2] "Digital Signature Standard (DSS)", United States of
American, National Institute of Science and Technology,
Federal Information Processing Standard (FIPS) 186-2,
January 2000.
[FIPS197] "Advanced Encryption Standard (AES)", United States of
American, National Institute of Science and Technology,
Federal Information Processing Standard (FIPS) 197,
November 2001.
[IPSEC-REG] http://www.iana.org/assignments/ipsec-registry
[ISAKMP-REG] http://www.iana.org/assignments/isakmp-registry
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2407] Piper, D., "The Internet IP Domain of Interpretation for
ISAKMP", RFC 2407, November 1998.
[RFC2408] Maughan, D., Shertler, M., Schneider, M. and J. Turner,
"Internet Security Association and Key Management
Protocol", RFC 2408, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key
Management Protocol", RFC 2522, March 1999.
[RFC2627] Wallner, D., Harder, E. and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627,
September 1998.
[RSA] RSA Laboratories, "PKCS #1 v2.0: RSA Encryption
Standard", October 1998.10.2. Informative References
[FS00] N. Ferguson and B. Schneier, "A Cryptographic Evaluation
of IPsec, CounterPane",
http://www.counterpane.com/ipsec.html.
[GKMARCH] M. Baugher, R. Canetti, L. Dondeti, F. Lindholm, "Group
Key Management Architecture", Work in Progress.
[IKEv2] D. Harkins, et. al., "Proposal for the IKEv2 protocol",
Work In Progress.
[KINK] M. Thomas, J. Vilhuber, "Kerberized Internet Negotiation
of Keys (KINK)", Work in Progress.
[NNL] D. Naor, M. Naor and J. Lotspiech, "Revocation and
Tracing Schemes for Stateless Receivers", Advances in
Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001,
pp. 41-62. A full version of the paper appears in
http://www.wisdom.weizmann.ac.il/~naor/.
[OFT] D. Mcgrew and A. Sherman, "Key Establishment in Large
Dynamic Groups Using One-Way Function Trees", Manuscript
submitted to IEEE Transactions on Software Engineering.
A full version of the paper
appears in http://download.nai.com/products/media/nai/
misc/oft052098.ps, 1998
[PK01] R.Perlman, C.Kaufman, "Analysis of the IPsec Key
Exchange Standard", WET-ICE conference, 2001.
http://sec.femto.org/wetice-2001/papers/radia-paper.pdf
[RFC2093] Harney, H., and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Specification," RFC 2093, July 1997.
[RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture," RFC 2094, July 1997.
[RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998.
[RFC3550] Schulzrinne, H., Casner, S., Jacobson, V. and R.
Frederick, "RTP: A Transport Protocol for Real-Time
Applications", RFC 3550, June 2003.
[SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", ISOC Secure Networks and
Distributed Systems Symposium, San Diego, 1996.
[STS] Diffie, P. van Oorschot, M. J. Wiener, "Authentication
and Authenticated Key Exchanges, Designs, Codes and
Cryptography", 2, 107-125 (1992), Kluwer Academic
Publishers.Appendix A: Alternate GDOI Phase 1 protocols 🔮
This section describes a manner in which other protocols could be used as GDOI Phase 1 protocols in place of the ISAKMP Phase 1 protocol. However, they are not specified as a part of this document. A separate document MUST be written in order for another protocol to be used as a GDOI Phase 1 protocol 📝
Other possible phase 1 protocols are also described in [GKMARCH].
Any GDOI phase 1 protocol MUST satisfy the requirements specified in Section 2 of this document ✅
A.1. IKEv2 Phase 1 protocol
Version 2 of the IKE protocol (IKEv2) is a work in progress [IKEv2] 🚧 That protocol seeks to simplify the IKE Phase 1 and Phase 2 protocols, and improve the security of the IKE protocol. An IKEv2 Phase 1 negotiates an IPSEC SA during phase 1, which was not possible in IKE. However, IKEv2 also defines a phase 2 protocol. The phase 2 protocol is protected by the Phase 1, similar in concept to how IKE Quick Mode is protected by the IKE Phase 1 protocols in [RFC2409] 🦋
IKEv2 may not include a DOI value in the SA payload. However, since GDOI uses a unique port, choice of a phase 2 protocol in the SA payload using a GDOI value is not necessary. It is expected that an IKEv2 Phase 1 protocol definition could be run on the GDOI port. The SA payload in the protocol would be specific to GDOI, or omitted if not needed at all 💜
The GROUPKEY-PULL protocol would follow the IKEv2 Phase 1 protocol in the same manner as described in this document ✨
A.2. KINK Protocol 🦋
okay so there's this work-in-progress doc, [KINK], that came up with a way to wrap an IKE Quick Mode [RFC2409] exchange inside Kerberos KRB_AP_REQ and KRB_AP_REP payloads 🧚 and honestly? It's giving efficiency. KINK is low-latency, computationally inexpensive, easy to manage, and cryptographically sound for setting up IPsec security associations 🔥
The KINK message format has a GDOI field sitting in the KINK header 💅 And the [KINK] document defines the DOI for the IPSEC DOI ✨
Now here's the lowkey genius part: a new DOI for KINK could be defined that wraps a GROUPKEY-PULL exchange inside those same KRB_AP_REQ and KRB_AP_REP payloads 🌈 So GDOI would get to borrow KINK's computational efficiencies. main character energy for GDOI, no cap 👑
Authors' Addresses 🌸
Mark Baugher 💜
Mark Baugher
Cisco Systems
5510 SW Orchid Street
Portland, OR 97219, USA
Phone: (503) 245-4543
EMail: mbaugher@cisco.comThomas Hardjono 💜
Thomas Hardjono
VeriSign
401 Edgewater Place, Suite 280
Wakefield, MA 01880
Phone: 781-245-6996
EMail: thardjono@verisign.comHugh Harney 💜
Hugh Harney
Sparta
9861 Broken Land Parkway
Columbia, MD 21046
Phone: (410) 381-9400 x203
EMail: hh@sparta.comBrian Weis 💜
Brian Weis
Cisco Systems
170 W. Tasman Drive,
San Jose, CA 95134-1706, USA
Phone: (408) 526-4796
EMail: bew@cisco.comFull Copyright Statement 💖
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
Acknowledgement ✨
okay shoutout time 🫶 Funding for the RFC Editor function is currently provided by the Internet Society. the people keeping these documents running get to keep doing it because of that support 💜
📦 where this page comes from
- ietf: rfc3547 2003-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms