draft-ietf-ipsecme-g-ikev2-02.txt   draft-ietf-ipsecme-g-ikev2-03.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: July 15, 2021 January 11, 2021 Expires: January 13, 2022 July 12, 2021
Group Key Management using IKEv2 Group Key Management using IKEv2
draft-ietf-ipsecme-g-ikev2-02 draft-ietf-ipsecme-g-ikev2-03
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 July 15, 2021. This Internet-Draft will expire on January 13, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 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
skipping to change at page 9, line 45 skipping to change at page 9, line 45
Section 1.4.1. Section 1.4.1.
Initiator (Member) Responder (GCKS) Initiator (Member) Responder (GCKS)
-------------------- ------------------ -------------------- ------------------
HDR, SK{IDg, [SAg,] [N]} --> HDR, SK{IDg, [SAg,] [N]} -->
<-- HDR, SK{N} <-- HDR, SK{N}
Figure 7: GSA_REGISTRATION Error Exchange Figure 7: GSA_REGISTRATION Error Exchange
This exchange can also be used if the group member finds the policy This exchange can also be used if the group member finds the policy
sent by the GCKS is unacceptable or for some reason wants to sent by the GCKS is unacceptable or for some reason wants to leave
unregister itself from the group. The group member SHOULD notify the the group. The group member SHOULD notify the GCKS by sending IDg
GCKS by sending IDg and the Notify type NO_PROPOSAL_CHOSEN or and the Notify type NO_PROPOSAL_CHOSEN or REGISTRATION_FAILED, as
REGISTRATION_FAILED, as shown below. The GCKS MUST unregister the shown below. The GCKS in this case MUST remove the GM from the group
group member. IDg.
Initiator (Member) Responder (GCKS) Initiator (Member) Responder (GCKS)
-------------------- ------------------ -------------------- ------------------
HDR, SK{IDg, N} --> HDR, SK{IDg, N} -->
<-- HDR, SK{} <-- HDR, SK{}
Figure 8: GM Reporting Errors in GSA_REGISTRATION Exchange Figure 8: GM Reporting Errors in GSA_REGISTRATION Exchange
1.4.3. GM Registration Operations 1.4.3. GM Registration Operations
A G-IKEv2 Initiator (GM) requesting registration contacts the GCKS A G-IKEv2 Initiator (GM) requesting registration contacts the GCKS
using the IKE_SA_INIT exchange and receives the response from the using the IKE_SA_INIT exchange and receives the response from the
GCKS. This exchange is unchanged from the IKE_SA_INIT in IKEv2 GCKS. This exchange is unchanged from the IKE_SA_INIT in IKEv2
protocol. protocol.
Upon completion of parsing and verifying the IKE_SA_INIT response, Upon completion of parsing and verifying the IKE_SA_INIT response,
the GM sends the GSA_AUTH message with the IKEv2 payloads from the GM sends the GSA_AUTH message with the IKEv2 payloads from
IKE_AUTH (without the SAi2, TSi and TSr payloads) along with the IKE_AUTH (without the SAi2, TSi and TSr payloads) along with the
Group ID informing the GCKS of the group the initiator wishes to Group ID informing the GCKS of the group the initiator wishes to
join. An initiator intending to emit data traffic SHOULD send a join. An initiator intending to emit data traffic SHOULD send a
SENDER Notify payload status. The SENDER not only signifies that it SENDER Notify payload status. The SENDER notification not only
is a sender, but provides the initiator the ability to request signifies that it is a sender, but provides the initiator the ability
Sender-ID values, in case the data security SA supports a counter to request Sender-ID values, in case the data security SA supports a
mode cipher. Section 1.4.6) includes guidance on requesting Sender- counter mode cipher. Section 1.4.6) includes guidance on requesting
ID values. Sender-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 [RFC4302] and/or ESP [RFC4303]) SAs may be included into security (AH [RFC4302] and/or ESP [RFC4303]) SAs may be included into
SAg. Each Proposal contains a list of Transforms that the GM is able SAg. Each Proposal contains a list of Transforms that the GM is able
to support for that protocol. Valid transform types depend on the to support for that protocol. Valid transform types depend on the
protocol and are defined in Figure 15. Other transform types SHOULD protocol and are defined in Figure 15. Other transform types SHOULD
NOT be included. The SPI length of each Proposal in an SAg is set to NOT be included. The SPI length of each Proposal in an SAg is set to
skipping to change at page 14, line 13 skipping to change at page 14, line 13
the GCKS via the GSA_REKEY messages. the GCKS via the GSA_REKEY messages.
GSA_INBAND_REKEY The GSA_INBAND_REKEY is a normal IKEv2 exchange GSA_INBAND_REKEY The GSA_INBAND_REKEY is a normal IKEv2 exchange
using the IKEv2 SA that was setup to protecting the member using the IKEv2 SA that was setup to protecting the member
registration exchange. This exchange allows the GCKS to rekey registration exchange. This exchange allows the GCKS to rekey
without using an independent GSA_REKEY pseudo-exchange. The 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 is useful when G-IKEv2 is used with a small group of cooperating
devices. devices.
Depending on the policy the GCKS may combine these two methods. For Depending on the policy the GCKS MAY combine these two methods. For
example, it may use the GSA_INBAND_REKEY to deliver key to the GMs in example, it may use the GSA_INBAND_REKEY to deliver key to the GMs in
the group acting as senders (as this would provide reliable keys the group acting as senders (as this would provide reliable keys
delivery), and the GSA_REKEY for the rest GMs. delivery), and the GSA_REKEY for the rest GMs.
1.4.5.1. GSA_REKEY 1.4.5.1. GSA_REKEY
The GCKS initiates the G-IKEv2 Rekey securely, usually using IP The GCKS initiates the G-IKEv2 Rekey securely, usually using IP
multicast. Since this rekey does not require a response and it sends multicast. Since this rekey does not require a response and it sends
to multiple GMs, G-IKEv2 rekeying MUST NOT support IKE SA windowing. to multiple GMs, G-IKEv2 rekeying MUST NOT support IKE SA windowing.
The GCKS rekey message replaces the rekey GSA KEK or KEK array, and/ The GCKS rekey message replaces the rekey GSA KEK or KEK array, and/
skipping to change at page 54, line 40 skipping to change at page 54, line 40
<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., Bartlett, G., Fluhrer, S., Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S.,
Geest, D., Garcia-Morchon, O., and V. Smyslov, "Multiple Geest, D. V., Garcia-Morchon, O., and V. Smyslov,
Key Exchanges in IKEv2", draft-ietf-ipsecme-ikev2- "Multiple Key Exchanges in IKEv2", draft-ietf-ipsecme-
multiple-ke-02 (work in progress), January 2021. ikev2-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-02 (work in progress), August 2020. ipsecme-ikev2-qr-alt-03 (work in progress), February 2021.
[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,
 End of changes. 8 change blocks. 
18 lines changed or deleted 18 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/