draft-ietf-ipsecme-g-ikev2-01.txt   draft-ietf-ipsecme-g-ikev2-02.txt 
Network Working Group V. Smyslov Network Working Group V. Smyslov
Internet-Draft ELVIS-PLUS Internet-Draft ELVIS-PLUS
Obsoletes: 6407 (if approved) B. Weis Obsoletes: 6407 (if approved) B. Weis
Intended status: Standards Track Independent Intended status: Standards Track Independent
Expires: January 14, 2021 July 13, 2020 Expires: July 15, 2021 January 11, 2021
Group Key Management using IKEv2 Group Key Management using IKEv2
draft-ietf-ipsecme-g-ikev2-01 draft-ietf-ipsecme-g-ikev2-02
Abstract Abstract
This document presents an extension to the Internet Key Exchange This document presents an extension to the Internet Key Exchange
version 2 (IKEv2) protocol for the purpose of a group key management. version 2 (IKEv2) protocol for the purpose of a group key management.
The protocol is in conformance with the Multicast Security (MSEC) key The protocol is in conformance with the Multicast Security (MSEC) key
management architecture, which contains two components: member management architecture, which contains two components: member
registration and group rekeying. Both components require a Group registration and group rekeying. Both components require a Group
Controller/Key Server to download IPsec group security associations Controller/Key Server to download IPsec group security associations
to authorized members of a group. The group members then exchange IP to authorized members of a group. The group members then exchange IP
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 14, 2021. This Internet-Draft will expire on July 15, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 26 skipping to change at page 2, line 26
1.2.2. IKEv2 Header Initialization . . . . . . . . . . . . . 6 1.2.2. IKEv2 Header Initialization . . . . . . . . . . . . . 6
1.3. G-IKEv2 Protocol . . . . . . . . . . . . . . . . . . . . 6 1.3. G-IKEv2 Protocol . . . . . . . . . . . . . . . . . . . . 6
1.3.1. G-IKEv2 Payloads . . . . . . . . . . . . . . . . . . 6 1.3.1. G-IKEv2 Payloads . . . . . . . . . . . . . . . . . . 6
1.4. G-IKEv2 Member Registration and Secure Channel 1.4. G-IKEv2 Member Registration and Secure Channel
Establishment . . . . . . . . . . . . . . . . . . . . . . 7 Establishment . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1. GSA_AUTH exchange . . . . . . . . . . . . . . . . . . 7 1.4.1. GSA_AUTH exchange . . . . . . . . . . . . . . . . . . 7
1.4.2. GSA_REGISTRATION Exchange . . . . . . . . . . . . . . 9 1.4.2. GSA_REGISTRATION Exchange . . . . . . . . . . . . . . 9
1.4.3. GM Registration Operations . . . . . . . . . . . . . 10 1.4.3. GM Registration Operations . . . . . . . . . . . . . 10
1.4.4. GCKS Registration Operations . . . . . . . . . . . . 12 1.4.4. GCKS Registration Operations . . . . . . . . . . . . 12
1.4.5. Group Maintenance Channel . . . . . . . . . . . . . . 13 1.4.5. Group Maintenance Channel . . . . . . . . . . . . . . 13
1.4.6. Counter-based modes of operation . . . . . . . . . . 20 1.4.6. Counter-based modes of operation . . . . . . . . . . 21
2. Group Key Management and Access Control . . . . . . . . . . . 22 2. Group Key Management and Access Control . . . . . . . . . . . 23
2.1. Key Wrap Keys . . . . . . . . . . . . . . . . . . . . . . 23 2.1. Key Wrap Keys . . . . . . . . . . . . . . . . . . . . . . 23
2.1.1. Default Key Wrap Key . . . . . . . . . . . . . . . . 23 2.1.1. Default Key Wrap Key . . . . . . . . . . . . . . . . 24
2.2. GCKS Key Management Semantics . . . . . . . . . . . . . . 23 2.2. GCKS Key Management Semantics . . . . . . . . . . . . . . 24
2.2.1. Forward Access Control Requirements . . . . . . . . . 24 2.2.1. Forward Access Control Requirements . . . . . . . . . 25
2.3. GM Key Management Semantics . . . . . . . . . . . . . . . 25 2.3. GM Key Management Semantics . . . . . . . . . . . . . . . 25
2.4. Group SA Keys . . . . . . . . . . . . . . . . . . . . . . 26 2.4. Group SA Keys . . . . . . . . . . . . . . . . . . . . . . 27
3. Header and Payload Formats . . . . . . . . . . . . . . . . . 27 3. Header and Payload Formats . . . . . . . . . . . . . . . . . 28
3.1. G-IKEv2 Header . . . . . . . . . . . . . . . . . . . . . 27 3.1. G-IKEv2 Header . . . . . . . . . . . . . . . . . . . . . 28
3.2. Group Identification Payload . . . . . . . . . . . . . . 27 3.2. Group Identification Payload . . . . . . . . . . . . . . 28
3.3. Security Association - GM Supported Transforms Payload . 27 3.3. Security Association - GM Supported Transforms Payload . 28
3.4. Group Security Association Payload . . . . . . . . . . . 28 3.4. Group Security Association Payload . . . . . . . . . . . 28
3.4.1. Group Policies . . . . . . . . . . . . . . . . . . . 28 3.4.1. Group Policies . . . . . . . . . . . . . . . . . . . 29
3.4.2. Group Security Association Policy Substructure . . . 29 3.4.2. Group Security Association Policy Substructure . . . 30
3.4.3. Group Associated Policy Substructure . . . . . . . . 35 3.4.3. Group Associated Policy Substructure . . . . . . . . 35
3.5. Key Download Payload . . . . . . . . . . . . . . . . . . 37 3.5. Key Download Payload . . . . . . . . . . . . . . . . . . 37
3.5.1. Wrapped Key Format . . . . . . . . . . . . . . . . . 37 3.5.1. Wrapped Key Format . . . . . . . . . . . . . . . . . 38
3.5.2. Group Key Packet Substructure . . . . . . . . . . . . 39 3.5.2. Group Key Packet Substructure . . . . . . . . . . . . 39
3.5.3. Member Key Packet Substructure . . . . . . . . . . . 40 3.5.3. Member Key Packet Substructure . . . . . . . . . . . 41
3.6. Delete Payload . . . . . . . . . . . . . . . . . . . . . 43 3.6. Delete Payload . . . . . . . . . . . . . . . . . . . . . 44
3.7. Notify Payload . . . . . . . . . . . . . . . . . . . . . 43 3.7. Notify Payload . . . . . . . . . . . . . . . . . . . . . 44
3.7.1. USE_TRANSPORT_MODE Notification . . . . . . . . . . . 44 3.7.1. USE_TRANSPORT_MODE Notification . . . . . . . . . . . 45
3.8. Authentication Payload . . . . . . . . . . . . . . . . . 45 3.8. Authentication Payload . . . . . . . . . . . . . . . . . 45
4. Interaction with other IKEv2 Protocol Extensions . . . . . . 45 4. Interaction with other IKEv2 Protocol Extensions . . . . . . 46
4.1. Mixing Preshared Keys in IKEv2 for Post-quantum Security 45 4.1. Mixing Preshared Keys in IKEv2 for Post-quantum Security 46
5. Security Considerations . . . . . . . . . . . . . . . . . . . 47 5. Security Considerations . . . . . . . . . . . . . . . . . . . 48
5.1. GSA Registration and Secure Channel . . . . . . . . . . . 47 5.1. GSA Registration and Secure Channel . . . . . . . . . . . 48
5.2. GSA Maintenance Channel . . . . . . . . . . . . . . . . . 47 5.2. GSA Maintenance Channel . . . . . . . . . . . . . . . . . 48
5.2.1. Authentication/Authorization . . . . . . . . . . . . 47 5.2.1. Authentication/Authorization . . . . . . . . . . . . 48
5.2.2. Confidentiality . . . . . . . . . . . . . . . . . . . 47 5.2.2. Confidentiality . . . . . . . . . . . . . . . . . . . 48
5.2.3. Man-in-the-Middle Attack Protection . . . . . . . . . 48 5.2.3. Man-in-the-Middle Attack Protection . . . . . . . . . 48
5.2.4. Replay/Reflection Attack Protection . . . . . . . . . 48 5.2.4. Replay/Reflection Attack Protection . . . . . . . . . 49
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
6.1. New Registries . . . . . . . . . . . . . . . . . . . . . 48 6.1. New Registries . . . . . . . . . . . . . . . . . . . . . 49
6.2. Changes in the Existing IKEv2 Registries . . . . . . . . 50 6.2. Changes in the Existing IKEv2 Registries . . . . . . . . 51
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 51 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 51 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
9.1. Normative References . . . . . . . . . . . . . . . . . . 52 9.1. Normative References . . . . . . . . . . . . . . . . . . 53
9.2. Informative References . . . . . . . . . . . . . . . . . 53 9.2. Informative References . . . . . . . . . . . . . . . . . 54
Appendix A. Use of LKH in G-IKEv2 . . . . . . . . . . . . . . . 56 Appendix A. Use of LKH in G-IKEv2 . . . . . . . . . . . . . . . 57
A.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 56 A.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 57
A.2. Group Creation . . . . . . . . . . . . . . . . . . . . . 56 A.2. Group Creation . . . . . . . . . . . . . . . . . . . . . 57
A.3. Simple Group SA Rekey . . . . . . . . . . . . . . . . . . 57 A.3. Simple Group SA Rekey . . . . . . . . . . . . . . . . . . 58
A.4. Group Member Exclusion . . . . . . . . . . . . . . . . . 58 A.4. Group Member Exclusion . . . . . . . . . . . . . . . . . 59
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
1. Introduction and Overview 1. Introduction and Overview
A group key management protocol provides IPsec keys and policy to a A group key management protocol provides IPsec keys and policy to a
set of IPsec devices which are authorized to communicate using a set of IPsec devices which are authorized to communicate using a
Group Security Association (GSA) defined in [RFC3740]. The data Group Security Association (GSA) defined in [RFC3740]. The data
communications within the group (e.g., IP multicast packets) are communications within the group (e.g., IP multicast packets) are
protected by a key pushed to the group members (GMs) by the Group protected by a key pushed to the group members (GMs) by the Group
Controller/Key Server (GCKS). This document presents an extension to Controller/Key Server (GCKS). This document presents an extension to
IKEv2 [RFC7296] called G-IKEv2, that allows to perform a group key IKEv2 [RFC7296] called G-IKEv2, that allows to perform a group key
skipping to change at page 10, line 34 skipping to change at page 10, line 34
SENDER Notify payload status. The SENDER not only signifies that it SENDER Notify payload status. The SENDER not only signifies that it
is a sender, but provides the initiator the ability to request is a sender, but provides the initiator 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 cipher. Section 1.4.6) includes guidance on requesting Sender- mode cipher. Section 1.4.6) includes guidance on requesting Sender-
ID values. ID values.
A GM may be limited in the types of Transforms that it is able or A GM may be limited in the types of Transforms that it is able or
willing to use, and may find it useful to inform the GCKS which willing to use, and may find it useful to inform the GCKS which
Transforms it is willing to accept for different security protocols. Transforms it is willing to accept for different security protocols.
Proposals for Rekey SA (with protocol GIKE_REKEY) and for data Proposals for Rekey SA (with protocol GIKE_REKEY) and for data
security (AH and/or ESP) SAs may be included into SAg. Each Proposal security (AH [RFC4302] and/or ESP [RFC4303]) SAs may be included into
contains a list of Transforms that the GM is able to support for that SAg. Each Proposal contains a list of Transforms that the GM is able
protocol. Valid transform types depend on the protocol and are to support for that protocol. Valid transform types depend on the
defined in Figure 15. Other transform types SHOULD NOT be included. protocol and are defined in Figure 15. Other transform types SHOULD
The SPI length of each Proposal in an SAg is set to zero, and thus NOT be included. The SPI length of each Proposal in an SAg is set to
the SPI field is empty. The GCKS MUST ignore SPI field in the SAg zero, and thus the SPI field is empty. The GCKS MUST ignore SPI
payload. field in the SAg payload.
Generally, a single Proposal of each type will suffice, because the Generally, a single Proposal of each type will suffice, because the
group member is not negotiating Transform sets, simply alerting the group member is not negotiating Transform sets, simply alerting the
GCKS to restrictions it may have. In particular, the restriction GCKS to restrictions it may have. In particular, the restriction
from Section 3.3 of [RFC7296] that AEAD and non-AEAD transforms must from Section 3.3 of [RFC7296] that AEAD and non-AEAD transforms must
not be combined in a single proposal doesn't hold when the SAg not be combined in a single proposal doesn't hold when the SAg
payload is being formed. However if the GM has restrictions on payload is being formed. However if the GM has restrictions on
combination of algorithms, this can be expressed by sending several combination of algorithms, this can be expressed by sending several
proposals. proposals.
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 data security (AH and/or ESP) SAs are dependent. In
particular, Proposals of different types having the same value in
Proposal Num field are treated as a set, so that if GCKS uses
transforms from one of such Proposal for one protocol, then it MUST
only use transforms from one of the Proposals with the same value in
Proposal Num field for other protocols. 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 SA, then only X can be
used in data security SAs, and the same for Y. To indicate this the
GM sends several Proposals marking those of them that must be used in
conjunction by putting the same value in their Proposal Num field.
In the simplest case when no dependency between transforms exists,
all Proposals in SAg payload will have the same value in Proposal Num
field.
Although the SAg payload is optional, it is RECOMMENDED for the GM to Although the SAg payload is optional, it is RECOMMENDED for the GM to
include this payload into the GSA_AUTH request to allow the GCKS to include this payload into the GSA_AUTH request to allow the GCKS to
select an appropriate policy. select an appropriate policy.
A GM may also indicate the support for IPcomp by inclusion one or A GM may also indicate the support for IPcomp by inclusion one or
more the IPCOMP_SUPPORTED notifications along with the SAg payload. more the IPCOMP_SUPPORTED notifications along with the SAg payload.
The CPI in these notifications is set to zero and MUST be ignored by The CPI in these notifications is set to zero and MUST be ignored by
the GCKS. the GCKS.
Upon receiving the GSA_AUTH response, the initiator parses the Upon receiving the GSA_AUTH response, the initiator parses the
skipping to change at page 16, line 29 skipping to change at page 17, line 17
| G-IKEv2 SA Initiator's SPI | | | | G-IKEv2 SA Initiator's SPI | | |
| | | | | | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I |
| G-IKEv2 SA Responder's SPI | K | | G-IKEv2 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |
| AdjustedLeng | | | | AdjustedLen | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ x |
| Next Payload |C| RESERVED | AdjustedPldLen | | | | Next Payload |C| RESERVED | AdjustedPldLen | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v
| Initialization Vector | n | | |
~ Initialization Vector ~ E
| | 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
Figure 10: Data to Authenticate in the GSA_REKEY Messages Figure 10: Data to Authenticate in the GSA_REKEY Messages
The authentication data is calculated using the authentication The authentication data is calculated using the authentication
algorithm from the Authentication Method transform and the key algorithm from the Authentication Method transform and the key
provided before in the AUTH_KEY attribute. Depending on the provided before in the AUTH_KEY attribute. Depending on the
authentication method the authentication data is either a digital authentication method the authentication data is either a digital
signature or a result of applying prf from the Pseudorandom Function signature or a result of applying prf from the Pseudorandom Function
transform. The calculated authentication data is placed into the transform. The calculated authentication data is placed into the
skipping to change at page 32, line 8 skipping to change at page 32, line 19
are used. In addition, new transform types are defined for using in are used. In addition, new transform types are defined for using in
G-IKEv2: Authentication Method (AUTH) and Group Key Management Method G-IKEv2: Authentication Method (AUTH) and Group Key Management Method
(GKM), see Section 6. (GKM), see Section 6.
Valid Transform Types depend on group SA protocol and are summarized Valid Transform Types depend on group SA protocol and are summarized
in the table below. in the table below.
Protocol Mandatory Types Optional Types Protocol Mandatory Types Optional Types
---------------------------------------------------------- ----------------------------------------------------------
GIKE_REKEY ENCR, INTEG*, PRF, AUTH, GKM GIKE_REKEY ENCR, INTEG*, PRF, AUTH, GKM
ESP ENCR INTEG ESP ENCR INTEG, ESN
AH INTEG AH INTEG ESN
Figure 15: Valid Transform Types Figure 15: Valid Transform Types
(*) If AEAD encryption algorithm is used, then INTEG transform MUST (*) If AEAD encryption algorithm is used, then INTEG transform MUST
NOT be specified, otherwise it MUST be specified. NOT be specified, otherwise it MUST be specified.
3.4.2.1.1. Authentication Method Transform 3.4.2.1.1. Authentication Method Transform
The Authentication Method (AUTH) transform is used in the GIKE_REKEY The Authentication Method (AUTH) transform is used in the GIKE_REKEY
policy to convey information of how GCKS will authenticate the policy to convey information of how GCKS will authenticate the
skipping to change at page 33, line 32 skipping to change at page 33, line 43
Wrapped Key Download (<TBA by IANA>) - Keys are downloaded by GCKS Wrapped Key Download (<TBA by IANA>) - Keys are downloaded by GCKS
to the GMs in encrypted form. This algorithm may provide forward to the GMs in encrypted form. This algorithm may provide forward
and backward access control if some form of key hierarchy is used and backward access control if some form of key hierarchy is used
and each GM is provided with a personal key at the time of and each GM is provided with a personal key at the time of
registration. Otherwise no access control is provided. registration. Otherwise no access control is provided.
The type of the Group Key Management Method transform is <TBA by The type of the Group Key Management Method transform is <TBA by
IANA>. IANA>.
3.4.2.1.3. Extended Sequence Number Transform
Extended Sequence Number (ESN) Transform is defined in [RFC7296] to
allow using 64-bit sequence numbers in ESP and AH. Since both AH
[RFC4302] and ESP [RFC4303] are defined so, that high-order 32 bits
of extended sequence numbers are never transferred on the wire, it
makes using ESN in multicast data security SAs problematic, because
GMs that join group long after it is created will have to somehow
learn the current high order 32 bits of ESN for each sender in the
group. The algorithm for doing this described in [RFC4302] and
[RFC4303] is resource-consuming. For this reason extended sequence
numbers SHOULD NOT be used for multicast data security SAs and thus
the ESN Transform SHOULD NOT be included in the GSA Payload.
3.4.2.2. GSA Attributes 3.4.2.2. GSA Attributes
GSA attributes are generally used to provide GMs with additional GSA attributes are generally used to provide GMs with additional
parameters for the GSA policy. Unlike security parameters parameters for the GSA policy. Unlike security parameters
distributed via transforms, which are expected not to change over distributed via transforms, which are expected not to change over
time (unless policy changes), the parameters distributed via GSA time (unless policy changes), the parameters distributed via GSA
attributes may depend on the time the distribution takes place, on attributes may depend on the time the provision takes place, on the
the existence of others group SAs or on other conditions. existence of others group SAs or on other conditions.
This document creates a new IKEv2 IANA registry for the types of the This document creates a new IKEv2 IANA registry for the types of the
GSA attributes which is initially filled as described in Section 6. GSA attributes which is initially filled as described in Section 6.
In particular, the following attributes are initially added. In particular, the following attributes are initially added.
GSA Attributes Value Type Multiple Used In GSA Attributes Value Type Multiple Used In
--------------------------------------------------------------------- ---------------------------------------------------------------------
Reserved 0 Reserved 0
GSA_KEY_LIFETIME 1 V N (GIKE_REKEY, AH, ESP) GSA_KEY_LIFETIME 1 V N (GIKE_REKEY, AH, ESP)
GSA_INITIAL_MESSAGE_ID 2 V N (GIKE_REKEY) GSA_INITIAL_MESSAGE_ID 2 V N (GIKE_REKEY)
skipping to change at page 43, line 4 skipping to change at page 43, line 38
authentication then the content of the AUTH_KEY attribute is the authentication then the content of the AUTH_KEY attribute is the
shared secret that MUST be represented in the form of Wrapped Key shared secret that MUST be represented in the form of Wrapped Key
(see Section 3.5.1) with zero KWK ID. The Key ID in this case is (see Section 3.5.1) with zero KWK ID. The Key ID in this case is
arbitrary and MUST be ignored by the GM. arbitrary and MUST be ignored by the GM.
o If digital signatures are used for the GSA_REKEY messages o If digital signatures are used for the GSA_REKEY messages
authentication then the content of the AUTH_KEY attribute is a authentication then the content of the AUTH_KEY attribute is a
public key used for digital signature authentication. The public public key used for digital signature authentication. The public
key MUST be represented as DER-encoded ASN.1 object key MUST be represented as DER-encoded ASN.1 object
SubjectPublicKeyInfo, defined in section 4.1.2.7 of [RFC5280]. SubjectPublicKeyInfo, defined in section 4.1.2.7 of [RFC5280].
The signature algorithm that will use this key was specified in The signature algorithm that will use this key was specified in
the Algorithm Identifier attribute of the Authentication Method the Algorithm Identifier attribute of the Authentication Method
transform. The key MUST be compatible with this algorithm. An transform. The key MUST be compatible with this algorithm. An
RSA public key format is defined in [RFC3447], Section A.1. DSS RSA public key format is defined in [RFC8017], Section A.1. DSS
public key format is defined in [RFC3279] Section 2.3.2. For public key format is defined in [RFC3279] Section 2.3.2. For
ECDSA Public keys, use format described in [RFC5480] Section 2. ECDSA Public keys, use format described in [RFC5480] Section 2.
Other algorithms added to the IKEv2 Authentication Method registry Other algorithms added to the IKEv2 Authentication Method registry
are also expected to include a format of the SubjectPublicKeyInfo are also expected to include a format of the SubjectPublicKeyInfo
object included in the algorithm specification. object included in the algorithm specification.
Multiple instances of the AUTH_KEY attributes MUST NOT be sent. Multiple instances of the AUTH_KEY attributes MUST NOT be sent.
3.6. Delete Payload 3.6. Delete Payload
skipping to change at page 52, line 39 skipping to change at page 53, line 39
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627,
DOI 10.17487/RFC2627, June 1999,
<https://www.rfc-editor.org/info/rfc2627>.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004,
<https://www.rfc-editor.org/info/rfc3740>.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005,
<https://www.rfc-editor.org/info/rfc4046>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <https://www.rfc-editor.org/info/rfc4301>. December 2005, <https://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with [RFC6054] McGrew, D. and B. Weis, "Using Counter Modes with
Encapsulating Security Payload (ESP) and Authentication Encapsulating Security Payload (ESP) and Authentication
Header (AH) to Protect Group Traffic", RFC 6054, Header (AH) to Protect Group Traffic", RFC 6054,
DOI 10.17487/RFC6054, November 2010, DOI 10.17487/RFC6054, November 2010,
<https://www.rfc-editor.org/info/rfc6054>. <https://www.rfc-editor.org/info/rfc6054>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in
the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
DOI 10.17487/RFC7427, January 2015,
<https://www.rfc-editor.org/info/rfc7427>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-ipsecme-ikev2-multiple-ke] [I-D.ietf-ipsecme-ikev2-multiple-ke]
Tjhai, C., Tomlinson, M., grbartle@cisco.com, g., Fluhrer, Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S.,
S., Geest, D., Garcia-Morchon, O., and V. Smyslov, Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple
"Multiple Key Exchanges in IKEv2", draft-ietf-ipsecme- Key Exchanges in IKEv2", draft-ietf-ipsecme-ikev2-
ikev2-multiple-ke-00 (work in progress), January 2020. multiple-ke-02 (work in progress), January 2021.
[I-D.smyslov-ipsecme-ikev2-qr-alt] [I-D.smyslov-ipsecme-ikev2-qr-alt]
Smyslov, V., "Alternative Approach for Mixing Preshared Smyslov, V., "Alternative Approach for Mixing Preshared
Keys in IKEv2 for Post-quantum Security", draft-smyslov- Keys in IKEv2 for Post-quantum Security", draft-smyslov-
ipsecme-ikev2-qr-alt-01 (work in progress), February 2020. ipsecme-ikev2-qr-alt-02 (work in progress), August 2020.
[IKEV2-IANA] [IKEV2-IANA]
IANA, "Internet Key Exchange Version 2 (IKEv2) IANA, "Internet Key Exchange Version 2 (IKEv2)
Parameters", <http://www.iana.org/assignments/ikev2- Parameters", <http://www.iana.org/assignments/ikev2-
parameters/ikev2-parameters.xhtml#ikev2-parameters-7>. parameters/ikev2-parameters.xhtml#ikev2-parameters-7>.
[NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and [NNL] Naor, D., Noal, M., and J. Lotspiech, "Revocation and
Tracing Schemes for Stateless Receivers", Advances in Tracing Schemes for Stateless Receivers", Advances in
Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001, Cryptology, Crypto '01, Springer-Verlag LNCS 2139, 2001,
pp. 41-62, 2001, pp. 41-62, 2001,
skipping to change at page 54, line 21 skipping to change at page 55, line 21
[OFT] McGrew, D. and A. Sherman, "Key Establishment in Large [OFT] McGrew, D. and A. Sherman, "Key Establishment in Large
Dynamic Groups Using One-Way Function Trees", Manuscript, Dynamic Groups Using One-Way Function Trees", Manuscript,
submitted to IEEE Transactions on Software Engineering, submitted to IEEE Transactions on Software Engineering,
1998, <https://pdfs.semanticscholar.org/ 1998, <https://pdfs.semanticscholar.org/
d24c/7b41f7bcc2b6690e1b4d80eaf8c3e1cc5ee5.pdf>. d24c/7b41f7bcc2b6690e1b4d80eaf8c3e1cc5ee5.pdf>.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998, (IKE)", RFC 2409, DOI 10.17487/RFC2409, November 1998,
<https://www.rfc-editor.org/info/rfc2409>. <https://www.rfc-editor.org/info/rfc2409>.
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
Multicast: Issues and Architectures", RFC 2627,
DOI 10.17487/RFC2627, June 1999,
<https://www.rfc-editor.org/info/rfc2627>.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
2002, <https://www.rfc-editor.org/info/rfc3279>. 2002, <https://www.rfc-editor.org/info/rfc3279>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <https://www.rfc-editor.org/info/rfc3447>.
[RFC3686] Housley, R., "Using Advanced Encryption Standard (AES) [RFC3686] Housley, R., "Using Advanced Encryption Standard (AES)
Counter Mode With IPsec Encapsulating Security Payload Counter Mode With IPsec Encapsulating Security Payload
(ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004, (ESP)", RFC 3686, DOI 10.17487/RFC3686, January 2004,
<https://www.rfc-editor.org/info/rfc3686>. <https://www.rfc-editor.org/info/rfc3686>.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004,
<https://www.rfc-editor.org/info/rfc3740>.
[RFC4046] Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm,
"Multicast Security (MSEC) Group Key Management
Architecture", RFC 4046, DOI 10.17487/RFC4046, April 2005,
<https://www.rfc-editor.org/info/rfc4046>.
[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode [RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
(GCM) in IPsec Encapsulating Security Payload (ESP)", (GCM) in IPsec Encapsulating Security Payload (ESP)",
RFC 4106, DOI 10.17487/RFC4106, June 2005, RFC 4106, DOI 10.17487/RFC4106, June 2005,
<https://www.rfc-editor.org/info/rfc4106>. <https://www.rfc-editor.org/info/rfc4106>.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)", Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, DOI 10.17487/RFC4309, December 2005, RFC 4309, DOI 10.17487/RFC4309, December 2005,
<https://www.rfc-editor.org/info/rfc4309>. <https://www.rfc-editor.org/info/rfc4309>.
skipping to change at page 55, line 34 skipping to change at page 56, line 44
[RFC6467] Kivinen, T., "Secure Password Framework for Internet Key [RFC6467] Kivinen, T., "Secure Password Framework for Internet Key
Exchange Version 2 (IKEv2)", RFC 6467, Exchange Version 2 (IKEv2)", RFC 6467,
DOI 10.17487/RFC6467, December 2011, DOI 10.17487/RFC6467, December 2011,
<https://www.rfc-editor.org/info/rfc6467>. <https://www.rfc-editor.org/info/rfc6467>.
[RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2 [RFC7383] Smyslov, V., "Internet Key Exchange Protocol Version 2
(IKEv2) Message Fragmentation", RFC 7383, (IKEv2) Message Fragmentation", RFC 7383,
DOI 10.17487/RFC7383, November 2014, DOI 10.17487/RFC7383, November 2014,
<https://www.rfc-editor.org/info/rfc7383>. <https://www.rfc-editor.org/info/rfc7383>.
[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in
the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
DOI 10.17487/RFC7427, January 2015,
<https://www.rfc-editor.org/info/rfc7427>.
[RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the [RFC7634] Nir, Y., "ChaCha20, Poly1305, and Their Use in the
Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634, Internet Key Exchange Protocol (IKE) and IPsec", RFC 7634,
DOI 10.17487/RFC7634, August 2015, DOI 10.17487/RFC7634, August 2015,
<https://www.rfc-editor.org/info/rfc7634>. <https://www.rfc-editor.org/info/rfc7634>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>. August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov,
"Mixing Preshared Keys in the Internet Key Exchange "Mixing Preshared Keys in the Internet Key Exchange
Protocol Version 2 (IKEv2) for Post-quantum Security", Protocol Version 2 (IKEv2) for Post-quantum Security",
RFC 8784, DOI 10.17487/RFC8784, June 2020, RFC 8784, DOI 10.17487/RFC8784, June 2020,
<https://www.rfc-editor.org/info/rfc8784>. <https://www.rfc-editor.org/info/rfc8784>.
 End of changes. 35 change blocks. 
90 lines changed or deleted 132 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/