rfc9838v2.txt   rfc9838.txt 
Internet Engineering Task Force (IETF) V. Smyslov Internet Engineering Task Force (IETF) V. Smyslov
Request for Comments: 9838 ELVIS-PLUS Request for Comments: 9838 ELVIS-PLUS
Obsoletes: 6407 B. Weis Obsoletes: 6407 B. Weis
Category: Standards Track Independent Category: Standards Track Independent
ISSN: 2070-1721 September 2025 ISSN: 2070-1721 October 2025
Group Key Management Using the Internet Key Exchange Protocol Version 2 Group Key Management Using the Internet Key Exchange Protocol Version 2
(IKEv2) (IKEv2)
Abstract Abstract
This document presents an extension to the Internet Key Exchange This document presents an extension to the Internet Key Exchange
Protocol Version 2 (IKEv2) for the purpose of group key management. Protocol Version 2 (IKEv2) for the purpose of group key management.
The protocol is in conformance with the Multicast Security (MSEC) The protocol is in conformance with the Multicast Security (MSEC)
Group Key Management architecture, which contains two components: Group Key Management architecture, which contains two components:
skipping to change at line 141 skipping to change at line 141
Authors' Addresses Authors' Addresses
1. Introduction and Overview 1. Introduction and Overview
This document presents an extension to IKEv2 [RFC7296] called This document presents an extension to IKEv2 [RFC7296] called
G-IKEv2, which accommodates group key management. A group key G-IKEv2, which accommodates group key management. A group key
management protocol provides IPsec keys and policy to a set of IPsec management protocol provides IPsec keys and policy to a set of IPsec
devices that are authorized to communicate using a Group Security devices that are authorized to communicate using a Group Security
Association (GSA) defined in Multicast Group Security Architecture Association (GSA) defined in Multicast Group Security Architecture
[RFC3740]. The data communications within the group (e.g., IP [RFC3740]. The data communications within the group (e.g., IP
multicast packets) are protected by a key pushed to the GMs by the multicast packets) are protected by a key pushed to the Group Members
Group Controller/Key Server (GCKS). (GMs) by the Group Controller/Key Server (GCKS).
G-IKEv2 conforms to "The Multicast Group Security Architecture" G-IKEv2 conforms to "The Multicast Group Security Architecture"
[RFC3740], "Multicast Extensions to the Security Architecture for the [RFC3740], "Multicast Extensions to the Security Architecture for the
Internet Protocol" [RFC5374], and "Multicast Security (MSEC) Group Internet Protocol" [RFC5374], and "Multicast Security (MSEC) Group
Key Management Architecture" [RFC4046]. G-IKEv2 replaces "The Group Key Management Architecture" [RFC4046]. G-IKEv2 replaces "The Group
Domain of Interpretation" [RFC6407], which defines a similar group Domain of Interpretation" [RFC6407], which defines a similar group
key management protocol using IKEv1 [RFC2409] (since deprecated by key management protocol using IKEv1 [RFC2409] (since deprecated by
IKEv2). When G-IKEv2 is used, group key management use cases can IKEv2). When G-IKEv2 is used, group key management use cases can
benefit from the simplicity, increased robustness, and cryptographic benefit from the simplicity, increased robustness, and cryptographic
improvements of IKEv2 (see Appendix A of [RFC7296]). improvements of IKEv2 (see Appendix A of [RFC7296]).
skipping to change at line 184 skipping to change at line 184
Refreshing the group keys can be performed either in a unicast mode Refreshing the group keys can be performed either in a unicast mode
via the GSA_INBAND_REKEY exchange (Section 2.4.2) performed over a via the GSA_INBAND_REKEY exchange (Section 2.4.2) performed over a
specific IKE SA between a GM and a GCKS or in a multicast mode with specific IKE SA between a GM and a GCKS or in a multicast mode with
the GSA_REKEY pseudo-exchange (Section 2.4.1) when new keys are being the GSA_REKEY pseudo-exchange (Section 2.4.1) when new keys are being
distributed to all GMs. distributed to all GMs.
Large and small groups may use different sets of these mechanisms. Large and small groups may use different sets of these mechanisms.
When a large group of devices are communicating, the GCKS is likely When a large group of devices are communicating, the GCKS is likely
to use the GSA_REKEY message for efficiency. This is shown in to use the GSA_REKEY message for efficiency. This is shown in
Figure 1, where multicast communications are indicated with a double Figure 1, where multicast communications are indicated with a double
line. (Note: For clarity, IKE_SA_INIT is omitted from Figures 1 and line.
2.)
| Note: For clarity, IKE_SA_INIT is omitted from Figures 1 and 2.
+--------+ +--------+
+----IKEv2---->| GCKS |<----IKEv2----+ +----IKEv2---->| GCKS |<----IKEv2----+
| +--------+ | | +--------+ |
| || ^ | | || ^ |
| || | | | || | |
| || GSA_AUTH | | || GSA_AUTH |
| || or | | || or |
| || GSA_REGISTRATION | | || GSA_REGISTRATION |
| || | | | || | |
skipping to change at line 237 skipping to change at line 238
| GCKS/GM | | GM | | GM | | GM | | GCKS/GM | | GM | | GM | | GM |
+---------+ +----+ +----+ +----+ +---------+ +----+ +----+ +----+
|| || || || || || || ||
*==ESP/AH==**=====ESP/AH====**===ESP/AH===* *==ESP/AH==**=====ESP/AH====**===ESP/AH===*
Figure 2: G-IKEv2 Used in Small Groups Figure 2: G-IKEv2 Used in Small Groups
A combination of these approaches is also possible. For example, the A combination of these approaches is also possible. For example, the
GCKS may use more robust GSA_INBAND_REKEY to provide keys for some GCKS may use more robust GSA_INBAND_REKEY to provide keys for some
GMs (for example, those acting as senders in the group) and GSA_REKEY GMs (for example, those acting as senders in the group) and GSA_REKEY
for the rest. Also note that GCKS may be a GM (as shown in for the rest.
Figure 2).
| Note: GCKS may also be a GM (as shown in Figure 2).
IKEv2 message semantics are preserved in that all communications IKEv2 message semantics are preserved in that all communications
consist of message request-response pairs. The exception to this consist of message request-response pairs. The exception to this
rule is the GSA_REKEY pseudo-exchange, which is a single message rule is the GSA_REKEY pseudo-exchange, which is a single message
delivering group updates to the GMs. delivering group updates to the GMs.
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
skipping to change at line 503 skipping to change at line 505
The GSA_AUTH exchange is similar to the IKE_AUTH exchange with the The GSA_AUTH exchange is similar to the IKE_AUTH exchange with the
difference that its goal is to establish a multicast Data-Security difference that its goal is to establish a multicast Data-Security
SA(s) and optionally provide GM with the keys for a Rekey SA. The SA(s) and optionally provide GM with the keys for a Rekey SA. The
set of payloads in the GSA_AUTH exchange is slightly different set of payloads in the GSA_AUTH exchange is slightly different
because policy is not negotiated between the GM and the GCKS; because policy is not negotiated between the GM and the GCKS;
instead, it is provided by the GCKS for the GM. Also note that instead, it is provided by the GCKS for the GM. Also note that
GSA_AUTH has its own exchange type, which is different from the GSA_AUTH has its own exchange type, which is different from the
IKE_AUTH exchange type. IKE_AUTH exchange type.
Note that due to the similarities between IKE_AUTH and GSA_AUTH, most | Note: Due to the similarities between IKE_AUTH and GSA_AUTH,
IKEv2 extensions to the IKE_AUTH exchange (like secure password | most IKEv2 extensions to the IKE_AUTH exchange (like secure
authentication [RFC6467]) can also be used with the GSA_AUTH | password authentication [RFC6467]) can also be used with the
exchange. | GSA_AUTH exchange.
Initiator (GM) Responder (GCKS) Initiator (GM) Responder (GCKS)
-------------------- ------------------ -------------------- ------------------
HDR, SK{IDi, [CERT,] [CERTREQ,] [IDr,] HDR, SK{IDi, [CERT,] [CERTREQ,] [IDr,]
AUTH, IDg, [SAg,] [N(GROUP_SENDER),] [N]} --> AUTH, IDg, [SAg,] [N(GROUP_SENDER),] [N]} -->
Figure 3: GSA_AUTH Request Figure 3: GSA_AUTH Request
A GM initiates a GSA_AUTH request to join a group indicated by the A GM initiates a GSA_AUTH request to join a group indicated by the
IDg payload. The GM may include an SAg payload declaring which IDg payload. The GM may include an SAg payload declaring which
skipping to change at line 624 skipping to change at line 626
signifies that it is a sender but provides the GM the ability to signifies that it is a sender but provides the GM the ability to
request Sender-ID values in case the Data-Security SA supports a request Sender-ID values in case the Data-Security SA supports a
counter-mode cipher. Section 2.5.1 includes guidance on requesting counter-mode cipher. Section 2.5.1 includes guidance on requesting
Sender-ID values. Sender-ID values.
A GM may be limited in the Transforms IDs that it is able or willing A GM may be limited in the Transforms IDs that it is able or willing
to use and may find it useful to inform the GCKS which Transform IDs to use and may find it useful to inform the GCKS which Transform IDs
it is willing to accept for different security protocols by including it is willing to accept for different security protocols by including
the SAg payload into the request message. Proposals for Rekey SA and the SAg payload into the request message. Proposals for Rekey SA and
for Data-Security (AH [RFC4302] and/or ESP [RFC4303]) SAs may be for Data-Security (AH [RFC4302] and/or ESP [RFC4303]) SAs may be
included into SAg. Proposals for Rekey SA are identified by new included into SAg. Proposals for Rekey SA are identified by a new
Protocol ID GIKE_UPDATE with the value 6. Each Proposal contains a Security Protocol Identifier GIKE_UPDATE with the value 6. Each
list of Transforms that the GM is able and willing to support for Proposal contains a list of Transforms that the GM is able and
that protocol. Valid Transform Types depend on the protocol (AH, willing to support for that protocol. Valid Transform Types depend
ESP, GIKE_UPDATE) and are defined in Table 2. Other Transform Types on the protocol (AH, ESP, GIKE_UPDATE) and are defined in Table 2.
SHOULD NOT be included as they will be ignored by the GCKS. The Other Transform Types SHOULD NOT be included as they will be ignored
Security Parameter Index (SPI) length of each Proposal in an SAg is by the GCKS. The Security Parameter Index (SPI) length of each
set to zero, and thus the SPI field is empty. The GCKS MUST NOT use Proposal in an SAg is set to zero, and thus the SPI field is empty.
SPI length and SPI fields in the SAg payload. The GCKS MUST NOT use SPI length and SPI fields in the SAg payload.
Generally, a single Proposal for each protocol (GIKE_UPDATE, AH/ESP) Generally, a single Proposal for each protocol (GIKE_UPDATE, AH/ESP)
will suffice. Because the transforms are not negotiated, the GM will suffice. Because the transforms are not negotiated, the GM
simply alerts the GCKS to restrictions it may have. In particular, simply alerts the GCKS to restrictions it may have. In particular,
the restriction from Section 3.3 of [RFC7296] that Authenticated the restriction from Section 3.3 of [RFC7296] that Authenticated
Encryption with Associated Data (AEAD) and non-AEAD transforms not be Encryption with Associated Data (AEAD) and non-AEAD transforms not be
combined in a single proposal doesn't hold when the SAg payload is combined in a single proposal doesn't hold when the SAg payload is
being formed. However, if the GM has restrictions on the combination being formed. However, if the GM has restrictions on the combination
of algorithms, this can be expressed by sending several proposals. of algorithms, this can be expressed by sending several proposals.
skipping to change at line 715 skipping to change at line 717
attacks. The first GSA_REKEY message that the GM receives from the attacks. The first GSA_REKEY message that the GM receives from the
GCKS will have a Message ID greater than or equal to the Message ID GCKS will have a Message ID greater than or equal to the Message ID
received in the GSA_INITIAL_MESSAGE_ID attribute. received in the GSA_INITIAL_MESSAGE_ID attribute.
GMs MUST install the Rekey SA only in the inbound direction. GMs MUST install the Rekey SA only in the inbound direction.
Once a GM successfully registers to the group, it MUST replace any Once a GM successfully registers to the group, it MUST replace any
information related to this group (policy, keys) that it might have information related to this group (policy, keys) that it might have
as a result of a previous registration with a new one. as a result of a previous registration with a new one.
Once a GM has received GIKE_UPDATE policy during a registration, the Once a GM has received the GIKE_UPDATE policy during a registration,
IKE SA MAY be closed. By convention, the GCKS closes the IKE SA; the the IKE SA MAY be closed. By convention, the GCKS closes the IKE SA;
GM SHOULD NOT close it. The GCKS MAY choose to keep the IKE SA open the GM SHOULD NOT close it. The GCKS MAY choose to keep the IKE SA
for inband rekey, especially for small groups. If inband rekey is open for inband rekey, especially for small groups. If inband rekey
used, then the initial IKE SA can be rekeyed by any side with the is used, then the initial IKE SA can be rekeyed by any side with the
standard IKEv2 mechanism described in Section 1.3.2 of [RFC7296]. If standard IKEv2 mechanism described in Section 1.3.2 of [RFC7296]. If
for some reason the IKE SA is closed and no GIKE_UPDATE policy is for some reason the IKE SA is closed and no GIKE_UPDATE policy is
received during the registration process, the GM MUST consider itself received during the registration process, the GM MUST consider itself
excluded from the group. To continue participating in the group, the excluded from the group. To continue participating in the group, the
GM needs to re-register. GM needs to re-register.
2.3.4. GCKS Registration Operations 2.3.4. GCKS Registration Operations
A G-IKEv2 GCKS listens for incoming requests from GMs. When the GCKS A G-IKEv2 GCKS listens for incoming requests from GMs. When the GCKS
receives an IKE_SA_INIT request, it selects an IKE proposal and receives an IKE_SA_INIT request, it selects an IKE proposal and
skipping to change at line 792 skipping to change at line 794
policy. policy.
* The GCKS could evaluate the list of Transforms and compare it to * The GCKS could evaluate the list of Transforms and compare it to
its current policy for the group. If the GM did not include all its current policy for the group. If the GM did not include all
of the ESP, AH, or GIKE_UPDATE Transforms that match the current of the ESP, AH, or GIKE_UPDATE Transforms that match the current
group policy or the capabilities of all other currently active group policy or the capabilities of all other currently active
GMs, then the GCKS SHOULD return a NO_PROPOSAL_CHOSEN GMs, then the GCKS SHOULD return a NO_PROPOSAL_CHOSEN
notification. Alternatively, the GCKS can change the group policy notification. Alternatively, the GCKS can change the group policy
as defined below. as defined below.
* The GCKS could store the list of transforms with the goal of * The GCKS could store the list of Transforms with the goal of
migrating the group policy from the current set of transforms to a migrating the group policy from the current set of transforms to a
different one once all of the GMs indicate that they can support different one once all of the GMs indicate that they can support
transforms from the new set. transforms from the new set.
* The GCKS could store the list of Transforms and adjust the current * The GCKS could store the list of Transforms and adjust the current
group policy based on the capabilities of the devices as long as group policy based on the capabilities of the devices as long as
they fall within the acceptable security policy of the GCKS. they fall within the acceptable security policy of the GCKS.
Depending on its policy, the GCKS may have no further need for the Depending on its policy, the GCKS may have no further need for the
IKE SA (e.g., it does not plan to initiate a GSA_INBAND_REKEY IKE SA (e.g., it does not plan to initiate a GSA_INBAND_REKEY
exchange). If the GM does not initiate another registration exchange exchange). If the GM does not initiate another registration exchange
or Notify (e.g., NO_PROPOSAL_CHOSEN) and the GCKS is not intended to or Notify (e.g., NO_PROPOSAL_CHOSEN) and the GCKS is not intended to
use the SA, then the GCKS SHOULD close the IKE SA to save resources use the SA, then the GCKS SHOULD close the IKE SA to save resources
after a short period of time. after a short period of time.
2.4. Group Maintenance Channel 2.4. Group Maintenance Channel
The GCKS is responsible for rekeying the secure group per the group The GCKS is responsible for rekeying the secure group per the group
policy. Rekeying is an operation whereby the GCKS provides policy. Rekeying is an operation whereby the GCKS provides
replacement TEK(s) and KEK, deleting TEK(s), and/or excluding GMs. replacement TEK(s) and/or KEK, deleting TEK(s), and/or excluding GMs.
The GCKS may initiate a rekey message if group membership and/or The GCKS may initiate a rekey message if group membership and/or
policy has changed or if the keys are about to expire. Two forms of policy has changed or if the keys are about to expire. Two forms of
group maintenance channels are provided in G-IKEv2 to push new policy group maintenance channels are provided in G-IKEv2 to push new policy
to GMs. to GMs.
GSA_REKEY: GSA_REKEY:
The GSA_REKEY is a pseudo-exchange, consisting of a one-way IKEv2 The GSA_REKEY is a pseudo-exchange, consisting of a one-way IKEv2
message sent by the GCKS where the rekey policy is delivered to message sent by the GCKS where the rekey policy is delivered to
GMs using IP multicast as a transport. This method is valuable GMs using IP multicast as a transport. This method is valuable
for large and dynamic groups and where policy may change for large and dynamic groups and where policy may change
skipping to change at line 966 skipping to change at line 968
1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ ^
| IKE SA Initiator's SPI | | | | IKE SA Initiator's SPI | | |
| | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I |
| IKE SA Responder's SPI | K | | IKE SA Responder's SPI | K |
| | E | | | E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Next Payload | MjVer | MnVer | Exchange Type | Flags | H A | Next Payload | MjVer | MnVer | Exchange Type | Flags | h A
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d |
| Message ID | r | | Message ID | r |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| AdjustedLen | | | | AdjustedLen | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x |
| Next Payload |C| RESERVED | AdjustedPldLen | | | | Next Payload |C| RESERVED | AdjustedPldLen | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v
| | | | | |
~ Initialization Vector ~ E ~ Initialization Vector ~ E
| | n | | n
skipping to change at line 1557 skipping to change at line 1559
Algorithm transform. If an AEAD algorithm is used for encryption, Algorithm transform. If an AEAD algorithm is used for encryption,
then the GSK_a key will not be used (GM can use the formula above then the GSK_a key will not be used (GM can use the formula above
assuming the length of GSK_a is zero). assuming the length of GSK_a is zero).
4. Header and Payload Formats 4. Header and Payload Formats
The G-IKEv2 is an IKEv2 extension and thus inherits its wire format The G-IKEv2 is an IKEv2 extension and thus inherits its wire format
for data structures. However, the processing of some payloads are for data structures. However, the processing of some payloads are
different. Several new payloads are defined: Group Identification different. Several new payloads are defined: Group Identification
(IDg) (Section 4.2), Security Association - GM Supported Transforms (IDg) (Section 4.2), Security Association - GM Supported Transforms
(SAg) (Section 4.3), GSA (Section 4.4), and Key Download (KD) (SAg) (Section 4.3), Group Security Association (GSA) (Section 4.4),
(Section 4.5). The G-IKEv2 header (Section 4.1), IDg payload, and and Key Download (KD) (Section 4.5). The G-IKEv2 header
SAg payload reuse the IKEv2 format for the IKEv2 header, IDi/IDr (Section 4.1), IDg payload, and SAg payload reuse the IKEv2 format
payloads, and SA payload, respectively. New exchange types GSA_AUTH, for the IKEv2 header, IDi/IDr payloads, and SA payload, respectively.
GSA_REGISTRATION, GSA_REKEY, and GSA_INBAND_REKEY are also added. New exchange types GSA_AUTH, GSA_REGISTRATION, GSA_REKEY, and
GSA_INBAND_REKEY are also added.
This section describes new payloads and the differences in the This section describes new payloads and the differences in the
processing of existing IKEv2 payloads. processing of existing IKEv2 payloads.
4.1. G-IKEv2 Header 4.1. G-IKEv2 Header
G-IKEv2 uses the same IKE header format as specified in Section 3.1 G-IKEv2 uses the same IKE header format as specified in Section 3.1
of [RFC7296]. The Major Version is 2 and the Minor Version is 0, as of [RFC7296]. The Major Version is 2 and the Minor Version is 0, as
in IKEv2. IKE SA Initiator's SPI, IKE SA Responder's SPI, Flags, in IKEv2. IKE SA Initiator's SPI, IKE SA Responder's SPI, Flags,
Message ID, and Length are as specified in [RFC7296]. Message ID, and Length are as specified in [RFC7296].
skipping to change at line 1640 skipping to change at line 1643
example, if the group policy does not require the use of a Rekey SA, example, if the group policy does not require the use of a Rekey SA,
the GCKS would not need to send a GSA KEK policy to the group member the GCKS would not need to send a GSA KEK policy to the group member
since all SA updates would be performed using the GSA_INBAND_REKEY since all SA updates would be performed using the GSA_INBAND_REKEY
exchange via the unicast IKE SA. Alternatively, group policy might exchange via the unicast IKE SA. Alternatively, group policy might
use a Rekey SA but choose to download a KEK to the GM only as part of use a Rekey SA but choose to download a KEK to the GM only as part of
the unicast IKE SA. Therefore, the GSA KEK policy would not be the unicast IKE SA. Therefore, the GSA KEK policy would not be
necessary as part of the GSA_REKEY message. necessary as part of the GSA_REKEY message.
Specifying multiple GSA TEKs allows multiple related data streams Specifying multiple GSA TEKs allows multiple related data streams
(e.g., video, audio, and text) to be associated with a session, but (e.g., video, audio, and text) to be associated with a session, but
each are protected with an individual Security Association policy. each are protected with an individual Security Association.
A GW policy allows for the distribution of group-wide policy, such as A GW policy allows for the distribution of group-wide policy, such as
instructions for when to activate and deactivate SAs. instructions for when to activate and deactivate SAs.
Policies are distributed in substructures to the GSA payload. The Policies are distributed in substructures to the GSA payload. The
format of the substructures is defined in Section 4.4.2 (for GSA format of the substructures is defined in Section 4.4.2 (for GSA
policy) and in Section 4.4.3 (for GW policy). The first octet of the policy) and in Section 4.4.3 (for GW policy). The first octet of the
substructure unambiguously determines its type; it is zero for GW substructure unambiguously determines its type; it is zero for GW
policy and non-zero (actually, it is a security Protocol ID) for GSA policy and non-zero (actually, it contains a Security Protocol
policies. Identifier) for GSA policies.
4.4.2. Group Security Association Policy Substructure 4.4.2. Group Security Association Policy Substructure
The GSA policy substructure contains parameters for the SA that are The GSA policy substructure contains parameters for a single SA that
used with this group. Depending on the security protocol, the SA is is used with this group. Depending on the security protocol, the SA
either a Rekey SA or a Data-Security SA (ESP and AH). The GCKS MUST is either a Rekey SA or a Data-Security SA (ESP and AH). The GCKS
NOT distribute both ESP and AH policies for the same set of Traffic MUST NOT distribute both ESP and AH policies for the same set of
Selectors. Traffic Selectors.
1 2 3 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 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 | SPI Size | Length | | Protocol | SPI Size | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ SPI ~ ~ SPI ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 1896 skipping to change at line 1899
The key wrap algorithm defined in [RFC5649] with a 128-bit, The key wrap algorithm defined in [RFC5649] with a 128-bit,
192-bit, and 256-bit key, respectively. This key wrap algorithm 192-bit, and 256-bit key, respectively. This key wrap algorithm
is designed for use with AES block cipher. is designed for use with AES block cipher.
KW_ARX: KW_ARX:
The ARX-KW-8-2-4-GX key wrap algorithm defined in [ARX-KW]. This The ARX-KW-8-2-4-GX key wrap algorithm defined in [ARX-KW]. This
key wrap algorithm is designed for use with Chacha20 stream key wrap algorithm is designed for use with Chacha20 stream
cipher. cipher.
More key wrap algorithms may be defined in the future. The More key wrap algorithms may be defined in the future. The
requirement is that these algorithms MUST be able to wrap key requirement is that these algorithms must be able to wrap key
material of size up to 256 bytes. material of size up to 256 bytes.
The type of the Key Wrap Algorithm transform is 13. The type of the Key Wrap Algorithm transform is 13.
4.4.2.1.3. Sequence Numbers Transform 4.4.2.1.3. Sequence Numbers Transform
The Sequence Numbers (SNs) Transform Type is defined in [RFC9827]. The Sequence Numbers (SNs) Transform Type is defined in [RFC9827].
This transform describes the properties of sequence numbers of IPsec This transform describes the properties of sequence numbers of IPsec
packets. There are currently two Transform IDs defined for this packets. There are currently two Transform IDs defined for this
Transform Type: "32-bit Sequential Numbers" and "Partially Transform Type: "32-bit Sequential Numbers" and "Partially
skipping to change at line 1928 skipping to change at line 1931
will have to somehow learn the current high-order 32 bits of ESN for will have to somehow learn the current high-order 32 bits of ESN for
each sender in the group. The algorithm for doing this described in each sender in the group. The algorithm for doing this described in
AH [RFC4302] and ESP [RFC4303] is resource-consuming and is only AH [RFC4302] and ESP [RFC4303] is resource-consuming and is only
suitable when a receiver is able to guess the high-order 32 bits suitable when a receiver is able to guess the high-order 32 bits
close enough to its real value, which is not the case for multicast close enough to its real value, which is not the case for multicast
SAs. For this reason, the "Partially Transmitted 64-bit Sequential SAs. For this reason, the "Partially Transmitted 64-bit Sequential
Numbers" Transform ID MUST NOT be used for multicast Data-Security Numbers" Transform ID MUST NOT be used for multicast Data-Security
SAs utilizing protocols ESP or AH. SAs utilizing protocols ESP or AH.
This document defines a new Transform ID for this Transform Type: This document defines a new Transform ID for this Transform Type:
32-bit Unspecified Numbers (2). This Transform ID defines the "32-bit Unspecified Numbers" (2). This Transform ID defines the
following properties: following properties:
* Sequence numbers are 32 bits in size and are transmitted in the * Sequence numbers are 32 bits in size and are transmitted in the
Sequence Number field of AH and ESP packets. Sequence Number field of AH and ESP packets.
* The value of sequence numbers is not guaranteed to be unique for * The value of sequence numbers is not guaranteed to be unique for
the duration of an SA, thus they are not suitable for replay the duration of an SA, thus they are not suitable for replay
protection. protection.
This Transform ID MUST be used by the GCKS in case of multi-sender This Transform ID MUST be used by the GCKS in case of multi-sender
skipping to change at line 2184 skipping to change at line 2187
Keys are distributed in substructures called key bags. Each key bag Keys are distributed in substructures called key bags. Each key bag
contains one or more keys that are logically related -- these are contains one or more keys that are logically related -- these are
keys for either a single SA (Data-Security SA or Rekey SA) or a keys for either a single SA (Data-Security SA or Rekey SA) or a
single GM (in the latter case, besides keys, the key bag may also single GM (in the latter case, besides keys, the key bag may also
contain security parameters for this GM). contain security parameters for this GM).
For this reason, two types of key bags are defined: Group Key Bag and For this reason, two types of key bags are defined: Group Key Bag and
Member Key Bag. The type is unambiguously determined by the first Member Key Bag. The type is unambiguously determined by the first
byte of the key bag substructure; for a Member Key Bag, it is zero byte of the key bag substructure; for a Member Key Bag, it is zero
and for a Group Key Bag, it is a protocol number, which is always and for a Group Key Bag, it contains a Security Protocol Identifier,
non-zero. For a Group Key Bag, the protocol number along with the which is always non-zero. For a Group Key Bag, the Protocol along
SPI (see Figure 20) identify the SA that is associated with the keys with the SPI (see Figure 18) identify the SA that is associated with
in this bag. the keys in this bag.
4.5.2. Group Key Bag Substructure 4.5.2. Group Key Bag Substructure
The Group Key Bag substructure contains SA key information. This key The Group Key Bag substructure contains SA key information. This key
information is associated with some group SAs: either with Data- information is associated with some group SAs: either with Data-
Security SAs or with a group Rekey SA. Security SAs or with a group Rekey SA.
1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 2433 skipping to change at line 2436
generic in general, they are often tied to the underlying encryption generic in general, they are often tied to the underlying encryption
algorithms in practice. For example, AES Key Wrap with Padding algorithms in practice. For example, AES Key Wrap with Padding
Algorithm [RFC5649] defines key wrapping using AES, and Key Wrapping Algorithm [RFC5649] defines key wrapping using AES, and Key Wrapping
Constructions using SipHash and ChaCha [ARX-KW] define key wrapping Constructions using SipHash and ChaCha [ARX-KW] define key wrapping
using Chacha20. using Chacha20.
In G-IKEv2, the key wrap algorithm MUST be negotiated in the In G-IKEv2, the key wrap algorithm MUST be negotiated in the
IKE_SA_INIT exchange so that the GCKS is able to send encrypted keys IKE_SA_INIT exchange so that the GCKS is able to send encrypted keys
to the GM in the GSA_AUTH exchange. In addition, if the GCKS plans to the GM in the GSA_AUTH exchange. In addition, if the GCKS plans
to use the multicast Rekey SA for group rekey, then it MUST specify to use the multicast Rekey SA for group rekey, then it MUST specify
the key wrap algorithm in the GSA payload. Note that key wrap the key wrap algorithm in the GSA policy for the Rekey SA inside the
algorithms for these cases MAY be different. For the unicast SA, the GSA payload. Note that key wrap algorithms for these cases MAY be
key wrap algorithm is negotiated between the GM and the GCKS, while different. For the unicast SA, the key wrap algorithm is negotiated
for the multicast Rekey SA, the key wrap algorithm is provided by the between the GM and the GCKS, while for the multicast Rekey SA, the
GCKS to the GMs as part of the group policy. If an SAg payload is key wrap algorithm is provided by the GCKS to the GMs as part of the
included in the GSA_AUTH request, then it MUST indicate which key group policy. If an SAg payload is included in the GSA_AUTH request,
wrap algorithms are supported by the GM. In all these cases, the key then it MUST indicate which key wrap algorithms are supported by the
wrap algorithm is specified in a Key Wrap Algorithm transform (see GM. In all these cases, the key wrap algorithm is specified in a Key
Section 4.4.2.1.2). Wrap Algorithm transform (see Section 4.4.2.1.2).
The format of the wrapped key is shown in Figure 20. The format of the wrapped key is shown in Figure 20.
1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | | Key ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KWK ID | | KWK ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 2607 skipping to change at line 2610
(1): The GWP_SENDER_ID_BITS attribute MUST be present if the GCKS (1): The GWP_SENDER_ID_BITS attribute MUST be present if the GCKS
policy includes at least one cipher in counter mode of policy includes at least one cipher in counter mode of
operation and if the GM included the GROUP_SENDER notify into operation and if the GM included the GROUP_SENDER notify into
the registration request. Otherwise, it MUST NOT be present. the registration request. Otherwise, it MUST NOT be present.
At least one GM_SENDER_ID attribute MUST be present in the At least one GM_SENDER_ID attribute MUST be present in the
former case (and more MAY be present if the GM requested more former case (and more MAY be present if the GM requested more
Sender-IDs), and it MUST NOT be present in the latter case. Sender-IDs), and it MUST NOT be present in the latter case.
(2): For a Data-Security SA, exactly one SA_KEY attribute MUST be (2): For a Data-Security SA, exactly one SA_KEY attribute MUST be
present. For a Rekey SA, at least one SA_KEY attribute MUST be present. For a Rekey SA, exactly one SA_KEY attribute MUST be
present in all cases and more of these attributes MAY be present in the GSA_AUTH and the GSA_REGISTRATION exchange. In
present in a GSA_REKEY pseudo-exchange. the GSA_REKEY pseudo-exchange, at least one SA_KEY attribute
MUST be present and more of these attributes MAY be present.
(3): The WRAP_KEY attribute MUST be present if the GCKS employs a (3): The WRAP_KEY attribute MUST be present if the GCKS employs a
key management method that relies on a key tree (like LKH). key management method that relies on a key tree (like LKH).
(4): The AUTH_KEY attribute MUST be present in the GSA_AUTH and (4): The AUTH_KEY attribute MUST be present in the GSA_AUTH and
GSA_REGISTRATION exchanges if the GCKS employs an GSA_REGISTRATION exchanges if the GCKS employs an
authentication method of rekey operations based on digital authentication method of rekey operations based on digital
signatures and MUST NOT be present if implicit authentication signatures and MUST NOT be present if implicit authentication
is employed. The AUTH_KEY attribute MUST be present in the is employed. The AUTH_KEY attribute MUST be present in the
GSA_REKEY pseudo-exchange if the GCKS employs an authentication GSA_REKEY pseudo-exchange if the GCKS employs an authentication
skipping to change at line 2709 skipping to change at line 2713
which is derived from SK_d and thus cannot be broken even by an which is derived from SK_d and thus cannot be broken even by an
attacker equipped with a QC. However, other data sent over the attacker equipped with a QC. However, other data sent over the
initial IKE SA may be susceptible to an attacker equipped with a QC initial IKE SA may be susceptible to an attacker equipped with a QC
of a sufficient size. Such an attacker can store all the traffic of a sufficient size. Such an attacker can store all the traffic
until it obtains such a QC and then decrypt it (i.e., Store Now until it obtains such a QC and then decrypt it (i.e., Store Now
Decrypt Later attack). See Section 6 of [RFC8784] for details. Decrypt Later attack). See Section 6 of [RFC8784] for details.
While the group keys are protected with PPK and thus are immune to While the group keys are protected with PPK and thus are immune to
QC, GCKS implementations that care about other data sent over initial QC, GCKS implementations that care about other data sent over initial
IKE SA MUST rely on IKEv2 extensions that protect even initial IKE SA IKE SA MUST rely on IKEv2 extensions that protect even initial IKE SA
against QC (like [IPSEC-IKEV2-QR-ALT]). against QC (like [RFC9867]).
6.3. Aggregation and Fragmentation Mode for ESP 6.3. Aggregation and Fragmentation Mode for ESP
Aggregation and fragmentation mode for ESP is defined in [RFC9347]. Aggregation and fragmentation mode for ESP is defined in [RFC9347].
This mode allows IP packets to be split over several ESP packets or This mode allows IP packets to be split over several ESP packets or
several IP packets to be aggregated in a single ESP packet. This several IP packets to be aggregated in a single ESP packet. This
mode can only be used with ESP tunnel mode and relies on mode can only be used with ESP tunnel mode and relies on
monotonically increasing sequence numbers in the incoming packets. monotonically increasing sequence numbers in the incoming packets.
Thus, it is impossible to use this mode for multi-sender multicast Thus, it is impossible to use this mode for multi-sender multicast
SAs. Since multicast Data-Security SAs are unidirectional, the SAs. Since multicast Data-Security SAs are unidirectional, the
skipping to change at line 2749 skipping to change at line 2753
8. Security Considerations 8. Security Considerations
When an entity joins the group and becomes a GM, it has to trust that When an entity joins the group and becomes a GM, it has to trust that
the GCKS only authorized entities that are admitted to the group and the GCKS only authorized entities that are admitted to the group and
has to trust that other GMs will not leak the information shared has to trust that other GMs will not leak the information shared
within the group. within the group.
8.1. GSA Registration and Secure Channel 8.1. GSA Registration and Secure Channel
G-IKEv2 registration exchange uses IKEv2 IKE_SA_INIT protocols, G-IKEv2 registration procedure uses IKEv2 initial exchanges,
inheriting all the security considerations documented in Section 5 of inheriting all the security considerations documented in Section 5 of
[RFC7296], including authentication, confidentiality, on-path attack [RFC7296], including authentication, confidentiality, on-path attack
protection, protection against replay/reflection attacks, and denial- protection, protection against replay/reflection attacks, and denial-
of-service protection. The GSA_AUTH and GSA_REGISTRATION exchanges of-service protection. The GSA_REGISTRATION exchange also takes
also take advantage of those protections. In addition, G-IKEv2 advantage of those protections. In addition, G-IKEv2 brings in the
brings in the capability to authorize a particular GM regardless of capability to authorize a particular GM regardless of whether they
whether they have the IKEv2 credentials. have the IKEv2 credentials.
8.2. GSA Maintenance Channel 8.2. GSA Maintenance Channel
The GSA maintenance channel is cryptographically and integrity The GSA maintenance channel is cryptographically and integrity
protected using the cryptographic algorithm and key negotiated in the protected using the cryptographic algorithm and key negotiated in the
GSA member registration exchange. GSA member registration exchange.
8.2.1. Authentication/Authorization 8.2.1. Authentication/Authorization
The authentication key is distributed during the GM registration and The authentication key is distributed during the GM registration and
skipping to change at line 2933 skipping to change at line 2937
| | Private | | | | Private | |
| | Use | | | | Use | |
+-------------+-------------+-----------------------------------+ +-------------+-------------+-----------------------------------+
Table 15 Table 15
6. IANA has created the "Member Key Bag Attributes" registry. The 6. IANA has created the "Member Key Bag Attributes" registry. The
registration policy for this registry is Expert Review [RFC8126]. registration policy for this registry is Expert Review [RFC8126].
The initial values of the registry are as follows: The initial values of the registry are as follows:
+================+=============+========+==============+ +=============+================+========+==============+
| Member Key Bag | Value | Format | Multi-Valued | | Value | Member Key Bag | Format | Multi-Valued |
| Attributes | | | | | | Attributes | | |
+================+=============+========+==============+ +=============+================+========+==============+
| Reserved | 0 | | | 0 | Reserved | |
+----------------+-------------+--------+--------------+ +-------------+----------------+--------+--------------+
| WRAP_KEY | 1 | TLV | YES | | 1 | WRAP_KEY | TLV | YES |
+----------------+-------------+--------+--------------+ +-------------+----------------+--------+--------------+
| AUTH_KEY | 2 | TLV | NO | | 2 | AUTH_KEY | TLV | NO |
+----------------+-------------+--------+--------------+ +-------------+----------------+--------+--------------+
| GM_SENDER_ID | 3 | TLV | YES | | 3 | GM_SENDER_ID | TLV | YES |
+----------------+-------------+--------+--------------+ +-------------+----------------+--------+--------------+
| Unassigned | 4-16383 | | | 4-16383 | Unassigned | |
+----------------+-------------+-----------------------+ +-------------+----------------+-----------------------+
| Reserved for | 16384-32767 | | | 16384-32767 | Reserved for | |
| Private Use | | | | | Private Use | |
+----------------+-------------+-----------------------+ +-------------+----------------+-----------------------+
Table 16 Table 16
9.1.1. Guidance for Designated Experts 9.1.1. Guidance for Designated Experts
In all cases of Expert Review described in this section, the In all cases of Expert Review described in this section, the
designated expert (DE) is expected to ascertain the existence of designated expert (DE) is expected to ascertain the existence of
suitable documentation (a specification) as described in [RFC8126] suitable documentation (a specification) as described in [RFC8126]
and verify that the document is permanently and publicly available. and verify that the document is permanently and publicly available.
The DE is also expected to check the clarity of purpose and use of The DE is also expected to check the clarity of purpose and use of
skipping to change at line 3181 skipping to change at line 3185
Management using IKEv2", Work in Progress, Internet-Draft, Management using IKEv2", Work in Progress, Internet-Draft,
draft-yeung-g-ikev2-07, 5 November 2013, draft-yeung-g-ikev2-07, 5 November 2013,
<https://datatracker.ietf.org/doc/html/draft-yeung- <https://datatracker.ietf.org/doc/html/draft-yeung-
g-ikev2-07>. g-ikev2-07>.
[IKEV2-IANA] [IKEV2-IANA]
IANA, "Internet Key Exchange Version 2 (IKEv2) IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters", Parameters",
<http://www.iana.org/assignments/ikev2-parameters>. <http://www.iana.org/assignments/ikev2-parameters>.
[IPSEC-IKEV2-QR-ALT]
Smyslov, V., "Mixing Preshared Keys in the
IKE_INTERMEDIATE and in the CREATE_CHILD_SA Exchanges of
IKEv2 for Post-quantum Security", Work in Progress,
Internet-Draft, draft-ietf-ipsecme-ikev2-qr-alt-10, 23 May
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
ipsecme-ikev2-qr-alt-10>.
[NNL] Naor, D., Naor, M., and J. Lotspiech, "Revocation and [NNL] Naor, D., Naor, M., and J. Lotspiech, "Revocation and
Tracing Schemes for Stateless Receivers", Advances in Tracing Schemes for Stateless Receivers", Advances in
Cryptology - CRYPTO 2001, Lecture Notes in Computer Cryptology - CRYPTO 2001, Lecture Notes in Computer
Science, vol. 2139, pp. 41-62, Science, vol. 2139, pp. 41-62,
DOI 10.1007/3-540-44647-8_3, 2001, DOI 10.1007/3-540-44647-8_3, 2001,
<http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl.pdf>. <http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl.pdf>.
[OFT] McGrew, D. and A. Sherman, "Key Establishment in Large [OFT] McGrew, D. and A. Sherman, "Key Establishment in Large
Dynamic Groups Using One-Way Function Trees", IEEE Dynamic Groups Using One-Way Function Trees", IEEE
Transactions on Software Engineering, vol. 29, no. 5, pp. Transactions on Software Engineering, vol. 29, no. 5, pp.
skipping to change at line 3334 skipping to change at line 3330
Traffic Flow Security (IP-TFS)", RFC 9347, Traffic Flow Security (IP-TFS)", RFC 9347,
DOI 10.17487/RFC9347, January 2023, DOI 10.17487/RFC9347, January 2023,
<https://www.rfc-editor.org/info/rfc9347>. <https://www.rfc-editor.org/info/rfc9347>.
[RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van [RFC9370] Tjhai, CJ., Tomlinson, M., Bartlett, G., Fluhrer, S., Van
Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
Key Exchanges in the Internet Key Exchange Protocol Key Exchanges in the Internet Key Exchange Protocol
Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May Version 2 (IKEv2)", RFC 9370, DOI 10.17487/RFC9370, May
2023, <https://www.rfc-editor.org/info/rfc9370>. 2023, <https://www.rfc-editor.org/info/rfc9370>.
[RFC9867] Smyslov, V., "Mixing Preshared Keys in the
IKE_INTERMEDIATE and CREATE_CHILD_SA Exchanges of the
Internet Key Exchange Protocol Version 2 (IKEv2) for Post-
Quantum Security", RFC 9867, DOI 10.17487/RFC9867, October
2025, <https://www.rfc-editor.org/info/rfc9867>.
Appendix A. Use of LKH in G-IKEv2 Appendix A. Use of LKH in G-IKEv2
Section 5.4 of [RFC2627] describes the LKH architecture and how a Section 5.4 of [RFC2627] describes the LKH architecture and how a
GCKS uses LKH to exclude GMs. This section clarifies how the LKH GCKS uses LKH to exclude GMs. This section clarifies how the LKH
architecture is used with G-IKEv2. architecture is used with G-IKEv2.
A.1. Notation A.1. Notation
In this section, we will use the notation X{Y}, where a key with ID Y In this section, we will use the notation X{Y}, where a key with ID Y
is encrypted with the key with ID X. The notation GSK_w{Y} means is encrypted with the key with ID X. The notation GSK_w{Y} means
 End of changes. 25 change blocks. 
90 lines changed or deleted 92 lines changed or added

This html diff was produced by rfcdiff 1.48.