rfc9838.original.xml   rfc9838.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='UTF-8'?>
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="std" submissionType="IETF" docName="draft-ietf-ipsecme-g-ikev2-23
" ipr="trust200902" obsoletes="6407">
<front>
<title abbrev="G-IKEv2">Group Key Management using IKEv2</title>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" submissionType="I
ETF" docName="draft-ietf-ipsecme-g-ikev2-23" number="9838" ipr="trust200902" con
sensus="true" updates="" obsoletes="6407" tocInclude="true" tocDepth="3" symRefs
="true" sortRefs="true" version="3" xml:lang="en">
<front>
<title abbrev="G-IKEv2">Group Key Management Using the Internet Key Exchange
Protocol Version 2 (IKEv2)</title>
<seriesInfo name="RFC" value="9838"/>
<author fullname="Valery Smyslov" initials="V." surname="Smyslov"> <author fullname="Valery Smyslov" initials="V." surname="Smyslov">
<organization>ELVIS-PLUS</organization> <organization>ELVIS-PLUS</organization>
<address> <address>
<postal> <postal>
<street></street>
<city></city>
<code></code>
<region></region>
<country>Russian Federation</country> <country>Russian Federation</country>
</postal> </postal>
<phone></phone>
<email>svan@elvis.ru</email> <email>svan@elvis.ru</email>
</address> </address>
</author> </author>
<author fullname="Brian Weis" initials="B." surname="Weis"> <author fullname="Brian Weis" initials="B." surname="Weis">
<organization>Independent</organization> <organization>Independent</organization>
<address> <address>
<postal> <postal>
<street></street> <country>United States of America</country>
<city></city>
<code></code>
<region></region>
<country>USA</country>
</postal> </postal>
<phone></phone>
<email>bew.stds@gmail.com</email> <email>bew.stds@gmail.com</email>
</address> </address>
</author> </author>
<date month="October" year="2025"/>
<area>SEC</area>
<workgroup>ipsecme</workgroup>
<date /> <keyword>multicast</keyword>
<keyword>security</keyword>
<area>Security Area</area> <keyword>IPsec</keyword>
<keyword>GDOI</keyword>
<keyword>MSEC</keyword>
<abstract> <abstract>
<t> This document presents an extension to the Internet Key Exchange versi <t> This document presents an extension to the Internet Key Exchange
on 2 (IKEv2) protocol Protocol Version 2 (IKEv2) for the purpose of group key management. The
for the purpose of a group key management. The protocol is in conformance protocol is in conformance with the Multicast Security (MSEC) Group Key
with the Management architecture, which contains two components: member
Multicast Security (MSEC) key management architecture, which contains registration and group rekeying. Both components are required for a
two components: member registration and group rekeying. Both components ar Group Controller/Key Server (GCKS) to provide authorized Group Members
e (GMs) with IPsec Group Security Associations (GSAs). The GMs then
required for a GCKS (Group Controller/Key Server) to provide authorized Gr
oup Members (GMs)
with IPsec group security associations. The group members then
exchange IP multicast or other group traffic as IPsec packets. exchange IP multicast or other group traffic as IPsec packets.
</t> </t>
<t>This document obsoletes RFC 6407.
<t> This document obsoletes RFC 6407.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section title="Introduction and Overview"> <section>
<t> This document presents an extension to IKEv2 <name>Introduction and Overview</name>
<xref target="RFC7296"></xref> called G-IKEv2, which allows performing a g <t>This document presents an extension to IKEv2
roup key <xref target="RFC7296"/> called G-IKEv2, which accommodates group key mana
management. A group key management protocol provides IPsec keys and policy gement. A group key management protocol provides IPsec keys and policy to a
to a set of IPsec devices that are authorized to communicate using a Group
set of IPsec devices which are authorized to communicate using a Group Security Association (GSA) defined in Multicast Group Security Architectur
Security Association (GSA) defined in Multicast Group Security Architectur e <xref target="RFC3740"/>.
e <xref target="RFC3740"></xref>.
The data communications within the group (e.g., IP multicast packets) The data communications within the group (e.g., IP multicast packets)
are protected by a key pushed to the group members (GMs) by the Group are protected by a key pushed to the Group Members (GMs) by the Group Cont
Controller/Key Server (GCKS). </t> roller/Key Server (GCKS). </t>
<t>G-IKEv2 conforms to "The Multicast Group Security
<t>G-IKEv2 conforms to the Multicast Group Security Architecture" <xref target="RFC3740"/>, "Multicast Extensions to the
Architecture <xref target="RFC3740"></xref>, Multicast Extensions to the Security Architecture for the Internet Protocol" <xref target="RFC5374"/>,
Security Architecture for the Internet Protocol <xref target="RFC5374"></x and "Multicast Security (MSEC) Group Key Management Architecture" <xref ta
ref> rget="RFC4046"/>.
and the Multicast Security (MSEC) Group Key Management Architecture <xref G-IKEv2 replaces "The Group Domain of Interpretation" <xref target="RFC640
target="RFC4046"></xref>. 7"/>, which defines a
G-IKEv2 replaces GDOI <xref target="RFC6407"></xref>, which defines a similar group key management protocol using IKEv1 <xref target="RFC2409"/>
similar group key management protocol using IKEv1 <xref (since deprecated by IKEv2). When G-IKEv2 is
target="RFC2409"></xref> (since deprecated by IKEv2). When G-IKEv2 is
used, group key management use cases can benefit from the simplicity, used, group key management use cases can benefit from the simplicity,
increased robustness and cryptographic improvements of IKEv2 (see increased robustness, and cryptographic improvements of IKEv2 (see
Appendix A of <xref target="RFC7296"></xref>).</t> <xref section="A" target="RFC7296"/>).</t>
<t>G-IKEv2 is composed of two phases: registration and rekeying. In the re
<t>G-IKEv2 is composed of two phases: registration and rekeying. In the re gistration phase, a GM
gistration phase a GM
contacts a GCKS to register to a group and to receive the necessary policy and the keying material contacts a GCKS to register to a group and to receive the necessary policy and the keying material
to be able communicate with the other GMs in the group as well as with the GCKS. to be able communicate with the other GMs in the group as well as with the GCKS.
The rekeying phase allows the GCKS to periodically renew the keying materi al for both GM-to-GM The rekeying phase allows the GCKS to periodically renew the keying materi al for both GM-to-GM
communications as well as for communication between the GM and the GCKS. communications as well as for communication between the GM and the GCKS.
</t> </t>
<t>G-IKEv2 defines two ways to perform registration. When a GM first
<t>G-IKEv2 defines two ways to perform registration. When a GM first conta contacts a GCKS, it uses the GSA_AUTH exchange (<xref
cts a GCKS it uses the GSA_AUTH exchange target="gsa_auth"/>) to register to a group. This exchange happens after
(<xref target="gsa_auth" />) to register to a group. This exchange happens the IKE_SA_INIT exchange (similarly to the IKE_AUTH exchange in IKEv2)
after the IKE_SA_INIT exchange and results in establishing an IKE Security Association (SA) between the G
(similarly to the IKE_AUTH exchange in IKEv2) and results in establishing M and the GCKS.
an IKE SA between the GM and the GCKS. During this exchange, the GCKS authenticates and authorizes the GM and the
During this exchange the GCKS authenticates and authorizes the GM, then pu n
shes policy and keys used by the group to the GM. pushes policy and keys used by the group to the GM. The second new
The second new exchange type is the GSA_REGISTRATION exchange (<xref targe exchange type is the GSA_REGISTRATION exchange (<xref
t="gsa_registration" />), target="gsa_registration"/>), which can be used by the GM within the alrea
which a GM can use within the already established IKE SA with the GCKS (e. dy-established
g. for registering to another group). IKE SA with the GCKS (e.g., for registering to another
group).
</t> </t>
<t>Refreshing the group keys can be performed either in a unicast mode via
<t> Refreshing the group keys can be performed either in an unicast mode v the
ia the GSA_INBAND_REKEY exchange (<xref target="gsa_inband_rekey"/>) performed ov
GSA_INBAND_REKEY exchange (<xref target="gsa_inband_rekey" />) performed o er a specific IKE SA between a GM and a GCKS
ver a specific IKE SA between a GM and a GCKS or in a multicast mode with the GSA_REKEY pseudo-exchange (<xref target="g
or in a multicast mode with the GSA_REKEY pseudo exchange (<xref target="g sa_rekey"/>) when new keys are being distributed to all GMs.
sa_rekey" />), when new keys are being distributed to all GMs.
</t> </t>
<t>Large and small groups may use different sets of these mechanisms. <t>Large and small groups may use different sets of these mechanisms.
When a large group of devices are communicating, the GCKS is likely to When a large group of devices are communicating, the GCKS is likely to
use the GSA_REKEY message for efficiency. This is shown in <xref use the GSA_REKEY message for efficiency. This is shown in <xref target="l
target="large-groups"></xref>, where multicast communications indicated wi arge-groups"/>, where multicast communications are indicated with a double line.
th a double line. </t>
(Note: For clarity, IKE_SA_INIT is omitted from <xref target="large-groups <aside><t>Note: For clarity, IKE_SA_INIT is omitted from Figures <xref target="l
" /> and <xref target="small-groups" />).</t> arge-groups" format="counter"/> and <xref target="small-groups" format="counter"
/>.</t></aside>
<figure anchor="large-groups" title="G-IKEv2 used in large groups"> <figure anchor="large-groups">
<artwork align="center" name=""><![CDATA[ <name>G-IKEv2 Used in Large Groups</name>
<artwork name=""><![CDATA[
+--------+ +--------+
+----IKEv2---->| GCKS |<----IKEv2----+ +----IKEv2---->| GCKS |<----IKEv2----+
| +--------+ | | +--------+ |
| || ^ | | || ^ |
| || | | | || | |
| || GSA_AUTH | | || GSA_AUTH |
| || or | | || or |
| || GSA_REGISTRATION | | || GSA_REGISTRATION |
| || | | | || | |
GSA_AUTH || IKEv2 GSA_AUTH GSA_AUTH || IKEv2 GSA_AUTH
skipping to change at line 140 skipping to change at line 134
|| || || || || ||
*=====ESP/AH=====**=====ESP/AH====* *=====ESP/AH=====**=====ESP/AH====*
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Alternatively, a small group may simply use the GSA_AUTH or GSA_REGISTR ATION as <t>Alternatively, a small group may simply use the GSA_AUTH or GSA_REGISTR ATION as
registration protocols, where the GCKS issues rekeys using the registration protocols, where the GCKS issues rekeys using the
GSA_INBAND_REKEY within the same IKE SA. GSA_INBAND_REKEY within the same IKE SA.
</t> </t>
<figure anchor="small-groups" title="G-IKEv2 used in small groups"> <figure anchor="small-groups">
<artwork align="center" name=""><![CDATA[ <name>G-IKEv2 Used in Small Groups</name>
<artwork name=""><![CDATA[
GSA_AUTH or GSA_REGISTRATION, GSA_INBAND_REKEY GSA_AUTH or GSA_REGISTRATION, GSA_INBAND_REKEY
+--------------------IKEv2----------------------+ +--------------------IKEv2----------------------+
| | | |
| GSA_AUTH or GSA_REGISTRATION, | | GSA_AUTH or GSA_REGISTRATION, |
| GSA_INBAND_REKEY | | GSA_INBAND_REKEY |
| +-----------IKEv2-------------+ | | +-----------IKEv2-------------+ |
| | | | | | | |
| |GSA_AUTH or GSA_REGISTRATION,| | | |GSA_AUTH or GSA_REGISTRATION,| |
| | GSA_INBAND_REKEY | | | | GSA_INBAND_REKEY | |
| | +--IKEv2-+ | | | | +--IKEv2-+ | |
skipping to change at line 163 skipping to change at line 158
+---------+ +----+ +----+ +----+ +---------+ +----+ +----+ +----+
| GCKS/GM | | GM | | GM | | GM | | GCKS/GM | | GM | | GM | | GM |
+---------+ +----+ +----+ +----+ +---------+ +----+ +----+ +----+
|| || || || || || || ||
*==ESP/AH==**=====ESP/AH====**===ESP/AH===* *==ESP/AH==**=====ESP/AH====**===ESP/AH===*
]]></artwork> ]]></artwork>
</figure> </figure>
<t> A combination of these approaches is also possible. For example, <t> A combination of these approaches is also possible. For example,
the GCKS may use more robust GSA_INBAND_REKEY to provide keys for some GMs the 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 for the (for example, those acting as senders in the group) and GSA_REKEY for the
rest. rest.</t>
Note also, that GCKS may also be a GM (as shown in <xref target="small-gro <aside><t>Note: GCKS may also be a GM (as shown in <xref target="small-groups"/>
ups"></xref>). ).
</t> </t></aside>
<t>IKEv2 message semantics are preserved in that all communications <t>IKEv2 message semantics are preserved in that all communications
consists of message request-response pairs. The exception to this rule consist of message request-response pairs. The exception to this rule
is the GSA_REKEY pseudo-exchange, which is a single message delivering gro up is the GSA_REKEY pseudo-exchange, which is a single message delivering gro up
updates to the GMs.</t> updates to the GMs.</t>
<section>
<section title="Requirements Notation"> <name>Requirements Notation</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", <t>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"OPTIONAL" in this document are to be interpreted as described in BCP IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
and only when, they appear in all capitals, as shown here.</t> RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="terms">
<section title="Terminology" anchor="terms"> <name>Terminology</name>
<t> It is assumed that readers are familiar with the IPsec architecture <t> It is assumed that readers are familiar with the IPsec
<xref target="RFC4301" />, architecture <xref target="RFC4301"/> and its extension for multicast
and its extension for multicast <xref target="RFC5374" />. This document <xref target="RFC5374"/>. This document defines an extension to the
defines an extension to the IKEv2 protocol <xref target="RFC7296" /> IKEv2 protocol <xref target="RFC7296"/> and skips many of its
and skips many its details. The notation and conventions from <xref targ details. The notation and conventions from <xref target="RFC7296"/>
et="RFC7296" /> are used for describing G-IKEv2 payloads and exchanges. are used for describing G-IKEv2 payloads and exchanges.
</t> </t>
<t>The following key terms are used throughout this document (mostly bor <t>The following key terms are used throughout this document (mostly
rowed from Multicast Group Security Architecture <xref target="RFC3740" />, borrowed from <xref
Multicast Extensions to the Security Architecture <xref target="RFC53 target="RFC3740"/>, <xref target="RFC5374"/>, and <xref target="RFC6407"
74" /> and GDOI <xref target="RFC6407" />).</t> />).</t>
<dl anchor="definitions" newline="true"> <dl anchor="definitions" newline="true" spacing="normal">
<dt>Group</dt> <dt>Group:</dt>
<dd>A set of IPsec devices that communicate to each other using multic ast.</dd> <dd>A set of IPsec devices that communicate to each other using multic ast.</dd>
<dt>Group Member (GM):</dt>
<dt>Group Member (GM)</dt> <dd>An IPsec device that belongs to a group. A GM is
<dd>An IPsec device that belongs to a group. A Group Member is authorized to be a group sender and/or a group receiver.
authorized to be a Group Sender and/or a Group Receiver.
</dd> </dd>
<dt>Group Receiver:</dt>
<dt>Group Receiver</dt> <dd>A GM that is authorized to receive packets sent to a group by a gr
<dd>A Group Member that is authorized to receive packets sent to a gro oup sender.
up by a Group Sender.
</dd> </dd>
<dt>Group Sender:</dt>
<dt>Group Sender</dt> <dd>A GM that is authorized to send packets to a group.
<dd>A Group Member that is authorized to send packets to a group.
</dd> </dd>
<dt>Group Key Management (GKM) Protocol:</dt>
<dt>Group Key Management (GKM) Protocol</dt>
<dd>A key management protocol used by a GCKS to distribute IPsec <dd>A key management protocol used by a GCKS to distribute IPsec
Security Association policy and keying material. A GKM protocol Security Association policy and keying material. A GKM protocol
is needed because a group of IPsec devices require the same SAs. For is needed because a group of IPsec devices require the same SAs. For
example, when an IPsec SA describes an IP multicast destination, example, when an IPsec SA describes an IP multicast destination,
the sender and all receivers need to have the group SA. the sender and all receivers need to have the group SA.
</dd> </dd>
<dt>Group Controller/Key Server (GCKS):</dt>
<dt>Group Controller/Key Server (GCKS)</dt>
<dd>A Group Key Management (GKM) protocol server that manages IPsec <dd>A Group Key Management (GKM) protocol server that manages IPsec
state for a group. A GCKS authenticates and provides the IPsec SA state for a group. A GCKS authenticates and provides the IPsec SA
policy and keying material to GMs. policy and keying material to GMs.
</dd> </dd>
<dt>Data-Security SA:</dt>
<dt>Data-Security SA</dt>
<dd>A multicast SA between each multicast sender and the group's recei vers. <dd>A multicast SA between each multicast sender and the group's recei vers.
The Data-Security SA protects data between member senders and The Data-Security SA protects data between member senders and
member receivers. One or more SAs are required for the multicast trans mission of member receivers. One or more SAs are required for the multicast trans mission of
data-messages from the Group Sender to other group members. data messages from the group sender to other GMs.
This specification relies on ESP and AH as protocols for Data-Security This specification relies on Encapsulating Security Payload (ESP) and
SAs. Authentication Header (AH) as protocols for Data-Security SAs.
</dd> </dd>
<dt>Rekey SA:</dt>
<dt>Rekey SA</dt> <dd>A single multicast SA between the GCKS and all of the GMs.
<dd>A single multicast SA between the GCKS and all of the group member
s.
This SA is used for multicast transmission of key management messages from the GCKS to all GMs. This SA is used for multicast transmission of key management messages from the GCKS to all GMs.
</dd> </dd>
<dt>Group SA:</dt><dd>A Data-Security SA or Rekey SA that is shared as
<dt>Group Security Association (GSA)</dt> part of group policy.</dd>
<dd>A collection of Data-Security SAs and Rekey SA <dt>Group Security Association (GSA):</dt>
necessary for a Group Member to receive key updates. <dd>A collection of Data-Security SAs and Rekey SAs
A GSA describes the working policy for a group. Refer to MSEC Group K necessary for a GM to receive key updates.
ey Management Architecture <xref target="RFC4046" /> A GSA describes the working policy for a group. Refer to the MSEC Gro
up Key Management Architecture <xref target="RFC4046"/>
for additional information. for additional information.
</dd> </dd>
<dt>Traffic Encryption Key (TEK):</dt>
<dt>Traffic Encryption Key (TEK)</dt>
<dd>The symmetric cipher key used in a Data-Security SA (e.g., IPsec E SP) to protect traffic. <dd>The symmetric cipher key used in a Data-Security SA (e.g., IPsec E SP) to protect traffic.
</dd> </dd>
<dt>Key Encryption Key (KEK):</dt>
<dt>Key Encryption Key (KEK)</dt>
<dd>The symmetric key (or a set of keys) used in a Rekey SA to protect its messages. The set of keys may include keys <dd>The symmetric key (or a set of keys) used in a Rekey SA to protect its messages. The set of keys may include keys
for encryption and authentication, as well as keys for key wrapping. for encryption and authentication, as well as keys for key wrapping.
</dd> </dd>
<dt>Key Wrap Key (KWK):</dt>
<dt>Key Wrap Key (KWK)</dt>
<dd>The symmetric cipher key used to protect another key. <dd>The symmetric cipher key used to protect another key.
</dd> </dd>
<dt>Group-Wide (GW) policy:</dt>
<dt>Group-wide (GW) policy</dt>
<dd>Group policy not related to a particular SA. <dd>Group policy not related to a particular SA.
</dd> </dd>
<dt>Activation Time Delay (ATD):</dt>
<dt>Activation Time Delay (ATD)</dt> <dd>Defines how long group senders should wait after receiving new SAs
<dd>Defines how long Group Senders should wait after receiving new SAs before sending traffic over them.
before starting sending traffic over them.
</dd> </dd>
<dt>Deactivation Time Delay (DTD):</dt>
<dt>Deactivation Time Delay (DTD)</dt> <dd>Defines how long GMs should wait after receiving a request to dele
<dd>Defines how long Group Members should wait after receiving a reque te Data-Security SAs before actually deleting them.
st to delete Data-Security SAs before actually deleting them.
</dd> </dd>
<dt>Sender-ID:</dt>
<dt>Sender-ID</dt> <dd>A unique identifier of a group sender in the context of an active
<dd>A unique identifier of a Group Sender in the context of an active GSA used to form the Initialization Vector (IV) in counter-based cipher modes.
GSA, used to form Initialization Vector (IV) in counter-based cipher modes.
</dd> </dd>
<dt>Logical Key Hierarchy (LKH):</dt>
<dt>Logical Key Hierarchy (LKH)</dt> <dd>A group management method defined in <xref target="RFC2627" sectio
<dd>A group management method defined in Section 5.4 of Key Management nFormat="of" section="5.4"/>.
for Multicast <xref target="RFC2627" />.
</dd> </dd>
</dl> </dl>
</section> </section>
</section> </section>
<section>
<section title="G-IKEv2 Protocol"> <name>G-IKEv2 Protocol</name>
<t>G-IKEv2 is an extension to the IKEv2 protocol <xref target="RFC7296" <t>G-IKEv2 is an extension to the IKEv2 protocol <xref target="RFC7296"/>
/> that provides group authorization, that provides group authorization,
secure policy and keys download from the GCKS to GMs. secure policy, and keys download from the GCKS to GMs.
</t> </t>
<section>
<section title="G-IKEv2 Integration into IKEv2 Protocol"> <name>G-IKEv2 Integration into the IKEv2 Protocol</name>
<t>G-IKEv2 is compatible with most IKEv2 extensions defined so far (see <t>G-IKEv2 is compatible with most IKEv2 extensions defined so far (see
<xref target="ike_ext" /> for details). <xref target="ike_ext"/> for details).
In particular, it is assumed that, if necessary, the IKE_INTERMEDIATE ex In particular, it is assumed that, if necessary, the IKE_INTERMEDIATE ex
changes <xref target="RFC9242" /> may be utilized changes <xref target="RFC9242"/> may be utilized
while establishing the registration SA. It is also believed that while establishing the registration SA. It is also believed that
future IKEv2 extensions will be possible to use with G-IKEv2, however, s ome IKEv2 extensions may require future IKEv2 extensions will be possible to use with G-IKEv2. However, s ome IKEv2 extensions may require
special handling when used with G-IKEv2.</t> special handling when used with G-IKEv2.</t>
<section>
<section title="G-IKEv2 Transport and Port"> <name>G-IKEv2 Transport and Port</name>
<t> As IKEv2 extension, G-IKEv2 <bcp14>SHOULD</bcp14> use the IKEv2 po <t> As an IKEv2 extension, G-IKEv2 <bcp14>SHOULD</bcp14> use the IKEv2
rts (500, 4500). ports (500, 4500).
G-IKEv2 <bcp14>MAY</bcp14> also use TCP transport for registration (un G-IKEv2 <bcp14>MAY</bcp14> use TCP transport for the IKE SA used for registratio
icast) IKE SA, n (which is unicast),
as defined in TCP Encapsulation of IKEv2 and IPsec <xref target="RFC93 as defined in TCP Encapsulation of IKEv2 and IPsec <xref target="RFC9329"/>.
29" />. G-IKEv2 <bcp14>MAY</bcp14> also use UDP port 848, the same as Group Do
G-IKEv2 <bcp14>MAY</bcp14> also use UDP port 848, the same as GDOI <xr main of Interpretation (GDOI) <xref target="RFC6407"/>, because they serve a sim
ef ilar function.
target="RFC6407"></xref>, because they serve a similar function.
The version number in the IKE header distinguishes the G-IKEv2 The version number in the IKE header distinguishes the G-IKEv2
protocol from GDOI protocol <xref target="RFC6407"></xref>. protocol from the GDOI protocol <xref target="RFC6407"/>.
</t> </t>
<t><xref target="RFC7296" sectionFormat="of"
<t>Section 2.23 of IKEv2 <xref target="RFC7296" /> describes how IKEv2 section="2.23"/> describes how IKEv2 supports paths with NATs.
supports paths with NATs. The G-IKEv2 registration SA doesn't create any unicast IPsec SAs; thus
G-IKEv2 registration SA doesn't create any unicast IPsec SAs, thus if ,
a NAT is present between the GM and the GCKS, there is no unicast if a NAT is present between the GM and the GCKS, there is no unicast
ESP traffic to encapsulate in UDP. However, the actions described ESP traffic to encapsulate in UDP. However, the actions described in
in this section regarding the IKE SA <bcp14>MUST</bcp14> be honored. this section regarding the IKE SA <bcp14>MUST</bcp14> be honored.
The behavior of GMs and GCKS <bcp14>MUST NOT</bcp14> depend on the por The behavior of GMs and GCKS <bcp14>MUST NOT</bcp14> depend on the
t used to create the initial IKE SA. port used to create the initial IKE SA. For example, if the GM and
For example, if the GM and the GCKS used UDP port 848 for the IKE_SA_I the GCKS used UDP port 848 for the IKE_SA_INIT exchange, they will
NIT exchange, they operate the same as if they had used UDP port 500.
will operate the same as if they had used UDP port 500.
</t> </t>
</section> </section>
</section> </section>
<section>
<section title="G-IKEv2 Payloads"> <name>G-IKEv2 Payloads</name>
<t>In the following descriptions, the payloads contained in the G-IKEv <t>In the following descriptions, the payloads contained in the G-IKEv2
2 messages are indicated by names as listed below.</t>
messages are indicated by names as listed below.</t> <table>
<name>Payloads Used in G-IKEv2</name>
<table title="Payloads used in G-IKEv2"> <thead>
<thead> <tr>
<tr> <th>Notation</th>
<th>Notation</th><th>Payload</th><th>Defined in</th> <th>Payload</th>
</tr> <th>Defined in</th>
</thead> </tr>
<tbody> </thead>
<tr> <tbody>
<td>AUTH</td><td>Authentication</td><td><xref target="RFC7296"/> <tr>
</td> <td>AUTH</td>
</tr> <td>Authentication</td>
<tr> <td>
<td>CERT</td><td>Certificate</td><td><xref target="RFC7296"/></t <xref target="RFC7296"/></td>
d> </tr>
</tr> <tr>
<tr> <td>CERT</td>
<td>CERTREQ</td><td>Certificate Request</td><td><xref target="RF <td>Certificate</td>
C7296"/></td> <td>
</tr> <xref target="RFC7296"/></td>
<tr> </tr>
<td>D</td><td>Delete</td><td><xref target="RFC7296"/></td> <tr>
</tr> <td>CERTREQ</td>
<tr> <td>Certificate Request</td>
<td>GSA</td><td>Group Security Association</td><td><xref target= <td>
"gsa_payload"/></td> <xref target="RFC7296"/></td>
</tr> </tr>
<tr> <tr>
<td>HDR</td><td>IKEv2 Header</td><td><xref target="RFC7296"/></t <td>D</td>
d> <td>Delete</td>
</tr> <td>
<tr> <xref target="RFC7296"/></td>
<td>IDg</td><td>Identification - Group</td><td><xref target="idg </tr>
_payload"/></td> <tr>
</tr> <td>GSA</td>
<tr> <td>Group Security Association</td>
<td>IDi</td><td>Identification - Initiator</td><td><xref target= <td>
"RFC7296"/></td> <xref target="gsa_payload"/></td>
</tr> </tr>
<tr> <tr>
<td>IDr</td><td>Identification - Responder</td><td><xref target= <td>HDR</td>
"RFC7296"/></td> <td>IKE header (not a payload)</td>
</tr> <td>
<tr> <xref target="RFC7296"/></td>
<td>KD</td><td>Key Download</td><td><xref target="kd_payload"/>< </tr>
/td> <tr>
</tr> <td>IDg</td>
<tr> <td>Group Identification</td>
<td>KE</td><td>Key Exchange</td><td><xref target="RFC7296"/></td <td>
> <xref target="idg_payload"/></td>
</tr> </tr>
<tr> <tr>
<td>Ni, Nr</td><td>Nonce</td><td><xref target="RFC7296"/></td> <td>IDi</td>
</tr> <td>Identification - Initiator</td>
<tr> <td>
<td>N</td><td>Notify</td><td><xref target="RFC7296"/></td> <xref target="RFC7296"/></td>
</tr> </tr>
<tr> <tr>
<td>SA</td><td>Security Association</td><td><xref target="RFC729 <td>IDr</td>
6"/></td> <td>Identification - Responder</td>
</tr> <td>
<tr> <xref target="RFC7296"/></td>
<td>SAg</td><td>Security Association - GM Supported Transforms</ </tr>
td><td><xref target="sag_payload"/></td> <tr>
</tr> <td>KD</td>
<tr> <td>Key Download</td>
<td>SK</td><td>Encrypted</td><td><xref target="RFC7296"/></td> <td>
</tr> <xref target="kd_payload"/></td>
</tbody> </tr>
</table> <tr>
<td>KE</td>
<t> Payloads defined as part of other IKEv2 extensions <bcp14>MAY</bcp <td>Key Exchange</td>
14> also be included in <td>
<xref target="RFC7296"/></td>
</tr>
<tr>
<td>Ni, Nr</td>
<td>Nonce</td>
<td>
<xref target="RFC7296"/></td>
</tr>
<tr>
<td>N</td>
<td>Notify</td>
<td>
<xref target="RFC7296"/></td>
</tr>
<tr>
<td>SA</td>
<td>Security Association</td>
<td>
<xref target="RFC7296"/></td>
</tr>
<tr>
<td>SAg</td>
<td>Security Association - GM Supported Transforms</td>
<td>
<xref target="sag_payload"/></td>
</tr>
<tr>
<td>SK</td>
<td>Encrypted and Authenticated (also known as Encrypted)</td>
<td>
<xref target="RFC7296"/></td>
</tr>
</tbody>
</table>
<t> Payloads defined as part of other IKEv2 extensions <bcp14>MAY</bcp14
> also be included in
these messages. Payloads that may optionally appear in G-IKEv2 message s these messages. Payloads that may optionally appear in G-IKEv2 message s
will be shown in brackets, such as [CERTREQ]. will be shown in brackets, such as [CERTREQ].
</t> </t>
<t>G-IKEv2 defines several new payloads not used in IKEv2:</t>
<t>G-IKEv2 defines several new payloads not used in IKEv2:</t> <dl newline="true" spacing="normal">
<t><list style="symbols"> <dt>Group Identification (IDg):</dt><dd>The GM requests the GCKS for m
<t>IDg (Group ID) -- The GM requests the GCKS for membership into embership
the group by sending its IDg payload.</t> into the group by sending its IDg payload.</dd>
<dt>Security Association - GM Supported
<t>SAg (Security Association -- GM Supported Transforms) -- the GM o Transforms (SAg):</dt><dd>The GM optionally sends supported transforms
ptionally sends so
supported transforms, so that GCKS may select a policy appropriate f that GCKS may select a policy appropriate for all members of the
or all members group (which is not negotiated, unlike SA parameters in IKEv2).</dd>
of the group (which is not negotiated, unlike SA parameters in IKEv2 <dt>Group Security Association (GSA):</dt><dd>The GCKS sends the
).</t> group policy to the GM using this payload.</dd>
<dt>Key Download (KD):</dt><dd>The GCKS sends the keys and the
<t>GSA (Group Security Association) -- The GCKS sends the group security parameters to the GMs using this payload.</dd>
policy to the GM using this payload.</t> </dl>
<t> The details of the contents of each payload are described in <xref t
<t>KD (Key Download) -- The GCKS sends the keys and the security par arget="header_payload"/>.
ameters </t>
to the GMs using this payload.</t>
</list></t>
<t> The details of the contents of each payload are described in <xref
target="header_payload"></xref>.
</t>
</section> </section>
<section anchor="registration">
<section title="G-IKEv2 Member Registration and Secure Channel Establishme <name>G-IKEv2 Member Registration and Secure Channel Establishment</name
nt" anchor="registration"> >
<t>Initial registration is combined with establishing a secure connectio n between the <t>Initial registration is combined with establishing a secure connectio n between the
entity seeking registration and the GCKS. This process consists of a min imum of two entity seeking registration and the GCKS. This process consists of a min imum of two
exchanges, IKE_SA_INIT and GSA_AUTH; member registration may have a exchanges, IKE_SA_INIT and GSA_AUTH; member registration may have a
few more messages exchanged if the EAP method, cookie challenge (for few more messages exchanged if the Extensible Authentication Protocol (E
DoS protection), negotiation of key exchange method or IKEv2 extensions AP) method, cookie challenge (for
based on the IKEv2 Intermediate exchange <xref target="RFC9242" /> DoS protection), negotiation of key exchange method, or IKEv2 extensions
are used. Each exchange consists of request/response pairs. The first ex based on the IKEv2 Intermediate Exchange <xref target="RFC9242"/>
change are used. Each exchange consists of request/response pairs. The first ex
IKE_SA_INIT is defined in IKEv2 <xref target="RFC7296"></xref>. This change, called
exchange negotiates cryptographic algorithms, exchanges nonces and IKE_SA_INIT, is defined in IKEv2 <xref target="RFC7296"/>.
This
exchange negotiates cryptographic algorithms, exchanges nonces, and
computes a shared key between the GM and the GCKS. computes a shared key between the GM and the GCKS.
In addition to the cryptographic algorithms negotiated for use in IKEv2 SA, In addition to the cryptographic algorithms negotiated for use in IKEv2 SA,
a key wrap algorithm is also negotiated in this exchange by means of a n ew "Key Wrap Algorithm" transform. a key wrap algorithm is also negotiated in this exchange by means of a n ew "Key Wrap Algorithm" transform.
See <xref target="wrapped_key" /> for details. See <xref target="wrapped_key"/> for details.
</t> </t>
<t>The second exchange, called GSA_AUTH, is similar to the IKEv2 IKE_AUT
<t>The second exchange called GSA_AUTH is similar to the IKEv2 IKE_AUTH H exchange <xref target="RFC7296"/>.
exchange <xref target="RFC7296"></xref>. It authenticates the previously exchanged messages and exchanges identit
It authenticates the previously exchanged messages, exchanges identities ies and certificates.
and certificates.
The GSA_AUTH messages are encrypted and integrity protected with keys es tablished through the previous The GSA_AUTH messages are encrypted and integrity protected with keys es tablished through the previous
exchanges, so the identities are hidden from eavesdroppers and all exchanges, so the identities are hidden from eavesdroppers and all
fields in all the messages are authenticated. The GCKS authorizes fields in all the messages are authenticated. The GCKS authorizes
group members to be allowed into the group as part of the GMs to be allowed into the group as part of the
GSA_AUTH exchange. Once the GCKS accepts a GM to join a GSA_AUTH exchange. Once the GCKS accepts a GM to join a
group it will provide the GM with the data-security keys (TEKs) and/or g roup key group, it will provide the GM with the data-security keys (TEKs) and/or a group key
encrypting key (KEK) as part of the GSA_AUTH response message. </t> encrypting key (KEK) as part of the GSA_AUTH response message. </t>
<t>The established secure channel between the GM and the GCKS is in fact IKE SA (as defined in <t>The established secure channel between the GM and the GCKS is in fact IKE SA (as defined in
<xref target="RFC7296"></xref>) and is referred to as such throughout th is document. <xref target="RFC7296"/>) and is referred to as such throughout this doc ument.
However, it is <bcp14>NOT RECOMMENDED</bcp14> to use this IKE SA for the purpose of creating However, it is <bcp14>NOT RECOMMENDED</bcp14> to use this IKE SA for the purpose of creating
unicast Child SAs between the GM and the GCKS, since authentication requ unicast Child SAs between the GM and the GCKS since authentication requi
irements for rements for
group admission and for unicast communication may differ. In addition, t group admission and for unicast communication may differ. In addition, t
he lifecycle he life cycle
of this IKE SA is determined by the GCKS and this SA can be deleted at a ny time. of this IKE SA is determined by the GCKS and this SA can be deleted at a ny time.
</t> </t>
<section anchor="gsa_auth">
<section anchor="gsa_auth" title="GSA_AUTH Exchange"> <name>GSA_AUTH Exchange</name>
<t>The GSA_AUTH exchange is used to authenticate the previous exchange <t>The GSA_AUTH exchange is used to authenticate the previous exchange
s, s and
exchange identities and certificates. G-IKEv2 also uses this exchange identities and certificates. G-IKEv2 also uses this
exchange for group member registration and authorization. exchange for GM registration and authorization.
</t> </t>
<t> The GSA_AUTH exchange is similar to the IKE_AUTH exchange with the <t> The GSA_AUTH exchange is similar to the IKE_AUTH exchange with the
difference that its goal is to establish multicast Data-Security SA(s) difference that its goal is to establish a multicast Data-Security SA(
and optionally provide GM with the keys for Rekey SA. The set of paylo s)
ads and optionally provide GM with the keys for a Rekey SA. The set of pay
in the GSA_AUTH exchange is slightly different, because policy is not loads
negotiated between the group member and the GCKS, but instead in the GSA_AUTH exchange is slightly different because policy is not
provided by the GCKS for the GM. Note also, that GSA_AUTH negotiated between the GM and the GCKS; 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 IKE_AUTH exchan ge type. has its own exchange type, which is different from the IKE_AUTH exchan ge type.
</t> </t>
<aside><t>Note: Due to the similarities between IKE_AUTH and GSA_AUTH,
<t>Note, that due to the similarities between IKE_AUTH and GSA_AUTH,
most IKEv2 extensions to the IKE_AUTH exchange most IKEv2 extensions to the IKE_AUTH exchange
(like Secure Password authentication <xref target="RFC6467" />) can al (like secure password authentication <xref target="RFC6467"/>) can als
so be used with the GSA_AUTH exchange. o be used with the GSA_AUTH exchange.
</t> </t></aside>
<figure title="GSA_AUTH Request" anchor="gsa_auth_request">
<preamble></preamble>
<artwork><![CDATA[ <figure anchor="gsa_auth_request">
<name>GSA_AUTH Request</name>
<artwork><![CDATA[
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]} -->
]]></artwork> ]]></artwork>
<postamble></postamble>
</figure> </figure>
<t>A group member initiates a GSA_AUTH request to join a group indicat ed <t>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 by the IDg payload. The GM may include an SAg payload declaring which
Transforms it is willing to accept. A GM that intends to act as Group Sender Transforms it is willing to accept. A GM that intends to act as group sender
<bcp14>MUST</bcp14> include a Notify payload status type of GROUP_SEND ER, <bcp14>MUST</bcp14> include a Notify payload status type of GROUP_SEND ER,
which enables the GCKS to provide any additional policy necessary by which enables the GCKS to provide any additional policy necessary by
group senders.</t> group senders.</t>
<figure title="GSA_AUTH Normal Response" anchor="gsa_auth_norm_respons <figure anchor="gsa_auth_norm_response">
e"> <name>GSA_AUTH Normal Response</name>
<preamble></preamble> <artwork><![CDATA[
<artwork><![CDATA[
Initiator (GM) Responder (GCKS) Initiator (GM) Responder (GCKS)
-------------------- ------------------ -------------------- ------------------
<-- HDR, SK{IDr, [CERT,] <-- HDR, SK{IDr, [CERT,]
AUTH, GSA, KD, [N]} AUTH, GSA, KD, [N]}
]]></artwork> ]]></artwork>
<postamble></postamble>
</figure> </figure>
<t> The GCKS responds with IDr, optional CERT, and AUTH payloads <t> The GCKS responds with IDr, optional CERT, and AUTH payloads
with the same meaning as in IKE_AUTH. It also informs the group member with the same meaning as in IKE_AUTH. It also informs the GM
of the cryptographic policies of the group in the GSA payload and of the cryptographic policies of the group in the GSA payload and
the key material in the KD payload. the key material in the KD payload.
</t> </t>
<t> Possible errors should be handled in accordance with <xref target=
<t> Possible erors should be handled in accordance with Section 2.21.2 "RFC7296" sectionFormat="of" section="2.21.2"/>.
of <xref target="RFC7296"/>.
In addition to the IKEv2 error handling, the GCKS can reject the In addition to the IKEv2 error handling, the GCKS can reject the
registration request when the IDg is invalid or authorization fails, registration request when the IDg is invalid or authorization fails,
etc. In these cases, see <xref target="notify"></xref>, the GSA_AUTH etc. In these cases (see <xref target="notify"/>), the GSA_AUTH
response will not include the GSA and KD, but will include a Notify response will not include the GSA and KD but will include a Notify
payload indicating errors. If a GM included an SAg payload indicating errors. If a GM included an SAg
payload, and the GCKS chooses to evaluate it, and the GCKS detects tha payload and the GCKS chooses to evaluate it and detects that
t the GM cannot support the security policy defined for the
the group member cannot support the security policy defined for the
group, then the GCKS returns the NO_PROPOSAL_CHOSEN notification. group, then the GCKS returns the NO_PROPOSAL_CHOSEN notification.
Other types of error notifications can be INVALID_GROUP_ID, AUTHORIZAT ION_FAILED or REGISTRATION_FAILED.</t> Other types of error notifications can be INVALID_GROUP_ID, AUTHORIZAT ION_FAILED, or REGISTRATION_FAILED.</t>
<figure title="GSA_AUTH Error Response for Group-Related Errors" ancho <figure anchor="gsa_auth_err_response">
r="gsa_auth_err_response"> <name>GSA_AUTH Error Response for Group-Related Errors</name>
<preamble></preamble> <artwork><![CDATA[
<artwork><![CDATA[
Initiator (GM) Responder (GCKS) Initiator (GM) Responder (GCKS)
-------------------- ------------------ -------------------- ------------------
<-- HDR, SK{IDr, [CERT,] AUTH, N} <-- HDR, SK{IDr, [CERT,] AUTH, N}
]]></artwork> ]]></artwork>
<postamble></postamble>
</figure> </figure>
<t>If the GSA_AUTH exchange is completed successfully, but <t>If the GSA_AUTH exchange is completed successfully but
the group member finds the policy sent by the GCKS is the GM finds that the policy sent by the GCKS is
unacceptable, the member <bcp14>SHOULD</bcp14> inform the GCKS about t his by initiating the GSA_REGISTRATION exchange unacceptable, the member <bcp14>SHOULD</bcp14> inform the GCKS about t his by initiating the GSA_REGISTRATION exchange
with the IDg payload and the NO_PROPOSAL_CHOSEN notification with the IDg payload and the NO_PROPOSAL_CHOSEN notification
(see <xref target="gsa_registration_gm_error" />). (see <xref target="gsa_registration_gm_error"/>).
</t> </t>
</section> </section>
<section anchor="gsa_registration">
<section anchor="gsa_registration" title="GSA_REGISTRATION Exchange"> <name>GSA_REGISTRATION Exchange</name>
<t>Once the IKE SA between the GM and the GCKS is established, <t>Once the IKE SA between the GM and the GCKS is established,
the GM can use it for other registration requests, if this is needed. the GM can use it for other registration requests if needed.
In this scenario the GM will use the In this scenario, the GM will use the
GSA_REGISTRATION exchange. Payloads in the exchange are generated GSA_REGISTRATION exchange. Payloads in the exchange are generated
and processed as defined in <xref target="gsa_auth"></xref>.</t> and processed as defined in <xref target="gsa_auth"/>.</t>
<figure title="GSA_REGISTRATION Normal Exchange" anchor="gsa_registrat <figure anchor="gsa_registration_exchange">
ion_exchange"> <name>GSA_REGISTRATION Normal Exchange</name>
<preamble></preamble> <artwork><![CDATA[
<artwork><![CDATA[
Initiator (GM) Responder (GCKS) Initiator (GM) Responder (GCKS)
-------------------- ------------------ -------------------- ------------------
HDR, SK{IDg, [SAg,] HDR, SK{IDg, [SAg,]
[N(GROUP_SENDER),] [N]} --> [N(GROUP_SENDER),] [N]} -->
<-- HDR, SK{GSA, KD, [N]} <-- HDR, SK{GSA, KD, [N]}
]]></artwork> ]]></artwork>
<postamble></postamble>
</figure> </figure>
<t>As with GSA_AUTH exchange, the GCKS can reject the <t>As with GSA_AUTH exchange, the GCKS can reject the
registration request when the IDg is invalid or authorization fails, registration request when the IDg is invalid or authorization fails,
or GM cannot support the security policy defined for the or GM cannot support the security policy defined for the
group (which can be concluded by GCKS by evaluation of SAg payload). group (which can be concluded by the GCKS by evaluation of the SAg pay
In this case the GCKS returns an appropriate error notification load).
as described in <xref target="gsa_auth" />. In this case, the GCKS returns an appropriate error notification
as described in <xref target="gsa_auth"/>.
</t> </t>
<figure title="GSA_REGISTRATION Error Exchange" anchor="gsa_registrati <figure anchor="gsa_registration_err_exchange">
on_err_exchange"> <name>GSA_REGISTRATION Error Exchange</name>
<preamble></preamble> <artwork><![CDATA[
<artwork><![CDATA[
Initiator (GM) Responder (GCKS) Initiator (GM) Responder (GCKS)
-------------------- ------------------ -------------------- ------------------
HDR, SK{IDg, [SAg,] HDR, SK{IDg, [SAg,]
[N(GROUP_SENDER),] [N]} --> [N(GROUP_SENDER),] [N]} -->
<-- HDR, SK{N} <-- HDR, SK{N}
]]></artwork> ]]></artwork>
<postamble></postamble> </figure>
</figure>
<t>This exchange can also be used if the group member finds the <t>This exchange can also be used if the GM finds that the
policy sent by the GCKS is unacceptable or for some reason wants to le policy sent by the GCKS is unacceptable or wants to leave
ave the group for some reason. The GM <bcp14>SHOULD</bcp14>
the group. The group member <bcp14>SHOULD</bcp14>
notify the GCKS by sending IDg and the Notify type notify the GCKS by sending IDg and the Notify type
NO_PROPOSAL_CHOSEN or REGISTRATION_FAILED, as shown below. NO_PROPOSAL_CHOSEN or REGISTRATION_FAILED as shown below.
The GCKS in this case <bcp14>MUST</bcp14> remove the GM from the group In this case, the GCKS <bcp14>MUST</bcp14> remove the GM from the grou
IDg. p denoted in IDg.
</t> </t>
<figure title="GM Reporting Errors in GSA_REGISTRATION Exchange" ancho <figure anchor="gsa_registration_gm_error">
r="gsa_registration_gm_error"> <name>GM Reporting Errors in GSA_REGISTRATION Exchange</name>
<preamble></preamble> <artwork><![CDATA[
<artwork><![CDATA[
Initiator (GM) Responder (GCKS) Initiator (GM) Responder (GCKS)
-------------------- ------------------ -------------------- ------------------
HDR, SK{IDg, N} --> HDR, SK{IDg, N} -->
<-- HDR, SK{} <-- HDR, SK{}
]]></artwork> ]]></artwork>
</figure> </figure>
</section>
<section title="GM Registration Operations"> </section>
<section>
<name>GM Registration Operations</name>
<t>A GM requesting registration contacts the <t>A GM requesting registration contacts the
GCKS using the IKE_SA_INIT exchange. This exchange is unchanged from I KE_SA_INIT GCKS using the IKE_SA_INIT exchange. This exchange is unchanged from I KE_SA_INIT
in the IKEv2 protocol. The IKE_SA_INIT exchange may optionally be foll in the IKEv2 protocol.
owed
by one or more the IKE_INTERMEDIATE exchanges if the GM and the GCKS The IKE_SA_INIT exchange may optionally be followed
by one or more of the IKE_INTERMEDIATE exchanges if the GM and the GCK
S
negotiated use of IKEv2 extensions based on this exchange. negotiated use of IKEv2 extensions based on this exchange.
</t> </t>
<t>Next, the GM sends the GSA_AUTH request message with the IKEv2 payl
<t>Next the GM sends the GSA_AUTH request message with the IKEv2 paylo oads
ads from IKE_AUTH (without the SAi2, TSi, and TSr payloads) along with
from IKE_AUTH (without the SAi2, TSi and TSr payloads) along with
the Group ID informing the GCKS of the group the GM wishes to the Group ID informing the GCKS of the group the GM wishes to
join. An GM intending to emit data traffic <bcp14>MUST</bcp14> send a join. A GM intending to emit data traffic <bcp14>MUST</bcp14> send a
GROUP_SENDER Notify message type. The GROUP_SENDER notification not on GROUP_SENDER notification. The GROUP_SENDER notification not only sign
ly signifies that it ifies that it
is a sender, but provides the GM the ability to request is a sender but provides the GM the ability to request
Sender-ID values, in case the Data-Security SA supports a counter Sender-ID values in case the Data-Security SA supports a counter-mode
mode cipher. <xref target="sid_alloc"></xref> includes guidance cipher. <xref target="sid_alloc"/> includes guidance
on requesting Sender-ID values.</t> on requesting Sender-ID values.</t>
<t>A GM may be limited in the Transforms IDs that it is <t>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 able or willing to use and may find it useful to inform the GCKS
which Transform IDs it is willing to accept for different security pro tocols which Transform IDs it is willing to accept for different security pro tocols
by including the SAg payload into the request message. by including the SAg payload into the request message.
Proposals for Rekey SA and for Data-Security Proposals for Rekey SA and for Data-Security
(AH <xref target="RFC4302" /> and/or ESP <xref target="RFC4303" />) SA s (AH <xref target="RFC4302"/> and/or ESP <xref target="RFC4303"/>) SAs
may be included into SAg. Proposals for Rekey SA are identified may be included into SAg. Proposals for Rekey SA are identified
by a new Protocol ID GIKE_UPDATE with the value &lt;TBA by IANA&gt;. by a new Security Protocol Identifier GIKE_UPDATE with the value 6.
Each Proposal contains a list of Transforms that the GM is able Each Proposal contains a list of Transforms that the GM is able
and willing to support for that protocol. Valid transform types depend and willing to support for that protocol. Valid Transform Types depend
on the on the
protocol (AH, ESP, GIKE_UPDATE) and are defined in <xref target="allow protocol (AH, ESP, GIKE_UPDATE) and are defined in <xref target="allow
ed_transforms" />. ed_transforms"/>.
Other transform types <bcp14>SHOULD NOT</bcp14> be included as they wi Other Transform Types <bcp14>SHOULD NOT</bcp14> be included as they wi
ll be ignored by the GCKS. ll be ignored by the GCKS.
The SPI length of each Proposal in an SAg is set to zero, and thus the The Security Parameter Index (SPI) length of each Proposal in an SAg i
SPI field is empty. s set to zero, and thus the SPI field is empty.
The GCKS <bcp14>MUST NOT</bcp14> use SPI length and SPI fields in the SAg payload. The GCKS <bcp14>MUST NOT</bcp14> use SPI length and SPI fields in the SAg payload.
</t> </t>
<t>Generally, a single Proposal for each protocol (GIKE_UPDATE,
<t>Generally, a single Proposal for each protocol (GIKE_UPDATE, AH/ESP AH/ESP) will suffice. Because the transforms are not negotiated, the
) GM simply alerts the GCKS to restrictions it may have. In
will suffice, because the transforms are not negotiated, the GM particular, the restriction from <xref target="RFC7296"
simply alerts the GCKS to restrictions it may have. sectionFormat="of" section="3.3"/> that Authenticated Encryption with
In particular, the restriction from Section 3.3 of IKEv2 <xref target= Associated Data (AEAD) and non-AEAD
"RFC7296" /> that transforms not be combined in a single proposal doesn't hold when
AEAD and non-AEAD transforms not be combined in a single proposal the SAg payload is being formed. However, if the GM has restrictions
doesn't hold when the SAg payload is being formed. However on the combination of algorithms, this can be expressed by sending
if the GM has restrictions on combination of algorithms, several proposals.</t>
this can be expressed by sending several proposals.</t> <t>The Proposal Num field in the Proposal substructure is treated spec
ially in the SAg payload:
<t>Proposal Num field in Proposal substructure is treated specially in
SAg payload:
it allows a GM to indicate that algorithms used in Rekey SA and in it allows a GM to indicate that algorithms used in Rekey SA and in
Data-Security (AH and/or ESP) SAs are dependent. Data-Security (AH and/or ESP) SAs are dependent.
In particular, Proposals for different protocols having the same value In particular, Proposals for different protocols having the same value
in in the
Proposal Num field are treated as a set, so that if GCKS uses transfor Proposal Num field are treated as a set so that if GCKS uses transform
ms s
from one of such Proposal for one protocol, then it <bcp14>MUST</bcp14 > only use transforms from from one of such Proposal for one protocol, then it <bcp14>MUST</bcp14 > only use transforms from
one of the Proposals with the same value in Proposal Num field for oth er protocols. one of the Proposals with the same value in the Proposal Num field for other protocols.
For example, a GM may support algorithms X and Y for both Rekey and For example, a GM may support algorithms X and Y for both Rekey and
Data-Security SAs, but with a restriction that if X is used in Rekey S A, then only X can be used Data-Security SAs, but with a restriction that if X is used in Rekey SAs, then only X can be used
in Data-Security SAs, and the same for Y. in Data-Security SAs, and the same for Y.
Use of the same value in the Proposal Num field of different Use of the same value in the Proposal Num field of different
proposals indicates that the GM expects these proposals to be proposals indicates that the GM expects these proposals to be
used in conjunction with each other. used in conjunction with each other.
In the simplest case when no dependency between transforms exists, In the simplest case when no dependency between transforms exists,
all Proposals in SAg payload will have the same value in Proposal Num field. all Proposals in the SAg payload will have the same value in the Propo sal Num field.
</t> </t>
<t>Although the SAg payload is optional, it is <bcp14>RECOMMENDED</bcp
<t>Although the SAg payload is optional, it is <bcp14>RECOMMENDED</bcp 14> that the GM include
14> for the GM to include
this payload into the GSA_AUTH request to allow the GCKS to select an appropriate policy. this payload into the GSA_AUTH request to allow the GCKS to select an appropriate policy.
</t> </t>
<t>A GM <bcp14>MAY</bcp14> also indicate the support for IPcomp by inc luding one or more the IPCOMP_SUPPORTED <t>A GM <bcp14>MAY</bcp14> also indicate the support for IPcomp by inc luding one or more the IPCOMP_SUPPORTED
notifications along with the SAg payload in the request. The Compressi on Parameter Index (CPI) in these notifications is set to zero notifications along with the SAg payload in the request. The Compressi on Parameter Index (CPI) in these notifications is set to zero
and <bcp14>MUST</bcp14> be ignored by the GCKS. and <bcp14>MUST</bcp14> be ignored by the GCKS.
</t> </t>
<t>Upon receiving the GSA_AUTH response, the GM parses the <t>Upon receiving the GSA_AUTH response, the GM parses the
response from the GCKS authenticating the exchange using the IKEv2 response from the GCKS authenticating the exchange using the IKEv2
method, then processes the GSA and KD payloads.</t> method, then processes the GSA and KD payloads.</t>
<t>The GSA payload contains the security policy and cryptographic <t>The GSA payload contains the security policy and cryptographic
protocols used by the group. This policy describes the optional Rekey protocols used by the group.
SA
(KEK), Data-Security SAs (TEK), and optional Group-wide (GW) policy. This policy describes zero or more Data-Security SAs (TEK), zero or one Rekey SA
(KEK), and zero or one GW policy (although at least one TEK or KEK policy <bcp1
4>MUST</bcp14> be
Present).
If the policy in the GSA payload is not acceptable to the GM, If the policy in the GSA payload is not acceptable to the GM,
it <bcp14>SHOULD</bcp14> notify the GCKS by initiating a GSA_REGISTRAT ION exchange it <bcp14>SHOULD</bcp14> notify the GCKS by initiating a GSA_REGISTRAT ION exchange
with a NO_PROPOSAL_CHOSEN Notify payload (see <xref target="gsa_regist with a NO_PROPOSAL_CHOSEN Notify payload (see <xref target="gsa_regist
ration"></xref>). ration"/>).
Note, that this should normally not happen if the GM includes SAg payl Note that this should normally not happen if the GM includes the SAg p
oad ayload
in the GSA_AUTH request and the GCKS takes it into account. in the GSA_AUTH request and the GCKS takes it into account.
Finally the KD payload is parsed providing the keying material for the TEK and/or KEK. Finally, the KD payload is parsed, providing the keying material for t he TEK and/or KEK.
The KD payload contains a list of key bags, where each key bag include s the The KD payload contains a list of key bags, where each key bag include s the
keying material for SAs distributed in the GSA payload. Keying keying material for SAs distributed in the GSA payload. Keying
material is matched by comparing the SPIs in the key bags to SPIs material is matched by comparing the SPIs in the key bags to SPIs
previously included in the GSA payloads. Once TEK keys and policy previously included in the GSA payloads. Once TEK keys and policy
are matched, the GM provides them to the data-security subsystem, are matched, the GM provides them to the data-security subsystem,
and it is ready to send or receive packets matching the TEK and it is ready to send or receive packets matching the TEK
policy.</t> policy.</t>
<t> If the GM is not a sender for a received Data-Security SA,
<t> If the group member is not a sender for a received Data-Security S
A,
then it <bcp14>MUST</bcp14> install this SA only in the inbound direct ion. then it <bcp14>MUST</bcp14> install this SA only in the inbound direct ion.
If the group member is a sender for a received Data-Security SA, If the GM is a sender for a received Data-Security SA,
and it is not going to receive back the data it sends, and it is not going to receive back the data it sends,
then it <bcp14>MUST</bcp14> install this SA only in the outgoing direc tion. then it <bcp14>MUST</bcp14> install this SA only in the outgoing direc tion.
</t> </t>
<t>If the first Message ID the GM should expect to receive is non-zero , <t>If the first Message ID the GM should expect to receive is non-zero ,
the GSA KEK policy includes the attribute GSA_INITIAL_MESSAGE_ID with the GSA KEK policy includes the attribute GSA_INITIAL_MESSAGE_ID with
the expected non-zero value. the expected non-zero value.
The value of the attribute <bcp14>MUST</bcp14> be checked by a GM agai nst any previously received Message ID for this group. The value of the attribute <bcp14>MUST</bcp14> be checked by a GM agai nst any previously received Message ID for this group.
If it is less than the previously received number, it should be If it is less than the previously received number, it should be
considered stale and <bcp14>MUST</bcp14> be ignored. This could happen if two GSA_AUTH considered stale and <bcp14>MUST</bcp14> be ignored. This could happen if two GSA_AUTH
exchanges happened in parallel, and the Message ID changed. This exchanges happened in parallel and the Message ID changed. This
attribute is used by the GM to prevent GSA_REKEY message replay attribute is used by the GM to prevent GSA_REKEY message replay
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 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.</t> received in the GSA_INITIAL_MESSAGE_ID attribute.</t>
<t>GMs <bcp14>MUST</bcp14> install the Rekey SA only in the inbound di
<t>Group members <bcp14>MUST</bcp14> install the Rekey SA only in the rection.
inbound direction.
</t> </t>
<t>Once a GM successfully registers to the group, it <bcp14>MUST</bcp1
<t>Once a GM successfully registers to the group it <bcp14>MUST</bcp14 4> replace
> replace
any information related to this group (policy, keys) that it might any information related to this group (policy, keys) that it might
have as a result of a previous registration with a new one. have as a result of a previous registration with a new one.
</t> </t>
<t>Once a GM has received the GIKE_UPDATE policy during a registration
<t>Once a GM has received GIKE_UPDATE policy during a registration, th ,
e the IKE SA <bcp14>MAY</bcp14> be closed. By convention, the GCKS
IKE SA <bcp14>MAY</bcp14> be closed. By convention, the GCKS closes t closes the IKE SA; the GM <bcp14>SHOULD NOT</bcp14> close it. The
he IKE SA, GCKS <bcp14>MAY</bcp14> choose to keep the IKE SA open for inband
the GM <bcp14>SHOULD NOT</bcp14> close it. rekey, especially for small groups. If inband rekey is used, then
The GKCS <bcp14>MAY</bcp14> choose to keep the IKE SA open for inband the initial IKE SA can be rekeyed by any side with the standard
rekey, IKEv2 mechanism described in <xref target="RFC7296"
especially for small groups. If inband rekey is used, then the sectionFormat="of" section="1.3.2"/>. If for some reason the
initial IKE SA can be rekeyed by any side with the standard IKEv2 mech
anism
described in Section 1.3.2 of IKEv2 <xref target="RFC7296" />. If for
some reason the
IKE SA is closed and no GIKE_UPDATE policy is received during the IKE SA is closed and no GIKE_UPDATE policy is received during the
registration process, the GM <bcp14>MUST</bcp14> consider itself exclu registration process, the GM <bcp14>MUST</bcp14> consider itself
ded from the excluded from the group. To continue participating in the group,
group. To continue participating in the group, the GM needs to the GM needs to re-register.
re-register.
</t> </t>
</section> </section>
<section>
<section title="GCKS Registration Operations"> <name>GCKS Registration Operations</name>
<t>A G-IKEv2 GCKS listens for incoming requests from group <t>A G-IKEv2 GCKS listens for incoming requests from GMs. When the GCK
members. When the GCKS receives an IKE_SA_INIT request, it selects S receives an IKE_SA_INIT request, it selects
an IKE proposal and generates a nonce and DH to include them in the an IKE proposal and generates a nonce and Diffie-Hellman (DH) to inclu
de in the
IKE_SA_INIT response.</t> IKE_SA_INIT response.</t>
<t>Upon receiving the GSA_AUTH request, the GCKS authenticates the <t>Upon receiving the GSA_AUTH request, the GCKS authenticates the
group member via the GSA_AUTH exchange. The GM via the GSA_AUTH exchange. The
GCKS then authorizes the group member according to group policy GCKS then authorizes the GM according to group policy
before preparing to send the GSA_AUTH response. If the GCKS fails to before preparing to send the GSA_AUTH response. If the GCKS fails to
authorize the GM, it responds with an AUTHORIZATION_FAILED authorize the GM, it responds with an AUTHORIZATION_FAILED
notify message type. The GCKS may also respond with an INVALID_GROUP_I D notify message notification. The GCKS may also respond with an INVALID_GROUP_ID notif ication
if the requested group is unknown to the GCKS or with an REGISTRATION_ FAILED if the requested group is unknown to the GCKS or with an REGISTRATION_ FAILED
notify message if there is a problem with the requested group (for exa mple notification if there is a problem with the requested group (e.g., if
the capacity of the group is exceeded).</t> the capacity of the group is exceeded).</t>
<t>The GSA_AUTH response will include the group policy in the GSA <t>The GSA_AUTH response will include the group policy in the GSA
payload and keys in the KD payload. If the GCKS policy includes a payload and keys in the KD payload.
If the GCKS policy includes a
group rekey option and the initial Message ID value the GCKS will use when sending the GSA_REKEY messages group rekey option and the initial Message ID value the GCKS will use when sending the GSA_REKEY messages
to the group members is non-zero, then this value is specified in the GSA_INITIAL_MESSAGE_ID attribute. to the GMs is non-zero, then this value is specified in the GSA_INITIA L_MESSAGE_ID attribute.
This Message ID is used to prevent GSA_REKEY This Message ID is used to prevent GSA_REKEY
message replay attacks and will be increased each time a GSA_REKEY mes sage is sent message replay attacks and will be increased each time a GSA_REKEY mes sage is sent
to the group. The GCKS data traffic policy is included in the GSA to the group. The GCKS data traffic policy is included in the GSA
TEK and keys are included in the KD TEK. The GW policy <bcp14>MAY</bcp 14> also be TEK and keys are included in the KD TEK. The GW policy <bcp14>MAY</bcp 14> also be
included to provide the ATD and/or DTD (<xref target="gwp_attr_atd_dtd included to provide the Activation
"></xref>) Time Delay (ATD) and/or Deactivation Time Delay (DTD) (<xref target="gwp_attr
specifying activation and deactivation _atd_dtd"/>)
delays for SAs generated from the TEKs. If the group member has to specify activation and deactivation
indicated that it is a sender of data traffic and one or more Data delays for SAs generated from the TEKs. If the GM has
Security SAs distributed in the GSA payload included a counter mode indicated that it is a sender of data traffic and one or more Data-Sec
of operation, the GCKS responds with one or more Sender-ID values (see urity SAs distributed in the GSA payload included a counter mode
<xref of operation, the GCKS responds with one or more Sender-ID values (see
target="counter-modes"></xref>).</t> <xref target="counter-modes"/>).</t>
<t> Multicast Extensions to the Security Architecture <xref target="RF
<t> Multicast Extensions to the Security Architecture <xref target="RF C5374"/> defines two modes of operation for multicast
C5374" /> defines two modes of operation for multicast
Data-Security SAs: transport mode and tunnel mode with address preserv ation. Data-Security SAs: transport mode and tunnel mode with address preserv ation.
In the latter case outer source and destination addresses are taken fr om In the latter case, outer source and destination addresses are taken f rom
the inner IP packet. The mode of operation for the Data-Security SAs i s determined the inner IP packet. The mode of operation for the Data-Security SAs i s determined
by the presence of the USE_TRANSPORT_MODE notification by the presence of the USE_TRANSPORT_MODE notification
in the GCKS's response message of the registration exchange: if it is present, in the GCKS's response message of the registration exchange. If it is present,
then SAs are created in transport mode; otherwise, SAs are created in tunnel mode. then SAs are created in transport mode; otherwise, SAs are created in tunnel mode.
If multiple Data-Security SAs are being created in a single registrati on exchange, If multiple Data-Security SAs are being created in a single registrati on exchange,
then all of them will have the same mode of operation. then all of them will have the same mode of operation.
</t> </t>
<t>If the GCKS receives a GSA_REGISTRATION exchange with a request <t>If the GCKS receives a GSA_REGISTRATION exchange with a request
to register a GM to a group, the GCKS will need to authorize the GM to register a GM to a group, the GCKS will need to authorize the GM
with the new group (IDg) and respond with the corresponding group with the new group (IDg) and respond with the corresponding group
policy and keys. If the GCKS fails to authorize the GM, it will policy and keys. If the GCKS fails to authorize the GM, it will
respond with the AUTHORIZATION_FAILED notification. The GCKS may also respond with the AUTHORIZATION_FAILED notification. The GCKS may also
respond with an INVALID_GROUP_ID or REGISTRATION_FAILED notify message s respond with an INVALID_GROUP_ID or REGISTRATION_FAILED notify message s
for the reasons described above.</t> for the reasons described above.</t>
<t>If a GM includes an SAg in its GSA_AUTH or
<t>If a group member includes an SAg in its GSA_AUTH or
GSA_REGISTRATION request, the GCKS may evaluate it according to an GSA_REGISTRATION request, the GCKS may evaluate it according to an
implementation specific policy. implementation-specific policy.
<list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>The GCKS could evaluate the list of Transforms and compare it <t>The GCKS could evaluate the list of Transforms and compare it
to its current policy for the group. If the group member did not to its current policy for the group. If the GM did not
include all of the ESP, AH or GIKE_UPDATE Transforms that match th include all of the ESP, AH, or GIKE_UPDATE Transforms that match t
e current group policy he current group policy
or the capabilities of all other currently active GMs, or the capabilities of all other currently active GMs,
then the GCKS <bcp14>SHOULD</bcp14> return a NO_PROPOSAL_CHOSEN No tification. then the GCKS <bcp14>SHOULD</bcp14> return a NO_PROPOSAL_CHOSEN no tification.
Alternatively, the GCKS can change the group policy as defined bel ow.</t> Alternatively, the GCKS can change the group policy as defined bel ow.</t>
</li>
<t>The GCKS could store the list of Transforms, with the goal of <li>
migrating the group policy to a different Transforms when all of <t>The GCKS could store the list of Transforms with the goal of
the group members indicate that they can support that migrating the group policy from the current set of transforms to
Transforms.</t> a different one once all of the GMs indicate that they
can support transforms from the new set.</t>
</li>
<li>
<t>The GCKS could store the list of Transforms and adjust the <t>The GCKS could store the list of Transforms and adjust the
current group policy based on the capabilities of the devices as current group policy based on the capabilities of the devices as
long as they fall within the acceptable security policy of the long as they fall within the acceptable security policy of the
GCKS.</t> GCKS.</t>
</list> </li>
</ul>
<t>
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 an 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 u
use the SA, then after a se the SA, then the GCKS <bcp14>SHOULD</bcp14> close the IKE SA to save resource
short period of time the GCKS <bcp14>SHOULD</bcp14> close the IKE SA t s after a short period of time.</t>
o save resources.</t>
</section> </section>
</section> </section>
<section>
<section title="Group Maintenance Channel"> <name>Group Maintenance Channel</name>
<t>The GCKS is responsible for rekeying the secure group per the group <t>The GCKS is responsible for rekeying the secure group per the group
policy. Rekeying is an operation whereby the GCKS provides replacement policy.
TEKs and KEK, deleting TEKs, and/or excluding group members. The GCKS Rekeying is an operation whereby the GCKS provides
may initiate a rekey message if group membership and/or policy has replacement TEK(s) and/or KEK, deleting TEK(s), and/or
changed, or if the keys are about to expire. Two forms of group excluding GMs.
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 group
maintenance channels are provided in G-IKEv2 to push new policy to maintenance channels are provided in G-IKEv2 to push new policy to
group members.</t> GMs.</t>
<dl newline="true" spacing="normal">
<dl newline="true"> <dt>GSA_REKEY:</dt>
<dt>GSA_REKEY</dt>
<dd>The GSA_REKEY is a pseudo-exchange, consisting <dd>The GSA_REKEY is a pseudo-exchange, consisting
of a one-way IKEv2 message sent by the GCKS, where the rekey policy is of a one-way IKEv2 message sent by the GCKS where the rekey policy is
delivered delivered
to group members using IP multicast as a transport. This method is to GMs using IP multicast as a transport. This method is
valuable for large and dynamic groups, and where policy may change valuable for large and dynamic groups and where policy may change
frequently and a scalable rekey method is required. When the frequently and a scalable rekey method is required. When the
GSA_REKEY is used, the IKE SA protecting the member GSA_REKEY is used, the IKE SA protecting the member
registration exchanges is usually terminated, and group members await registration exchanges is usually terminated and GMs await
policy changes from the GCKS via the GSA_REKEY messages.</dd> policy changes from the GCKS via the GSA_REKEY messages.</dd>
<dt>GSA_INBAND_REKEY:</dt>
<dt>GSA_INBAND_REKEY</dt>
<dd>The GSA_INBAND_REKEY is a <dd>The GSA_INBAND_REKEY is a
normal IKEv2 exchange using the IKE SA that was setup to protecting th e normal IKEv2 exchange using the IKE SA that was set up to protect the
member registration exchange. This exchange allows the GCKS to member registration exchange. This exchange allows the GCKS to
rekey without using an independent GSA_REKEY pseudo-exchange. The rekey without using an independent GSA_REKEY pseudo-exchange. The
GSA_INBAND_REKEY exchange provides a reliable policy delivery and GSA_INBAND_REKEY exchange provides a reliable policy delivery and
is useful when G-IKEv2 is used with a small group of cooperating devic es.</dd> is useful when G-IKEv2 is used with a small group of cooperating devic es.</dd>
</dl> </dl>
<t>Depending on its policy, the GCKS <bcp14>MAY</bcp14> combine these tw
<t>Depending on its policy the GCKS <bcp14>MAY</bcp14> combine these two o methods.
methods. For example, the GCKS may use the GSA_INBAND_REKEY to deliver a key to t
For example, it may use the GSA_INBAND_REKEY to deliver key to the he
GMs in the group acting as senders (as this would provide reliable keys GMs in the group acting as senders (as this would provide reliable keys
delivery), delivery)
and the GSA_REKEY for the rest GMs. and the GSA_REKEY for the rest of the GMs.
</t> </t>
<section anchor="gsa_rekey">
<section anchor="gsa_rekey" title="GSA_REKEY"> <name>GSA_REKEY</name>
<t>The GCKS initiates the G-IKEv2 Rekey by sending a protected message <t>The GCKS initiates the G-IKEv2 rekey by sending a protected
to the GMs, message to the GMs, usually using IP multicast. Since the Rekey
usually using IP multicast. Since the Rekey messages do not require re messages do not require responses and are sent to multiple GMs,
sponses and they are sent the windowing mechanism described in <xref target="RFC7296"
to multiple GMs, the windowing mechanism described in Section 2.3 sectionFormat="of" section="2.3"/> <bcp14>MUST NOT</bcp14>
of IKEv2 <xref target="RFC7296" /> <bcp14>MUST NOT</bcp14> be used for be used for the Rekey messages. The GCKS rekey message replaces the
the Rekey messages. current rekey GSA KEK or KEK array (e.g., in the case of LKH) and/or
The GCKS rekey message replaces the current rekey GSA KEK or KEK array creates new Data-Security SAs. The GM_SENDER_ID attribute in
(e.g. in case of LKH), the Key Download payload (defined in <xref
and/or creates new Data-Security GSA TEKs. The GM_SENDER_ID target="mkd_attr_gm_sid"/>) <bcp14>MUST NOT</bcp14> be part of the
attribute in the Key Download payload (defined in <xref Rekey Exchange, as this is sender-specific information and the Rekey
target="mkd_attr_gm_sid"></xref>) <bcp14>MUST NOT</bcp14> be part of t
he Rekey
Exchange as this is sender specific information and the Rekey
Exchange is group specific. The GCKS initiates the GSA_REKEY Exchange is group specific. The GCKS initiates the GSA_REKEY
pseudo-exchange as following:</t> pseudo-exchange as following:</t>
<t><figure title="GSA_REKEY Pseudo-Exchange" anchor="gsa_rekey_exchang <figure anchor="gsa_rekey_exchange">
e"> <name>GSA_REKEY Pseudo-Exchange</name>
<preamble></preamble>
<artwork><![CDATA[ <artwork><![CDATA[
GMs (Receivers) GCKS (Sender) GMs (Receivers) GCKS (Sender)
----------------- --------------- ----------------- ---------------
<-- HDR, SK{GSA, KD, [N,] [AUTH]} <-- HDR, SK{GSA, KD, [N,] [AUTH]}
]]></artwork> ]]></artwork>
<postamble></postamble> </figure>
</figure></t>
<t>HDR is defined in <xref target="header"></xref>. While GSA_REKEY re -uses IKEv2 header, <t>HDR is defined in <xref target="header"/>. While GSA_REKEY reuses t he IKEv2 header,
the "IKE SA Initiator's SPI" and the "IKE SA Responder's SPI" fields a re treated as a single field the "IKE SA Initiator's SPI" and the "IKE SA Responder's SPI" fields a re treated as a single field
with a length of 16 octets containing the SPI of Rekey SA. The value f with a length of 16 octets containing the SPI of a Rekey SA. The value
or this field is provided by the GCKS for this field is provided by the GCKS
in the GSA payload (see <xref target="gsa_policy" />). in the GSA payload (see <xref target="gsa_policy"/>).
The Message ID in this message will start with the value the GCKS sent to the The Message ID in this message will start with the value the GCKS sent to the
group members in the attribute GSA_INITIAL_MESSAGE_ID or from GMs in the attribute GSA_INITIAL_MESSAGE_ID or from
zero if this attribute wasn't sent. The Message ID will be incremented each time a new zero if this attribute wasn't sent. The Message ID will be incremented each time a new
GSA_REKEY message is sent to the group members.</t> GSA_REKEY message is sent to the GMs.</t>
<t>The GSA payload contains the current policy for rekey and Data-Secu rity SAs. <t>The GSA payload contains the current policy for rekey and Data-Secu rity SAs.
The GSA may contain a new Rekey SA and/or a new Data-Security SAs
<xref target="gsa_payload"></xref>.</t>
The GSA may contain a new Rekey SA and/or a new Data-Security SA(s)
(<xref target="gsa_payload"/>).</t>
<t>The KD payload contains the keys for the policy included in the <t>The KD payload contains the keys for the policy included in the
GSA. If one or more Data-Security SAs are being refreshed in this reke y GSA. If one or more Data-Security SAs are being refreshed in this reke y
message, the IPsec keys are updated in the KD, and/or if the rekey message, the IPsec keys are updated in the KD, and/or if the Rekey
SA is being refreshed in this rekey message, the rekey Key or the SA is being refreshed in this rekey message, the rekey Key or the
LKH KEK array (e.g. in case of LKH) is updated in the KD payload.</t> LKH KEK array (e.g., in case of LKH) is updated in the KD payload.</t>
<t>A Delete payload <bcp14>MAY</bcp14> be included to instruct the GM to delete <t>A Delete payload <bcp14>MAY</bcp14> be included to instruct the GM to delete
existing SAs. See <xref target="delete" /> for more detail.</t> existing SAs. See <xref target="delete"/> for more detail.</t>
<t>The AUTH payload <bcp14>MUST</bcp14> be included to authenticate th e GSA_REKEY <t>The AUTH payload <bcp14>MUST</bcp14> be included to authenticate th e GSA_REKEY
message if the authentication method is based on public key signatures message if the authentication method is based on public key signatures
and <bcp14>MUST NOT</bcp14> be included if authentication is implicit. and <bcp14>MUST NOT</bcp14> be included if authentication is implicit.
In the latter case, the fact that a GM can decrypt the GSA_REKEY messa ge and verify its ICV In the latter case, the fact that a GM can decrypt the GSA_REKEY messa ge and verify its Integrity Check Value (ICV)
proves that the sender of this message knows the current KEK, proves that the sender of this message knows the current KEK,
thus authenticating the sender as a member of the group. thus authenticating the sender as a member of the group.
Note, that implicit authentication doesn't provide source origin authe Note that implicit authentication doesn't provide source origin authen
ntication. tication.
For this reason using implicit authentication for GSA_REKEY is <bcp14> For this reason, using implicit authentication for GSA_REKEY is <bcp14
NOT RECOMMENDED</bcp14> >NOT RECOMMENDED</bcp14>
unless source origin authentication is not required (for example, in a small group of unless source origin authentication is not required (for example, in a small group of
highly trusted GMs). See more about authentication methods in <xref ta rget="auth_method" />. highly trusted GMs). See more about authentication methods in <xref ta rget="auth_method"/>.
</t> </t>
<t> During GM registration, the GCKS
<t> During group member registration, the GCKS sends the authentication key in the KD payload, the AUTH_KEY attribute
sends the authentication key in the KD payload, AUTH_KEY attribute, ,
which the group member uses to authenticate the key which the GM uses to authenticate the key
server. Before the current authentication key expires, the GCKS will server. Before the current authentication key expires, the GCKS will
send a new AUTH_KEY to the group members in a GSA_REKEY message. send a new AUTH_KEY to the GMs in a GSA_REKEY message.
The authentication key that is sent in the rekey message may be not th The authentication key that is sent in the rekey message may not
e same be the same
as the authentication key sent during the GM registration. If implicit authentication as the authentication key sent during the GM registration. If implicit authentication
is used, then AUTH_KEY <bcp14>MUST NOT</bcp14> be sent to GMs.</t> is used, then AUTH_KEY <bcp14>MUST NOT</bcp14> be sent to GMs.</t>
<section anchor="gsa_rekey_auth">
<section anchor="gsa_rekey_auth" title="GSA_REKEY Message Authenticati <name>GSA_REKEY Message Authentication</name>
on"> <t>The content of the AUTH payload generally depends on the authenti
<t>The content of the AUTH payload generally depends on the authenti cation method from the Group Controller Authentication Method (GCAUTH) transform
cation method from the Group Controller Authentication Method transform (<xref target="auth_method"/>).
(<xref target="auth_method" />). This specification defines the use This specification defines the use of only one authentication method, Digital Si
of only one authentication method - Digital Signature, gnature, and the AUTH payload contains a digital signature calculated over the c
and the AUTH payload contains digital signature calculated over the ontent of the not-yet-encrypted GSA_REKEY message.
content of the not yet encrypted GSA_REKEY message.
</t> </t>
<t>The digital signing is applied to the concatenation of two chunks : A and P. <t>The digital signing is applied to the concatenation of two chunks : A and P.
The chunk A starts with the first octet of the G-IKEv2 header (not i Chunk A starts with the first octet of the G-IKEv2 header (not inclu
ncluding prepended four octets of zeros, if port 4500 is used) ding prepended four octets of zeros, if port 4500 is used)
and continues to the last octet of the Encrypted Payload header. The and continues to the last octet of the Encrypted Payload header.
chunk P consists of the not yet encrypted content of the Encrypted payload, exc Chunk P consists of the not-yet-encrypted content of the Encrypted payload, excl
luding uding
the Initialization Vector, the Padding, the Pad Length and the Integ the Initialization Vector, the Padding, the Pad Length, and the Inte
rity Checksum Data fields (see 3.14 of IKEv2 <xref target="RFC7296" /> for descr grity Checksum Data fields (see <xref section="3.14" target="RFC7296"/> for the
iption description
of the Encrypted payload). In other words, the P chunk is the inner of the Encrypted payload). In other words, chunk P is the inner payl
payloads of the Encrypted payload in plaintext form. oads of the Encrypted payload in plaintext form.
<xref target="auth_data" /> illustrates the layout of the P and A ch <xref target="auth_data"/> illustrates the layout of chunks P and A
unks in the GSA_REKEY message. in the GSA_REKEY message.
</t> </t>
<t>Before the calculation of the AUTH payload, the inner payloads
<t>Before the calculation of the AUTH payload the inner payloads of of the Encrypted payload must be fully formed and ready for
Encrypted payload must be encryption except for the content of the AUTH payload. The AUTH
fully formed and ready for encryption, except for the content of the payload must have correct values in the Payload header, the Auth
AUTH payload. Method, and the RESERVED fields. The Authentication Data field is
The AUTH payload must have correct values in the Payload Header, the zeroed, but the ASN.1 Length and the AlgorithmIdentifier fields
Auth Method and the RESERVED fields. must be properly filled in; see Signature Authentication in
The Authentication Data field is zeroed, but the ASN.1 Length and th <xref target="RFC7427"/>.
e AlgorithmIdentifier fields must be properly filled in,
see Signature Authentication in IKEv2 <xref target="RFC7427" />.
</t> </t>
<t>For the purpose of the AUTH payload calculation, the Length field
<t>For the purpose of the AUTH payload calculation the Length field in the IKE header and the Payload Length
in the IKE header and the Payload Length
field in the Encrypted Payload header are adjusted so that they don' t count the lengths field in the Encrypted Payload header are adjusted so that they don' t count the lengths
of Initialization Vector, Integrity Checksum Data and Padding (along with Pad Length field). of Initialization Vector, Integrity Checksum Data, and Padding (alon g with Pad Length field).
In other words, the Length field in the IKE header (denoted as Adjus tedLen in In other words, the Length field in the IKE header (denoted as Adjus tedLen in
<xref target="auth_data" />) is set to the sum of the lengths of A a nd P, and the Payload Length <xref target="auth_data"/>) is set to the sum of the lengths of A an d P, and the Payload Length
field in the Encrypted Payload header (denoted as AdjustedPldLen in field in the Encrypted Payload header (denoted as AdjustedPldLen in
<xref target="auth_data" />) is set to the length of P plus the size of the Payload header (four octets). <xref target="auth_data"/>) is set to the length of P plus the size of the Payload header (four octets).
</t> </t>
<t>The input to the digital signature algorithm that computes the co ntent of the AUTH payload can be described as: <t>The input to the digital signature algorithm that computes the co ntent of the AUTH payload can be described as:
</t> </t>
<figure align="center"> <artwork align="left"><![CDATA[
<artwork align="left"><![CDATA[
DataToAuthenticate = A | P DataToAuthenticate = A | P
GsaRekeyMessage = GenIKEHDR | EncPayload GsaRekeyMessage = GenIKEHDR | EncPayload
GenIKEHDR = [ four octets 0 if using port 4500 ] | AdjustedIKEHDR GenIKEHDR = [ four octets 0 if using port 4500 ] | AdjustedIKEHDR
AdjustedIKEHDR = SPIi | SPIr | . . . | AdjustedLen AdjustedIKEHDR = SPIi | SPIr | . . . | AdjustedLen
EncPayload = AdjustedEncPldHdr | IV | InnerPlds | Pad | PadLen | ICV EncPayload = AdjustedEncPldHdr | IV | InnerPlds | Pad | PadLen | ICV
AdjustedEncPldHdr = NextPld | C | RESERVED | AdjustedPldLen AdjustedEncPldHdr = NextPld | C | RESERVED | AdjustedPldLen
A = AdjustedIKEHDR | AdjustedEncPldHdr A = AdjustedIKEHDR | AdjustedEncPldHdr
P = InnerPlds P = InnerPlds
]]></artwork> ]]></artwork>
</figure>
<figure align="center" anchor="auth_data" title="Data to Authenticat <figure anchor="auth_data">
e in the GSA_REKEY Messages"> <name>Data to Authenticate in the GSA_REKEY Messages</name>
<artwork align="left"><![CDATA[ <artwork align="left"><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ c ^
| | r | | | r |
~ Inner payloads (not yet encrypted) ~ P ~ Inner Payloads (not yet encrypted) ~ P
| | P | | | P |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ l v
~ Padding (0-255 octets) | Pad Length | d ~ Padding (0-255 octets) | Pad Length | d
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | | | |
~ Integrity Checksum Data ~ | ~ Integrity Checksum Data ~ |
| | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The authentication data is calculated using the authentication al gorithm from the Group Controller Authentication Method transform <t>The authentication data is calculated using the authentication al gorithm from the Group Controller Authentication Method transform
(<xref target="auth_method" />) and the current authentication key p (<xref target="auth_method"/>) and the current authentication key pr
rovided in the AUTH_KEY attribute (<xref target="mkd_attr_auth_key" />). ovided in the AUTH_KEY attribute (<xref target="mkd_attr_auth_key"/>).
The calculated authentication data is placed into the AUTH payload, The calculated authentication data is placed into the AUTH payload,
the Length fields in the IKE Header and the Encryption Payload the Length fields in the IKE header and the Encryption Payload
header are restored, the content of the Encrypted payload is encrypt ed and the ICV is computed using the current KEK. header are restored, the content of the Encrypted payload is encrypt ed and the ICV is computed using the current KEK.
</t> </t>
</section> </section>
<section>
<section title="IKE Fragmentation"> <name>IKE Fragmentation</name>
<t>IKEv2 fragmentation <xref target="RFC7383"></xref> can be used to <t>IKEv2 fragmentation <xref target="RFC7383"/> can be used to
perform fragmentation of large GSA_REKEY messages; however, when perform fragmentation of large GSA_REKEY messages; however, when
the GSA_REKEY message is emitted as an IP multicast packet there the GSA_REKEY message is emitted as an IP multicast packet, there
is a lack of response from the GMs. This has the following is a lack of response from the GMs. This has the following
implications. implications.
<list style="symbols"> </t>
<t>Policy regarding the use of IKE fragmentation is implicit. <ul spacing="normal">
<li>
<t>Policy regarding the use of IKE fragmentation is implicit.
If a GCKS detects that all GMs have negotiated support of IKE If a GCKS detects that all GMs have negotiated support of IKE
fragmentation in IKE_SA_INIT, then it <bcp14>MAY</bcp14> use IKE fragmentation in IKE_SA_INIT, then it <bcp14>MAY</bcp14> use IKE
fragmentation on large GSA_REKEY messages.</t> fragmentation on large GSA_REKEY messages.</t>
</li>
<t>The GCKS must always use IKE fragmentation based on a pre-confi <li>
gured <t>The GCKS must always use IKE fragmentation based on a
fragmentation threshold, as there is no way to check if fragmentat preconfigured fragmentation threshold, as there is no way to
ion is needed by first sending check if fragmentation is needed by first sending unfragmented
unfragmented messages and waiting for response. Section 2.5.1 of I messages and waiting for response. <xref
KEv2 Fragmentation <xref target="RFC7383" /> target="RFC7383" sectionFormat="of" section="2.5.1"/> contains r
contains recommendation on selecting the fragmentation threshold.< ecommendations on selecting the
/t> fragmentation threshold.</t>
</li>
<t>PMTU mechanism, defined in Section 2.5.2 of IKEv2 Fragmentation <li>
<xref target="RFC7383" />, <t>The Path MTU (PMTU) mechanism, defined in <xref target="RFC73
cannot be used due to lack of GSA_REKEY response messages.</t> 83"
</list></t> sectionFormat="of" section="2.5.2"/>,
cannot be used due to lack of GSA_REKEY response messages.</t>
<t> The calculation of authentication data <bcp14>MUST</bcp14> be ap </li>
plied to whole messages only, before possible IKE Fragmentation. </ul>
<t> The calculation of authentication data <bcp14>MUST</bcp14> be ap
plied to whole messages only before possible IKE Fragmentation.
If the message was received in fragmented form, it should be reconst ructed before verifying its authenticity as if it were received unfragmented. If the message was received in fragmented form, it should be reconst ructed before verifying its authenticity as if it were received unfragmented.
The RESERVED field in the reconstructed Encrypted Payload header <bc The RESERVED field in the reconstructed Encrypted Payload header <bcp14>MUST</bc
p14>MUST</bcp14> be set to the value of the RESERVED p14> be set to the value of the RESERVED
field in the Encrypted Fragment payload header from the first fragme field in the Encrypted Fragment payload header from the first fragme
nt (that with Fragment Number equal to 1). nt (with the Fragment Number equal to 1).
</t> </t>
</section> </section>
<section>
<section title="GSA_REKEY GCKS Operations"> <name>GSA_REKEY GCKS Operations</name>
<t>The GCKS builds the rekey message with a Message ID value that <t>The GCKS builds the rekey message with a Message ID value that
is one greater than the value included in the previous rekey message . is one greater than the value included in the previous rekey message .
The first message sent over a new Rekey SA <bcp14>MUST</bcp14> use M The first message sent over a new Rekey SA <bcp14>MUST</bcp14> use a
essage ID of 0. Message ID of 0.
The GSA, KD and N payloads follow with the The GSA, KD, and N payloads follow with the
same characteristics as in the GSA Registration exchange. same characteristics as in the GSA Registration exchange.
The AUTH payload (if present) is created as defined in <xref target= "gsa_rekey_auth" />. The AUTH payload (if present) is created as defined in <xref target= "gsa_rekey_auth"/>.
</t> </t>
<t>Because GSA_REKEY messages are not acknowledged and could be <t>Because GSA_REKEY messages are not acknowledged and could be
discarded by the network, one or more GMs may not receive discarded by the network, one or more GMs may not receive
the new policy. To mitigate such lost messages, during a rekey event the the new policy. To mitigate such lost messages, during a rekey event , the
GCKS may transmit several copies of an encrypted GSA_REKEY message w ith the new GCKS may transmit several copies of an encrypted GSA_REKEY message w ith the new
policy. The (encrypted) retransmitted messages <bcp14>MUST</bcp14> b e bitwise identical and should be policy. The (encrypted) retransmitted messages <bcp14>MUST</bcp14> b e bitwise identical and should be
sent within a short time interval (a few seconds) to ensure sent within a short time interval (a few seconds) to ensure
that the SA lifetime calculations would not be substantially skewed for the GMs that that the SA lifetime calculations would not be substantially skewed for the GMs that
would receive different copies of the messages. </t> would receive different copies of the messages. </t>
<t> GCKS may also include one or several GSA_NEXT_SPI <t> GCKS may also include one or several GSA_NEXT_SPI
attributes specifying SPIs for the prospected rekeys, so that attributes specifying SPIs for the prospected rekeys so that
listening GMs are able to detect lost rekey messages and recover listening GMs are able to detect lost rekey messages and recover
from this situation. See Sections <xref target="gsa_attr_next_spi" / > for more detail. from this situation. See <xref target="gsa_attr_next_spi"/> for more detail.
</t> </t>
</section> </section>
<section>
<section title="GSA_REKEY GM Operations"> <name>GSA_REKEY GM Operations</name>
<t> When a group member receives the Rekey message from the GCKS it <t> When a GM receives the rekey message from the GCKS, it
decrypts the message and verifies its integrity using the current KE K. If the AUTH payload is present decrypts the message and verifies its integrity using the current KE K. If the AUTH payload is present
in the decrypted message, then the GM validates authenticity of the message using the key retrieved in the decrypted message, then the GM validates authenticity of the message using the key retrieved
in a previous G-IKEv2 exchange. Then the GM verifies the Message ID, in a previous G-IKEv2 exchange. Then the GM verifies the Message ID
and processes and processes
the GSA and KD payloads. The group member then installs the new Data the GSA and KD payloads. The GM then installs the new Data-Security
-Security SA(s) SA(s)
and/or new Rekey SA. The parsing of the payloads is identical to and/or a new Rekey SA. The parsing of the payloads is identical to
the parsing done in the registration exchange.</t> the parsing done in the registration exchange.</t>
<t>Replay protection is achieved by a GM rejecting a
<t>Replay protection is achieved by a group member rejecting a GSA_REKEY message that has a Message ID smaller than the current
GSA_REKEY message which has a Message ID smaller than the current
Message ID that the GM is expecting. The GM expects the Message ID Message ID that the GM is expecting. The GM expects the Message ID
in the first GSA_REKEY message it receives to be equal or greater in the first GSA_REKEY message it receives to be equal to or greater
than the Message ID it receives in the GSA_INITIAL_MESSAGE_ID attrib ute. than the Message ID it receives in the GSA_INITIAL_MESSAGE_ID attrib ute.
Note, that if the GSA_INITIAL_MESSAGE_ID attribute is not received f or the Rekey SA, Note that if the GSA_INITIAL_MESSAGE_ID attribute is not received fo r the Rekey SA,
the GM <bcp14>MUST</bcp14> assume zero as the first expected Message ID. the GM <bcp14>MUST</bcp14> assume zero as the first expected Message ID.
The GM expects the Message ID in subsequent GSA_REKEY messages to The GM expects the Message ID in subsequent GSA_REKEY messages to
be greater than the last valid GSA_REKEY message ID it be greater than the last valid GSA_REKEY message ID it
received.</t> received.</t>
<t> This specification assumes that the GSA_REKEY messages are sent <t> This specification assumes that the GSA_REKEY messages are sent
with intervals, that are significantly greater than typical network packet reordering intervals. with intervals that are significantly greater than typical network p acket reordering intervals.
</t> </t>
<t>If the GSA payload includes a Data-Security SA using cipher in
<t>If the GSA payload includes a Data-Security SA using cipher in a a counter-mode of operation and the receiving GM is a
counter-mode of operation and the receiving group member is a sender for that SA, the GM uses its current Sender-ID value
sender for that SA, the group member uses its current Sender-ID valu
e
with the Data-Security SAs to create counter-mode nonces. If it is with the Data-Security SAs to create counter-mode nonces. If it is
a sender and does not hold a current Sender-ID value (for example, a sender and does not hold a current Sender-ID value (for example,
when no counter-mode is employed for other Data-Security SAs), when no counter-mode is employed for other Data-Security SAs),
it <bcp14>MUST NOT</bcp14> install the Data-Security SAs. It <bcp14> MUST</bcp14> initiate a re-registration it <bcp14>MUST NOT</bcp14> install the Data-Security SAs. It <bcp14> MUST</bcp14> initiate a re-registration
to the GCKS in order to obtain an Sender-ID value (along with to the GCKS in order to obtain a Sender-ID value (along with
the current group policy). the current group policy).
</t> </t>
<t>Once a new Rekey SA is installed as a result of a GSA_REKEY
<t>Once a new Rekey SA is installed as a result of GSA_REKEY
message, the current Rekey SA (over which the message was received) message, the current Rekey SA (over which the message was received)
<bcp14>MUST</bcp14> be silently deleted after waiting DEACTIVATION_T <bcp14>MUST</bcp14> be silently deleted after waiting the DEACTIVATI
IME_DELAY interval ON_TIME_DELAY interval
regardless of its expiration time. If the message includes Delete pa regardless of its expiration time. If the message includes a Delete
yload payload
for existing Data-Security SA, then after installing a new Data-Secu for an existing Data-Security SA, then after installing a new Data-S
rity SA the old one, ecurity SA, the old one
identified by the Protocol and SPI fields in the Delete payload, <bc (identified by the Protocol and SPI fields in the Delete payload) <b
p14>MUST</bcp14> be silently deleted cp14>MUST</bcp14> be silently deleted
after waiting DEACTIVATION_TIME_DELAY interval regardless of its exp after waiting the DEACTIVATION_TIME_DELAY interval regardless of its
iration time. expiration time.
</t> </t>
<t>If a Data-Security SA is not rekeyed yet and is <t>If a Data-Security SA is not rekeyed yet and is
about to expire (a "soft lifetime" expiration is described about to expire (a "soft lifetime" expiration is described
in Section 4.4.2.1 of <xref target="RFC4301"></xref>), the GM <bcp14 >SHOULD</bcp14> in <xref target="RFC4301" sectionFormat="of" section="4.4.2.1"/>), t he GM <bcp14>SHOULD</bcp14>
initiate a registration to the GCKS. This registration serves as a initiate a registration to the GCKS. This registration serves as a
request for current SAs, and will result in the download of request for current SAs and will result in the download of
replacement SAs, assuming the GCKS policy has created them. replacement SAs, assuming the GCKS policy has created them.
A GM <bcp14>SHOULD</bcp14> also initiate a registration request if a Rekey SA A GM <bcp14>SHOULD</bcp14> also initiate a registration request if a Rekey SA
is about to expire and not yet replaced with a new one.</t> is about to expire and not yet replaced with a new one.</t>
</section> </section>
</section> </section>
<section anchor="gsa_inband_rekey">
<section anchor="gsa_inband_rekey" title="GSA_INBAND_REKEY Exchange"> <name>GSA_INBAND_REKEY Exchange</name>
<t>When the IKE SA protecting the member registration exchange is <t>When the IKE SA protecting the member registration exchange is
maintained while group member participates in the group, the GCKS maintained while a GM participates in the group, the GCKS
can use the GSA_INBAND_REKEY exchange to individually provide policy can use the GSA_INBAND_REKEY exchange to individually provide policy
updates to the group member.</t> updates to the GM.</t>
<figure title="GSA_INBAND_REKEY Exchange" anchor="gsa_inband_rekey_exc <figure anchor="gsa_inband_rekey_exchange">
hange"> <name>GSA_INBAND_REKEY Exchange</name>
<artwork><![CDATA[ <artwork><![CDATA[
GM (Responder) GCKS (Initiator) GM (Responder) GCKS (Initiator)
---------------- ------------------ ---------------- ------------------
<-- HDR, SK{GSA, KD, [N]} <-- HDR, SK{GSA, KD, [N]}
HDR, SK{} --> HDR, SK{} -->
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Because this is a normal IKEv2 exchange, the HDR is treated as defi ned <t>Because this is a normal IKEv2 exchange, the HDR is treated as defi ned
in IKEv2 <xref target="RFC7296"></xref>.</t> in IKEv2 <xref target="RFC7296"/>.</t>
<section>
<section title="GSA_INBAND_REKEY GCKS Operations"> <name>GSA_INBAND_REKEY GCKS Operations</name>
<t>The GSA, KD and N payloads are built in the same manner as in <t>The GSA, KD, and N payloads are built in the same manner as in
a registration exchange.</t> a registration exchange.</t>
</section> </section>
<section>
<section title="GSA_INBAND_REKEY GM Operations"> <name>GSA_INBAND_REKEY GM Operations</name>
<t>The GM processes the GSA, KD and N payloads in the same manner <t>The GM processes the GSA, KD, and N payloads in the same manner
as if they were received in a registration exchange.</t> as if they were received in a registration exchange.</t>
</section> </section>
</section> </section>
<section anchor="deletion">
<section title="Deletion of SAs" anchor="deletion" > <name>Deletion of SAs</name>
<t>There are occasions when the GCKS may want to signal to group <t>There are occasions when the GCKS may want to signal to GMs to dele
members to delete policy when the application sending data traffic has te policy when the application sending data traffic has ended or if group
ended, or if group
policy has changed. Deletion of SAs is accomplished by sending policy has changed. Deletion of SAs is accomplished by sending
the Delete Payload described in Section 3.11 of IKEv2 <xref target="RF C7296"></xref> the Delete Payload described in <xref target="RFC7296" sectionFormat=" of" section="3.11"/>
as part of the GSA_REKEY pseudo-exchange as shown below.</t> as part of the GSA_REKEY pseudo-exchange as shown below.</t>
<t><figure title="SA Deletion in GSA_REKEY" anchor="gsa_rekey_sa_delet <figure anchor="gsa_rekey_sa_deletion">
ion"> <name>SA Deletion in GSA_REKEY</name>
<preamble></preamble>
<artwork><![CDATA[ <artwork><![CDATA[
GMs (Receivers) GCKS (Sender) GMs (Receivers) GCKS (Sender)
---------------- --------------- ---------------- ---------------
<-- HDR, SK{D, [N,] [AUTH]} <-- HDR, SK{D, [N,] [AUTH]}
]]></artwork> ]]></artwork>
<postamble></postamble> </figure>
</figure></t>
<t>If GCKS has a unicast SA with group member then it can use the GSA_ INBAND_REKEY <t>If GCKS has a unicast SA with a GM, then it can use the GSA_INBAND_ REKEY
exchange to delete SAs. exchange to delete SAs.
</t> </t>
<t><figure title="SA Deletion in GSA_INBAND_REKEY" anchor="gsa_inband_ <figure anchor="gsa_inband_rekey_sa_deletion">
rekey_sa_deletion"> <name>SA Deletion in GSA_INBAND_REKEY</name>
<preamble></preamble>
<artwork><![CDATA[ <artwork><![CDATA[
GM (Responder) GCKS (Initiator) GM (Responder) GCKS (Initiator)
--------------- ------------------ --------------- ------------------
<-- HDR, SK{D, [N]} <-- HDR, SK{D, [N]}
HDR, SK{} --> HDR, SK{} -->
]]></artwork> ]]></artwork>
<postamble></postamble> </figure>
</figure></t>
<t>There may be circumstances where the GCKS may want to start over <t>There may be circumstances where the GCKS may want to start over
with a clean state, for example in case it runs out of available Sende r-IDs. with a clean state, e.g., in case it runs out of available Sender-IDs.
The GCKS can signal deletion of all the Data-Security SAs by The GCKS can signal deletion of all the Data-Security SAs by
sending a Delete payload with an SPI value equal to zero. sending a Delete payload with an SPI value equal to zero.
For example, if the GCKS wishes to remove the Rekey SA and all the For example, if the GCKS wishes to remove the Rekey SA and all the
Data-Security SAs, the GCKS sends a Delete payload with an SPI Data-Security SAs, the GCKS sends a Delete payload with an SPI
of zero and Protocol ID of AH or ESP, followed by another Delete paylo of zero and a Protocol ID of AH or ESP, followed by another Delete pay
ad load
with a SPI of zero and Protocol ID of GIKE_UPDATE. with an SPI of zero and a Protocol ID of GIKE_UPDATE.
</t> </t>
<t> If a GM receives a Delete payload with zero SPI and a Protocol ID
<t> If a group member receives a Delete payload with zero SPI and prot of GIKE_UPDATE, it means that the GM is excluded from the group.
ocol ID
of GIKE_UPDATE, it means that the group member is excluded from the gr
oup.
Such Delete payload may be received either in the GSA_REKEY pseudo-exc hange or in the GSA_INBAND_REKEY exchange. Such Delete payload may be received either in the GSA_REKEY pseudo-exc hange or in the GSA_INBAND_REKEY exchange.
In this situation the group member <bcp14>MUST</bcp14> re-register if it wants to continue In this situation, the GM <bcp14>MUST</bcp14> re-register if it wants to continue
participating in this group. The registration is performed as describe d participating in this group. The registration is performed as describe d
in <xref target="registration" />. It is <bcp14>RECOMMENDED</bcp14> th at a GM waits some randomly chosen time in <xref target="registration"/>. It is <bcp14>RECOMMENDED</bcp14> tha t a GM waits some randomly chosen time
before initiating a registration request in this situation to avoid ov erloading the GCKS. before initiating a registration request in this situation to avoid ov erloading the GCKS.
This document doesn't specify the maximum delay, which is implementati on-dependent, This document doesn't specify the maximum delay, which is implementati on-dependent,
but it is believed, that the order of seconds suits most situations. but it is believed that the order of seconds suits most situations.
Note, that if the unicast SA between the group member and the GCKS exi Note that if the unicast SA between the GM and the GCKS exists, then t
sts, then the group member may use the GSA_REGISTRATION exchange he GM may use the GSA_REGISTRATION exchange
to re-register. However, after excluding an GM from the group the GCKS to re-register. However, after excluding a GM from the group, the GCKS
<bcp14>MAY</bcp14> <bcp14>MAY</bcp14>
immediately delete the unicast SA with this GM (if any) if the credent ials of this GM are revoked. immediately delete the unicast SA with this GM (if any) if the credent ials of this GM are revoked.
</t> </t>
</section> </section>
</section> </section>
<section anchor="counter-modes">
<section anchor="counter-modes" title="Counter-based modes of operation"> <name>Counter-Based Modes of Operation</name>
<t>Several counter-based modes of operation have been specified <t>Several counter-based modes of operation have been specified
for ESP (e.g., AES-CTR <xref target="RFC3686"></xref>, AES-GCM <xref for ESP (e.g., AES-CTR <xref target="RFC3686"/>, AES-GCM <xref target="R
target="RFC4106"></xref>, AES-CCM <xref target="RFC4309"></xref>, FC4106"/>, AES-CCM <xref target="RFC4309"/>,
ChaCha20-Poly1305 <xref target="RFC7634"></xref>, ChaCha20-Poly1305 <xref target="RFC7634"/>, and
AES-GMAC <xref target="RFC4543"></xref>) and AH (e.g., AES-GMAC <xref AES-GMAC <xref target="RFC4543"/>) and AH (e.g., AES-GMAC <xref target="
target="RFC4543"></xref>). These counter-based modes require that no RFC4543"/>). These counter-based modes require that no
two senders in the group ever send a packet with the same two senders in the group ever send a packet with the same
Initialization Vector (IV) using the same cipher key and mode. This IV using the same cipher key and mode. This
requirement is met in G-IKEv2 when the following measures are requirement is met in G-IKEv2 when the following measures are
taken: taken:
<list style="symbols"> </t>
<ul spacing="normal">
<t>The GCKS distributes a unique key for each Data-Security SA.</t> <li>
<t>The GCKS distributes a unique key for each Data-Security SA.</t>
<t>The GCKS uses the method described in Using Counter Modes with ESP an </li>
d AH <li>
to Protect Group Traffic <xref target="RFC6054"></xref>, <t>The GCKS uses the method described in <xref target="RFC6054"/>,
which assigns each sender a portion of the IV space by provisioning each which assigns each sender a portion of the IV space by provisioning each
sender with one or more unique Sender-ID values.</t> sender with one or more unique Sender-ID values.</t>
</li>
</list></t> </ul>
<section anchor="sid_alloc">
<section anchor="sid_alloc" title="Allocation of Sender-ID"> <name>Allocation of Sender-ID</name>
<t>When at least one Data-Security SA included in the group policy <t>When at least one Data-Security SA included in the group policy
includes a counter-based mode of operation, the GCKS automatically includes a counter-based mode of operation, the GCKS automatically
allocates and distributes one Sender-ID to each group member acting in the allocates and distributes one Sender-ID to each GM acting in the
role of sender on the Data-Security SA. The Sender-ID value is used role of sender on the Data-Security SA. The Sender-ID value is used
exclusively by the group sender to which it was allocated. The group exclusively by the group sender to which it was allocated. The group
sender uses the same Sender-ID for each Data-Security SA specifying th e sender uses the same Sender-ID for each Data-Security SA specifying th e
use of a counter-based mode of operation. A GCKS <bcp14>MUST</bcp14> d istribute use of a counter-based mode of operation. A GCKS <bcp14>MUST</bcp14> d istribute
unique keys for each Data-Security SA including a counter-based mode unique keys for each Data-Security SA, including a counter-based mode
of operation in order to maintain unique key and nonce usage.</t> of operation in order to maintain unique key and nonce usage.</t>
<t>During registration, the group sender can choose to request one <t>During registration, the group sender can choose to request one
or more Sender-ID values. Requesting a value of 1 is not necessary sin ce or more Sender-ID values. Requesting a value of 1 is not necessary sin ce
the GCKS will automatically allocate exactly one to the group the GCKS will automatically allocate exactly one to the group
sender. A group sender <bcp14>MUST</bcp14> request as many Sender-ID v alues matching the number sender. A group sender <bcp14>MUST</bcp14> request as many Sender-ID v alues matching the number
of encryption modules in which it will be installing the TEKs in the of encryption modules in which it will be installing the TEKs in the
outbound direction. Alternatively, a group sender <bcp14>MAY</bcp14> r equest more outbound direction. Alternatively, a group sender <bcp14>MAY</bcp14> r equest more
than one Sender-ID and use them serially. This could be useful when it is than one Sender-ID and use them serially. This could be useful when it is
anticipated that the group sender will exhaust their range of Data- anticipated that the group sender will exhaust their range of Data-Sec
Security SA nonces using a single Sender-ID too quickly (e.g., before urity SA nonces using a single Sender-ID too quickly (e.g., before the
the
time-based policy in the TEK expires).</t> time-based policy in the TEK expires).</t>
<t>When the group policy includes a counter-based mode of operation, <t>When the group policy includes a counter-based mode of operation,
a GCKS should use the following method to allocate Sender-ID values, w hich a GCKS should use the following method to allocate Sender-ID values, w hich
ensures that each Sender-ID will be allocated to just one group ensures that each Sender-ID will be allocated to just one group
sender.<list style="numbers"> sender.</t>
<ol spacing="normal" type="1"><li>
<t>A GCKS maintains an Sender-ID counter, which records the Sender-IDs <t>A GCKS maintains a Sender-ID counter, which records the Sender-
that IDs that
have been allocated. Sender-IDs are allocated sequentially, with zero have been allocated. Sender-IDs are allocated sequentially with zero a
as s
the first allocated value.</t> the first allocated value.</t>
</li>
<t>Each time an Sender-ID is allocated, the current value of the <li>
<t>Each time a Sender-ID is allocated, the current value of the
counter is saved and allocated to the group sender. The Sender-ID coun ter counter is saved and allocated to the group sender. The Sender-ID coun ter
is then incremented in preparation for the next allocation.</t> is then incremented in preparation for the next allocation.</t>
</li>
<t>When the GCKS specifies a counter-based mode of operation in <li>
the Data-Security SA a group sender may request a count of Sender-IDs <t>When the GCKS specifies a counter-based mode of operation in
the Data-Security SA, a group sender may request a count of Sender-IDs
during registration in a Notify payload information of type SENDER. during registration in a Notify payload information of type SENDER.
When the GCKS receives this request, it increments the Sender-ID count er When the GCKS receives this request, it increments the Sender-ID count er
once for each requested Sender-ID, and distributes each Sender-ID valu e to the once for each requested Sender-ID and distributes each Sender-ID value to the
group sender. The GCKS should have a policy-defined upper bound for group sender. The GCKS should have a policy-defined upper bound for
the number of Sender-ID values that it will return irrespective of the number the number of Sender-ID values that it will return irrespective of the number
requested by the GM.</t> requested by the GM.</t>
</li>
<t>A GCKS allocates new Sender-ID values for each registration operati <li>
on <t>A GCKS allocates new Sender-ID values for each registration ope
ration
by a group sender, regardless of whether the group by a group sender, regardless of whether the group
sender had previously contacted the GCKS. In this way, the GCKS is sender had previously contacted the GCKS. In this way, the GCKS is
not required to maintaining a record of which Sender-ID values it had not required to maintain a record of which Sender-ID values it had
previously allocated to each group sender. More importantly, since previously allocated to each group sender. More importantly, since
the GCKS cannot reliably detect whether the group sender had sent the GCKS cannot reliably detect whether the group sender had sent
data on the current group Data-Security SAs it does not know what data on the current group Data-Security SAs, it does not know what
Data-Security counter-mode nonce values that a group sender has Data-Security counter-mode nonce values that a group sender has
used. By distributing new Sender-ID values, the key server ensures tha t used. By distributing new Sender-ID values, the key server ensures tha t
each time a conforming group sender installs a Data-Security SA it each time a conforming group sender installs a Data-Security SA, it
will use a unique set of counter-based mode nonces.</t> will use a unique set of counter-based mode nonces.</t>
</li>
<t>When the Sender-ID counter maintained by the GCKS reaches its final <li>
<t>When the Sender-ID counter maintained by the GCKS reaches its f
inal
Sender-ID value, no more Sender-ID values can be distributed. Before Sender-ID value, no more Sender-ID values can be distributed. Before
distributing any new Sender-ID values, the GCKS <bcp14>MUST</bcp14> distributing any new Sender-ID values, the GCKS <bcp14>MUST</bcp14>
exclude all group members from the group as described exclude all GMs from the group as described
in <xref target="deletion" />. This will result in the group members in <xref target="deletion"/>. This will result in the GMs
performing re-registration, during which they will receive new Data-Se curity SAs performing re-registration, during which they will receive new Data-Se curity SAs
and group senders will additionally receive new Sender-ID values. and group senders will additionally receive new Sender-ID values.
The new Sender-ID values can safely be used because they are only used with The new Sender-ID values can safely be used because they are only used with
the new Data-Security SAs.</t> the new Data-Security SAs.</t>
</li>
</list></t> </ol>
</section> </section>
<section anchor="sid-usage">
<section anchor="sid-usage" title="GM Usage of Sender-ID"> <name>GM Usage of Sender-ID</name>
<t>A GM applies the Sender-ID to Data-Security SAs as follows. <t>A GM applies the Sender-ID to Data-Security SAs as follows:
<list style="symbols"> </t>
<ul spacing="normal">
<t>The most significant bits of the IV indicated in the GWP_SENDER_ID_ <li>
BITS attribute (<xref target="gwp_attr_sid_bits" />) are <t>The most significant bits of the IV indicated in the GWP_SENDER
_ID_BITS attribute (<xref target="gwp_attr_sid_bits"/>) are
taken to be the Sender-ID field of the IV.</t> taken to be the Sender-ID field of the IV.</t>
</li>
<t>The Sender-ID is placed in the least significant bits of the Sender <li>
-ID <t>The Sender-ID is placed in the least significant bits of the Se
nder-ID
field, where any unused most significant bits are set to zero. field, where any unused most significant bits are set to zero.
If the Sender-ID value doesn't fit into the number of bits from the GW P_SENDER_ID_BITS attributes, If the Sender-ID value doesn't fit into the number of bits from the GW P_SENDER_ID_BITS attributes,
then the GM <bcp14>MUST</bcp14> treat this as a fatal error and re-reg ister to the group. then the GM <bcp14>MUST</bcp14> treat this as a fatal error and re-reg ister to the group.
</t> </t>
</li>
</list></t> </ul>
</section> </section>
</section> </section>
<section anchor="seqnum">
<section anchor="seqnum" title="Replay Protection for Multicast Data-Secur <name>Replay Protection for Multicast Data-Security SAs</name>
ity SAs"> <t>IPsec provides anti-replay service as part of its security
<t>IPsec provides anti-replay service as part of its security services. services. With multicast extensions for IPsec, replay protection is not
With multicast extension for IPsec replay protection is not always possi always possible to achieve (see <xref target="RFC3740"
ble to achieve sectionFormat="of" section="6.1"/>). In particular, if there
(see Section 6.1 of Multicast Group Security Architecture <xref target=" are many group senders for a Data-Security SA, then each of them will
RFC3740" />). independently increment the Sequence Number field in the ESP header
In particular, if there are many group senders for a Data-Security SA, t (see <xref target="RFC4303" sectionFormat="of"
hen section="2.2"/> and <xref target="RFC4302"
each of them will independently increment the Sequence Number field in t sectionFormat="of" section="2.5"/>), thus making it impossible
he ESP header for the group receivers to filter out replayed packets. However, if
(see Section 2.2 of ESP <xref target="RFC4303" /> and Section 2.5 of AH there is only one group sender for a Data-Security SA, then it is
<xref target="RFC4302" />) thus making it impossible for the possible to achieve replay protection with some restrictions (see
group receivers to filter out replayed packets. However, if there is onl <xref target="antireplay"/>). The GCKS <bcp14>MAY</bcp14> create
y one several Data-Security SAs with the same traffic selectors allowing
group sender for a Data-Security SA, then it is possible to achieve repl only a single group sender in each SA if it is desirable to get replay
ay protection protection with multiple (but still a limited number) of group senders.
with some restrictions (see <xref target="antireplay" />). The GCKS <bcp
14>MAY</bcp14> create several Data-Security SAs
with the same traffic selectors allowing only a single group sender in e
ach SA
if it is desirable to get replay protection with multiple (but still lim
ited number) of group senders.
</t> </t>
<t>IPsec architecture assumes that whether
<t>IPsec architecture assumes that it is a local matter for an IPsec rec anti-replay service is enabled or not is a local matter for an IPsec rec
eiver whether eiver. In other words, an IPsec sender always increments
anti-replay service is enabled or not. In other words, an IPsec sender a
lways increments
the Sequence Number field in the ESP/AH header and a receiver decides wh ether to check the Sequence Number field in the ESP/AH header and a receiver decides wh ether to check
for replayed packets or not. Since in some cases it is known that the re for replayed packets or not. Since it is known in some cases that the re
play protection play protection
is not possible (like in an SA with many group senders), a new transform is not possible (like in an SA with many group senders), a new Transform
ID ID
"32-bit Unspecified Numbers" is defined for the Sequence Numbers (SN) tr "32-bit Unspecified Numbers" is defined for the Sequence Numbers (SNs) T
ansform type. ransform Type.
Using this transform ID the the GCKS can inform group members that the u Using this Transform ID, the GCKS can inform GMs that the uniqueness of
niqueness of sequence sequence
numbers for a given SA is not guaranteed. The decision whether to enable numbers for a given SA is not guaranteed. The decision of whether to ena
anti-replay service ble anti-replay service
is still a local matter of a GM (in accordance with IPsec architecture). is still a local matter of a GM (in accordance with IPsec architecture).
</t> </t>
<t>The GCKS <bcp14>MUST</bcp14> include the Sequence Numbers transform i
<t> The GCKS <bcp14>MUST</bcp14> include the Sequence Numbers transform n the GSA payload for every Data-Security SA.
in the GSA payload for every Data-Security SA. See <xref target="antireplay"/> for more details.
See <xref target="antireplay" /> for more details.
</t> </t>
<t>When a Data-Security SA has a single sender, the GCKS <bcp14>MUST</bc
<t> When a Data-Security SA has a single sender, the GCKS <bcp14>MUST</b p14>
cp14>
be configured to rekey the SA frequently enough so that the 32-bit seque nce numbers do not wrap. be configured to rekey the SA frequently enough so that the 32-bit seque nce numbers do not wrap.
</t> </t>
</section> </section>
<section anchor="implicit-iv">
<section anchor="implicit-iv" title="Encryption Transforms with Implicit I <name>Encryption Transforms with Implicit IV</name>
V"> <t>The "Transform Type 1 - Encryption Algorithm Transform IDs" IANA regi
<t>IKEv2 IANA registry for Encryption Algorithm Transform IDs <xref targ stry <xref target="IKEV2-IANA"/> defines several transforms
et="IKEV2-IANA" /> defines several transforms with implicit IV. These transforms rely on ESP Sequence Numbers for cons
with implicit IV. These transforms rely on ESP Sequence Number for const tructing IV
ructing IV (see <xref target="RFC8750"/> for details).
(see Implicit IV for Counter-Based Ciphers in ESP <xref target="RFC8750"
/> for details).
It requires anti-replay service to be enabled for an ESP SA using these encryption transforms. It requires anti-replay service to be enabled for an ESP SA using these encryption transforms.
Unless the properties of sequence numbers for a multicast ESP SA include Unless the properties of sequence numbers for a multicast ESP SA include
their uniqueness (see <xref target="seqnum" />), their uniqueness (see <xref target="seqnum"/>),
encryption transforms that rely on Sequence Number for IV construction < encryption transforms that rely on Sequence Numbers for IV construction
bcp14>MUST NOT</bcp14> be used. <bcp14>MUST NOT</bcp14> be used.
In any case, such transforms <bcp14>MUST NOT</bcp14> be used for any G-I KEv2 SA (both unicast and multicast). In any case, such transforms <bcp14>MUST NOT</bcp14> be used for any G-I KEv2 SA (both unicast and multicast).
</t> </t>
</section> </section>
</section> </section>
<section anchor="key_management">
<section anchor="key_management" title="Group Key Management and Access Cont <name>Group Key Management and Access Control</name>
rol">
<t>Through the G-IKEv2 rekey, G-IKEv2 supports algorithms such as <t>Through the G-IKEv2 rekey, G-IKEv2 supports algorithms such as
Logical Key Hierarchy (LKH) that have the property of denying access to a Logical Key Hierarchy (LKH) that have the property of denying access to
new group key by a new group key by a member removed from the group (forward access
a member removed from the group (forward access control) and to an control) and to an old group key by a member added to the group
old group key by a member added to the group (backward access (backward access control). This is unrelated to the Perfect Forward
control). This is unrelated to PFS (Perfect Forward Secrecy) property as d Secrecy (PFS) property as defined in <xref target="RFC7296"
efined in Section 2.12 of IKEv2 <xref target="RFC7296" />. sectionFormat="of" section="2.12"/>.
</t> </t>
<t>Group management algorithms providing forward and backward <t>Group management algorithms providing forward and backward access
access control other than LKH have been proposed in the control other than LKH have also been proposed,
literature, including OFT <xref target="OFT"></xref> and Subset for example, OFT <xref target="OFT"/> and Subset Difference <xref target="NNL
Difference <xref target="NNL"></xref>. These algorithms could be "/>. These algorithms could be
used with G-IKEv2, but are not specified as a part of this used with G-IKEv2 but are not specified as a part of this
document.</t> document.</t>
<t>This specification assumes that all group keys, that are <t>This specification assumes that all group keys, that are
sent to the GMs by the GCKS, are encrypted with some other keys, sent to the GMs by the GCKS, are encrypted with some other keys,
called Key Wrap Keys (KWK). The Key Wrap Algorithm transform called Key Wrap Keys (KWKs). The Key Wrap Algorithm transform
defines the algorithm used for key wrapping in the context of an SA. defines the algorithm used for key wrapping in the context of an SA.
</t> </t>
<section anchor="kwk">
<section anchor="kwk" title="Key Wrap Keys"> <name>Key Wrap Keys</name>
<t>Every GM always knows at least one KWK -- the KWK that is associated with the IKE SA <t>Every GM always knows at least one KWK -- the KWK that is associated with the IKE SA
or multicast Rekey SA over which wrapped keys are sent. or multicast Rekey SA over which wrapped keys are sent.
In this document it is called default KWK and is denoted as GSK_w. In this document, it is called default KWK and is denoted as "GSK_w".
</t> </t>
<t>For the purpose of forward access control, the GCKS may provide each
<t>For the purpose of forward access control the GCKS may provide each G GM
M
with its personal KWK at the time of registration. Additionally, several intermediate KWKs that form a key with its personal KWK at the time of registration. Additionally, several intermediate KWKs that form a key
hierarchy and are shared among several GMs may be provided by the GCKS. hierarchy and are shared among several GMs may be provided by the GCKS.
</t> </t>
<t>Each KWK is associated with a key wrap algorithm specified in the Key
<t>Each KWK is associated with a key wrap algorithm, specified in the Ke Wrap Algorithm transform.
y Wrap Algorithm transform. The size of these KWKs is determined by the key wrap algorithm used,
The size of these KWKs is determined by the used key wrap algorithm,
but it <bcp14>SHOULD NOT</bcp14> be less than the size of the key for th e Encryption Algorithm transform but it <bcp14>SHOULD NOT</bcp14> be less than the size of the key for th e Encryption Algorithm transform
for the Rekey SA and for all Data-Security SAs in the group (taking into consideration the Key Length attribute if present). for the Rekey SA and for all Data-Security SAs in the group (taking the Key Length attribute into consideration if it is present).
</t> </t>
<section anchor="sk_w">
<section anchor="sk_w" title="Default Key Wrap Key"> <name>Default Key Wrap Key</name>
<t>The default KWK (GSK_w) is only used in the context of a single IKE SA. <t>The default KWK (GSK_w) is only used in the context of a single IKE SA.
Every IKE SA (unicast IKE SA or multicast Rekey SA) will have its own GSK_w. Every IKE SA (unicast IKE SA or multicast Rekey SA) will have its own GSK_w.
</t> </t>
<t>For the unicast IKE SA (used for the GM registration and for GSA_IN BAND_REKEY exchanges if they appear), the GSK_w is computed as follows:</t>
<t>For the unicast IKE SA (used for the GM registration <artwork><![CDATA[
and for the GSA_INBAND_REKEY exchanges, if they are take place)
the GSK_w is computed as follows:
<figure >
<artwork><![CDATA[
GSK_w = prf+(SK_d, "Key Wrap for G-IKEv2") GSK_w = prf+(SK_d, "Key Wrap for G-IKEv2")
]]></artwork> ]]></artwork>
</figure>
<t>
where the string "Key Wrap for G-IKEv2" is 20 ASCII characters where the string "Key Wrap for G-IKEv2" is 20 ASCII characters
without null termination. without null termination.
</t> </t>
<t>For the multicast Rekey SA, the GSK_w is provided along with
<t>For the multicast Rekey SA the GSK_w is provided along with other SA keys as defined in <xref target="group_sa_keys"/>.
other SA keys as defined in <xref target="group_sa_keys" />.
</t> </t>
</section> </section>
</section> </section>
<section anchor="key_gcks_semantics">
<section anchor="key_gcks_semantics" title="GCKS Key Management Semantics" <name>GCKS Key Management Semantics</name>
> <t>The Wrapped Key Download method allows the GCKS to employ various key
<t>Wrapped Key Download method allows the GCKS to employ various key man management methods.</t>
agement methods <dl newline="false" spacing="normal">
<list style="symbols"> <dt>A simple key management method:</dt><dd>The GCKS always sends
<t>A simple key management methods -- when the GCKS always sends group SA keys encrypted with the GSK_w.</dd>
group SA keys encrypted with the GSK_w. <dt>An LKH key management method:</dt><dd>The GCKS provides each
</t> GM with an individual key at the time of the GM registration
<t>An LKH key management method -- when the GCKS provides (encrypted with GSK_w). Then, the GCKS forms a hierarchy of keys so
each GM with an individual key at the time of the GM registration that the group SA keys are encrypted with other keys that are
(encrypted with GSK_w). Then the GCKS forms an hierarchy of keys so th encrypted with other keys and so on, tracing back to the keys for
at the group each GM.</dd>
SA keys are encrypted with other keys which are encrypted with other k </dl>
eys and so on, <t>
tracing back to the keys for each GM.
</t>
</list>
Other key policies may also be employed by the GCKS. Other key policies may also be employed by the GCKS.
</t> </t>
<section>
<section title="Forward Access Control Requirements"> <name>Forward Access Control Requirements</name>
<t>When group membership is altered using a group management <t>When a group membership is altered using a group management
algorithm new Data-Security SAs and their associated keys are usually algorithm, new Data-Security SAs and their associated keys are usually
also needed. New Data-Security SAs and keys ensure that members who we re also needed. New Data-Security SAs and keys ensure that members who we re
denied access can no longer participate in the group.</t> denied access can no longer participate in the group.</t>
<t>If forward access control is a desired property of the group, <t>If forward access control is a desired property of the group,
new TEK policy and the associated keys <bcp14>MUST NOT</bcp14> be incl a new TEK policy and the associated keys <bcp14>MUST NOT</bcp14> be in
uded cluded
in a G-IKEv2 rekey message which changes group membership. in a G-IKEv2 rekey message, which changes group membership.
This is required because the GSA TEK policy This is required because the GSA TEK policy
and the associated keys are not protected with the new KEK. and the associated keys are not protected with the new KEK.
A second G-IKEv2 rekey message can A second G-IKEv2 rekey message can
deliver the new GSA TEK policies and their associated keys deliver the new GSA TEK policies and their associated keys
because it will be protected with the new KEK, and thus will not because it will be protected with the new KEK and thus will not
be visible to the members who were denied access.</t> be visible to the members who were denied access.</t>
<t>If forward access control policy for the group includes <t>If forward access control policy for the group includes
keeping group policy changes from members that are denied access keeping group policy changes from members that are denied access
to the group, then two sequential G-IKEv2 rekey messages to the group, then two sequential G-IKEv2 rekey messages
changing the group KEK <bcp14>MUST</bcp14> be sent by the GCKS. The fi rst changing the group KEK <bcp14>MUST</bcp14> be sent by the GCKS. The fi rst
G-IKEv2 rekey message creates a new KEK for the group. Group G-IKEv2 rekey message creates a new KEK for the group. GMs, which are
members, which are denied access, will not be able to access the denied access, will not be able to access the
new KEK, but will see the group policy since the G-IKEv2 rekey new KEK, but they will see the group policy since the G-IKEv2 rekey
message is protected under the current KEK. A subsequent G-IKEv2 message is protected under the current KEK. A subsequent G-IKEv2
rekey message containing the changed group policy and again rekey message containing the changed group policy and again
changing the KEK allows complete forward access control. A changing the KEK allows complete forward access control. A
G-IKEv2 rekey message <bcp14>MUST NOT</bcp14> change the policy withou t G-IKEv2 rekey message <bcp14>MUST NOT</bcp14> change the policy withou t
creating a new KEK.</t> creating a new KEK.</t>
<t>If other methods of using LKH or other group management <t>If other methods of using LKH or other group management
algorithms are added to G-IKEv2, those methods <bcp14>MAY</bcp14> remo ve the algorithms are added to G-IKEv2, those methods <bcp14>MAY</bcp14> remo ve the
above restrictions requiring multiple G-IKEv2 rekey messages, above restrictions requiring multiple G-IKEv2 rekey messages,
providing those methods specify how the forward access control providing those methods specify how the forward access control
policy is maintained within a single G-IKEv2 rekey message.</t> policy is maintained within a single G-IKEv2 rekey message.</t>
</section> </section>
</section> </section>
<section anchor="keys_gm_semantics">
<section anchor="keys_gm_semantics" title="GM Key Management Semantics"> <name>GM Key Management Semantics</name>
<t>This specification defines a GM Key Management semantics <t>This specification defines GM Key Management semantics
in such a way, that it doesn't depend on the key management in such a way that it doesn't depend on the key management
method employed by the GCKS. This allows having all the complexity method employed by the GCKS. This allows having all the complexity
of key management in the GCKS, which is free to implement various of key management in the GCKS, which is free to implement various
key management methods, such as direct transmitting of group SA key management methods such as direct transmitting of group SA
keys or using some kind of key hierarchy (e.g. LKH). keys or using some kind of key hierarchy (e.g., LKH).
For all these policies the GM behavior is the same. The GM behavior is the same for all of these policies.
</t> </t>
<t>All keys in G-IKEv2 are transmitted in encrypted form as specified
<t>All keys in G-IKEv2 are transmitted in encrypted form, as specified in <xref target="wrapped_key"/>. This format includes a 32-bit Key ID
in <xref target="wrapped_key" />. This format includes a 32-bit Key ID
(ID of a key that is encrypted) and a 32-bit KWK ID (ID of a key that is encrypted) and a 32-bit KWK ID
(ID of a key that was used to encrypt this key). Keys may be (ID of a key that was used to encrypt this key). Keys may be
encrypted either with default KWK (GSK_w) or with other keys, encrypted either with a default KWK (GSK_w) or with other keys,
which the GM has received in the WRAP_KEY attributes. which the GM has received in the WRAP_KEY attributes.
If a key was encrypted with GSK_w, then the KWK ID field is set to zero, If a key was encrypted with GSK_w, then the KWK ID field is set to zero.
otherwise the KWK ID field identifies the key used for encryption. Otherwise, the KWK ID field identifies the key used for encryption.
Zero Key ID always identifies the key from which the keys for protecting A zero Key ID always identifies the key from which the keys for protecti
Data-Security SAs and Rekey SA are taken. ng Data-Security SAs and Rekey SA are taken.
</t> </t>
<t>When a GM receives a message from the GCKS installing the new Data-Se
<t>When a GM receives a message from the GCKS installing new Data-Securi curity or Rekey SA,
ty or Rekey SA,
it will contain a KD payload with an SA_KEY attribute containing keying material for this SA. it will contain a KD payload with an SA_KEY attribute containing keying material for this SA.
For a Data-Security SA exactly one SA_KEY attribute will be present For a Data-Security SA, exactly one SA_KEY attribute will be present
with both Key ID and KWK ID fields set to zero. This means that the with both Key ID and KWK ID fields set to zero. This means that the
default KWK (GSK_w) should be used to extract this keying material. default KWK (GSK_w) should be used to extract this keying material.
</t> </t>
<t>For a multicast Rekey SA, multiple SA_KEY attributes may be present
<t>For a multicast Rekey SA multiple SA_KEY attributes may be present
depending on the key management method employed by the GCKS. If multiple SA_KEY attributes depending on the key management method employed by the GCKS. If multiple SA_KEY attributes
are present then all of them <bcp14>MUST</bcp14> contain the same keying material encrypted using different KWKs. are present, then all of them <bcp14>MUST</bcp14> contain the same keyin g material encrypted using different KWKs.
The GM in general is unaware of the key management method used by the GC KS and can always use the same procedure to get The GM in general is unaware of the key management method used by the GC KS and can always use the same procedure to get
the keys. The GM tries to decrypt at least one of the SA_KEY attributes the keys. The GM tries to decrypt at least one of the SA_KEY attributes
using either the GSK_w or the keys from the WRAP_KEY attributes that are present in the same message using either the GSK_w or the keys from the WRAP_KEY attributes that are present in the same message
or were receives in previous messages. or were received in previous messages.
</t> </t>
<t>We will use the term "Key Path" to describe an ordered sequence of ke ys <t>We will use the term "Key Path" to describe an ordered sequence of ke ys
where each subsequent key was used to encrypt the previous one. where each subsequent key was used to encrypt the previous one.
The GM keeps its own Key Path (called Working Key Path) in the memory as sociated The GM keeps its own Key Path (called Working Key Path) in the memory as sociated
with each group it is registered to and updates it when needed. with each group it is registered to and updates it when needed.
When the GSA_REKEY message is received the GM processes the received SA_ When the GSA_REKEY message is received, the GM processes the received SA
KEY attributes _KEY attributes
one by one trying to construct a new key path that starts from one of th one by one and tries to construct a new key path that starts from one of
ese attributes and these attributes and
ends with any key in the Working Key Path or with the default KWK (GSK_w ). ends with any key in the Working Key Path or with the default KWK (GSK_w ).
</t> </t>
<t>In the simplest case, the SA_KEY attribute is encrypted
<t>In the simplest case the SA_KEY attribute is encrypted
with GSK_w so that the new Key Path is empty. with GSK_w so that the new Key Path is empty.
If more complex key management methods are used then a Key Path will If more complex key management methods are used, then a Key Path will
contain intermediate keys from the WRAP_KEY attributes contain intermediate keys from the WRAP_KEY attributes
received by a GM so far starting from its registration to the group. If the GM is able received by a GM so far, starting from its registration to the group. If the GM is able
to construct a new Key Path using intermediate keys it has, then it is a ble to decrypt the SA_KEY attribute to construct a new Key Path using intermediate keys it has, then it is a ble to decrypt the SA_KEY attribute
and use its content to form new SA keys. If it is unable to build a new Key Path, then in means that the GM is excluded and use its content to form new SA keys. If it is unable to build a new Key Path, then it means that the GM is excluded
from the group. from the group.
</t> </t>
<t>Depending on the new Key Path, the GM should do the following actions
<t>Depending on the new Key Path the GM should do the following actions to be prepared for future key updates:
to be prepared for future key updates: </t>
<list style="symbols"> <ul spacing="normal">
<t>If the new Key Path is empty then no actions are needed. This may h <li>
appen <t>If the new Key Path is empty, then no actions are needed. This ma
y happen
if no WRAP_KEY attributes from the received message were used. if no WRAP_KEY attributes from the received message were used.
</t> </t>
<t>If the new Key Path is non-empty and it ends with the default KWK ( </li>
GSK_w), then the whole new <li>
<t>If the new Key Path is non-empty and it ends with the default KWK
(GSK_w), then the whole new
Key Path is stored by the GM as the GM's Working Key Path. Key Path is stored by the GM as the GM's Working Key Path.
This situation may only happen at the time the GM is registering to th
e group, This situation may only happen at the time the GM is registering to the group,
when the GCKS is providing it with its personal key and the other keys when the GCKS is providing the GM with its personal key and the other
from the key tree that are needed for this GM. keys from the key tree that are needed.
These keys form an initial Working Key Path for this GM. These keys form an initial Working Key Path for this GM.
</t> </t>
<t>In all other cases the new Key Path will end at some intermediate k </li>
ey from the GM's current Working Key Path. <li>
In this case the new Key Path is constructed by replacing a part of th <t>In all other cases, the new Key Path will end at some intermediat
e GM's current Working Key Path from the beginning and up to (but not including) e key from the GM's current Working Key Path.
In this case, the new Key Path is constructed by replacing a part of t
he GM's current Working Key Path from the beginning and up to (but not including
)
the key that the GM has used to decrypt the last key in the new Key Pa th. the key that the GM has used to decrypt the last key in the new Key Pa th.
</t> </t>
</list> </li>
<xref target="lkh_key_management" /> contains an example of how this alg </ul>
orithm works in case of LKH key management method. <t>
<xref target="lkh_key_management"/> contains an example of how this algo
rithm works in case of LKH key management method.
</t> </t>
</section> </section>
<section anchor="group_sa_keys">
<section anchor="group_sa_keys" title="SA Keys"> <name>SA Keys</name>
<t>The keys that are used for Data-Security SAs or Rekey SA (called here <t>The keys that are used for Data-Security SAs or a Rekey SA (called
SA keys) are downloaded to GMs in the form of keying material from which SA keys here) are downloaded to GMs in the form of keying material from
, which,
according to policy, a set of keys are deterministically extracted. according to policy, a set of keys are deterministically extracted.
</t> </t>
<t>For a Data-Security SA, the keys are taken in accordance to the
<t>For a Data-Security SA the keys are taken in accordance to the third third bullet from <xref target="RFC7296" sectionFormat="of"
bullet from Section 2.17 of section="2.17"/>. In particular, for the ESP and AH SAs, the encryption
<xref target="RFC7296" />. In particular, for the ESP and AH SAs the enc key (if any) <bcp14>MUST</bcp14> be taken from the leftmost bits of
ryption key (if any) <bcp14>MUST</bcp14> be the keying material and the integrity key (if any) <bcp14>MUST</bcp14>
taken from the leftmost bits of the keying material and the integrity ke be taken from the remaining bits.
y (if any) <bcp14>MUST</bcp14> be
taken from the remaining bits.
</t> </t>
<t>For a Rekey SA, the following keys are taken from the keying material
<t>For a Rekey SA the following keys are taken from the keying material: :
</t>
<figure > <artwork><![CDATA[
<artwork><![CDATA[
GSK_e | GSK_a | GSK_w = KEYMAT GSK_e | GSK_a | GSK_w = KEYMAT
]]></artwork> ]]></artwork>
</figure> <t>
where GSK_e and GSK_a are the keys used for the Encryption Algorithm and
where GSK_e and GSK_a are the keys used for the Encryption Algorithm and the Integrity Algorithm transforms, respectively, for the corresponding
the Integrity Algorithm transforms SA and GSK_w is a default KWK for this SA. Note that GSK_w is used with
for the corresponding SA and GSK_w is a default KWK for this SA. Note, t
hat GSK_w is used with
the key wrap algorithm specified in the Key Wrap Algorithm transform. If an AEAD algorithm is used for encryption, the key wrap algorithm specified in the Key Wrap Algorithm transform. If an AEAD algorithm is used for encryption,
then GSK_a key will not be used (GM can use the formula above assuming t he length of GSK_a is zero). then the GSK_a key will not be used (GM can use the formula above assumi ng the length of GSK_a is zero).
</t> </t>
</section> </section>
</section> </section>
<section anchor="header_payload">
<section anchor="header_payload" title="Header and Payload Formats"> <name>Header and Payload Formats</name>
<t>The G-IKEv2 is an IKEv2 extension and thus inherits its wire format <t>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: different. Several new payloads are defined:
Group Identification (IDg, <xref target="idg_payload" />), Security Associ Group Identification (IDg) (<xref target="idg_payload"/>), Security Associ
ation - GM Supported Transforms (SAg, <xref target="sag_payload" />), ation - GM Supported Transforms (SAg) (<xref target="sag_payload"/>),
Group Security Association (GSA, <xref target="gsa_payload" />), and Key D Group Security Association (GSA) (<xref target="gsa_payload"/>), and Key D
ownload (KD, <xref target="kd_payload" />). ownload (KD) (<xref target="kd_payload"/>).
G-IKEv2 header (<xref target="header" />), IDg payload and SAg payload reu The G-IKEv2 header (<xref target="header"/>), IDg payload, and SAg payload
se IKEv2 format for the IKEv2 header, IDi/IDr payloads reuse the IKEv2 format for the IKEv2 header, IDi/IDr payloads, and SA payload,
and SA payload respectively. New exchange types GSA_AUTH, GSA_REGISTRATION respectively. New exchange types GSA_AUTH, GSA_REGISTRATION, GSA_REKEY, and GSA_
, GSA_REKEY and GSA_INBAND_REKEY are INBAND_REKEY are
also added. also added.
</t> </t>
<t>This section describes new payloads and the differences in the processi
<t>This section describes new payloads and the differences in processing ng
of existing IKEv2 payloads. of existing IKEv2 payloads.
</t> </t>
<section anchor="header">
<section anchor="header" title="G-IKEv2 Header"> <name>G-IKEv2 Header</name>
<t>G-IKEv2 uses the same IKE header format as specified in <xref target= <t>G-IKEv2 uses the same IKE header format as specified in <xref
"RFC7296" /> target="RFC7296" sectionFormat="of" section="3.1"/>. The Major Version i
section 3.1. Major Version is 2 and Minor Version is 0 as in IKEv2. s
IKE SA Initiator's SPI, IKE SA Responder's SPI, Flags, Message ID, and L 2 and the Minor Version is 0, as in IKEv2. IKE SA Initiator's SPI, IKE S
ength are A
as specified in <xref target="RFC7296"></xref>. Responder's SPI, Flags, Message ID, and Length are as specified in
<xref target="RFC7296"/>.
</t> </t>
</section> </section>
<section anchor="idg_payload">
<section title="Group Identification Payload" anchor="idg_payload"> <name>Group Identification Payload</name>
<t>The Group Identification (IDg) payload allows the group member to ind <t>The Group Identification (IDg) payload allows the GM to indicate whic
icate which group it h group it
wants to join. The payload is constructed by using the IKEv2 wants to join. The payload is constructed by using the IKEv2
Identification Payload (section 3.5 of <xref target="RFC7296"></xref>). Identification Payload (<xref target="RFC7296" sectionFormat="of" sectio
ID type ID_KEY_ID <bcp14>MUST</bcp14> be supported. ID types ID_IPV4_ADD n="3.5"/>).
R, ID_FQDN, ID_RFC822_ADDR, ID type ID_KEY_ID <bcp14>MUST</bcp14> be supported. ID types ID_IPV4_ADD
ID_IPV6_ADDR <bcp14>SHOULD</bcp14> be supported. ID types ID_DER_ASN1_DN R, ID_FQDN, ID_RFC822_ADDR, and ID_IPV6_ADDR <bcp14>SHOULD</bcp14> be supported.
and ID_DER_ASN1_GN ID types ID_DER_ASN1_DN and ID_DER_ASN1_GN
are not expected to be used. The Payload Type for the Group Identificati are not expected to be used. The Payload Type for the IDg payload is fif
on payload is fifty (50). ty (50).
</t> </t>
</section> </section>
<section anchor="sag_payload">
<section title="Security Association - GM Supported Transforms Payload" an <name>Security Association - GM Supported Transforms Payload</name>
chor="sag_payload"> <t>The Security Association - GM Supported Transforms (SAg) payload
<t>The Security Association - GM Supported Transforms Payload (SAg) declares which Transforms a GM is willing to
payload declares which Transforms a GM is willing to
accept. The payload is constructed using the format of the IKEv2 accept. The payload is constructed using the format of the IKEv2
Security Association payload (section 3.3 of <xref target="RFC7296"></xr ef>). Security Association payload (<xref target="RFC7296" sectionFormat="of" section="3.3"/>).
The Payload Type for SAg payloads is thirty-three (33), which is The Payload Type for SAg payloads is thirty-three (33), which is
identical to the SA Payload Type. identical to the SA Payload Type.
</t> </t>
</section> </section>
<section anchor="gsa_payload">
<section title="Group Security Association Payload" anchor="gsa_payload"> <name>Group Security Association Payload</name>
<t>The Group Security Association (GSA) payload is used by the GCKS to <t>The GSA payload is used by the GCKS to assert security attributes for
assert security attributes for both Rekey SA and Data-Security SAs. both Rekey and Data-Security SAs.
The Payload Type for the Group Security Association payload is fifty-one The Payload Type for the GSA payload is fifty-one (51).
(51).
</t> </t>
<figure title="GSA Payload Format" anchor="gsa_payload_format"> <figure anchor="gsa_payload_format">
<preamble></preamble> <name>GSA Payload Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ <Group Policies> ~ ~ <Group Policies> ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
]]></artwork>
<postamble></postamble>
</figure> </figure>
<t>The Security Association Payload fields are defined as follows: <t>The GSA payload fields are defined as follows:
<list style="symbols">
<t>Next Payload, C, RESERVED, Payload Length fields comprise the IKE
v2 Generic Payload Header and
are defined in Section 3.2. of <xref target="RFC7296"></xref>.</t>
<t>Group Policies (variable) -- A set of group policies for the grou
p.</t>
</list>
</t> </t>
<dl spacing="normal" newline="true">
<section anchor="group_policy" title="Group Policies"> <dt>Next Payload, C, RESERVED, and Payload Length
<t>Group policies are comprised of two types of policy -- Group SA (GS fields:</dt><dd>Comprise the IKEv2 generic payload header and are
A) policy defined in <xref target="RFC7296" sectionFormat="of" section="3.2"/>.<
and Group-wide (GW) policy. GSA policy defines parameters /dd>
for the Security Association for the group. Depending on the <dt>Group Policies (variable):</dt><dd>A set of group policies for
employed security protocol GSA policies may further be classified as the group.</dd>
Rekey SA policy (GSA KEK) and Data-Security SA policy (GSA TEK). </dl>
GSA payload may contain zero or one GSA KEK policy, zero or more GSA T <section anchor="group_policy">
EK policies, <name>Group Policies</name>
and zero or one GW policy, where either one GSA KEK or GSA TEK policy <t>Group policies are comprised of two types: group SA policy and
<bcp14>MUST</bcp14> be present.</t> group-wide (GW) policy. Group SA policy defines parameters for the
Security Association of the group. Depending on the employed
security protocol, group SA policies may further be classified as Reke
y
SA (GSA KEK) policy and Data-Security (GSA TEK) SA policy. GSA
payload may contain zero or one GSA KEK policy, zero or more GSA TEK
policies, and zero or one GW policy, where either one GSA KEK or one
GSA TEK policy <bcp14>MUST</bcp14> be present.</t>
<t>This latitude allows various group policies to be accommodated. <t>This latitude allows various group policies to be accommodated.
For example if the group policy does not require the use of a Rekey For 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 SA, 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_RE KEY exchange via the member since all SA updates would be performed using the GSA_INBAND_RE KEY exchange via the
unicast IKE SA. Alternatively, group policy might use a Rekey SA unicast IKE SA. Alternatively, group policy might use a Rekey SA
but choose to download a KEK to the group member only as part of the 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 unicast IKE SA. Therefore, the GSA KEK policy would not be
necessary as part of the GSA_REKEY message.</t> necessary as part of the GSA_REKEY message.</t>
<t>Specifying multiple GSA TEKs allows multiple related data streams <t>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 protected with an individual security association policy.</t> each are protected with an individual Security Association.</t>
<t>A GW policy allows for the distribution of group-wide policy, <t>A GW policy allows for the distribution of group-wide policy,
such as instructions for when to activate and de-activate SAs.</t> such as instructions for when to activate and deactivate SAs.</t>
<t>Policies are distributed in substructures to the GSA payload. <t>Policies are distributed in substructures to the GSA payload.
The format of the substructures is defined below in <xref target="gsa_ The format of the substructures is defined in <xref target="gsa_policy
policy" /> "/>
(for GSA policy) and in <xref target="gw_policy" /> (for GW policy). (for group SA policy) and in <xref target="gw_policy"/> (for GW policy
The first octet of the substructure unambiguously determines its type ).
-- The first octet of the substructure unambiguously determines its type;
it is zero for GW policy and non-zero (actually, it is a security prot it is zero for GW policy and non-zero (actually, it contains a Securit
ocol ID) y Protocol Identifier)
for GSA policies. for group SA policies.
</t> </t>
</section> </section>
<section anchor="gsa_policy">
<section title="Group Security Association Policy Substructure" anchor=" <name>Group Security Association Policy Substructure</name>
gsa_policy"> <t>The group SA policy substructure contains parameters for a single
<t>The GSA policy substructure contains parameters for the SA SA that is used with this group. Depending on the security protocol,
used with this group. Depending on the security protocol the SA is either a Rekey SA or a Data-Security SA (ESP and AH). The
the SA is either a Rekey SA or a Data-Security SA (ESP and AH). GCKS <bcp14>MUST NOT</bcp14> distribute both ESP and AH policies for
The GCKS <bcp14>MUST NOT</bcp14> distribute both ESP and AH the same set of Traffic Selectors.
policies for the same set of Traffic Selectors.
</t> </t>
<t><figure title="GSA Policy Substructure Format" anchor="gsa_format"> <figure anchor="gsa_format">
<preamble></preamble> <name>Group SA Policy Substructure Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
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 ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Source Traffic Selector ~ ~ Source Traffic Selector ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Destination Traffic Selector ~ ~ Destination Traffic Selector ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ <GSA Transforms> ~ ~ <Group SA Transforms> ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ <GSA Attributes> ~ ~ <Group SA Attributes> ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
<postamble></postamble> </figure>
</figure></t>
<t>The GSA policy fields are defined as follows:
<ul>
<li><t>Protocol (1 octet) -- Identifies the security protocol for th
is group SA.
The values are defined in the IKEv2 Security Protocol Identifiers in
<xref target="IKEV2-IANA" />. The valid values for this field are:
&lt;TBA&gt; (GIKE_UPDATE) for Rekey SA and 2 (AH) or 3 (ESP) for Dat
a-Security SAs.
</t></li>
<li><t>SPI Size (1 octet) -- Size of Security Parameter Index (SPI)
for the SA.
SPI size depends on the SA protocol. For GIKE_UPDATE it is 16 octets
, while for AH and ESP it is 4 octets.
</t></li>
<li><t>Length (2 octets, unsigned integer) -- Length of this substru <t>The group SA policy fields are defined as follows:</t>
cture including the header.
</t></li>
<li><t>SPI (variable) -- Security Parameter Index for the group SA. <dl spacing="normal" newline="true">
<dt>Protocol (1 octet):</dt><dd>Identifies the security protocol
for this group SA. The values are defined in the "IKEv2 Security
Protocol Identifiers" registry in <xref target="IKEV2-IANA"/>. The v
alid
values for this field are 6 (GIKE_UPDATE) for Rekey SA
and 2 (AH) or 3 (ESP) for Data-Security SAs.</dd>
<dt>SPI Size (1 octet):</dt><dd>Size of the SPI
for the SA. SPI size depends on the SA protocol. It is 16 octets fo
r GIKE_UPDATE and 4 octets for AH and ESP.</dd>
<dt>Length (2 octets, unsigned integer):</dt><dd>Length of this
substructure including the header.</dd>
<dt>SPI (variable):</dt><dd>Security Parameter Index for the group S
A.
The size of this field is determined by the SPI Size field. The size of this field is determined by the SPI Size field.
As described above, these SPIs are assigned by the GCKS. As described above, these SPIs are assigned by the GCKS.
In case of GIKE_UPDATE the SPI is the IKEv2 Header SPI pair where th e In the case of GIKE_UPDATE, the SPI is the IKEv2 header SPI pair whe re the
first 8 octets become the "IKE SA Initiator's SPI" field in the first 8 octets become the "IKE SA Initiator's SPI" field in the
G-IKEv2 rekey message IKEv2 HDR, and the second 8 octets become G-IKEv2 rekey message IKEv2 HDR, and the second 8 octets become
the "IKE SA Responder's SPI" in the same HDR. the "IKE SA Responder's SPI" in the same HDR.</dd>
</t></li> <dt>Source &amp; Destination Traffic Selectors (variable):</dt><dd>
<t>Substructures describing the source and destination of the networ
<li><t>Source &amp; Destination Traffic Selectors (variable) -- k
Substructures describing the source and destination of the identities. The format for these substructures is defined in IKEv2
network identities. The format for these substructures (<xref target="RFC7296" sectionFormat="of" section="3.13.1"/>).</t>
is defined in IKEv2 <xref target="RFC7296"></xref>, Section 3.13.1. <t>For the Rekey SA (with the GIKE_UPDATE protocol), the
</t> destination traffic selectors <bcp14>MUST</bcp14> define a single
<t>For the Rekey SA (with the GIKE_UPDATE protocol) the multicast IP address, an IP protocol (assumed to be UDP), and a
destination traffic selectors <bcp14>MUST</bcp14> define a single mu single port the GSA_REKEY messages will be destined to. In this case
lticast IP address, an IP protocol (assumed to be UDP) , the source
and a single port the GSA_REKEY messages will be destined to. The so traffic selector <bcp14>SHOULD</bcp14> define a
urce traffic selector in this case <bcp14>SHOULD</bcp14> define single IP address, an IP protocol (assumed to be UDP), and a single
a single IP address, an IP protocol (assumed to be UDP) and a single port the GSA_REKEY messages will be originated from. The source
port the GSA_REKEY messages will be originated from. traffic selector <bcp14>MAY</bcp14> define a wildcard IP address
The source traffic selector <bcp14>MAY</bcp14> define wildcard IP ad and/or wildcard port. For the Data-Security (AH and ESP) SAs, the
dress and/or wildcard port. For the Data-Security (AH and ESP) SAs the destination traffic selectors will usually define a single
destination traffic selectors will usually define a single multicast multicast IP address. The source traffic selector in this case
IP address. will usually define a single IP address or be a wildcard selector.
The source traffic selector in this case will usually define a singl An IP protocol and ports define the characteristics of traffic
e IP address or be a wildcard selector. protected by this Data-Security SA.</t>
IP protocol and ports define the characteristics of traffic protecte <t>If the Data-Security SAs are created in tunnel mode, then it
d by this Data-Security SA. <bcp14>MUST</bcp14> be tunnel mode with address preservation (see
</t> Multicast Extensions to the Security Architecture <xref
<t>If the Data-Security SAs are created in tunnel mode, then it <bcp target="RFC5374"/>. UDP encapsulation of ESP packets <xref
14>MUST</bcp14> be tunnel mode with address target="RFC3948"/> cannot be specified in G-IKEv2 and thus is
preservation (see Multicast Extensions to the Security Architecture not used for the multicast Data-Security SAs.</t></dd>
<xref target="RFC5374" />. <dt>Group SA Transforms (variable):</dt><dd>A list of Transform
UDP encapsulation of ESP packets <xref target="RFC3948" /> cannot be Substructures specifies the policy information for the SA. The
specified in G-IKEv2 and format is defined in IKEv2 (<xref target="RFC7296"
thus it is not used for the multicast Data-Security SAs. sectionFormat="of" section="3.3.2"/>). The "Last Substruc" field
</t></li> in each Transform Substructure is set to 3 except for the last
Transform Substructure, where it is set to 0. <xref
<li><t>GSA Transforms (variable) -- A list of Transform target="gsa_transforms"/> describes using IKEv2 transforms in the
Substructures specifies the policy information for the SA. group SA policy substructure.</dd>
The format is defined in IKEv2 <xref target="RFC7296"></xref>, secti <dt>Group SA Attributes (variable):</dt><dd>Contains policy attribut
on 3.3.2. es
The "Last Substruc" field in each Transform Substructure is set to 3 associated with the group SA. The following sections describe the
except for the last Transform Substructure, where it is possible attributes. Any or all attributes may be optional,
set to 0. <xref target="gsa_transforms" /> describes using IKEv2 tra depending on the protocol and the group policy. <xref
nsforms target="gsa_attr"/> defines attributes used in the group SA policy
in GSA policy substructure. substructure.</dd>
</t></li> </dl>
<section anchor="gsa_transforms">
<li><t>GSA Attributes (variable) -- Contains policy attributes assoc <name>Group SA Transforms</name>
iated <t>Group SA policy is defined by the means of transforms in the grou
with the group SA. The following sections describe the possible p SA policy substructure.
attributes. Any or all attributes may be optional, depending on For this purpose, the transforms defined in <xref target="RFC7296"/>
the protocol and the group policy. <xref target="gsa_attr" /> are used. In addition, new Transform Types are defined for use in G-
defines attributes used in GSA policy substructure.</t></li> IKEv2:
</ul></t>
<section anchor="gsa_transforms" title="GSA Transforms">
<t>GSA policy is defined by means of transforms in the GSA policy su
bstructure.
For this purpose the transforms defined in <xref target="RFC7296" />
are used. In addition, new transform types are defined for using in
G-IKEv2:
Group Controller Authentication Method (GCAUTH) Group Controller Authentication Method (GCAUTH)
and Key Wrap Algorithm (KWA), see <xref target="IANA" />. and Key Wrap Algorithm (KWA); see <xref target="IANA"/>.
</t>
<t> Valid transform types depend on the SA protocol and are summariz
ed in the table below.
Exactly one instance of each mandatory transform type and at most on
e instance of each
optional transform type <bcp14>MUST</bcp14> be present in the GSA po
licy substructure.
<figure align="center" anchor="allowed_transforms" title="Valid Tran
sform Types">
<artwork align="left"><![CDATA[
Protocol Mandatory Types Optional Types
GIKE_UPDATE ENCR, INTEG*, GCAUTH**, KWA
ESP ENCR, SN INTEG
AH INTEG, SN
]]></artwork>
</figure>
</t>
<t>(*) If AEAD encryption algorithm is used, then INTEG transform
either <bcp14>MUST NOT</bcp14> be specified or <bcp14>MUST</bcp14> c
ontain value NONE;
otherwise it <bcp14>MUST</bcp14> be specified and <bcp14>MUST</bcp14
> contain value other than NONE.
</t> </t>
<t>(**) May only appear at the time of a GM registration, <t> Valid Transform Types depend on the SA protocol and are summariz
(in the GSA_AUTH and GSA_REGISTRATION exchanges). ed in the table below.
Exactly one instance of each mandatory Transform Type and at most on
e instance of each
optional Transform Type <bcp14>MUST</bcp14> be present in the group
SA policy substructure.
</t> </t>
<section anchor="auth_method" title="Group Controller Authentication <table anchor="allowed_transforms">
Method Transform"> <name>Valid Transform Types</name>
<t>The Group Controller Authentication Method (GCAUTH) transform i <thead>
s used to convey information of how the GCKS <tr>
<th>Protocol</th>
<th>Mandatory Types</th>
<th>Optional Types</th>
</tr>
</thead>
<tbody>
<tr>
<td>GIKE_UPDATE</td>
<td>ENCR, INTEG*, GCAUTH**, KWA</td>
<td></td>
</tr>
<tr>
<td>ESP</td>
<td>ENCR, SN</td>
<td>INTEG</td>
</tr>
<tr>
<td>AH</td>
<td>INTEG, SN</td>
<td></td>
</tr>
</tbody>
</table>
<t>Notes:</t>
<dl spacing="normal" newline="false">
<dt>(*):</dt><dd>If the AEAD encryption algorithm is used, then IN
TEG
transform either <bcp14>MUST NOT</bcp14> be specified or
<bcp14>MUST</bcp14> contain value NONE; otherwise, it
<bcp14>MUST</bcp14> be specified and <bcp14>MUST</bcp14> contain
a value other than NONE.</dd>
<dt>(**):</dt><dd>May only appear at the time of a GM
registration (in the GSA_AUTH and GSA_REGISTRATION
exchanges).</dd>
</dl>
<section anchor="auth_method">
<name>Group Controller Authentication Method Transform</name>
<t>The Group Controller Authentication Method (GCAUTH) transform i
s used to convey information on how the GCKS
will authenticate the GSA_REKEY messages. will authenticate the GSA_REKEY messages.
</t> </t>
<t> This document creates a new IKEv2 IANA registry for Transform
<t> This document creates a new IKEv2 IANA registry for transform IDs of this Transform Type, which has been initially populated as described in <
IDs for this transform type, xref target="IANA"/>.
which is initially filled as described in <xref target="IANA" />. In particular, the following entries have been added:
In particular, the following entries are initially added.
</t> </t>
<figure> <table>
<preamble></preamble> <name>Group Controller Authentication Method Transform IDs</name>
<artwork align="center"><![CDATA[ <thead>
Group Controller Authentication Method Value <tr>
Reserved 0 <th>Value</th>
Implicit 1 <th>Group Controller Authentication Method</th>
Digital Signature 2 </tr>
]]></artwork> </thead>
</figure> <tbody>
<tr>
<t>These transform IDs are defined as follows. <td>0</td><td>Reserved</td>
<ul> </tr>
<li><t> Implicit -- means that no authentication of the GSA_REKE <tr>
Y messages will be provided <td>1</td><td>Implicit</td>
by the GCKS besides the ability for the GMs to correctly decrypt </tr>
them and verify their ICV. <tr>
In this case the GCKS <bcp14>MUST NOT</bcp14> include the AUTH_K <td>2</td><td>Digital Signature</td>
EY attribute into the KD payload. </tr>
Additionally, the AUTH payload <bcp14>MUST NOT</bcp14> be includ </tbody>
ed in the GIKE_UPDATE messages.</t></li> </table>
<li><t> Digital Signature -- means that digital signatures will
be used by the GCKS to authenticate the GSA_REKEY messages.
In this case the GCKS <bcp14>MUST</bcp14> include the AUTH_KEY a
ttribute containing the public key
into the KD payload at the time the GM is registered to the grou
p. To specify the details of the
signature algorithm a new attribute Signature Algorithm Identifi
er (&lt;TBA by IANA&gt;) is defined.
This attribute contains DER-encoded ASN.1 object AlgorithmIdenti
fier, which specifies the
signature algorithm and the hash function that the GCKS will use
for authentication.
The AlgorithmIdentifier object is defined in Section 4.1.1.2 of
Internet X.509 Public
Key Infrastructure Certificate and CRL Profile <xref target="RFC
5280" />,
see also Signature Authentication in IKEv2 <xref target="RFC7427
" /> for the list of common AlgorithmIdentifier values used in IKEv2.</t>
<t>In case of the Digital Signature transform ID, the GCKS <bcp1 <t>These Transform IDs are defined as follows:</t>
4>MUST</bcp14> include the Signature Algorithm Identifier attribute
in the Group Controller Authentication Method transform. In this
case the AUTH payload
in the GIKE_UPDATE messages <bcp14>MUST</bcp14> contain the Digi
tal Signature authentication method (value 14)
and is formatted as defined in Section 3 of <xref target="RFC742
7" />. The
AlgorithmIdentifier ASN.1 object in the AUTH payload <bcp14>MUST
</bcp14> match the content of the
Signature Algorithm Identifier attribute in the Group Controller
Authentication Method transform.
The Signature Algorithm Identifier attribute is only meaningful
for the Digital Signature transform ID
and <bcp14>MUST NOT</bcp14> be used with other transform IDs.
</t></li>
</ul>
More authentication methods may be defined in future. <dl spacing="normal" newline="true">
<dt>Implicit:</dt><dd>No authentication of the
GSA_REKEY messages will be provided by the GCKS besides the
ability for the GMs to correctly decrypt them and verify their
ICV. In this case, the GCKS <bcp14>MUST NOT</bcp14> include
the AUTH_KEY attribute into the KD payload. Additionally, the
AUTH payload <bcp14>MUST NOT</bcp14> be included in the
GIKE_UPDATE messages.</dd>
<dt>Digital Signature</dt><dd><t>Digital signatures
will be used by the GCKS to authenticate the GSA_REKEY
messages. In this case, the GCKS <bcp14>MUST</bcp14> include
the AUTH_KEY attribute containing the public key into the KD
payload at the time the GM is registered to the group. To
specify the details of the signature algorithm, a new attribute
Signature Algorithm Identifier (value 18) is
defined. This attribute contains DER-encoded ASN.1 object
AlgorithmIdentifier, which specifies the signature algorithm
and the hash function that the GCKS will use for
authentication. The AlgorithmIdentifier object is defined in
<xref target="RFC5280" sectionFormat="of"
section="4.1.1.2"/>. Also, see <xref target="RFC7427"/>
for the list of common AlgorithmIdentifier values used in
IKEv2.</t>
<t>In the case of the Digital Signature Transform ID, the GCKS
<bcp14>MUST</bcp14> include the Signature Algorithm Identifier
attribute in the Group Controller Authentication Method
transform. In this case, the AUTH payload in the GIKE_UPDATE
messages <bcp14>MUST</bcp14> contain the Digital Signature
authentication method (value 14) and be formatted as defined
in <xref target="RFC7427" sectionFormat="of" section="3"/>. The
AlgorithmIdentifier ASN.1 object in the AUTH payload
<bcp14>MUST</bcp14> match the content of the Signature
Algorithm Identifier attribute in the Group Controller
Authentication Method transform. The Signature Algorithm
Identifier attribute is only meaningful for the Digital
Signature Transform ID and <bcp14>MUST NOT</bcp14> be used
with other Transform IDs.</t></dd>
</dl>
<t>
More authentication methods may be defined in the future.
</t> </t>
<t>The authentication method <bcp14>MUST NOT</bcp14> change as a r
<t> The authentication method <bcp14>MUST NOT</bcp14> change as a esult of rekey operations.
result of rekey operations.
This means that the Group Controller Authentication Method transfo rm <bcp14>MUST NOT</bcp14> appear in the rekey This means that the Group Controller Authentication Method transfo rm <bcp14>MUST NOT</bcp14> appear in the rekey
messages, it may only appear in the registration exchange (either GSA_AUTH or GSA_REGISTRATION). messages; it may only appear in the registration exchange (either GSA_AUTH or GSA_REGISTRATION).
</t> </t>
<t>The type of the Group Controller Authentication Method transfor
<t>The type of the Group Controller Authentication Method Transfor m is 14.
m is &lt;TBA by IANA&gt;.
</t> </t>
</section> </section>
<section anchor="wrapping_alg">
<section anchor="wrapping_alg" title="Key Wrap Algorithm Transform"> <name>Key Wrap Algorithm Transform</name>
<t>The Key Wrap Algorithm (KWA) transform is used to convey inform <t>The Key Wrap Algorithm (KWA) transform is used to convey inform
ation about an algorithm, ation about an algorithm
that is used for key wrapping in G-IKEv2. See <xref target="wrappe that is used for key wrapping in G-IKEv2. See <xref target="wrappe
d_key" /> for details. d_key"/> for details.
</t> </t>
<t> This document creates a new IKEv2 IANA registry for the key wr
<t> This document creates a new IKEv2 IANA registry for the key wr ap algorithms,
ap algorithms which has been initially populated as described in <xref target="I
which is initially filled as described in <xref target="IANA" />. ANA"/>.
In particular, the following entries are initially added. In particular, the following entries have been added:
</t> </t>
<figure> <table>
<preamble></preamble> <name>Key Wrap Algorithm Transform IDs</name>
<artwork align="center"><![CDATA[ <thead>
Key Wrap Algorithm Value <tr>
Reserved 0 <th>Value</th>
KW_5649_128 1 <th>Key Wrap Algorithm</th>
KW_5649_192 2 </tr>
KW_5649_256 3 </thead>
KW_ARX 4 <tbody>
]]></artwork> <tr>
</figure> <td>0</td>
<td>Reserved</td>
<t>These algorithms are defined as follows. </tr>
<list style="symbols"> <tr>
<t> KW_5649_128, KW_5649_192, KW_5649_256 -- Key wrap algorithm <td>1</td>
defined in <xref target="RFC5649" /> with 128-bit, 192-bit and 256-bit key respe <td>KW_5649_128</td>
ctively. </tr>
This key wrap algorithm is designed for use with AES block ciphe <tr>
r.</t> <td>2</td>
<t> KW_ARX -- The ARX-KW-8-2-4-GX key wrap algorithm defined in <td>KW_5649_192</td>
<xref target="ARX-KW" />. This key wrap algorithm is designed for use </tr>
with Chacha20 stream cipher.</t> <tr>
</list> <td>3</td>
<td>KW_5649_256</td>
</tr>
<tr>
<td>4</td>
<td>KW_ARX</td>
</tr>
</tbody>
</table>
<t>These algorithms are defined as follows:</t>
<dl spacing="normal" newline="true">
<dt>KW_5649_128, KW_5649_192, KW_5649_256:</dt><dd>The key wrap
algorithm defined in <xref target="RFC5649"/> with a 128-bit,
192-bit, and 256-bit key, respectively. This key wrap algorithm
is designed for use with AES block cipher.</dd>
<dt>KW_ARX:</dt><dd>The ARX-KW-8-2-4-GX key wrap algorithm
defined in <xref target="ARX-KW"/>. This key wrap algorithm is
designed for use with Chacha20 stream cipher.</dd>
</dl>
More key wrap algorithms may be defined in future. The requirement <t>More key wrap algorithms may be defined in the future. The
is that these algorithms <bcp14>MUST</bcp14> be able requirement is that these algorithms must be able
to wrap key material of size up to 256 bytes. to wrap key material of size up to 256 bytes.
</t> </t>
<t>The type of the Key Wrap Algorithm transform is 13.
<t>The type of the Key Wrap Algorithm transform is &lt;TBA by IANA
&gt;.
</t> </t>
</section> </section>
<section anchor="antireplay">
<section anchor="antireplay" title="Sequence Numbers Transform"> <name>Sequence Numbers Transform</name>
<t>The "Sequence Numbers (SN)" transform type is defined in <xref <t>The Sequence Numbers (SNs) Transform Type is defined in <xref t
target="I-D.ietf-ipsecme-ikev2-rename-esn" />. arget="RFC9827"/>.
This transform describes the properties of sequence numbers of IPs This transform describes the properties of sequence numbers of IPs
ec packets. There are currently two transform IDs ec packets. There are currently two Transform IDs
defined for this transform type: "32-bit Sequential Numbers" and " defined for this Transform Type: "32-bit Sequential Numbers" and "
Partially Transmitted 64-bit Sequential Numbers" Partially Transmitted 64-bit Sequential Numbers"
that correspond to non-ESN and ESN cases from AH <xref target="RFC that correspond to non-ESN and ESN cases from AH <xref target="RFC
4302" /> and ESP <xref target="RFC4303" /> specifications. 4302"/> and ESP <xref target="RFC4303"/> specifications.
</t> </t>
<t>Transform ID "32-bit Sequential Numbers" <bcp14>SHOULD</bcp14>
<t> Transform ID "32-bit Sequential Numbers" <bcp14>SHOULD</bcp14> be used by the GCKS for
be used by the GCKS for
single-sender multicast Data-Security SAs utilizing protocols ESP or AH. single-sender multicast Data-Security SAs utilizing protocols ESP or AH.
</t> </t>
<t>Since both AH <xref target="RFC4302"/> and ESP <xref target="RF
<t>Since both AH <xref target="RFC4302" /> and ESP <xref target="R C4303"/> are defined in such a way that high-order 32 bits of extended sequence
FC4303" /> are defined in such a way, numbers are never transmitted, it makes using ESN in multicast Data-Security SAs
that high-order 32 bits of extended sequence numbers are never tra problematic because GMs that join the group long after it is creat
nsmitted, it makes using ESN in multicast Data-Security SAs ed will have to somehow learn the current high-order 32 bits
problematic, because GMs that join group long after it is created of ESN for each sender in the group. The algorithm for doing this
will have to somehow learn the current high order 32 bits described in AH <xref target="RFC4302"/>
of ESN for each sender in the group. The algorithm for doing this and ESP <xref target="RFC4303"/> is resource-consuming and is only
described in AH <xref target="RFC4302" /> suitable when a receiver is able to guess
and ESP <xref target="RFC4303" /> is resource-consuming and is onl
y suitable when a receiver is able to guess
the high-order 32 bits close enough to its real value, which is no t the case for multicast SAs. the high-order 32 bits close enough to its real value, which is no t the case for multicast SAs.
For this reason the "Partially Transmitted 64-bit Sequential Numbe rs" transform ID For this reason, the "Partially Transmitted 64-bit Sequential Numb ers" Transform ID
<bcp14>MUST NOT</bcp14> be used for multicast Data-Security SAs ut ilizing protocols ESP or AH. <bcp14>MUST NOT</bcp14> be used for multicast Data-Security SAs ut ilizing protocols ESP or AH.
</t> </t>
<t> This document defines a new Transform ID
<t> This document defines a new transform ID "32-bit Unspecified N for this Transform Type: "32-bit Unspecified Numbers" (2). This Tr
umbers" (&lt;TBA by IANA&gt;) ansform ID defines the following properties:</t>
for this transform type. This transform ID defines the following p <ul><li>Sequence numbers are
roperties. 32 bits in size and are transmitted in the Sequence Number field of AH and ESP
Sequence numbers are 32-bit in size and are transmitted in the Seq packets.</li>
uence Number field of AH and ESP packets. <li>The value of sequence numbers is not guaranteed to be unique for the
The value of sequence numbers is not guaranteed to be unique for t duration of an SA, thus they are not suitable for replay protection.</li></ul>
he duration of an SA, thus they <t>This
are not suitable for replay protection. This transform ID <bcp14>M Transform ID <bcp14>MUST</bcp14> be used by the GCKS in case of multi-sender
UST</bcp14> be used by the GCKS in case of multi-sender multicast Data-Security SAs utilizing protocols ESP or AH to inform the GMs
multicast Data-Security SAs utilizing protocols ESP or AH to infor that the replay protection is not expected to be possible. The GCKS
m the GMs that the replay protection is not expected to be possible. <bcp14>MAY</bcp14> also use this Transform ID for single-sender multicast
The GCKS <bcp14>MAY</bcp14> also use this transform ID for single- Data-Security SAs if replay protection is not needed (e.g., it is done on
sender multicast Data-Security SAs if replay the application level).
protection is not needed (e.g. it is done on application level).
</t> </t>
</section> </section>
</section> </section>
<section anchor="gsa_attr">
<section anchor="gsa_attr" title="GSA Attributes"> <name>Group SA Attributes</name>
<t>GSA attributes are generally used to provide GMs with additional <t>Group SA attributes are generally used to provide GMs with additi
parameters onal parameters
for the GSA policy. Unlike security parameters distributed via trans for the group SA policy. Unlike security parameters distributed via
forms, transforms,
which are expected not to change over time (unless policy changes), which are expected not to change over time (unless the policy change
the parameters distributed via GSA attributes s),
the parameters distributed via group SA attributes
may depend on the time the provision takes place, on the may depend on the time the provision takes place, on the
existence of others group SAs or on other conditions. existence of other group SAs, or on other conditions.
</t> </t>
<t>This document creates a new IKEv2 IANA registry for the types <t>This document creates a new IKEv2 IANA registry for the types
of the GSA attributes which is initially filled as described in <xre of group SA attributes, which has been initially populated as descri
f target="IANA" />. bed in <xref target="IANA"/>.
In particular, the following attributes are initially added. In particular, the following attributes have been added:
<figure>
<artwork align="center"><![CDATA[
GSA Attributes Value Format Multi-Valued Used in Protocol
Reserved 0
GSA_KEY_LIFETIME 1 TLV NO GIKE_UPDATE, AH, ESP
GSA_INITIAL_MESSAGE_ID 2 TLV NO GIKE_UPDATE
GSA_NEXT_SPI 3 TLV YES GIKE_UPDATE, AH, ESP
]]></artwork>
</figure>
The attributes follow the format defined in the IKEv2 <xref
target="RFC7296"></xref> section 3.3.5. The "Format" column
defines what attribute format is allowed: Type/Length/Value (TLV) or
Type/Value (TV).
The "Multi-Valued" column defines whether multiple instances of the
attribute can appear.
The "Used in Protocol" column lists the security protocols, for whic
h the attribute can be used.
</t> </t>
<section anchor="gsa_attr_key_lifetime" title="GSA_KEY_LIFETIME Attr <table>
ibute"> <name>Group SA Attributes</name>
<thead>
<tr>
<th>Value</th>
<th>Group SA Attributes</th>
<th>Format</th>
<th>Multi-Valued</th>
<th>Used in Protocol</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td colspan="3"></td>
</tr>
<tr>
<td>1</td>
<td>GSA_KEY_LIFETIME</td>
<td>TLV</td>
<td>NO</td>
<td>GIKE_UPDATE, AH, ESP</td>
</tr>
<tr>
<td>2</td>
<td>GSA_INITIAL_MESSAGE_ID</td>
<td>TLV</td>
<td>NO</td>
<td>GIKE_UPDATE</td>
</tr>
<tr>
<td>3</td>
<td>GSA_NEXT_SPI</td>
<td>TLV</td>
<td>YES</td>
<td>GIKE_UPDATE, AH, ESP</td>
</tr>
</tbody>
</table>
<t>
The attributes follow the format defined in IKEv2 (<xref
target="RFC7296" sectionFormat="of" section="3.3.5"/>). The
"Format" column defines what attribute format is allowed:
Type/Length/Value (TLV) or Type/Value (TV). The "Multi-Valued"
column defines whether multiple instances of the attribute can
appear. The "Used in Protocol" column lists the security
protocols, for which the attribute can be used.
</t>
<section anchor="gsa_attr_key_lifetime">
<name>GSA_KEY_LIFETIME Attribute</name>
<t>The GSA_KEY_LIFETIME attribute (1) specifies the maximum time f or <t>The GSA_KEY_LIFETIME attribute (1) specifies the maximum time f or
which the SA is valid. The value is a 4 octet unsigned integer in which the SA is valid. The value is a 4-octet unsigned integer in
a network byte order, specifying a valid time period in seconds. network byte order, specifying a valid time period in seconds.
When the lifetime expires, the group security association and all When the lifetime expires, the GSA and all associated keys <bcp14>
associated keys <bcp14>MUST</bcp14> be deleted. MUST</bcp14> be deleted.
The GCKS may delete the SA at any time before the end of the valid ity period. The GCKS may delete the SA at any time before the end of the valid ity period.
</t> </t>
<t>A single attribute of this type <bcp14>MUST</bcp14> be included
<t>A single attribute of this type <bcp14>MUST</bcp14> be included into any group SA policy substructure
into any GSA policy substructure
if multicast rekey is employed by the GCKS. This attribute <bcp14> SHOULD NOT</bcp14> be used if inband rekey if multicast rekey is employed by the GCKS. This attribute <bcp14> SHOULD NOT</bcp14> be used if inband rekey
(via the GSA_INBAND_REKEY exchange) is employed by the GCKS for th e GM. (via the GSA_INBAND_REKEY exchange) is employed by the GCKS for th e GM.
</t> </t>
</section> </section>
<section anchor="gsa_attr_initial_message_id">
<section anchor="gsa_attr_initial_message_id" title="GSA_INITIAL_MES <name>GSA_INITIAL_MESSAGE_ID Attribute</name>
SAGE_ID Attribute">
<t>The GSA_INITIAL_MESSAGE_ID attribute (2) defines the initial Me ssage ID <t>The GSA_INITIAL_MESSAGE_ID attribute (2) defines the initial Me ssage ID
to be used by the GCKS in the GSA_REKEY messages. The Message ID to be used by the GCKS in the GSA_REKEY messages. The Message ID
is a 4 octet unsigned integer in network byte order. is a 4-octet unsigned integer in network byte order.
</t> </t>
<t>A single attribute of this type is included into <t>A single attribute of this type is included into
the GSA KEK policy substructure if the initial Message ID of the R ekey SA is non-zero. the GSA KEK policy substructure if the initial Message ID of the R ekey SA is non-zero.
Note, that it is always the case if GMs join the group after some Note that it is always true if a GM joins the group after some
multicast rekey operations multicast rekey operations have already taken place in this group.
have already taken place, so in these cases this attribute will be In this case, this attribute will be included into the group SA policy when th
included into e
the GSA policy when the GM is registered. GM is registered.</t>
</t>
<t>This attribute <bcp14>MUST NOT</bcp14> be used if inband rekey (via the GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM. <t>This attribute <bcp14>MUST NOT</bcp14> be used if inband rekey (via the GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM.
</t> </t>
</section> </section>
<section anchor="gsa_attr_next_spi">
<section anchor="gsa_attr_next_spi" title="GSA_NEXT_SPI Attribute"> <name>GSA_NEXT_SPI Attribute</name>
<t>The optional GSA_NEXT_SPI attribute (3) contains SPI that the G <t>The optional GSA_NEXT_SPI attribute (3) contains the SPI that t
CKS reserved he GCKS reserved
for the next Rekey SA or Data-Security SAs replacing the current o nes. The length of the attribute data for the next Rekey SA or Data-Security SAs replacing the current o nes. The length of the attribute data
is determined by the SPI Size field in the GSA Policy substructure is determined by the SPI Size field in the group SA policy substru
the attribute cture the attribute
resides in (see <xref target="gsa_policy" />), and the attribute d resides in (see <xref target="gsa_policy"/>), and the attribute da
ata contains ta contains the
SPI as it would appear on the network. Multiple attributes of this type <bcp14>MAY</bcp14> be included, SPI as it would appear on the network. Multiple attributes of this type <bcp14>MAY</bcp14> be included,
meaning that any of the supplied SPIs can be used in the replaceme nt group SA. meaning that any of the supplied SPIs can be used in the replaceme nt group SA.
</t> </t>
<t>The GM <bcp14>MAY</bcp14> store these values. Later on, if the
<t>The GM <bcp14>MAY</bcp14> store these values and if later the G GM starts receiving
M starts receiving messages with one of these SPIs without seeing a rekey message ove
messages with one of these SPIs without seeing a rekey message ove r the current Rekey SA, then
r the current Rekey SA, it may be used as an indication that the rekey message got lost on
this may be used as an indication, that the rekey message got lost its way to this GM.
on its way to this GM. In this case, the GM <bcp14>SHOULD</bcp14> re-register to the grou
In this case the GM <bcp14>SHOULD</bcp14> re-register to the group p.
.
</t> </t>
<t>Note that this method of detecting lost rekey messages can only
<t>Note, that this method of detecting lost rekey messages can onl be used
y be used by group receivers. Additionally, there is no point to include thi
by group receivers. Additionally there is no point to include this s attribute in the GSA_INBAND_REKEY messages
attribute in the GSA_INBAND_REKEY messages, since they use reliable transport. Also note that the GCKS is free
since they use reliable transport. Note also, that the GCKS is fre
e
to forget its promises and not to use the SPIs it sent in the GSA_ NEXT_SPI to forget its promises and not to use the SPIs it sent in the GSA_ NEXT_SPI
attributes before (e.g. in case of the GCKS is rebooted), so the G attributes before (e.g., in cases where the GCKS is rebooted), so
M must only treat the GM must only treat
these information as a "best effort" made by the GCKS to prepare f this information as a "best effort" made by the GCKS to prepare fo
or future rekeys. r future rekeys.
</t> </t>
<t>This attribute <bcp14>MUST NOT</bcp14> be used if inband rekey (via the GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM. <t>This attribute <bcp14>MUST NOT</bcp14> be used if inband rekey (via the GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="gw_policy">
<section title="Group-wide Policy Substructure" anchor="gw_policy"> <name>Group-Wide Policy Substructure</name>
<t>Group specific policy that does not belong to any SA policy can be <t>Group-specific policy that does not belong to any SA policy can be
distributed to distributed to
all group member using Group-wide (GW) policy substructure.</t> all GMs using the GW policy substructure.</t>
<t>The GW policy substructure is defined as follows:</t> <t>The GW policy substructure is defined as follows:</t>
<figure title="GW Policy Substructure Format" anchor="gwp_format"> <figure anchor="gwp_format">
<preamble></preamble> <name>GW Policy Substructure Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
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 | RESERVED | Length | | Protocol | RESERVED | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ <GW Policy Attributes> ~ ~ <GW Policy Attributes> ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
<postamble></postamble>
</figure> </figure>
<t>The GW policy substructure fields are defined as follows:</t> <t>The GW policy substructure fields are defined as follows:</t>
<dl spacing="normal" newline="true">
<dt>Protocol (1 octet):</dt><dd><bcp14>MUST</bcp14> be zero. This
value is reserved (see <xref target="IANA"/>) and is never used for
any security protocol, so it is used here to indicate that this
substructure contains policy not related to any specific
protocol.</dd>
<dt>RESERVED (1 octet):</dt><dd><bcp14>MUST</bcp14> be zero on
transmission and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt>Length (2 octets, unsigned integer):</dt><dd>Length of this
substructure including the header.</dd>
<dt>GW Policy Attributes (variable):</dt><dd>Contains policy
attributes associated with no specific SA. The following sections
describe possible attributes. Any or all attributes may be
optional depending on the group policy.</dd>
</dl>
<t><list style="symbols"> <section anchor="gwp_attr">
<t>Protocol (1 octet) -- <bcp14>MUST</bcp14> be zero. This value is <name>GW Policy Attributes</name>
reserved in <xref target="IANA" /> and is never <t>This document creates a new IKEv2 IANA registry for the types
used for any security protocol, so it is used here to indicate that of group-wide policy attributes, which has been initially populate
this substructure contains policy d as described in <xref target="IANA"/>.
not related to any specific protocol. In particular, the following attributes have been added:
</t>
<t>RESERVED ( octet) -- <bcp14>MUST</bcp14> be zero on transmission,
<bcp14>MUST</bcp14> be ignored on receipt.
</t> </t>
<t>Length (2 octets, unsigned integer) -- Length of this substructur <table>
e including the header. <name>GW Policy Attributes</name>
<thead>
<tr>
<th>Value</th>
<th>GW Policy Attributes</th>
<th>Format</th>
<th>Multi-Valued</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td colspan="2"></td>
</tr>
<tr>
<td>1</td>
<td>GWP_ATD</td>
<td>TV</td>
<td>NO</td>
</tr>
<tr>
<td>2</td>
<td>GWP_DTD</td>
<td>TV</td>
<td>NO</td>
</tr>
<tr>
<td>3</td>
<td>GWP_SENDER_ID_BITS</td>
<td>TV</td>
<td>NO</td>
</tr>
</tbody>
</table>
<t>The attributes follow the format defined in the IKEv2 (<xref
target="RFC7296" sectionFormat="of" section="3.3.5"/>). The
"Format" column defines what attribute format is allowed:
Type/Length/Value (TLV) or Type/Value (TV). The "Multi-Valued"
column defines whether multiple instances of the attribute can
appear.
</t> </t>
<section anchor="gwp_attr_atd_dtd">
<t>GW Policy Attributes (variable) -- Contains policy attributes ass <name>GWP_ATD and GWP_DTD Attributes</name>
ociated <t><xref target="RFC5374" sectionFormat="of"
with no specific SA. The following sections describe possible section="4.2.1"/> specifies a key rollover method that
attributes. Any or all attributes may be optional, depending on requires two values be provided to GMs: Activation
the group policy.</t> Time Delay (ATD) and Deactivation Time Delay (DTD).
</list></t>
<section anchor="gwp_attr" title="GW Policy Attributes">
<t>This document creates a new IKEv2 IANA registry for the types
of the group-wide policy attributes which is initially filled as d
escribed in <xref target="IANA" />.
In particular, the following attributes are initially added.
<figure>
<artwork align="center"><![CDATA[
GW Policy Attributes Value Format Multi-Valued
Reserved 0
GWP_ATD 1 TV NO
GWP_DTD 2 TV NO
GWP_SENDER_ID_BITS 3 TV NO
]]></artwork>
</figure>
</t>
<t>The attributes follow the format defined in the IKEv2 <xref
target="RFC7296"></xref> section 3.3.5. The "Format" column
defines what attribute format is allowed: Type/Length/Value (TLV)
or Type/Value (TV).
The "Multi-Valued" column defines whether multiple instances of th
e attribute can appear.
</t> </t>
<t>The GWP_ATD attribute (1) allows a GCKS to set the
<section anchor="gwp_attr_atd_dtd" title="GWP_ATD And GWP_DTD Attr
ibutes">
<t>Section 4.2.1 of Multicast Extensions to the Security Archite
cture <xref target="RFC5374" /> specifies a key rollover method that
requires two values be provided to group members -- Activation T
ime Delay (ATD) and
Deactivation Time Delay (DTD).
</t>
<t>The GWP_ATD attribute (1) allows a GCKS to set the
Activation Time Delay for Data-Security SAs of the group. The AT D Activation Time Delay for Data-Security SAs of the group. The AT D
defines how long active members of the group (those who sends tr affic) defines how long active members of the group (those who sends tr affic)
should wait after receiving new SAs before staring sending traff should wait after receiving new SAs before sending traffic over
ic over them. them.
Note, that to achieve smooth rollover passive members of the gro Note that to achieve smooth rollover, passive members of the gro
up should up should
activate the SAs immediately once they receive them. activate the SAs immediately once they receive them.
</t> </t>
<t>The GWP_DTD attribute (2) allows the GCKS to set the
<t>The GWP_DTD attribute (2) allows the GCKS to set the DTD for previously distributed SAs. The
Deactivation Time Delay for previously distributed SAs. The
DTD defines how long after receiving a request to delete Data-Se curity SAs DTD defines how long after receiving a request to delete Data-Se curity SAs
passive group members should wait before actually deleting them. passive GMs should wait before actually deleting them.
Note that active members of the group should stop sending traffi c over these old SAs Note that active members of the group should stop sending traffi c over these old SAs
once new replacement SAs are activated (after time specified in the GWP_ATD attribute). once new replacement SAs are activated (after time specified in the GWP_ATD attribute).
</t> </t>
<t>The GWP_ATD and GWP_DTD attributes contain a 16-bit unsigned in
<t>The GWP_ATD and GWP_DTD attributes contain 16 bit unsigned in teger in
teger in a network byte order, specifying the delay in seconds. These attri
network byte order, specifying the delay in seconds. These attri butes are <bcp14>OPTIONAL</bcp14>.
butes are OPTIONAL.
If one of them or both are not sent by the GCKS, then no corresp onding delay If one of them or both are not sent by the GCKS, then no corresp onding delay
should be employed. should be employed.
</t> </t>
</section> </section>
<section anchor="gwp_attr_sid_bits">
<section anchor="gwp_attr_sid_bits" title="GWP_SENDER_ID_BITS Attr <name>GWP_SENDER_ID_BITS Attribute</name>
ibute"> <t>The GWP_SENDER_ID_BITS attribute (3) declares how many bits
<t>The GWP_SENDER_ID_BITS attribute (3) declares how many bits o of the cipher nonce are taken to represent a Sender-ID
f the value. The bits are applied as the most significant bits of the
cipher nonce are taken to represent a Sender-ID value. The bits IV, as shown in Figure 1 of Using Counter Modes with ESP and AH
are to Protect Group Traffic <xref target="RFC6054"/> and as specified
applied as the most significant bits of the IV, as shown in Figu in <xref target="sid-usage"/>. Guidance for a GCKS choosing the
re 1 of value is provided in <xref target="RFC6054"
Using Counter Modes with ESP and AH to Protect Group Traffic <xr sectionFormat="of" section="3"/>. This value is
ef target="RFC6054"></xref> and specified in applied to each Sender-ID value distributed in the KD
<xref target="sid-usage"></xref>. Guidance for a GCKS choosing t payload.</t>
he <t>The GCKS <bcp14>MUST</bcp14> include this attribute if there ar
value is provided in Section 3 of Using Counter Modes with ESP a e more than one senders
nd AH to Protect Group Traffic
<xref target="RFC6054"></xref>. This value is applied to each Se
nder-ID value
distributed in the KD payload.</t>
<t>The GCKS <bcp14>MUST</bcp14> include this attribute if there
are more than one sender
in the group and any of the Data-Security SAs use counter-based in the group and any of the Data-Security SAs use counter-based
cipher mode. The number of Sender-ID bits is represented as 16 b it unsigned integer in cipher mode. The number of Sender-ID bits is represented as a 16 -bit unsigned integer in
network byte order. network byte order.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
</section> </section>
<section anchor="kd_payload">
<section title="Key Download Payload" anchor="kd_payload"> <name>Key Download Payload</name>
<t>The Key Download (KD) payload contains the group keys for the SAs <t>The Key Download (KD) payload contains the group keys for the SAs
specified in the GSA Payload. specified in the GSA payload.
The Payload Type for the Key Download payload is fifty-two (52). The Payload Type for the Key Download payload is fifty-two (52).
</t> </t>
<figure title="Key Download Payload Format" anchor="kd_payload_format"> <figure anchor="kd_payload_format">
<preamble></preamble> <name>Key Download Payload Format</name>
<artwork><![CDATA[ <artwork><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Length | | Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ <Key Bags> ~ ~ <Key Bags> ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
<postamble></postamble>
</figure> </figure>
<t>The Key Download payload fields are defined as follows:</t> <t>The Key Download payload fields are defined as follows:</t>
<dl spacing="normal" newline="true">
<t><list style="symbols"> <dt>Next Payload, C, RESERVED, and Payload Length fields:</dt><dd>
<t>Next Payload, C, RESERVED, Payload Length fields comprise the IKEv2 Comprise the IKEv2 generic payload header and are defined in <xref
Generic Payload Header and target="RFC7296" sectionFormat="of" section="3.2"/>.</dd>
are defined in Section 3.2. of <xref target="RFC7296"></xref>.</t> <dt>Key Bags (variable):</dt><dd>A set of key bag substructures.</dd>
</dl>
<t>Key Bags (variable) -- A set of Key Bag substructures.
</t>
</list>
</t>
<section anchor="key_bag" title="Key Bags"> <section anchor="key_bag">
<t> Keys are distributed in a substructures called key bags. Each key <name>Key Bags</name>
bag contains one or more keys <t> Keys are distributed in substructures called key bags. Each key ba
that are logically related -- either these are keys for a single SA (D g contains one or more keys
ata-Security SA or Rekey SA) that are logically related -- these are keys for either a single SA (D
or these are keys for a single group member (in the latter case beside ata-Security SA or Rekey SA)
s keys the key bag may also or a single GM (in the latter case, besides keys, the key bag may also
contain security parameters for this group member). contain security parameters for this GM).
</t> </t>
<t>
<t> For this reason two types of key bags are defined -- Group Key Bag For this reason, two types of key bags are defined: Group Key Bag and
and Member Key Bag. The type is unambiguously Member Key Bag. The type is unambiguously determined by the first byte of
determined by the first byte of the key bag substructure -- for member the key bag substructure; for a Member Key Bag, it is zero and for a Group
key bag it is zero and for group Key Bag, it contains a Security Protocol Identifier, which is always non-zero
key bag it represents the protocol number, which along with the follow .
ing SPI, identify the SA associated with the keys in the bag. For a Group Key Bag, the Protocol along with the SPI (see <xref target="group
_key_bag_format"/>)
identify the SA that is associated with the keys in this bag.
</t> </t>
</section> </section>
<section anchor="group_key_bag">
<section anchor="group_key_bag" title="Group Key Bag Substructure"> <name>Group Key Bag Substructure</name>
<t>The Group Key Bag substructure contains SA key information. This ke y information is associated <t>The Group Key Bag substructure contains SA key information. This ke y information is associated
with some group SAs: either with Data-Security SAs or with group Rekey SA. with some group SAs: either with Data-Security SAs or with a group Rek ey SA.
</t> </t>
<figure title="Group Key Bag Substructure Format" anchor="group_key_ba <figure anchor="group_key_bag_format">
g_format"> <name>Group Key Bag Substructure Format</name>
<preamble></preamble> <artwork ><![CDATA[
<artwork align="center"><![CDATA[
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 ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ <Group Key Bag Attributes> ~ ~ <Group Key Bag Attributes> ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
<postamble></postamble>
</figure> </figure>
<t><list style="symbols"> <dl spacing="normal" newline="true">
<t>Protocol (1 octet) -- Identifies the security protocol for this k <dt>Protocol (1 octet):</dt><dd>Identifies the security protocol
ey bag. for this key bag. The values are defined in the "IKEv2 Security
The values are defined in the IKEv2 Security Protocol Identifiers in Protocol Identifiers" registry in <xref target="IKEV2-IANA"/>. The v
<xref target="IKEV2-IANA" />. The valid values for this field are: alid
&lt;TBA&gt; (GIKE_UPDATE) for KEK Key packet and 2 (AH) or 3 (ESP) f values for this field are: 6 (GIKE_UPDATE) for KEK Key
or TEK key bag. packet and 2 (AH) or 3 (ESP) for TEK key bag.</dd>
</t> <dt>SPI Size (1 octet):</dt><dd>Size of the
SPI for the corresponding SA. SPI size depends on the security
<t>SPI Size (1 octet) -- Size of Security Parameter Index (SPI) for protocol. It is 16 octets for GIKE_UPDATE and 4 octets for AH and ES
the corresponding SA. P.</dd>
SPI size depends on the security protocol. For GIKE_UPDATE it is 16 <dt>Length (2 octets, unsigned integer):</dt><dd>Length of this subs
octets, while for AH and ESP it is 4 octets. tructure including the header.</dd>
</t> <dt>SPI (variable):</dt><dd>Security Parameter Index for the corresp
onding SA.
<t>Length (2 octets, unsigned integer) -- Length of this substructur
e including the header.
</t>
<t>SPI (variable) -- Security Parameter Index for the corresponding
SA.
The size of this field is determined by the SPI Size field. The size of this field is determined by the SPI Size field.
In case of GIKE_UPDATE the SPI is the IKEv2 Header SPI pair where th e In the case of GIKE_UPDATE, the SPI is the IKEv2 header SPI pair whe re the
first 8 octets become the "IKE SA Initiator's SPI" field in the first 8 octets become the "IKE SA Initiator's SPI" field in the
G-IKEv2 rekey message IKEv2 HDR, and the second 8 octets become G-IKEv2 rekey message IKEv2 HDR, and the second 8 octets become
the "IKE SA Responder's SPI" in the same HDR. the "IKE SA Responder's SPI" in the same HDR. </dd>
</t> <dt>Group Key Bag Attributes (variable):</dt><dd>Contains key
information for the corresponding SA.</dd>
<t>Group Key Bag Attributes (variable) -- Contains Key </dl>
information for the corresponding SA.
</t>
</list>
</t>
<t>This document creates a new IKEv2 IANA registry for the types <t>This document creates a new IKEv2 IANA registry for the types
of the Group Key Bag attributes which is initially filled as described of Group Key Bag attributes, which has been initially populated as des
in <xref target="IANA" />. cribed in <xref target="IANA"/>.
In particular, the following attributes are initially added. In particular, the following attributes have been added:
<figure>
<artwork align="center"><![CDATA[
Group Key Bag
Attributes Value Format Multi-Valued Used in Protocol
Reserved 0
SA_KEY 1 TLV YES* GIKE_UPDATE
NO AH, ESP
]]></artwork>
</figure>
(*) Multiple SA_KEY attributes may only appear for the GIKE_UPDATE pro
tocol
in the GSA_REKEY exchange if the GCKS uses the group key management
method that allows excluding GMs from the group (like LKH).
</t> </t>
<t>The attributes follow the format defined in the IKEv2 <xref <table>
target="RFC7296"></xref> section 3.3.5. The "Format" column <name>Group Key Bag Attributes</name>
defines what attribute format is allowed: Type/Length/Value (TLV) or T <thead>
ype/Value (TV). <tr>
The "Multi-Valued" column defines whether multiple instances of the at <th>Value</th>
tribute can appear. <th>Group Key Bag Attributes</th>
The "Used in Protocol" column lists the security protocols, for which <th>Format</th>
the attribute can be used. <th>Multi-Valued</th>
</t> <th>Used in Protocol</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td colspan="3"></td>
</tr>
<tr>
<td>1</td>
<td>SA_KEY</td>
<td>TLV</td>
<td>YES*<br/>NO</td>
<td>GIKE_UPDATE<br/>AH, ESP</td>
</tr>
</tbody>
</table>
<section anchor="gkd_attr_group_key" title="SA_KEY Attribute"> <t>Notes:</t>
<dl spacing="normal" newline="false">
<dt>(*):</dt><dd>Multiple SA_KEY attributes may only appear for the GIK
E_UPDATE protocol
in the GSA_REKEY pseudo-exchange if the GCKS uses the group key manage
ment
method that allows excluding GMs from the group (like LKH).</dd>
</dl>
<t>The attributes follow the format defined in IKEv2 (<xref
target="RFC7296" sectionFormat="of" section="3.3.5"/>). The
"Format" column defines what attribute format is allowed:
Type/Length/Value (TLV) or Type/Value (TV). The "Multi-Valued"
column defines whether multiple instances of the attribute can
appear. The "Used in Protocol" column lists the security protocols,
for which the attribute can be used.
</t>
<section anchor="gkd_attr_group_key">
<name>SA_KEY Attribute</name>
<t>The SA_KEY attribute (1) contains a keying material for the corre sponding SA. <t>The SA_KEY attribute (1) contains a keying material for the corre sponding SA.
The content of the attribute is formatted according to The content of the attribute is formatted according to
<xref target="wrapped_key" /> with a precondition that the Key ID fi eld <bcp14>MUST</bcp14> always be zero. <xref target="wrapped_key"/> with a precondition that the Key ID fie ld <bcp14>MUST</bcp14> always be zero.
The size of the keying material <bcp14>MUST</bcp14> be equal to the total size of the keys needed to be taken The size of the keying material <bcp14>MUST</bcp14> be equal to the total size of the keys needed to be taken
from this keying material (see <xref target="group_sa_keys" />) for the corresponding SA. from this keying material (see <xref target="group_sa_keys"/>) for t he corresponding SA.
</t> </t>
<t>If the key bag is for a Data-Security SA (AH or ESP protocols), <t>If the key bag is for a Data-Security SA (AH or ESP protocols),
then exactly one SA_KEY attribute <bcp14>MUST</bcp14> be present wit h both then exactly one SA_KEY attribute <bcp14>MUST</bcp14> be present wit h both
Key ID and KWK ID fields set to zero. Key ID and KWK ID fields set to zero.
</t> </t>
<t>If the key bag is for a Rekey SA (GIKE_UPDATE protocol), <t>If the key bag is for a Rekey SA (GIKE_UPDATE protocol),
then in the GSA_AUTH, GSA_REGISTRATION and GSA_INBAND_REKEY exchange then exactly one SA_KEY attribute <bcp14>MUST</bcp14> be present in the GSA_AUTH
s , GSA_REGISTRATION, and GSA_INBAND_REKEY exchanges.
exactly one SA_KEY attribute <bcp14>MUST</bcp14> be present. In the GSA_REKEY pseudo-exchange, at least one SA_KEY attribute <bcp
In the GSA_REKEY exchange at least one SA_KEY attribute <bcp14>MUST< 14>MUST</bcp14> be present,
/bcp14> be present,
and more attributes <bcp14>MAY</bcp14> be present (depending on the key management method employed by the GCKS). and more attributes <bcp14>MAY</bcp14> be present (depending on the key management method employed by the GCKS).
</t> </t>
</section> </section>
</section> </section>
<section anchor="member_key_bag">
<section anchor="member_key_bag" title="Member Key Bag Substructure" > <name>Member Key Bag Substructure</name>
<t>The Member Key Bag substructure contains keys and other <t>The Member Key Bag substructure contains keys and other
parameters that are specific for a member of the group and are not parameters that are specific for a member of the group and are not
associated with any particular group SA. associated with any particular group SA.
</t> </t>
<figure title="Member Key Bag Substructure Format" anchor="mkd_key_bag <figure anchor="mkd_key_bag">
"> <name>Member Key Bag Substructure Format</name>
<preamble></preamble>
<artwork><![CDATA[ <artwork><![CDATA[
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 | RESERVED | Length | | Protocol | RESERVED | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ <Member Key Bag Attributes> ~ ~ <Member Key Bag Attributes> ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
<postamble></postamble>
</figure> </figure>
<t>The Member Key Bag substructure fields are defined as follows:</t> <t>The Member Key Bag substructure fields are defined as follows:</t>
<dl spacing="normal" newline="true">
<dt>Protocol (1 octet):</dt><dd><bcp14>MUST</bcp14> be zero. This
value is reserved (see <xref target="IANA"/>) and is never used for
any security protocol, so it is used here to indicate that this
key bag is not associated with any particular SA.</dd>
<dt>RESERVED ( octet):</dt><dd><bcp14>MUST</bcp14> be zero on
transmission and <bcp14>MUST</bcp14> be ignored on receipt.</dd>
<dt>Length (2 octets, unsigned integer):</dt><dd>Length of this
substructure including the header.</dd>
<dt>Member Key Bag Attributes (variable):</dt><dd>Contains key
information and other parameters exclusively for a particular
member of the group.</dd>
</dl>
<t><list style="symbols"> <t>
<t>Protocol (1 octet) -- <bcp14>MUST</bcp14> be zero. This value is The Member Key Bag substructure contains sensitive information for a s
reserved in <xref target="IANA" /> and is never ingle GM. For this reason,
used for any security protocol, so it is used here to indicate that
this key bag is not associated
with any particular SA.
</t>
<t>RESERVED ( octet) -- <bcp14>MUST</bcp14> be zero on transmission
, <bcp14>MUST</bcp14> be ignored on receipt.
</t>
<t>Length (2 octets, unsigned integer) -- Length of this substructur
e including the header.
</t>
<t>Member Key Bag Attributes (variable) -- Contains Key
information and other parameters exclusively for a particular member
of the group.
</t>
</list>
The member Key Bag substructure contains sensitive information for a s
ingle GM, for this reason
it <bcp14>MUST NOT</bcp14> be sent in GSA_REKEY messages and <bcp14>MU ST</bcp14> only be sent via unicast it <bcp14>MUST NOT</bcp14> be sent in GSA_REKEY messages and <bcp14>MU ST</bcp14> only be sent via unicast
SA at the time the GM registers to the group (in either GSA_AUTH or GS A_REGISTRATION exchanges). SA at the time the GM registers to the group (in either GSA_AUTH or GS A_REGISTRATION exchanges).
</t> </t>
<t>This document creates a new IKEv2 IANA registry for the types <t>This document creates a new IKEv2 IANA registry for the types
of the Member Key Bag attributes which is initially filled as describe of Member Key Bag attributes, which has been initially populated as de
d in <xref target="IANA" />. scribed in <xref target="IANA"/>.
In particular, the following attributes are initially added. In particular, the following attributes have been added:
<figure>
<artwork align="center"><![CDATA[
Member Key Bag
Attributes Value Format Multi-Valued
Reserved 0
WRAP_KEY 1 TLV YES
AUTH_KEY 2 TLV NO
GM_SENDER_ID 3 TLV YES
]]></artwork>
</figure>
</t> </t>
<t>The attributes follow the format defined in the IKEv2 <xref <table>
target="RFC7296"></xref> section 3.3.5. The "Format" column <name>Member Key Bag Attributes</name>
defines what attribute format is allowed: Type/Length/Value (TLV) or T <thead>
ype/Value (TV). <tr>
The "Multi-Valued" column defines whether multiple instances of the at <th>Value</th>
tribute can appear. <th>Member Key Bag Attributes</th>
</t> <th>Format</th>
<th>Multi-Valued</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td colspan="3">Reserved</td>
</tr>
<tr>
<td>1</td>
<td>WRAP_KEY</td>
<td>TLV</td>
<td>YES</td>
</tr>
<tr>
<td>2</td>
<td>AUTH_KEY</td>
<td>TLV</td>
<td>NO</td>
</tr>
<tr>
<td>3</td>
<td>GM_SENDER_ID</td>
<td>TLV</td>
<td>YES</td>
</tr>
</tbody>
</table>
<section anchor="mkd_attr_kwk" title="WRAP_KEY Attribute"> <t>The attributes follow the format defined in the IKEv2 (<xref
target="RFC7296" sectionFormat="of" section="3.3.5"/>). The
"Format" column defines what attribute format is allowed:
Type/Length/Value (TLV) or Type/Value (TV). The "Multi-Valued"
column defines whether multiple instances of the attribute can
appear.
</t>
<section anchor="mkd_attr_kwk">
<name>WRAP_KEY Attribute</name>
<t>The WRAP_KEY attribute (1) contains a key that is used <t>The WRAP_KEY attribute (1) contains a key that is used
to encrypt other keys. One or more these to encrypt other keys. One or more of these
attributes are sent to GMs if the GCKS key management method attributes are sent to GMs if the GCKS key management method
relies on some key hierarchy (e.g. LKH). relies on some key hierarchy (e.g., LKH).
This attribute <bcp14>MUST NOT</bcp14> be used if inband rekey (via the GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM. This attribute <bcp14>MUST NOT</bcp14> be used if inband rekey (via the GSA_INBAND_REKEY exchange) is employed by the GCKS for the GM.
</t> </t>
<t>The content of the attribute has a format defined in <xref target
<t>The content of the attribute has a format defined in <xref target ="wrapped_key"/>
="wrapped_key" />
with a precondition that the Key ID field <bcp14>MUST NOT</bcp14> be zero. with a precondition that the Key ID field <bcp14>MUST NOT</bcp14> be zero.
The algorithm associated with the key is defined by the Key Wrap Alg orithm transform The algorithm associated with the key is defined by the Key Wrap Alg orithm transform
for the SA the WRAP_KEY attributes was sent in. for the SA the WRAP_KEY attributes was sent in.
The size of the attribute data <bcp14>MUST</bcp14> be equal to the k ey size for this key wrap algorithm. The size of the attribute data <bcp14>MUST</bcp14> be equal to the k ey size for this key wrap algorithm.
</t> </t>
<t>Multiple instances of the WRAP_KEY attributes <bcp14>MAY</bcp14> be present in the key bag. <t>Multiple instances of the WRAP_KEY attributes <bcp14>MAY</bcp14> be present in the key bag.
</t> </t>
</section> </section>
<section anchor="mkd_attr_auth_key">
<section anchor="mkd_attr_auth_key" title="AUTH_KEY Attribute"> <name>AUTH_KEY Attribute</name>
<t>The AUTH_KEY attribute (2) contains the key that is used to authe nticate <t>The AUTH_KEY attribute (2) contains the key that is used to authe nticate
the GSA_REKEY messages. The content of the attribute depends on the authentication the GSA_REKEY messages. The content of the attribute depends on the authentication
method the GCKS specified in the Group Controller Authentication Met hod transform in the GSA payload. method the GCKS specified in the Group Controller Authentication Met hod transform in the GSA payload.
<list style="symbols"> </t>
<t>If digital signatures are used for the GSA_REKEY message authen <ul spacing="normal">
tication <li>
then the content of the AUTH_KEY attribute is a public key used <t>If digital signatures are used for the GSA_REKEY message
for digital signature authentication. The public key <bcp14>MUST</ authentication, then the content of the AUTH_KEY attribute is a
bcp14> be represented public key used for digital signature authentication. The
as DER-encoded ASN.1 object SubjectPublicKeyInfo, defined in Secti public key <bcp14>MUST</bcp14> be represented as DER-encoded
on ASN.1 object SubjectPublicKeyInfo, defined in <xref
4.1.2.7 of Internet X.509 Public Key Infrastructure Certificate an target="RFC5280" sectionFormat="of" section="4.1.2.7"/>. The alg
d CRL Profile <xref target="RFC5280" />. orithm field inside the
The algorithm field inside the SubjectPublicKeyInfo object <bcp14> SubjectPublicKeyInfo object <bcp14>MUST</bcp14> match the
MUST</bcp14> match the content of the Signature Algorithm Identifier attribute in the
content of the Signature Algorithm Identifier attribute in the Gro Group Controller Authentication Method transform. When the
up Controller Authentication Method transform. id-RSASSA-PSS object identifier appears in the algorithm field
When the id-RSASSA-PSS object identifier appears in the algorithm of the SubjectPublicKeyInfo object, then the parameters field
field of the SubjectPublicKeyInfo object, <bcp14>MUST</bcp14> include the RSASSA-PSS-params structure.
then the parameters field <bcp14>MUST</bcp14> include the RSASSA-P </t>
SS-params structure. </li>
</t> <li><t>In case of implicit authentication, the AUTH_KEY Attribute
</list> is not used and <bcp14>MUST</bcp14> be absent (see <xref target="gs
a_rekey"/>).</t></li>
</ul>
<t>
Multiple instances of the AUTH_KEY attributes <bcp14>MUST NOT</bcp14 > be sent. Multiple instances of the AUTH_KEY attributes <bcp14>MUST NOT</bcp14 > be sent.
</t> </t>
</section> </section>
<section anchor="mkd_attr_gm_sid">
<section anchor="mkd_attr_gm_sid" title="GM_SENDER_ID Attribute"> <name>GM_SENDER_ID Attribute</name>
<t>The GM_SENDER_ID attribute (3) is used to download one or more Se nder-ID <t>The GM_SENDER_ID attribute (3) is used to download one or more Se nder-ID
values for the exclusive use of a group member. One or more of this attributes <bcp14>MUST</bcp14> be values for the exclusive use of a GM. One or more of these attribut es <bcp14>MUST</bcp14> be
sent by the GCKS if the GM informed the GCKS that it would be a send er (by including sent by the GCKS if the GM informed the GCKS that it would be a send er (by including
the GROUP_SENDER notification to the request) and at least one of th the GROUP_SENDER notification to the request) and if at least one of
e Data-Security SAs the Data-Security SAs
included in the GSA payload uses counter-based mode of encryption. included in the GSA payload uses a counter-based mode of encryption.
</t> </t>
<t>If the GMs have requested multiple Sender-ID values in the GROUP_
<t>If the GMs has requested multiple Sender-ID values in the GROUP_S SENDER notification, then the GCKS <bcp14>SHOULD</bcp14>
ENDER notification, then the GCKS <bcp14>SHOULD</bcp14>
provide it with the requested number of Sender-IDs by sending multip le instances of the GM_SENDER_ID provide it with the requested number of Sender-IDs by sending multip le instances of the GM_SENDER_ID
attribute. The GCKS <bcp14>MAY</bcp14> send fewer values than reques ted by the GM (e.g. if it is running out of Sender-IDs), attribute. The GCKS <bcp14>MAY</bcp14> send fewer values than reques ted by the GM (e.g., if it is running out of Sender-IDs),
but it <bcp14>MUST NOT</bcp14> send more than requested. but it <bcp14>MUST NOT</bcp14> send more than requested.
</t> </t>
<t>This attribute <bcp14>MUST NOT</bcp14> appear in the rekey operat
<t>This attribute <bcp14>MUST NOT</bcp14> appear in the rekey operat ions (in the GSA_REKEY pseudo-exchange or in the GSA_INBAND_REKEY exchange).
ions (in the GSA_REKEY or GSA_INBAND_REKEY exchanges).
</t> </t>
</section> </section>
</section> </section>
<section anchor="wrapped_key">
<section anchor="wrapped_key" title="Key Wrapping"> <name>Key Wrapping</name>
<t>Symmetric keys in G-IKEv2 are never sent in clear inside G-IKEv2 me ssages. <t>Symmetric keys in G-IKEv2 are never sent in clear inside G-IKEv2 me ssages.
They are always protected with other symmetric keys. This protection i s called key wrapping. They are always protected with other symmetric keys. This protection i s called key wrapping.
Algorithms used for key wrapping are usually based on generic encrypti on algorithms, Algorithms used for key wrapping are usually based on generic encrypti on algorithms,
but their mode of operation is optimized for protecting short high-ent ropy data with minimal additional overhead. but their mode of operation is optimized for protecting short high-ent ropy data with minimal additional overhead.
While in general key wrap algorithms can be generic, in practice they While key wrap algorithms can be generic in general, they are often ti
are often tied to the underlying ed to the underlying
encryption algorithms. For example, AES Key Wrap with Padding Algorith encryption algorithms in practice. For example, AES Key Wrap with Padd
m <xref target="RFC5649" /> defines key wrapping using AES, ing Algorithm <xref target="RFC5649"/> defines key wrapping using AES,
and Key Wrapping Constructions using SipHash and ChaCha <xref target=" and Key Wrapping Constructions using SipHash and ChaCha <xref target="
ARX-KW" /> defines key wrapping using Chacha20. ARX-KW"/> define key wrapping using Chacha20.
</t> </t>
<t> In G-IKEv2 the key wrap algorithm <bcp14>MUST</bcp14> be negotiate <t>In G-IKEv2, the key wrap algorithm <bcp14>MUST</bcp14> be negotiated in the
d in the IKE_SA_INIT IKE_SA_INIT exchange so that the GCKS is able to send encrypted keys
exchange, so that the GCKS be able to send encrypted keys to the GM in to the GM in the GSA_AUTH exchange. In addition, if the GCKS plans
the GSA_AUTH exchange. to use the multicast Rekey SA for group rekey, then it <bcp14>MUST</bcp14> spec
In addition, if the GCKS plans to use the multicast Rekey SA for group ify
rekey, then it <bcp14>MUST</bcp14> the key wrap algorithm in the group SA policy for the Rekey SA inside the GSA p
specify the key wrap algorithm in the GSA payload. Note that key wrap ayload. Note that key wrap algorithms
algorithms for these cases <bcp14>MAY</bcp14> be different. For the unicast SA, t
for these cases <bcp14>MAY</bcp14> be different - for the unicast SA t he key wrap algorithm is negotiated
he key wrap algorithms is negotiated between the GM and the GCKS, while for the multicast Rekey SA, the key
between the GM and the GCKS, while for the multicast Rekey SA the key wrap algorithm
wrap algorithm is provided by the GCKS to the GMs as part of the group policy.
is provided by the GCKS to the group members as part of the group poli If an SAg payload is included in the GSA_AUTH request, then it <bcp14>
cy. MUST</bcp14> indicate which key wrap algorithms are supported by the GM.
If SAg payload is included in the GSA_AUTH request, then it <bcp14>MUS In all these cases, the key wrap algorithm is specified in a Key Wrap
T</bcp14> indicate which key wrap algorithms are supported by the GM. Algorithm transform (see <xref target="wrapping_alg"/>).
In all these cases the key wrap algorithm is specified in a Key Wrap A
lgorithm transform <xref target="wrapping_alg"/>.
</t> </t>
<t> The format of the wrapped key is shown in <xref target="key_format
<t> The format of the wrapped key is shown in <xref target="key_format "/>.
" />.
</t> </t>
<figure title="Wrapped Key Format" anchor="key_format"> <figure anchor="key_format">
<preamble></preamble> <name>Wrapped Key Format</name>
<artwork align="center"><![CDATA[ <artwork ><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
~ Encrypted Key ~ ~ Encrypted Key ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
<postamble></postamble>
</figure> </figure>
<t>The Wrapped Key fields are defined as follows:</t> <t>The Wrapped Key fields are defined as follows:</t>
<dl spacing="normal" newline="true">
<t><list style="symbols"> <dt>Key ID (4 octets):</dt><dd>ID of the encrypted key. The value
<t>Key ID (4 octets) -- ID of the encrypted key. The value zero mea zero means that the encrypted key contains SA keys (in the form of
ns that the encrypted key keying material; see <xref target="group_sa_keys"/>). Otherwise,
contains SA keys (in the form of keying material, see <xref target= it contains some intermediate key.</dd>
"group_sa_keys" />)), otherwise it contains some intermediate key.</t> <dt>KWK ID (4 octets):</dt><dd>ID of the key that was used to
<t>KWK ID (4 octets) -- ID of the key that was used to encrypt key encrypt the key with a specified Key ID. The value zero means that
with specified Key ID. the
The value zero means that the default KWK was used to encrypt the k default KWK was used to encrypt the key. Otherwise, some
ey, otherwise some intermediate intermediate key was used.</dd>
key was used.</t> <dt>Encrypted Key (variable):</dt><dd>The encrypted key bits. These
<t>Encrypted Key (variable) -- The encrypted key bits. These bits c bits comprise either a single encrypted key or a result of
omprise either a single encryption of a concatenation of keys (key material) for several
encrypted key or a result of encryption of a concatenation of keys algorithms. The format of this field is determined by the key
(key material) for several algorithms. wrap algorithm for the SA the wrapped key is sent over.</dd>
The format of this fields is determined by the key wrap algorithm f </dl>
or the SA the wrapped key is sent over.
</t>
</list>
</t>
</section> </section>
</section> </section>
<section anchor="delete">
<section anchor="delete" title="Delete Payload"> <name>Delete Payload</name>
<t> Delete payload is used in G-IKEv2 when the GCKS wants to <t>Delete payload is used in G-IKEv2 when the GCKS wants to
delete Data-Security and Rekey SAs. The interpretation of the Protocol delete Data-Security and Rekey SAs. The interpretation of the Protocol
field in the Delete payload is extended, so that zero protocol field in the Delete payload is extended so that zero protocol
indicates deletion of whole Group SA (i.e. all Data-Security SAs and Rek indicates deletion of whole Group SA (i.e., all Data-Security SAs and th
ey SA). e Rekey SA).
See <xref target="deletion" /> for detail. See <xref target="deletion"/> for detail.
</t> </t>
</section> </section>
<section anchor="notify">
<section anchor="notify" title="Notify Payload"> <name>Notify Payload</name>
<t>G-IKEv2 uses the same Notify payload as specified in <xref <t>G-IKEv2 uses the same Notify payload as specified in <xref target="RF
target="RFC7296"></xref>, section 3.10. C7296" sectionFormat="of" section="3.10"/>.
</t> </t>
<t>There are additional Notify message types introduced by G-IKEv2 to
<t>There are additional Notify Message types introduced by G-IKEv2 to communicate error conditions and status (see <xref target="IANA"/>).
communicate error conditions and status (see <xref target="IANA" />).
</t> </t>
<section anchor="inv_gr_id">
<section anchor="inv_gr_id" title="INVALID_GROUP_ID Notification"> <name>INVALID_GROUP_ID Notification</name>
<t>INVALID_GROUP_ID (45) is a new error type notification that indicat <t>INVALID_GROUP_ID (45) is a new error type notification that indicat
es that es that the IDg payload sent during the registration process denotes an invalid
the group ID sent during the registration process is invalid. group.
The Protocol ID and SPI Size fields in the Notify payload <bcp14>MUST< /bcp14> be zero. The Protocol ID and SPI Size fields in the Notify payload <bcp14>MUST< /bcp14> be zero.
There is no data associated with this notification and the content of the There is no data associated with this notification and the content of the
Notification Data field <bcp14>MUST</bcp14> be ignored on receipt. Notification Data field <bcp14>MUST</bcp14> be ignored on receipt.
</t> </t>
</section> </section>
<section anchor="autz_failed">
<section anchor="autz_failed" title="AUTHORIZATION_FAILED Notification"> <name>AUTHORIZATION_FAILED Notification</name>
<t>AUTHORIZATION_FAILED (46) is a new error type notification that is sent in <t>AUTHORIZATION_FAILED (46) is a new error type notification that is sent in
the response to a GSA_AUTH or GSA_REGISTRATION message when authorizat ion failed. the response to a GSA_AUTH or GSA_REGISTRATION message when authorizat ion failed.
The Protocol ID and SPI Size fields in the Notify payload <bcp14>MUST< /bcp14> be zero. The Protocol ID and SPI Size fields in the Notify payload <bcp14>MUST< /bcp14> be zero.
There is no data associated with this notification and the content of the There is no data associated with this notification and the content of the
Notification Data field <bcp14>MUST</bcp14> be ignored on receipt. Notification Data field <bcp14>MUST</bcp14> be ignored on receipt.
</t> </t>
</section> </section>
<section anchor="reg_failed">
<section anchor="reg_failed" title="REGISTRATION_FAILED Notification"> <name>REGISTRATION_FAILED Notification</name>
<t>REGISTRATION_FAILED (&lt;TBA&gt;) is a new error type notification <t>REGISTRATION_FAILED (49) is a new error type notification that is s
that is sent ent
by the GCKS when the GM registration request cannot be satisfied by the GCKS when the GM registration request cannot be satisfied
for the reasons not related to this particular GM, for example if for reasons not related to this particular GM, e.g., if
the capacity of the group is exceeded. the capacity of the group is exceeded.
The Protocol ID and SPI Size fields in the Notify payload <bcp14>MUST< /bcp14> be zero. The Protocol ID and SPI Size fields in the Notify payload <bcp14>MUST< /bcp14> be zero.
There is no data associated with this notification and the content of the There is no data associated with this notification and the content of the
Notification Data field <bcp14>MUST</bcp14> be ignored on receipt. Notification Data field <bcp14>MUST</bcp14> be ignored on receipt.
</t> </t>
</section> </section>
<section anchor="sender">
<section anchor="sender" title="GROUP_SENDER Notification"> <name>GROUP_SENDER Notification</name>
<t>GROUP_SENDER (16429) is a new status type notification that is sent in <t>GROUP_SENDER (16429) is a new status type notification that is sent in
the GSA_AUTH or the GSA_REGISTRATION exchanges to indicate that the GM the GSA_AUTH or the GSA_REGISTRATION exchanges to indicate that the GM
intends to be sender of data traffic. The data includes a count of intends to be sender of data traffic. The data includes a count of
how many Sender-ID values the GM desires. The count <bcp14>MUST</bcp14 > be 4 octets long how many Sender-ID values the GM desires. The count <bcp14>MUST</bcp14 > be 4 octets long
and contain the big endian representation of the number of and contain the big-endian representation of the number of
requested Sender-IDs. The Protocol ID and SPI Size fields in the Notif y payload <bcp14>MUST</bcp14> be zero. requested Sender-IDs. The Protocol ID and SPI Size fields in the Notif y payload <bcp14>MUST</bcp14> be zero.
</t> </t>
</section> </section>
</section> </section>
<section>
<section title="Authentication Payload"> <name>Authentication Payload</name>
<t>G-IKEv2 uses the same Authentication payload as specified in <xref <t>G-IKEv2 uses the same Authentication payload as specified in <xref
target="RFC7296"></xref>, section 3.8, to authenticate the rekey message target="RFC7296" sectionFormat="of" section="3.8"/> to
. authenticate the rekey message. However, if it is used in the
However, if it is used in the GSA_REKEY messages the content of the payl GSA_REKEY messages, the content of the payload is computed differently
oad as described in <xref target="gsa_rekey_auth"/>.
is computed differently, as described in <xref target="gsa_rekey_auth" /
>.
</t> </t>
</section> </section>
</section> </section>
<section anchor="restrictions">
<section anchor="restrictions" title="Using G-IKEv2 Attributes"> <name>Using G-IKEv2 Attributes</name>
<t>G-IKEv2 defines a number of attributes, that are used to convey informa <t>G-IKEv2 defines a number of attributes that are used to convey informat
tion ion
from GCKS to GMs. There are some restrictions on where and when these attr from the GCKS to GMs. There are some restrictions on where and when these
ibutes attributes
can appear in G-IKEv2 messages, which are defined when the attributes are introduced. can appear in G-IKEv2 messages, which are defined when the attributes are introduced.
For convenience these restrictions are summarized in <xref target="mcast_a For convenience, these restrictions are summarized in <xref target="mcast_
ttr" /> (for attr"/> (for
multicast rekey operations) and <xref target="inband_attr" /> (for inband multicast rekey operations) and <xref target="inband_attr"/> (for inband r
rekey operations) below. ekey operations) below.
</t> </t>
<t>The following notations are used:
<t>The following notation is used: </t>
<list style="hanging" hangIndent="6" > <dl newline="false" spacing="normal" indent="5">
<t hangText = "S" > <dt>S</dt>
A single attribute of this type <bcp14>MUST</bcp14> be present <dd>
</t> A single attribute of this type <bcp14>MUST</bcp14> be present.
<t hangText = "M" > </dd>
Multiple attributes of this type <bcp14>MAY</bcp14> be present <dt>M</dt>
</t> <dd>
<t hangText = "[]" > Multiple attributes of this type <bcp14>MAY</bcp14> be present.
Attribute is <bcp14>OPTIONAL</bcp14> </dd>
</t> <dt>[]</dt>
<t hangText = "-" > <dd>
Attribute <bcp14>MUST NOT</bcp14> be present Attribute is <bcp14>OPTIONAL</bcp14>.
</t> </dd>
</list> <dt>-</dt>
Note, that the restrictions are defined per a substructure corresponding a <dd>
ttributes Attribute <bcp14>MUST NOT</bcp14> be present.
are defined for and not per whole G-IKEv2 message. </dd>
</dl>
<t>
Note that the restrictions are defined per a substructure for which
corresponding attributes are defined and not per a whole G-IKEv2 message.
</t> </t>
<table anchor="mcast_attr"> <table anchor="mcast_attr">
<name>Attributes in G-IKEv2 exchanges with multicast rekey operations</n ame> <name>Attributes in G-IKEv2 Exchanges with Multicast Rekey Operations</n ame>
<thead> <thead>
<tr> <tr>
<th>Attributes</th> <th>Attributes</th>
<th align="center">GSA_AUTH GSA_REGISTRATION</th> <th >GSA_AUTH GSA_REGISTRATION</th>
<th align="center">GSA_REKEY</th> <th >GSA_REKEY</th>
<th>Notes</th> <th>Notes</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<th colspan="4" align="center">GSA Attributes (<xref target="gsa_att r" />)</th> <th colspan="4" >Group SA Attributes (<xref target="gsa_attr"/>)</th >
</tr> </tr>
<tr> <tr>
<td>GSA_KEY_LIFETIME</td> <td>GSA_KEY_LIFETIME</td>
<td align="center">S</td> <td >S</td>
<td align="center">S</td> <td >S</td>
<td align="center"></td> <td />
</tr> </tr>
<tr> <tr>
<td>GSA_INITIAL_MESSAGE_ID</td> <td>GSA_INITIAL_MESSAGE_ID</td>
<td align="center">[S]</td> <td >[S]</td>
<td align="center">[S]</td> <td >[S]</td>
<td align="center"></td> <td />
</tr> </tr>
<tr> <tr>
<td>GSA_NEXT_SPI</td> <td>GSA_NEXT_SPI</td>
<td align="center">[M]</td> <td >[M]</td>
<td align="center">[M]</td> <td >[M]</td>
<td align="center"></td> <td />
</tr> </tr>
<tr> <tr>
<th colspan="4" align="center">GW Policy Attributes (<xref target="g wp_attr" />)</th> <th colspan="4" >GW Policy Attributes (<xref target="gwp_attr"/>)</t h>
</tr> </tr>
<tr> <tr>
<td>GWP_ATD</td> <td>GWP_ATD</td>
<td align="center">[S]</td> <td >[S]</td>
<td align="center">[S]</td> <td >[S]</td>
<td align="center"></td> <td />
</tr> </tr>
<tr> <tr>
<td>GWP_DTD</td> <td>GWP_DTD</td>
<td align="center">[S]</td> <td >[S]</td>
<td align="center">[S]</td> <td >[S]</td>
<td align="center"></td> <td />
</tr> </tr>
<tr> <tr>
<td>GWP_SENDER_ID_BITS</td> <td>GWP_SENDER_ID_BITS</td>
<td align="center">S</td> <td >S</td>
<td align="center">-</td> <td >-</td>
<td align="center">1</td> <td >1</td>
</tr> </tr>
<tr> <tr>
<th colspan="4" align="center">Key Bag Attributes (<xref target="key _bag" />)</th> <th colspan="4" >Key Bag Attributes (<xref target="key_bag"/>)</th>
</tr> </tr>
<tr> <tr>
<td>SA_KEY</td> <td>SA_KEY</td>
<td align="center">S</td> <td >S</td>
<td align="center">S[M]</td> <td >S[M]</td>
<td align="center">2</td> <td >2</td>
</tr> </tr>
<tr> <tr>
<td>WRAP_KEY</td> <td>WRAP_KEY</td>
<td align="center">[M]</td> <td >[M]</td>
<td align="center">[M]</td> <td >[M]</td>
<td align="center">3</td> <td >3</td>
</tr> </tr>
<tr> <tr>
<td>AUTH_KEY</td> <td>AUTH_KEY</td>
<td align="center">S</td> <td >S</td>
<td align="center">[S]</td> <td >[S]</td>
<td align="center">4</td> <td >4</td>
</tr> </tr>
<tr> <tr>
<td>GM_SENDER_ID</td> <td>GM_SENDER_ID</td>
<td align="center">S[M]</td> <td >S[M]</td>
<td align="center">-</td> <td >-</td>
<td align="center">1</td> <td >1</td>
</tr> </tr>
</tbody> </tbody>
<tfoot>
<tr>
<td colspan="4">
<t>
Notes:
<list style="hanging" hangIndent="6" >
<t hangText = "(1)" >
The GWP_SENDER_ID_BITS attribute <bcp14>MUST</bcp14> be pres
ent if the GCKS policy includes at least one
cipher in counter mode of operation and the GM included the
GROUP_SENDER notify into the registration request.
Otherwise it <bcp14>MUST NOT</bcp14> be present. At least on
e GM_SENDER_ID attribute <bcp14>MUST</bcp14> be present
in the former case (and more <bcp14>MAY</bcp14> be present i
f the GM requested more Sender-IDs)
and it <bcp14>MUST NOT</bcp14> be present in the latter case
.
</t>
<t hangText="(2)" >
For a Data-Security SA exactly one SA_KEY attribute <bcp14>M
UST</bcp14> be present.
For a Rekey SA one SA_KEY attribute <bcp14>MUST</bcp14> be p
resent in all cases and
more these attributes <bcp14>MAY</bcp14> be present in GSA_R
EKEY exchange.
</t>
<t hangText = "(3)" >
The WRAP_KEY attributes <bcp14>MUST</bcp14> be present if th
e GCKS employs key management
method that relies on key tree (like LKH).
</t>
<t hangText = "(4)" >
The AUTH_KEY attribute <bcp14>MUST</bcp14> be present in the
GSA_AUTH / GSA_REGISTRATION exchanges
if the GCKS employs authentication method of rekey operation
s based on digital signatures and <bcp14>MUST NOT</bcp14> be present
if implicit authentication is employed. The AUTH_KEY attribu
te <bcp14>MUST</bcp14> be present
in the GSA_REKEY exchange if the GCKS employs authentication
method
based on digital signatures and wants to change the public k
ey for the following multicast rekey
operations.
</t>
</list>
</t>
</td>
</tr>
</tfoot>
</table> </table>
<t>Notes:</t>
<dl newline="false" spacing="normal" indent="6">
<dt>(1):</dt>
<dd>The GWP_SENDER_ID_BITS attribute <bcp14>MUST</bcp14> be present
if the GCKS policy includes at least one cipher in counter mode of
operation and if the GM included the GROUP_SENDER notify into the
registration request. Otherwise, it <bcp14>MUST NOT</bcp14> be
present. At least one GM_SENDER_ID attribute <bcp14>MUST</bcp14> be
present in the former case (and more <bcp14>MAY</bcp14> be present if
the GM requested more Sender-IDs), and it <bcp14>MUST NOT</bcp14> be
present in the latter case.</dd>
<dt>(2):</dt>
<dd>For a Data-Security SA, exactly one SA_KEY attribute <bcp14>MUST</bc
p14> be
present. For a Rekey SA, exactly one SA_KEY attribute <bcp14>MUST</bcp14>
be
present in the GSA_AUTH and the GSA_REGISTRATION exchange.
In the GSA_REKEY pseudo-exchange, at least one SA_KEY
attribute <bcp14>MUST</bcp14> be present and more of these attributes <
bcp14>MAY</bcp14> be
present.</dd>
<dt>(3):</dt>
<dd>The WRAP_KEY attribute <bcp14>MUST</bcp14> be present if the
GCKS employs a key management method that relies on a key tree (like LKH
).</dd>
<dt>(4):</dt>
<dd>The AUTH_KEY attribute <bcp14>MUST</bcp14> be present in the
GSA_AUTH and GSA_REGISTRATION exchanges if the GCKS employs
an authentication method of rekey operations based on digital signatures
and <bcp14>MUST NOT</bcp14> be present if implicit authentication is
employed. The AUTH_KEY attribute <bcp14>MUST</bcp14> be present in the
GSA_REKEY pseudo-exchange if the GCKS employs an authentication method b
ased on
digital signatures and wants to change the public key for the
following multicast rekey operations.</dd>
</dl>
<table anchor="inband_attr"> <table anchor="inband_attr">
<name>Attributes in G-IKEv2 exchanges with inband rekey operations</name > <name>Attributes in G-IKEv2 Exchanges with Inband Rekey Operations</name >
<thead> <thead>
<tr> <tr>
<th>Attributes</th> <th>Attributes</th>
<th align="center">GSA_AUTH GSA_REGISTRATION</th> <th >GSA_AUTH GSA_REGISTRATION</th>
<th align="center">GSA_INBAND_REKEY</th> <th >GSA_INBAND_REKEY</th>
<th>Notes</th> <th>Notes</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<th colspan="4" align="center">GSA Attributes (<xref target="gsa_att r" />)</th> <th colspan="4" >Group SA Attributes (<xref target="gsa_attr"/>)</th >
</tr> </tr>
<tr> <tr>
<td>GSA_KEY_LIFETIME</td> <td>GSA_KEY_LIFETIME</td>
<td align="center">[S]</td> <td >[S]</td>
<td align="center">[S]</td> <td >[S]</td>
<td align="center"></td> <td />
</tr> </tr>
<tr> <tr>
<td>GSA_INITIAL_MESSAGE_ID</td> <td>GSA_INITIAL_MESSAGE_ID</td>
<td align="center">-</td> <td >-</td>
<td align="center">-</td> <td >-</td>
<td align="center"></td> <td />
</tr> </tr>
<tr> <tr>
<td>GSA_NEXT_SPI</td> <td>GSA_NEXT_SPI</td>
<td align="center">-</td> <td >-</td>
<td align="center">-</td> <td >-</td>
<td align="center"></td> <td />
</tr> </tr>
<tr> <tr>
<th colspan="4" align="center">GW Policy Attributes (<xref target="g wp_attr" />)</th> <th colspan="4" >GW Policy Attributes (<xref target="gwp_attr"/>)</t h>
</tr> </tr>
<tr> <tr>
<td>GWP_ATD</td> <td>GWP_ATD</td>
<td align="center">[S]</td> <td >[S]</td>
<td align="center">[S]</td> <td >[S]</td>
<td align="center"></td> <td />
</tr> </tr>
<tr> <tr>
<td>GWP_DTD</td> <td>GWP_DTD</td>
<td align="center">[S]</td> <td >[S]</td>
<td align="center">[S]</td> <td >[S]</td>
<td align="center"></td> <td />
</tr> </tr>
<tr> <tr>
<td>GWP_SENDER_ID_BITS</td> <td>GWP_SENDER_ID_BITS</td>
<td align="center">S</td> <td >S</td>
<td align="center">-</td> <td >-</td>
<td align="center">1</td> <td >1</td>
</tr> </tr>
<tr> <tr>
<th colspan="4" align="center">Key Bag Attributes (<xref target="key _bag" />)</th> <th colspan="4" >Key Bag Attributes (<xref target="key_bag"/>)</th>
</tr> </tr>
<tr> <tr>
<td>SA_KEY</td> <td>SA_KEY</td>
<td align="center">S</td> <td >S</td>
<td align="center">S</td> <td >S</td>
<td align="center"></td> <td />
</tr> </tr>
<tr> <tr>
<td>WRAP_KEY</td> <td>WRAP_KEY</td>
<td align="center">-</td> <td >-</td>
<td align="center">-</td> <td >-</td>
<td align="center"></td> <td />
</tr> </tr>
<tr> <tr>
<td>AUTH_KEY</td> <td>AUTH_KEY</td>
<td align="center">-</td> <td >-</td>
<td align="center">-</td> <td >-</td>
<td align="center"></td> <td />
</tr> </tr>
<tr> <tr>
<td>GM_SENDER_ID</td> <td>GM_SENDER_ID</td>
<td align="center">S[M]</td> <td >S[M]</td>
<td align="center">-</td> <td >-</td>
<td align="center">1</td> <td >1</td>
</tr> </tr>
</tbody> </tbody>
<tfoot>
<tr>
<td colspan="4">
<t>
Notes:
<list style="hanging" hangIndent="6" >
<t hangText = "(1)" >
The GWP_SENDER_ID_BITS attribute <bcp14>MUST</bcp14> be pr
esent if the GCKS policy includes at least one
cipher in counter mode of operation and the GM included th
e GROUP_SENDER notify into the registration request.
Otherwise it <bcp14>MUST NOT</bcp14> be present. At least
one GM_SENDER_ID attribute <bcp14>MUST</bcp14> be present
in the former case (and more <bcp14>MAY</bcp14> be present
if the GM requested more Sender-IDs)
and it <bcp14>MUST NOT</bcp14> be present in the latter ca
se.
</t>
</list>
</t>
</td>
</tr>
</tfoot>
</table> </table>
</section> <t>Notes:</t>
<dl newline="false" spacing="normal" indent="6">
<dt>(1):</dt>
<dd>The GWP_SENDER_ID_BITS attribute <bcp14>MUST</bcp14> be present if
the GCKS policy includes at least one cipher in counter mode of
operation and the GM included the GROUP_SENDER notify into the
registration request. Otherwise, it <bcp14>MUST NOT</bcp14> be
present. At least one GM_SENDER_ID attribute <bcp14>MUST</bcp14> be
present in the former case (and more <bcp14>MAY</bcp14> be present if
the GM requested more Sender-IDs), and it <bcp14>MUST NOT</bcp14> be
present in the latter case.</dd>
</dl>
<section title="Interaction with IKEv2 and ESP Extensions" anchor="ike_ext" </section>
> <section anchor="ike_ext">
<t>A number of IKEv2 and ESP extensions is defined that can be used to ext <name>Interaction with IKEv2 and ESP Extensions</name>
end <t>A number of IKEv2 and ESP extensions are defined that can be used to ex
tend
protocol functionality. G-IKEv2 is compatible with most of them. protocol functionality. G-IKEv2 is compatible with most of them.
In particular, EAP authentication defined in <xref target="RFC7296" /> can In particular, EAP authentication defined in <xref target="RFC7296"/> can
be used be used
to establish registration IKE SA, as well as EAP-only authentication <xref to establish registration IKE SA, as well as EAP-only authentication <xref
target="RFC5998" /> and target="RFC5998"/> and
Secure Password authentication <xref target="RFC6467" />. secure password authentication <xref target="RFC6467"/>.
G-IKEv2 is compatible with and can use IKEv2 Redirect Mechanism <xref targ G-IKEv2 is compatible with and can use IKEv2 Redirect Mechanism <xref targ
et="RFC5685" /> and et="RFC5685"/> and
IKEv2 Session Resumption <xref target="RFC5723"></xref>. IKEv2 Session Resumption <xref target="RFC5723"/>.
G-IKEv2 is also compatible with Multiple Key Exchanges in IKEv2 G-IKEv2 is also compatible with Multiple Key Exchanges in the IKEv2
framework, defined in <xref target="RFC9370" />. framework, as defined in <xref target="RFC9370"/>.
</t> </t>
<t>The above list of compatible IKEv2 extensions is not exhaustive. Howeve
<t>The above list of compatible IKEv2 extensions is not exhaustive, howeve r, some IKEv2
r some IKEv2
extensions require special handling if used in G-IKEv2. extensions require special handling if used in G-IKEv2.
</t> </t>
<section>
<section title="Implicit IV for Counter-Based Ciphers in ESP"> <name>Implicit IV for Counter-Based Ciphers in ESP</name>
<t> Using implicit IV for counter-based encryption modes in ESP is defin <t> Using implicit IV for counter-based encryption modes in ESP is defin
ed in <xref target="RFC8750" />. ed in <xref target="RFC8750"/>.
This extension relies on the uniqueness of ESP sequence numbers. Thus, i t cannot be used for multi-sender This extension relies on the uniqueness of ESP sequence numbers. Thus, i t cannot be used for multi-sender
multicast SAs. However, it is possible to use implicit IV extension for a single-sender multicast ESP SA. multicast SAs. However, it is possible to use implicit IV extension for a single-sender multicast ESP SA.
Note, that while implicit IVs can be used with ESN, using ESN is prohibi Note that while implicit IVs can be used with ESN, using ESN is prohibit
ted ed
in multicast SAs (see <xref target="antireplay" />). in multicast SAs (see <xref target="antireplay"/>).
</t> </t>
</section> </section>
<section>
<section title="Mixing Preshared Keys in IKEv2 for Post-quantum Security"> <name>Mixing Preshared Keys in IKEv2 for Post-Quantum Security</name>
<t> G-IKEv2 can take advantage of the protection provided by <t>G-IKEv2 can take advantage of the protection provided by
Postquantum Preshared Keys (PPK) for IKEv2 <xref Post-quantum Preshared Keys (PPKs) for IKEv2 <xref target="RFC8784"/>. H
target="RFC8784"></xref>. However, the use of owever, the use of
PPK leaves the initial IKE SA susceptible to quantum PPKs leaves the initial IKE SA susceptible to quantum
computer (QC) attacks. Group SA keys are protected with computer (QC) attacks. Group SA keys are protected with
the default KWK (GSK_w), which is derived from SK_d and thus the default KWK (GSK_w), which is derived from SK_d and thus
cannot be broken even by attacker equipped with a QC. cannot be broken even by an attacker equipped with a QC.
However, other data sent over the initial IKE SA may However, other data sent over the initial IKE SA may
be susceptible to an attacker equipped with a QC of a sufficient size. S uch an attacker can store all the traffic be susceptible to an attacker equipped with a QC of a sufficient size. S uch an attacker can store all the traffic
until it obtains such a QC and then decrypt it (Store Now Decrypt Later until it obtains such a QC and then decrypt it (i.e., Store Now Decrypt
attack). Later attack).
See Section 6 of <xref target="RFC8784" /> for details. See <xref target="RFC8784" sectionFormat="of" section="6"/> for details.
</t> </t>
<t>While the group keys are protected with PPK and thus are immune to QC , GCKS implementations that care about other data sent over initial IKE SA <t>While the group keys are protected with PPK and thus are immune to QC , GCKS implementations that care about other data sent over initial IKE SA
<bcp14>MUST</bcp14> rely on IKEv2 extensions that protect even initial I KE SA against QC <bcp14>MUST</bcp14> rely on IKEv2 extensions that protect even initial I KE SA against QC
(like <xref target="I-D.ietf-ipsecme-ikev2-qr-alt" />). (like <xref target="RFC9867"/>).
</t> </t>
</section> </section>
<section>
<section title="Aggregation and Fragmentation Mode for ESP"> <name>Aggregation and Fragmentation Mode for ESP</name>
<t> Aggregation and fragmentation mode for ESP is defined in <xref targe <t>Aggregation and fragmentation mode for ESP is defined in <xref target
t="RFC9347" />. This mode allows IP packets to ="RFC9347"/>. This mode allows IP packets to
be split over several ESP packets, or several IP packets to be aggregate be split over several ESP packets or several IP packets to be aggregated
d in a single ESP packet. in a single ESP packet.
This mode can only be used with ESP tunnel mode and relies on monotonica lly increasing sequence numbers This mode can only be used with ESP tunnel mode and relies on monotonica lly increasing sequence numbers
in the incoming packets. Thus, it is impossible to use this mode for mul ti-sender multicast SAs. in the incoming packets. Thus, it is impossible to use this mode for mul ti-sender multicast SAs.
Since multicast Data-Security SAs are unidirectional, the congestion con trol feature of aggregation and fragmentation mode cannot be used. Since multicast Data-Security SAs are unidirectional, the congestion con trol feature of aggregation and fragmentation mode cannot be used.
</t> </t>
<t> It is possible to use the aggregation and fragmentation mode without congestion control for a single-sender multicast ESP SA created in tunnel mode. <t> It is possible to use the aggregation and fragmentation mode without congestion control for a single-sender multicast ESP SA created in tunnel mode.
GMs supporting this mode can send the USE_AGGFRAG notification in the re gistration request along with the SAg payload. GMs supporting this mode can send the USE_AGGFRAG notification in the re gistration request along with the SAg payload.
If the Data-Security SA(s) to be installed on GMs use the aggregation an d fragmentation mode, the GCKS would indicate it by including If the Data-Security SA(s) to be installed on GMs uses the aggregation a nd fragmentation mode, the GCKS would indicate it by including
the USE_AGGFRAG notification along with the GSA payload in its response. the USE_AGGFRAG notification along with the GSA payload in its response.
</t> </t>
</section> </section>
</section> </section>
<section anchor="gdoi_ext">
<section title="GDOI Protocol Extensions" anchor="gdoi_ext"> <name>GDOI Protocol Extensions</name>
<t> Few extensions were defined for GDOI protocol <xref target="RFC6407" <t> Few extensions were defined for the GDOI protocol <xref target="RFC640
/>, like 7"/>, like
GDOI Support for IEC 62351 Security Services <xref target="RFC8052" /> o GDOI Support for IEC 62351 Security Services <xref target="RFC8052"/> or
r GDOI GROUPKEY-PUSH Acknowledgement Message <xref target="RFC8263" />. the GDOI GROUPKEY-PUSH Acknowledgement Message <xref target="RFC8263"/>.
It is expected that these extensions will be redefined for G-IKEv2 in se parate documents, if needed. It is expected that these extensions will be redefined for G-IKEv2 in se parate documents, if needed.
</t> </t>
</section> </section>
<section>
<section title="Security Considerations"> <name>Security Considerations</name>
<t> When an entity joins the group and becomes a group member, it has to <t> When an entity joins the group and becomes a GM, it has to
trust the GCKS that only authorized entities are admitted to the group and trust that the GCKS only authorized entities that are admitted to the grou
has to trust other group members that they will not leak the information s p and
hared within the group. has to trust that other GMs will not leak the information shared within th
e group.
</t> </t>
<section>
<section title="GSA Registration and Secure Channel"> <name>GSA Registration and Secure Channel</name>
<t>G-IKEv2 registration exchange uses IKEv2 IKE_SA_INIT protocols, <t>G-IKEv2 registration procedure uses IKEv2 initial exchanges,
inheriting all the security considerations documented in the Section 5 o inheriting all the security considerations documented in <xref target="RFC7296"
f <xref target="RFC7296"/>, sectionFormat="of" section="5"/>, including authentication, confidentiality, on-
including authentication, confidentiality, protection against man-in-the path attack
-middle, protection, protection against replay/reflection attacks, and denial-
protection against replay/reflection attacks, and denial of service of-service protection. The GSA_REGISTRATION exchange
protection. The GSA_AUTH and GSA_REGISTRATION exchanges also take also takes advantage of those protections.
advantage of those protections. In addition, G-IKEv2 brings in the In addition, G-IKEv2 brings in the
capability to authorize a particular group member regardless of capability to authorize a particular GM regardless of
whether they have the IKEv2 credentials.</t> whether they have the IKEv2 credentials.</t>
</section> </section>
<section>
<section title="GSA Maintenance Channel"> <name>GSA Maintenance Channel</name>
<t>The GSA maintenance channel is cryptographically and integrity <t>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.</t> GSA member registration exchange.</t>
<section>
<section title="Authentication/Authorization"> <name>Authentication/Authorization</name>
<t>The authentication key is distributed during the GM registration, <t>The authentication key is distributed during the GM registration
and the receiver of the rekey message uses that key to verify the mess age came and the receiver of the rekey message uses that key to verify the mess age came
from the authorized GCKS. An implicit authentication can also be used, from the authorized GCKS.
in which case the ability of the GM to decrypt and to verify ICV An implicit authentication can also be used, in which case,
of the received message proved that a sender of the message is a membe the ability of the GM to decrypt and to verify ICV of
r of the group. incoming messages is used as a proof that the sender
knows group keys and therefore is a member of the group.
However, implicit authentication doesn't provide source origin authent ication, so the GM cannot be sure However, implicit authentication doesn't provide source origin authent ication, so the GM cannot be sure
that the message came from the GCKS. For this reason using implicit that the message came from the GCKS. For this reason, using implicit
authentication is <bcp14>NOT RECOMMENDED</bcp14> authentication is <bcp14>NOT RECOMMENDED</bcp14>
unless used with a small group of trusted parties. unless used with a small group of trusted parties.
</t> </t>
</section> </section>
<section>
<section title="Confidentiality"> <name>Confidentiality</name>
<t>Confidentiality is provided by distributing a confidentiality key <t>Confidentiality is provided by distributing a confidentiality key
as part of the GSA member registration exchange.</t> as part of the GSA member registration exchange.</t>
</section> </section>
<section>
<section title="Man-in-the-Middle Attack Protection"> <name>On-Path Attack Protection</name>
<t>GSA maintenance channel is integrity protected by using a digital <t>The GSA maintenance channel is integrity protected by using a digit
al
signature.</t> signature.</t>
</section> </section>
<section>
<section title="Replay/Reflection Attack Protection"> <name>Replay/Reflection Attack Protection</name>
<t>The GSA_REKEY message includes a monotonically increasing <t>The GSA_REKEY message includes a monotonically increasing
sequence number to protect against replay and reflection attacks. A sequence number to protect against replay and reflection attacks. A
group member will recognize a replayed message by comparing the GM will recognize a replayed message by comparing the
Message ID number to that of the last received rekey message, any Message ID number to that of the last received rekey message. Any
rekey message containing a Message ID number less than or equal to rekey message containing a Message ID number less than or equal to
the last received value <bcp14>MUST</bcp14> be discarded. Implementati ons should the last received value <bcp14>MUST</bcp14> be discarded. Implementati ons should
keep a record of recently received GSA rekey messages for this keep a record of recently received GSA rekey messages for this
comparison.</t> comparison.</t>
<t>The strict role separation between the GCKS and the GMs and, as a c onsequence, <t>The strict role separation between the GCKS and the GMs and, as a c onsequence,
the limitation for Rekey SA to be outbound/inbound only, helps to prev ent reflection attack. the limitation for a Rekey SA to be outbound/inbound only, helps to pr event reflection attack.
</t> </t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="IANA">
<name>IANA Considerations</name>
<section>
<name>New Registries</name>
<t>Per this document, new registries have been created for G-IKEv2 under
the "Internet Key Exchange Version 2 (IKEv2) Parameters" registry group <xref t
arget="IKEV2-IANA"/>. The terms
Reserved, Expert Review, and Private Use are as defined
in <xref target="RFC8126"/>.</t>
<section anchor="IANA" title="IANA Considerations"> <!-- [rfced] We have included some specific questions about the IANA
<section title="Note for Reviewers"> text below. In addition to responding to those questions, please
<t> **** RFC Editor, please DELETE this Section prior to publication! review all of the IANA-related updates carefully, including the
**** IANA values in the running text, and let us know if any further
</t> updates are needed.
<t> While reviewing the document please note, that some of the codepoi Please refer to the following URL to view the IANA registries:
nts, that this draft claims <https://www.iana.org/assignments/ikev2-parameters/>
to have allocated, in fact have been allocated by its predecessor, dra
ft-yeung-g-ikev2-07 in 2013,
as part of the early codepoint assignment. This documents makes use of
these already allocated
codepoints, renames one of them and allocates additional codepoints. N
ote also, that the semantics
of the codepoints allocated by draft-yeung-g-ikev2-07 is preserved, in
cluding for the renamed one.
</t>
</section>
<section title="New Registries"> a) For Tables 3-7 and 11-16, may we order the "Value" columns first to match
<t>A new set of registries is created for G-IKEv2 on IKEv2 the corresponding IANA registries?
parameters page <xref target="IKEV2-IANA" />. The terms
Reserved, Expert Review and Private Use are to be applied as defined
in <xref target="RFC8126"></xref>.</t>
<ol> b) FYI: For Tables 11-16, we updated "Private Use" to "Reserved
<li> for Private Use" to match the corresponding IANA registries.
<t>This document creates a new IANA registry "Transform Type &lt;TBA&gt;
-- Key Wrap Algorithm Transform IDs".
The initial values of the new registry are:
<figure>
<preamble></preamble>
<artwork align="left"><![CDATA[
Key Wrap Algorithm Value
Reserved 0
KW_5649_128 1
KW_5649_192 2
KW_5649_256 3
KW_ARX 4
Unassigned 5-1023
Private Use 1024-65535
]]></artwork>
</figure>
Changes and additions to the unassigned range of this registry are by
the Expert Review Policy <xref target="RFC8126" />.</t>
</li>
<li> e) FYI: For clarity, we added the "Reference" column to Table 19 to show
<t>This document creates a new IANA registry "Transform Type &lt;TBA&gt; that the "Security Association" Payload Type was registered by RFC 7296.
-- Group Controller Authentication Method Transform IDs". If this is not desired, please let us know.
The initial values of the new registry are:
<figure>
<preamble></preamble>
<artwork align="left"><![CDATA[
Group Controller Authentication Method Value
Reserved 0
Implicit 1
Digital Signature 2
Unassigned 3-1023
Private Use 1024-65535
]]></artwork>
</figure>
Changes and additions to the unassigned range of this registry are by
the Expert Review Policy <xref target="RFC8126" />.</t>
</li>
<li> f) Is it helpful for the reader if the history of the SENDER_REQUEST_ID
<t>This document creates a new IANA registry "GSA Attributes". The initi registration is included? If so, should an informative reference to
al values of the new registry are: "draft-yeung-g-ikev2-07" (e.g., "[G-IKEV2]") be added (option A)? Or
<figure> if the history isn't necessary, is option B preferred?
<preamble></preamble>
<artwork align="left"><![CDATA[
GSA Attributes Value Format Multi-Valued Used in Protocol
Reserved 0
GSA_KEY_LIFETIME 1 TLV NO GIKE_UPDATE, AH, ESP
GSA_INITIAL_MESSAGE_ID 2 TLV NO GIKE_UPDATE
GSA_NEXT_SPI 3 TLV YES GIKE_UPDATE, AH, ESP
Unassigned 5-16383
Private Use 16384-32767
]]></artwork>
</figure>
Changes and additions to the unassigned range of this registry are by
the Expert Review Policy <xref target="RFC8126" />.</t>
</li>
<li> Original:
<t>This document creates a new IANA registry "Group-wide Policy Attribut The Notify type with the value 16429 was allocated earlier in the
es". The initial values of the new registry are: development of G-IKEv2 document in the "IKEv2 Notify Message
<figure> Status Types" registry with the name SENDER_REQUEST_ID. This document
<preamble></preamble> renames it as follows:
<artwork align="left"><![CDATA[
GW Policy Attributes Value Format Multi-Valued
Reserved 0
GWP_ATD 1 TV NO
GWP_DTD 2 TV NO
GWP_SENDER_ID_BITS 3 TV NO
Unassigned 4-16383
Private Use 16384-32767
]]></artwork>
</figure>
Changes and additions to the unassigned range of this registry are by
the Expert Review Policy <xref target="RFC8126" />.</t>
</li>
<li> Perhaps A:
<t>This document creates a new IANA registry "Group Key Bag Attributes". An earlier draft of this document [G-IKEV2] registered the Notify
The initial values of the new registry are: type 16429 with the name SENDER_REQUEST_ID. Per this document,
<figure> IANA has updated the "IKEv2 Notify Message Status Types" registry
<preamble></preamble> as follows:
<artwork align="left"><![CDATA[
Group Key Bag or
Attributes Value Format Multi-Valued Used in Protocol Perhaps B:
Reserved 0 IANA has registered the following in the "IKEv2 Notify Message Status
SA_KEY 1 TLV YES GIKE_UPDATE Types" registry:
NO AH, ESP -->
Unassigned 2-16383
Private Use 16384-32767
]]></artwork>
</figure>
Changes and additions to the unassigned range of this registry are by
the Expert Review Policy <xref target="RFC8126" />.</t>
</li>
<ol type="1" spacing="normal">
<li> <li>
<t>This document creates a new IANA registry "Member Key Bag Attributes" <t>IANA has created the "Transform Type 13 - Key Wrap Algorithm Transf
. The initial values of the new registry are: orm IDs" registry.
<figure> The registration policy for this registry is Expert Review <xref target="RFC8126
<preamble></preamble> "/>. The initial values of the registry are as follows:</t>
<artwork align="left"><![CDATA[
Member Key Bag <table>
Attributes Value Format Multi-Valued <name></name>
Reserved 0 <thead>
WRAP_KEY 1 TLV YES <tr>
AUTH_KEY 2 TLV NO <th>Value</th>
GM_SENDER_ID 3 TLV YES <th>Key Wrap Algorithm</th>
Unassigned 4-16383 </tr>
Private Use 16384-32767 </thead>
]]></artwork> <tbody>
</figure> <tr>
Changes and additions to the unassigned range of this registry are by <td>0</td>
the Expert Review Policy <xref target="RFC8126" />.</t> <td>Reserved</td>
</tr>
<tr>
<td>1</td>
<td>KW_5649_128</td>
</tr>
<tr>
<td>2</td>
<td>KW_5649_192</td>
</tr>
<tr>
<td>3</td>
<td>KW_5649_256</td>
</tr>
<tr>
<td>4</td>
<td>KW_ARX</td>
</tr>
<tr>
<td>5-1023</td>
<td>Unassigned</td>
</tr>
<tr>
<td>1024-65535</td>
<td>Reserved for Private Use</td>
</tr>
</tbody>
</table>
</li> </li>
</ol> <li>
<t>IANA has created the "Transform Type
14 - Group Controller Authentication Method Transform
IDs" registry. The registration policy for this registry is Expert R
eview <xref target="RFC8126"/>. The initial values of the registry are as follo
ws:</t>
<section title="Guidance for Designated Experts"> <table>
<t> In all cases of Expert Review Policy described here, <name></name>
the Designated Expert (DE) is expected to ascertain the existence of <thead>
suitable <tr>
documentation (a specification) as described in <xref target="RFC8126 <th>Value</th>
" /> and to <th>Group Controller Authentication Method</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
</tr>
<tr>
<td>1</td>
<td>Implicit</td>
</tr>
<tr>
<td>2</td>
<td>Digital Signature</td>
</tr>
<tr>
<td>3-1023</td>
<td>Unassigned</td>
</tr>
<tr>
<td>1024-65535</td>
<td>Reserved for Private Use</td>
</tr>
</tbody>
</table>
</li>
<li>
<t>IANA has created the "Group SA Attributes" registry. The registr
ation policy for this registry is Expert Review <xref target="RFC8126"/>. The in
itial values of the registry are as follows:
</t>
<table>
<name></name>
<thead>
<tr>
<th>Value</th>
<th>Group SA Attributes</th>
<th>Format</th>
<th>Multi-Valued</th>
<th>Used in Protocol</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td colspan="3"></td>
</tr>
<tr>
<td>1</td>
<td>GSA_KEY_LIFETIME</td>
<td>TLV</td>
<td>NO</td>
<td>GIKE_UPDATE, AH, ESP</td>
</tr>
<tr>
<td>2</td>
<td>GSA_INITIAL_MESSAGE_ID</td>
<td>TLV</td>
<td>NO</td>
<td>GIKE_UPDATE</td>
</tr>
<tr>
<td>3</td>
<td>GSA_NEXT_SPI</td>
<td>TLV</td>
<td>YES</td>
<td>GIKE_UPDATE, AH, ESP</td>
</tr>
<tr>
<td>4-16383</td>
<td>Unassigned</td>
<td colspan="3"></td>
</tr>
<tr>
<td>16384-32767</td>
<td>Reserved for Private Use</td>
<td colspan="3"></td>
</tr>
</tbody>
</table>
</li>
<li>
<t>IANA has created the "Group-Wide Policy Attributes" registry. The
registration policy for this registry is Expert Review <xref target="RFC8126"/>
. The initial values of the registry are as follows:
</t>
<table>
<name></name>
<thead>
<tr>
<th>Value</th>
<th>GW Policy Attributes</th>
<th>Format</th>
<th>Multi-Valued</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td colspan="2"></td>
</tr>
<tr>
<td>1</td>
<td>GWP_ATD</td>
<td>TV</td>
<td>NO</td>
</tr>
<tr>
<td>2</td>
<td>GWP_DTD</td>
<td>TV</td>
<td>NO</td>
</tr>
<tr>
<td>3</td>
<td>GWP_SENDER_ID_BITS</td>
<td>TV</td>
<td>NO</td>
</tr>
<tr>
<td>4-16383</td>
<td>Unassigned</td>
<td colspan="2"></td>
</tr>
<tr>
<td>16384-32767</td>
<td>Reserved for Private Use</td>
<td colspan="2"></td>
</tr>
</tbody>
</table>
</li>
<li>
<t>IANA has created the "Group Key Bag Attributes" registry. The reg
istration policy for this registry is Expert Review <xref target="RFC8126"/>. Th
e initial values of the registry are as follows:
</t>
<table>
<name></name>
<thead>
<tr>
<th>Value</th>
<th>Group Key Bag Attributes</th>
<th>Format</th>
<th>Multi-Valued</th>
<th>Used in Protocol</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td colspan="3"></td>
</tr>
<tr>
<td>1</td>
<td>SA_KEY</td>
<td>TLV</td>
<td>YES<br/>NO</td>
<td>GIKE_UPDATE<br/>AH, ESP</td>
</tr>
<tr>
<td>2-16383</td>
<td>Unassigned</td>
<td colspan="3"></td>
</tr>
<tr>
<td>16384-32767</td>
<td>Reserved for Private Use</td>
<td colspan="3"></td>
</tr>
</tbody>
</table>
</li>
<li>
<t>IANA has created the "Member Key Bag Attributes" registry. The re
gistration policy for this registry is Expert Review <xref target="RFC8126"/>. T
he initial values of the registry are as follows:
</t>
<table>
<name></name>
<thead>
<tr>
<th>Value</th>
<th>Member Key Bag Attributes</th>
<th>Format</th>
<th>Multi-Valued</th>
</tr>
</thead>
<tbody>
<tr>
<td>0</td>
<td>Reserved</td>
<td colspan="2"></td>
</tr>
<tr>
<td>1</td>
<td>WRAP_KEY</td>
<td>TLV</td>
<td>YES</td>
</tr>
<tr>
<td>2</td>
<td>AUTH_KEY</td>
<td>TLV</td>
<td>NO</td>
</tr>
<tr>
<td>3</td>
<td>GM_SENDER_ID</td>
<td>TLV</td>
<td>YES</td>
</tr>
<tr>
<td>4-16383</td>
<td>Unassigned</td>
<td colspan="2"></td>
</tr>
<tr>
<td>16384-32767</td>
<td>Reserved for Private Use</td>
<td colspan="2"></td>
</tr>
</tbody>
</table>
</li>
</ol>
<section>
<name>Guidance for Designated Experts</name>
<t> In all cases of Expert Review described in this section,
the designated expert (DE) is expected to ascertain the existence of
suitable
documentation (a specification) as described in <xref target="RFC8126
"/> and
verify that the document is permanently and publicly available. The 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 the
requested code points. Last, the DE must verify that any specificatio n produced outside the IETF does not requested code points. Lastly, the DE must verify that any specificat ion produced outside the IETF does not
conflict with work that is active or already published within the IET F. conflict with work that is active or already published within the IET F.
</t> </t>
</section> </section>
</section> </section>
<section>
<section title="Changes in the Existing IKEv2 Registries"> <name>Changes in the Existing IKEv2 Registries</name>
<ol> <ol>
<li> <li>
<t>This document defines new Exchange Types in the "IKEv2 Exchange Types <t>In the "IKEv2 Exchange Types" registry, IANA has updated the references for
" registry: the following entries to point to this document and has registered "GSA_INBAND_R
<figure align="center"> EKEY":
<artwork align="left"><![CDATA[ </t>
Value Exchange Type <table>
39 GSA_AUTH <thead>
40 GSA_REGISTRATION <tr><th>Value</th><th>Exchange Type</th></tr>
41 GSA_REKEY </thead>
<TBA> GSA_INBAND_REKEY <tbody>
]]></artwork> <tr><td>39</td><td>GSA_AUTH</td></tr>
</figure> <tr><td>40</td><td>GSA_REGISTRATION</td></tr>
</t> <tr><td>41</td><td>GSA_REKEY</td></tr>
</li> <tr><td>42</td><td>GSA_INBAND_REKEY</td></tr>
</tbody>
</table>
<li> </li>
<t>This document defines new Payload Types in the "IKEv2 Payload Types" <li>
registry: <t>In the "IKEv2 Payload Types" registry, IANA has listed this docume
<figure align="center"> nt as a reference for the following entries:
<artwork align="left"><![CDATA[ </t>
Value Next Payload Type Notation
50 Group Identification IDg
51 Group Security Association GSA
52 Key Download KD
]]></artwork>
</figure>
</t>
</li>
<table>
<thead>
<tr>
<th>Value</th>
<th>Next Payload Type</th>
<th>Notation</th>
</tr>
</thead>
<tbody>
<tr>
<td>50</td>
<td>Group Identification</td>
<td>IDg</td>
</tr>
<tr>
<td>51</td>
<td>Group Security Association</td>
<td>GSA</td>
</tr>
<tr>
<td>52</td>
<td>Key Download</td>
<td>KD</td>
</tr>
</tbody>
</table>
</li>
<li> <li>
<t>This document also updates definition of Payload Type 33 in the "IKEv <t>In the "IKEv2 Payload Types" registry, IANA has updated the definitio
2 Payload n of Payload Type 33 and added a reference to this document as follows:</t>
Types" registry by adding an alternative name and notation for it refere
ncing
this document:
<figure align="center"> <table>
<artwork align="left"><![CDATA[ <thead>
Value Next Payload Type Notation <tr>
33 Security Association SA <th>Value</th>
Security Association - GM Supported Transforms SAg <th>Next Payload Type</th>
]]></artwork> <th>Notation</th>
</figure> <th>Reference</th>
</t> </tr>
</thead>
<tbody>
<tr>
<td rowspan="2">33</td>
<td>Security Association</td>
<td>SA</td>
<td><xref target="RFC7296"/></td>
</tr>
<tr>
<td>Security Association - GM Supported Transforms</td>
<td>SAg</td>
<td>RFC 9838</td>
</tr>
</tbody>
</table>
</li> </li>
<li> <li>
<t>This document makes the following changes in the "Transform Type Valu <t>In the "Transform Type Values" registry, IANA has made the following changes:
es" registry: </t>
<list style="symbols" >
<t>Defines two new transform types -- "Key Wrap Algorithm (KWA)" and "
Group Controller Authentication Method (GCAUTH)";</t>
<t>Changes the "Used In" column for the values 1 and 3 as follows;</t>
<t>Appends reference to this document to the values 1 and 3;</t>
</list>
<figure align="center">
<artwork align="left"><![CDATA[
Type Description Used In
1 Encryption Algorithm (ENCR) (IKE, GIKE_UPDATE and ESP)
3 Integrity Algorithm (INTEG) (IKE, GIKE_UPDATE, AH,
optional in ESP)
<TBA> Key Wrap Algorithm (KWA) (IKE, GIKE_UPDATE)
<TBA> Group Controller
Authentication Method (GCAUTH) (GIKE_UPDATE)
]]></artwork>
</figure>
</t>
</li>
<li> <ul spacing="normal">
<t>This document defines a new Attribute Type in the "IKEv2 Transform At <li>Registered "Key Wrap Algorithm (KWA)" and "Group Controller Au
tribute Types" registry: thentication Method (GCAUTH)".</li>
<figure align="center"> <li>
<artwork align="left"><![CDATA[ <t>Updated the "Used In" column for values 1 and 3 and listed th
Value Attribute Type Format is document as an additional reference.</t>
<TBA> Signature Algorithm Identifier TLV </li>
]]></artwork> </ul>
</figure>
</t>
</li>
<li> <table>
<t>This document defines a new value in the "Transform Type 5 - Sequence <thead>
Numbers Transform IDs" registry: <tr>
<figure align="center"> <th>Type</th>
<artwork align="left"><![CDATA[ <th>Description</th>
Number Name <th>Used In</th>
<TBA> 32-bit Unspecified Numbers </tr>
]]></artwork> </thead>
</figure> <tbody>
</t> <tr>
</li> <td>1</td>
<td>Encryption Algorithm (ENCR)</td>
<td>(IKE, GIKE_UPDATE, ESP)</td>
</tr>
<tr>
<td>3</td>
<td>Integrity Algorithm (INTEG)</td>
<td>(IKE, GIKE_UPDATE, AH, optional in ESP)</td>
</tr>
<tr>
<td>13</td>
<td>Key Wrap Algorithm (KWA)</td>
<td>(IKE, GIKE_UPDATE)</td>
</tr>
<tr>
<td>14</td>
<td>Group Controller Authentication Method (GCAUTH)</td>
<td>(GIKE_UPDATE)</td>
</tr>
</tbody>
</table>
<li> </li>
<t>This document defines new Notify Message types in the "IKEv2 Notify M <li>
essage Error Types" registry: <t>In the "IKEv2 Transform Attribute Types" registry, IANA has added
<figure align="center"> the following entry:
<artwork align="left"><![CDATA[ </t>
Value Notify Message Error Type
45 INVALID_GROUP_ID
46 AUTHORIZATION_FAILED
<TBA> REGISTRATION_FAILED
]]></artwork>
</figure>
</t>
</li>
<li> <table>
<t>The Notify type with the value 16429 was allocated earlier in the dev <thead>
elopment of G-IKEv2 document <tr>
in the "IKEv2 Notify Message Status Types" registry with the name SENDER <th>Value</th>
_REQUEST_ID. <th>Attribute Type</th>
This document renames it as follows: <th>Format</th>
<figure align="center"> </tr>
<artwork align="left"><![CDATA[ </thead>
Value Notify Message Status Type <tbody>
16429 GROUP_SENDER <tr>
]]></artwork> <td>18</td>
</figure> <td>Signature Algorithm Identifier</td>
</t> <td>TLV</td>
</li> </tr>
</tbody>
</table>
<li> </li>
<t>This document defines a new Security Protocol Identifier in the "IKEv <li>
2 Security Protocol Identifiers" registry: <t>In the "Transform Type 5 - Sequence Numbers Transform IDs" regist
<figure align="center"> ry, IANA has added the following entry:
<artwork align="left"><![CDATA[ </t>
Protocol ID Protocol
<TBA> GIKE_UPDATE
]]></artwork>
</figure>
</t>
</li>
</ol>
</section> <table>
</section> <thead>
<tr>
<th>Number</th>
<th>Name</th>
</tr>
</thead>
<tbody>
<tr>
<td>2</td>
<td>32-bit Unspecified Numbers</td>
</tr>
</tbody>
</table>
<section anchor="Acknowledgements" title="Acknowledgements"> </li>
<t>The authors thank Lakshminath Dondeti and Jing Xiang for first <li>
exploring the use of IKEv2 for group key management and providing the <t>In the "IKEv2 Notify Message Error Types" registry, IANA has made
basis behind the protocol. Mike Sullenberger and Amjad Inamdar were the following changes:
instrumental in helping resolve many issues in several versions of the </t>
document.</t> <ul>
<li>Registered "REGISTRATION_FAILED".</li>
<li>Updated the references for "INVALID_GROUP_ID" and "AUTHORIZATIO
N_FAILED" to point to this document.</li>
<t>The authors are grateful to Tero Kivinen, Daniel Migault, Gorry Fairhur </ul>
st, Robert Sparks, Russ Housley and Paul Wouters <table>
for their careful reviews and valuable proposals for improving the documen <thead>
t quality. <tr>
</t> <th>Value</th>
</section> <th>Notify Message Error Type</th>
</tr>
</thead>
<tbody>
<tr>
<td>45</td>
<td>INVALID_GROUP_ID</td>
</tr>
<tr>
<td>46</td>
<td>AUTHORIZATION_FAILED</td>
</tr>
<tr>
<td>49</td>
<td>REGISTRATION_FAILED</td>
</tr>
</tbody>
</table>
<section anchor="Contributers" title="Contributors"> </li>
<t>The following individuals made substantial contributions to early <li>
versions of this memo.</t> <t>An earlier draft of this document <xref target="I-D.yeung-g-ikev2
"/> registered the Notify
type 16429 in the "IKEv2 Notify Message Status Types" registry with
the name SENDER_REQUEST_ID. Per this document,
IANA has renamed it as follows:
</t>
<t><figure> <table>
<preamble></preamble> <thead>
<tr>
<th>Value</th>
<th>Notify Message Status Type</th>
</tr>
</thead>
<tbody>
<tr>
<td>16429</td>
<td>GROUP_SENDER</td>
</tr>
</tbody>
</table>
<artwork><![CDATA[ </li>
Sheela Rowles <li>
Cisco Systems <t>In the "IKEv2 Security Protocol Identifiers" registry, IANA has a
]]></artwork> dded the following entry:
</figure> </t>
<figure>
<artwork><![CDATA[ <table>
Aldous Yeung <thead>
Cisco Systems <tr>
Email: cyyeung@cisco.com <th>Protocol ID</th>
]]></artwork> <th>Protocol</th>
</figure> </tr>
<figure> </thead>
<artwork><![CDATA[ <tbody>
Paulina Tran <tr>
Cisco Systems <td>6</td>
]]></artwork> <td>GIKE_UPDATE</td>
</figure> </tr>
<figure> </tbody>
<artwork><![CDATA[ </table>
Yoav Nir
Dell EMC </li>
Email: ynir.ietf@gmail.com </ol>
]]></artwork> </section>
</figure></t>
</section> </section>
</middle> </middle>
<back>
<displayreference target="I-D.yeung-g-ikev2" to="G-IKEV2"/>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
054.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
296.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
301.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
302.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
303.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
427.xml"/>
<back> <!-- [RFC9827] draft-ietf-ipsecme-ikev2-rename-esn-05; companion doc RFC 9827 is
<references title="Normative References"> in AUTH48-DONE as of 09/11/25 and is waiting for this doc for PUB.
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.60 -->
54.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.72
96.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.43
01.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.43
02.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.43
03.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.21
19.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.81
74.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.81
26.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.52
80.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.74
27.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference
.I-D.ietf-ipsecme-ikev2-rename-esn.xml"?>
</references>
<references title="Informative References"> <reference anchor="RFC9827" target="https://www.rfc-editor.org/info/rfc9827">
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.24 <front>
09.xml"?> <title>Renaming the Extended Sequence Numbers (ESN) Transform Type in the In
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.26 ternet Key Exchange Protocol Version 2 (IKEv2)</title>
27.xml"?> <author initials="V." surname="Smyslov" fullname="Valery Smyslov">
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.37 <organization>ELVIS-PLUS</organization>
40.xml"?> </author>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.40 <date month='September' year='2025'/>
46.xml"?> </front>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.64 <seriesInfo name="RFC" value="9827"/>
07.xml"?> <seriesInfo name="DOI" value="10.17487/RFC9827"/>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.36 </reference>
86.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.41
06.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.43
09.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.45
43.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.53
74.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.56
85.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.59
98.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.57
23.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.64
67.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.73
83.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.76
34.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.87
84.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.39
48.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.92
42.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.93
29.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.87
50.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.93
47.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.93
70.xml"?>
<?rfc include="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference
.I-D.ietf-ipsecme-ikev2-qr-alt.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.80
52.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.82
63.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.56
49.xml"?>
<reference anchor="ARX-KW"
target="https://eprint.iacr.org/2020/059.pdf">
<front>
<title>ARX-KW, a family of key wrapping constructions using SipHash an
d ChaCha</title>
<author fullname="" initials="S." surname="Shinichi"></author>
<date month="January" year="2020" />
</front>
</reference>
<reference anchor="OFT"
target="https://pdfs.semanticscholar.org/d24c/7b41f7bcc2b6690e1
b4d80eaf8c3e1cc5ee5.pdf">
<front>
<title>Key Establishment in Large Dynamic Groups Using One-Way Functio
n Trees</title>
<author fullname="" initials="D." surname="McGrew">
<organization></organization>
</author>
<author fullname="" initials="A." surname="Sherman">
<organization></organization>
</author>
<date month="" year="1998" />
</front>
<seriesInfo name="Manuscript, "
value="submitted to IEEE Transactions on Software Engineerin
g" />
</reference>
<reference anchor="NNL"
target="http://www.wisdom.weizmann.ac.il/~naor/PAPERS/2nl.pdf">
<front>
<title>Revocation and Tracing Schemes for Stateless Receivers</title>
<author fullname="" initials="D." surname="Naor">
<organization></organization>
</author>
<author fullname="" initials="M." surname="Noal">
<organization></organization>
</author>
<author fullname="" initials="J." surname="Lotspiech">
<organization></organization>
</author>
<date month="" year="2001" />
</front>
<seriesInfo name="Advances in Cryptology, Crypto '01, "
value="Springer-Verlag LNCS 2139, 2001, pp. 41-62" />
</reference>
<reference anchor="IKEV2-IANA"
target="http://www.iana.org/assignments/ikev2-parameters/ikev2-
parameters.xhtml">
<front>
<title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
<author>
<organization>IANA</organization>
</author>
<date />
</front>
</reference>
</references>
<section anchor="lkh_key_management" title="Use of LKH in G-IKEv2"> </references>
<t>Section 5.4 of <xref target="RFC2627"></xref> describes the LKH <references>
architecture, and how a GCKS uses LKH to exclude group members. This <name>Informative References</name>
section clarifies how the LKH architecture is used with G-IKEv2.</t> <reference anchor="I-D.yeung-g-ikev2" target="https://datatracker.ietf.org/doc/h
tml/draft-yeung-g-ikev2-07">
<front>
<title>Group Key Management using IKEv2</title>
<author initials="S." surname="Rowles" fullname="Sheela Rowles"> </author>
<author initials="A." surname="Yeung" fullname="Aldous Yeung"> </author>
<author initials="P." surname="Tran" fullname="Paulina Tran"> </author>
<author initials="Y." surname="Nir" fullname="Yoav Nir"> </author>
<date month="November" day="5" year="2013"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-yeung-g-ikev2-07"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
409.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
627.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
740.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
046.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
407.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
686.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
106.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
309.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
543.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
374.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
685.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
998.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
723.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
467.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
383.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
634.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
784.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
948.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
242.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
329.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
750.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
347.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
370.xml"/>
<section anchor="lkh_notation" title="Notation"> <reference anchor="RFC9867" target="https://www.rfc-editor.org/info/rfc9867">
<t>In this section we will use the notation X{Y} <front>
<title>Mixing Preshared Keys in the IKE_INTERMEDIATE and CREATE_CHILD_SA Exc
hanges of the Internet Key Exchange Protocol Version 2 (IKEv2) for Post-Quantum
Security</title>
<author initials="V." surname="Smyslov" fullname="Valery Smyslov">
<organization>ELVIS-PLUS</organization>
</author>
<date month='October' year='2025'/>
</front>
<seriesInfo name="RFC" value="9867"/>
<seriesInfo name="DOI" value="10.17487/RFC9867"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
052.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
263.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
649.xml"/>
<reference anchor="ARX-KW" target="https://eprint.iacr.org/2020/059.pdf"
>
<front>
<title>ARX-KW, a family of key wrapping constructions using SipHash
and ChaCha</title>
<author fullname="" initials="S." surname="Shinichi"/>
<date month="January" year="2020"/>
</front>
<refcontent>Cryptology ePrint Archive, Paper 2020/059</refcontent>
</reference>
<reference anchor="OFT" target="https://pdfs.semanticscholar.org/d24c/7b
41f7bcc2b6690e1b4d80eaf8c3e1cc5ee5.pdf">
<front>
<title>Key Establishment in Large Dynamic Groups Using One-Way Funct
ion Trees</title>
<author fullname="" initials="D." surname="McGrew">
<organization/>
</author>
<author fullname="" initials="A." surname="Sherman">
<organization/>
</author>
<date month="May" year="1998"/>
</front>
<seriesInfo name="DOI" value="10.1109/TSE.2003.1199073"/>
<refcontent>IEEE Transactions on Software Engineering, vol. 29, no. 5,
pp. 444-458</refcontent>
</reference>
<reference anchor="NNL" target="http://www.wisdom.weizmann.ac.il/~naor/P
APERS/2nl.pdf">
<front>
<title>Revocation and Tracing Schemes for Stateless Receivers</title
>
<author fullname="" initials="D." surname="Naor">
<organization/>
</author>
<author fullname="" initials="M." surname="Naor">
<organization/>
</author>
<author fullname="" initials="J." surname="Lotspiech">
<organization/>
</author>
<date month="" year="2001"/>
</front>
<seriesInfo name="DOI" value="10.1007/3-540-44647-8_3"/>
<refcontent>Advances in Cryptology - CRYPTO 2001, Lecture Notes in Com
puter Science, vol. 2139, pp. 41-62</refcontent>
</reference>
<reference anchor="IKEV2-IANA" target="http://www.iana.org/assignments/i
kev2-parameters">
<front>
<title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
<author>
<organization>IANA</organization>
</author>
<date/>
</front>
</reference>
</references>
</references>
<section anchor="lkh_key_management">
<name>Use of LKH in G-IKEv2</name>
<t><xref target="RFC2627" sectionFormat="of" section="5.4"/> describes the
LKH
architecture and how a GCKS uses LKH to exclude GMs. This
section clarifies how the LKH architecture is used with G-IKEv2.</t>
<section anchor="lkh_notation">
<name>Notation</name>
<t>In this section, we will use the notation X{Y},
where a key with ID Y is encrypted with the key with ID X. where a key with ID Y is encrypted with the key with ID X.
The notation GSK_w{Y} means that the default wrap key GSK_w (with zero K WK ID)is used The notation GSK_w{Y} means that the default wrap key GSK_w (with zero K WK ID)is used
to encrypt key Y, and the notation X{K_sa} means key X is used to encrypt key Y, and the notation X{K_sa} means key X is used
to encrypt the SA key K_sa (wich always has zero Key ID). Note, that GSK to encrypt the SA key K_sa (which always has a Key ID of zero). Note tha
_w{K_sa} means that t GSK_w{K_sa} means that
the SA key is encrypted with the default wrap key, in which case both KW the SA key is encrypted with the default wrap key, in which case, both K
K ID and Key ID are zero. WK ID and Key ID are zero.
</t> </t>
<t>The content of the KD payload will be shown as a sequence <t>The content of the KD payload will be shown as a sequence
of key bags. The Group Key Bag substructure will be denoted as GP(SAn)() of key bags. The Group Key Bag substructure will be denoted as GP(SAn)()
, when n is an SPI for the SA and the Member Key Bag substructure
when n is an SPI for the SA, and the Member Key Bag substructure
will be denoted as MP(). The content of the key bags will be denoted as MP(). The content of the key bags
is shown as SA_KEY and WRAP_KEY attributes with the notation is shown as SA_KEY and WRAP_KEY attributes with the notation
described above. For simplicity the type of the attribute will not be sh own, described above. For simplicity, the type of the attribute will not be s hown
because it is implicitly defined by the type of key bag. because it is implicitly defined by the type of key bag.
</t> </t>
<t>Below is the example of a KD payload:</t>
<t> Here is the example of KD payload. <figure title="Example of a KD Payload">
<figure align="center"> <artwork><![CDATA[
<artwork align="center"><![CDATA[
KD(GP(SA1)(X{K_sa}),MP(Y{X},Z{Y},GSK_w{Z}) KD(GP(SA1)(X{K_sa}),MP(Y{X},Z{Y},GSK_w{Z})
]]></artwork> ]]></artwork>
</figure> </figure>
For simplicity any other attributes in the KD payload are omitted. <t>
For simplicity, any other attributes in the KD payload are omitted.
</t> </t>
<t>We will also use the notation X-&gt;Y-&gt;Z <t>We will also use the notation X-&gt;Y-&gt;Z
to describe the Key Path. In this case key Y is needed to decrypt key X to describe the Key Path. In this case, key Y is needed to decrypt key X
and key Z is needed to decrypt key Y. and key Z is needed to decrypt key Y.
In the example above the keys had the following relation: K_sa-&gt;X-&gt In the example above, the keys had the following relation: K_sa-&gt;X-&g
;Y-&gt;Z-&gt;GSK_w. t;Y-&gt;Z-&gt;GSK_w.
</t> </t>
</section> </section>
<section>
<section title="Group Creation"> <name>Group Creation</name>
<t>When a GCKS forms a group, it creates a key tree as shown in the <t>When a GCKS forms a group, it creates a key tree as shown in
figure below. The key tree contains logical keys (which are represented <xref target="initial-tree"/>. The key tree contains logical keys (which
as are represented as
the values of their Key IDs in the figure) and a private key shared with only a single GM the values of their Key IDs in the figure) and a private key shared with only a single GM
(the GMs are represented as letters followed by the corresponding (the GMs are represented as letters followed by the corresponding
key ID in parentheses in the figure). The root of the tree contains the key ID in parentheses in the figure). The root of the tree contains the
multicast Rekey SA key (which is represented as SAn(K_san). The figure b elow assumes that the Key IDs multicast Rekey SA key (which is represented as SAn(K_san). The figure b elow assumes that the Key IDs
are assigned sequentially; this is not a requirement and only used are assigned sequentially; this is not a requirement and only used
for illustrative purposes. The GCKS may create a complete tree as shown, or a partial tree which is for illustrative purposes. The GCKS may create a complete tree as shown or a partial tree, which is
created on demand as members join the group. created on demand as members join the group.
</t> </t>
<figure align="center" anchor="initial-tree" title="Initial LKH tree"> <figure anchor="initial-tree">
<artwork align="center"><![CDATA[ <name>Initial LKH Tree</name>
<artwork ><![CDATA[
SA1(K_sa1) SA1(K_sa1)
+------------------------------+ +------------------------------+
1 2 1 2
+---------------+ +---------------+ +---------------+ +---------------+
3 4 5 6 3 4 5 6
+-------+ +-------+ +--------+ +--------+ +-------+ +-------+ +--------+ +--------+
A(7) B(8) C(9) D(10) E(11) F(12) G(13) H(14) A(7) B(8) C(9) D(10) E(11) F(12) G(13) H(14)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>When GM A joins the group, the GCKS provides it <t>When GM A joins the group, the GCKS provides it
with the keys in the KD payload of the GSA_AUTH or with the keys in the KD payload of the GSA_AUTH or
GSA_REGISTRATION exchange. Given the tree shown in figure above, the GSA_REGISTRATION exchange. Given the tree shown in figure above, the
KD payload will be: KD payload will be:
<figure align="center" title="KD Payload for the Group Member A"> </t>
<artwork align="center"><![CDATA[ <figure>
<name>KD Payload for the Group Member A</name>
<artwork ><![CDATA[
KD(GP(SA1)(1{K_sa1}),MP(3{1},7{3},GSK_w{7}) KD(GP(SA1)(1{K_sa1}),MP(3{1},7{3},GSK_w{7})
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
From these attributes the GM A will construct From these attributes, the GM A will construct
the Key Path K_sa1-&gt;1-&gt;3-&gt;7-&gt;GSK_w and since it the Key Path K_sa1-&gt;1-&gt;3-&gt;7-&gt;GSK_w. Since it
ends up with GSK_w, it will use all the WRAP_KEY attributes ends up with GSK_w, it will use all the WRAP_KEY attributes
present in the path as its Working Key Path: 1-&gt;3-&gt;7. present in the path as its Working Key Path: 1-&gt;3-&gt;7.
</t> </t>
<t>Similarly, when other GMs join the group, they will be
provided with the corresponding keys and thus the GMs
will have the following Working Key Paths:
</t>
<t>Similarly, when other GMs will be joining the group they will be prov <figure title="Key Paths for all GMs">
ided with the corresponding <artwork align="left"><![CDATA[
keys, so after all the GMs will have the following Working Key Paths:
<figure align="center">
<artwork align="left"><![CDATA[
A: 1->3->7 B: 1->3->8 C: 1->4->9, D: 1->4->10 A: 1->3->7 B: 1->3->8 C: 1->4->9, D: 1->4->10
E: 2->5->11 F: 2->5->12 G: 2->6->13 H: 2->6->14 E: 2->5->11 F: 2->5->12 G: 2->6->13 H: 2->6->14
]]></artwork> ]]></artwork>
</figure> </figure>
</t>
</section>
<section title="Simple Group SA Rekey"> </section>
<section>
<name>Simple Group SA Rekey</name>
<t>If the GCKS performs a simple SA rekey without changing group members hip, <t>If the GCKS performs a simple SA rekey without changing group members hip,
it will only send group key bag in the KD payload with a new it will only send a Group Key Bag in the KD payload with a new
SA key encrypted with the default KWK. SA key encrypted with the default KWK.
</t>
<figure align="center" title="KD Payload for the Simple Group SA Rekey"> <figure>
<artwork align="center"><![CDATA[ <name>KD Payload for the Simple Group SA Rekey</name>
<artwork ><![CDATA[
KD(GP(SA2)(GSK_w{K_sa2})) KD(GP(SA2)(GSK_w{K_sa2}))
]]></artwork> ]]></artwork>
</figure> </figure>
<t>
All the GMs will be able to decrypt it and no changes in their Working K ey Paths will happen. All the GMs will be able to decrypt it and no changes in their Working K ey Paths will happen.
</t> </t>
</section> </section>
<section>
<section title="Group Member Exclusion"> <name>Group Member Exclusion</name>
<t>If the GKCS has reason to believe that a GM should be excluded, <t>If the GCKS has reason to believe that a GM should be excluded,
then it can do so by sending a GSA_REKEY message that includes a set then it can do so by sending a GSA_REKEY message that includes a set
of GM_KEY attributes which would allow all GMs except for the excluded o ne of GM_KEY attributes, which would allow all GMs, except for the excluded one,
to get a new SA key. to get a new SA key.
</t> </t>
<t>In the example below, the GCKS excludes GM F. For this purpose,
<t>In the example below the GCKS excludes GM F. For this purpose it changes the key tree as follows, replacing key 2 with key 15 and
it changes the key tree as follows, replacing the key 2 with the key 15 key 5 with key 16. It also generates a new SA key for a new SA3.
and
the key 5 with the key 16. It also generates a new SA key for a new SA3.
</t> </t>
<figure align="center" anchor="updated-tree" <figure anchor="updated-tree">
title="LKH tree after F has been excluded"> <name>LKH Tree after F Has Been Excluded</name>
<artwork align="center"><![CDATA[ <artwork ><![CDATA[
SA3(K_sa3) SA3(K_sa3)
+------------------------------+ +------------------------------+
1 15 1 15
+---------------+ +---------------+ +---------------+ +---------------+
3 4 16 6 3 4 16 6
+-------+ +-------+ +---- +--------+ +-------+ +-------+ +---- +--------+
A(7) B(8) C(9) D(10) E(11) F(12) G(13) H(14) A(7) B(8) C(9) D(10) E(11) F(12) G(13) H(14)
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Then it sends the following KD payload for the new Rekey SA3: <t>Then it sends the following KD payload for the new Rekey SA3:
</t>
<figure align="center" title="KD Payload for the Group Member F"> <figure>
<artwork align="center"><![CDATA[ <name>KD Payload for the Group Member F</name>
<artwork ><![CDATA[
KD(GP(SA3)(1{K_sa3},15{K_sa3}),MP(6{15},16{15},11{16}) KD(GP(SA3)(1{K_sa3},15{K_sa3}),MP(6{15},16{15},11{16})
]]></artwork> ]]></artwork>
</figure> </figure>
While processing this KD payload: <t>
<list style="symbols"> While processing this KD payload:</t>
<t>GMs A, B, C and D will be able to decrypt the SA_KEY attribute 1{K_ <ul spacing="normal">
sa3} by using <li>
<t>GMs A, B, C, and D will be able to decrypt the SA_KEY attribute 1
{K_sa3} by using
the "1" key from their key path. Since no new GM_KEY attributes are in the new the "1" key from their key path. Since no new GM_KEY attributes are in the new
Key Path, they won't update their Working Key Paths. Key Path, they won't update their Working Key Paths.
</t> </t>
<t>GMs G and H will construct new Key Path 15-&gt;6 and will be able t </li>
o decrypt <li>
the intermediate key 15 using the key 6 from their Working Key Paths. <t>GMs G and H will construct new Key Path 15-&gt;6 and will be able
So, they will to decrypt
update their Working Key Paths replacing their beginnings up to the ke the intermediate key 15 using key 6 from their Working Key Paths. So,
y 6 they will
update their Working Key Paths replacing their beginnings up to key 6
with the new Key Path (thus replacing the key 2 with the key 15). with the new Key Path (thus replacing the key 2 with the key 15).
</t> </t>
<t>GM E will construct new Key Path 16-&gt;15-&gt;11 and will be able </li>
to decrypt <li>
the intermediate key 16 using the key 11 from its Working Key Path. So <t>GM E will construct a new Key Path 16-&gt;15-&gt;11 and will be a
, it will ble to decrypt
update its Working Key Path replacing its beginnings up to the key 11 the intermediate key 16 using key 11 from its Working Key Path. So, it
with the new Key Path (thus replacing the key 2 with the key 15 and th will
e key 5 with the key 16). update its Working Key Path replacing its beginnings up to key 11
</t> with the new Key Path (thus replacing key 2 with key 15 and key 5 with
<t>GM F won't be able to construct any Key Path leading to any key he key 16).
possesses, </t>
so it will be unable to decrypt the new SA key for the SA3 and thus it </li>
will be excluded <li>
<t>GM F won't be able to construct any Key Path leading to any key i
t possesses,
so it will be unable to decrypt the new SA key for the SA3. Thus, it w
ill be excluded
from the group once the SA3 is used. from the group once the SA3 is used.
</t> </t>
</list> </li>
</ul>
<t>Finally, the GMs will have the following Working Key Paths:
</t> </t>
<t>Finally, the GMs will have the following Working Key Paths: <figure title="Key Paths for all GMs after Exclusion of a GM">
<figure align="center"> <artwork align="left"><![CDATA[
<artwork align="left"><![CDATA[
A: 1->3->7 B: 1->3->8 C: 1->4->9, D: 1->4->10 A: 1->3->7 B: 1->3->8 C: 1->4->9, D: 1->4->10
E: 15->16->11 F: excluded G: 15->6->13 H: 15->6->14 E: 15->16->11 F: excluded G: 15->6->13 H: 15->6->14
]]></artwork> ]]></artwork>
</figure> </figure>
</t>
</section> </section>
</section> </section>
<section anchor="Acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>The authors thank <contact fullname="Lakshminath Dondeti"/> and
<contact fullname="Jing Xiang"/> for first exploring the use of IKEv2
for group key management and providing the basis behind the
protocol. <contact fullname="Mike Sullenberger"/> and <contact
fullname="Amjad Inamdar"/> were instrumental in helping resolve many
issues in several draft versions of the document.</t>
<t>The authors are grateful to <contact fullname="Tero Kivinen"/>,
<contact fullname="Daniel Migault"/>, <contact fullname="Gorry
Fairhurst"/>, <contact fullname="Robert Sparks"/>, <contact
fullname="Russ Housley"/>, and <contact fullname="Paul Wouters"/> for
their careful reviews and valuable proposals for improving the document
quality.
</t>
</section>
<section anchor="Contributors" numbered="false">
<name>Contributors</name>
<t>The following individuals made substantial contributions to earlier
draft versions of this document.</t>
<contact fullname="Sheela Rowles">
<organization>Cisco Systems</organization>
</contact>
<contact fullname="Aldous Yeung">
<organization>Cisco Systems</organization>
<address>
<email>cyyeung@cisco.com</email>
</address>
</contact>
<contact fullname="Paulina Tran">
<organization>Cisco Systems</organization>
</contact>
<contact fullname="Yoav Nir">
<organization>Dell EMC</organization>
<address>
<email>ynir.ietf@gmail.com</email>
</address>
</contact>
</section>
<!-- [rfced] Abbreviations
a) FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
b) We note that some abbreviations are expanded multiple times
throughout the document. If there are no objections, we will update terms
to use their abbreviations after their first expansions for consistency.
One example (see the document for more examples):
-->
<!-- [rfced] Terminology
a) Please review the following terms for capitalization and let us know which
form you prefer (uppercase or lowercase) for consistency.
Data-Security vs. data-security
[Note: Only two instances of "data-security" are lowercase;
should they be uppercase?]
Key Bag vs. key bag
Key Wrap Algorithm vs. key wrap algorithm
Notify Message vs. Notify message vs. notify message
Security Association vs. security association
[Note: should the security association policy be uppercase
(e.g., "Security Association policy")?
b) We note that the following terms are used inconsistently. Please review and
let us know which form you prefer to use throughout the document.
Data-Security GSA TEK vs. GSA TEK vs. Data-Security SA policy (GSA TEK)
[Note: Are any of these terms the same?]
group key management vs. group key management protocol
Multicast Security (MSEC) Group Key Management Architecture vs.
Multicast Security (MSEC) key management architecture
c) FYI: We updated the text to reflect the forms on the right for consistency.
Please let us know of any objections.
G-IKEv2 Rekey -> G-IKEv2 rekey
GKCS -> GCKS
group key bag -> Group Key Bag
group security association -> Group Security Association
GSA Policy -> GSA policy=
IKEv2 Intermediate exchange -> IKEv2 Intermediate Exchange (per RFC 9242)
member Key Bag and member key bag -> Member Key Bag
NO_PROPOSAL_CHOSEN Notification -> NO_PROPOSAL_CHOSEN notification
protocol ID -> Protocol ID
Rekey message -> rekey message
rekey SA -> Rekey SA
Security Association Payload -> Security Association payload (per RFC 7296)
Secure Password authentication -> secure password authentication (per RFC 6467)
-->
<!-- [rfced] Some figures and tables were updated during the
formatting process and do not have titles. Would you like to add
titles to the figures and tables below for consistency throughout
the document? If so, please let us know the desired text.
Current:
Figure 10
Figure 15
Figure 16
Figure 24
Figure 27
Figure 31
Tables 3-8
Tables 11-25
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether the term "man-in-the-middle" should be
updated. -->
</back> </back>
</rfc> </rfc>
 End of changes. 604 change blocks. 
2753 lines changed or deleted 3169 lines changed or added

This html diff was produced by rfcdiff 1.48.