I finally managed to finish my G-IKEv2 review. Here are my comments:
----------------------------------------------------------------------
2.3.4. GCKS Registration Operations
The GAP MAY also be
included to provide the ATD and/or DTD (Section 4.4.3.1.1) specifying
activation and deactivation delays for SAs generated from the TEKs.
expand ATD and DTD, this is first time they are used, so they should
be expanded here.
--
2.4.3. Deletion of SAs
The GCKS MAY specify the remaining active time of the policy by using
the GAP_DTD attribute in the GSA GAP substructure. If a GCKS has no
further SAs to send to group members, the GSA and KD payloads MUST be
omitted from the message.
What is this text related to? This deletion of SA Figures 12 and 13,
do not include GSA or KD payloads.
--
3.4. SA Keys
algorithm is used for encryption, then SK_a key will not be used (GM
can use the formula above assuming the length of SK_a is zero).
I think the SA_a should GSK_a here.
--
4.4.1. Group Policies
Having terms Group Security Association Policy (GSA Policy) and Group
associated Policy (GAP are bit difficult to read, as those two are so
similar. Perhaps Group Policy (GP) and Group Security Association
Policy (GSAP)?
--
4.4.2. Group Security Association Policy Substructure
The SPI size for the IKE is 16, not 8, like in standard RFC7296 IKEv2.
As the 8-first octets of the IKE SPI is the initiator SPI and it is
only one part that is used to identify the Rekey SA, so I think it
could be possible to just send 8-octets, i.e., the initiator SPI, and
simply say that the Responder SPI of the Rekey SA is simply ignored,
i.e., receipient MUST use the Inititor SA to find the rekey SA, and
ignore the Responder SPI on recipient (and either that Initiator MUST
or SHOULD use the responder SPI static for all Rekey SA messages).
Or we could define we send SPIi, and the SPIr will always be same as
SPIi, so each rekey SA will have identical SPIi and SPIr.
Similar changes for the section 4.5.2.
--
4.4.2.1.3. Replay Protection Transform
Add titles for [RFC4302] and [RFC4303], or just change "described in
[RFC4302] and [RFC4303]" to "described in the AH and ESP RFCs".
It might be good idea to explain the "Not used" value for RP registry
here too. Currently that value is only defined in sections 2.6 and
9.2, but there is no text describing what that option really means
(section 2.6 just says that such value was added, and 9.2 adds it but
no functional description is given for it.
Also there have been discussion of making changes to ESP, so that we
would send full ESN in the header, and in that case the ESN can be
used with G-IKEv2.
To allow that change the:
For this
reason extended sequence numbers MUST NOT be used for multicast Data-
Security SAs and thus the value "Extended Sequence Numbers" (1) for
the Replay Protection transform type MUST NOT be used in the GSA
Payload.
to
For this
reason the value "Extended Sequence Numbers" (1) for the Replay
Protection transform type MUST NOT be used in the GSA Payload.
--
4.4.2.2. GSA Attributes
In the table, attributes that are defined as TV are
marked as Basic (B); attributes that are defined as TLV are marked as
Variable (V).
It would be better to use TV and TLV in the table, and not use IKEv1
terms B(asic) and V(ariable) at all.
Same for 4.4.3.1, 4.5.2, 4.5.3 and 9.
Also the IANA tables in uses column "Format" to specify whether
attribute is TV or TLV.
--
4.4.2.2.1. GSA_KEY_LIFETIME Attribute
Why is this attribute needed? The senders should take cere of the
rekeying the SA before too much data is sent over it, so there is no
security reason for this. Is this just to allow clients to clean up
extra SAs in case they loose connectivity, but why then this MUST be
sent.
I think we could just remove this attribute.
--
4.4.2.2.2. GSA_INITIAL_MESSAGE_ID Attribute
Could we use similar method to transport the upper 32-bits of the ESN?
This would of course only work in case the GCKS is actually either
part of the group or knows the current upper 32-bits of the ESN using
some other method (for example if it is the sender to that SA).
Should we provide method for this even if would not work always?
--
6.1. Mixing Preshared Keys in IKEv2 for Post-quantum Security
This sentence needs to say something that if implementations cares
those issues then it needs to:
For these reasons the GCKS MUST NOT send GSA and KD payloads in the
GSA_AUTH response message and MUST return a new notification
REKEY_IS_NEEDED instead.
As you noted the GSK_w is protected, so store now, decrypt later
attack is already not applicable. The IKEv2 with PPK is not
really designed to be safe against the attackers who can do online
real time QC attacks on the exchanges, and break the for example
authentication used in the IKEv2. The IKEv2 with PPK is designed to
protect against the attacks, where someone stores traffic now, and
then when they do get quantum computes they can decrypt the data.
G-IKEv2 is as safe against such attacks as is standard IKEv2.
It attacker can break encryption and authentication of the G-IKEv2
messages it still can't affect the multicast traffic keys which are
protected using GSK_w which is derived from SK_d.
It can send messages that changes the keys to random keys which will
cause DoS attacks, but it can do DoS most likely anyways even without
breaking the encryption and authentication.
--
6.1. Mixing Preshared Keys in IKEv2 for Post-quantum Security
The GM starts the IKE_SA_INIT exchange requesting using PPK, and the
GCKS responds with agreement to do it, or aborts according to its
"mandatory_or_not" flag:
This text is confusing, if the initiator proposes PPK then responder
do not have flag mandatory_or_not, it might have flag "PPK_disabled",
which would cause it to abort, but describing that is not needed here.
Remove the text starting ", or aborts ..." to end of paragraph.
Typo in Figure 22, it says "DR, SAr1,..." when it should say "HDR,
SAr1, ..."
--
8.2.4. Replay/Reflection Attack Protection
Hmm... actually if the attacker can break the IKEv2 encryption and
authentication it can most likely create the replayed GSA_REKEY
messages, which are using the keys from the previous messages (which
the attacker does not know as they are protected by GSK_w), but it
might be able to cause them to be reused unless the key wrap algorithm
also includes the Message ID of the message containing it to the
authentication part it has. I.e., attacker might cause sender to reuse
keys that it has used before.
--
Appendix A. Use of LKH in G-IKEv2
How does one specify that it will use LKH? I do not think we have any
way of specifying it anymore? If so remove the whole appendix A.
----------------------------------------------------------------------
Comments about RFC references without names of the documents:
----------------------------------------------------------------------
1. Introduction and Overview
Add RFC title before the RFC number, i.e., change
A group key
management protocol provides IPsec keys and policy to a set of IPsec
devices which are authorized to communicate using a Group Security
Association (GSA) defined in [RFC3740].
to
A group key
management protocol provides IPsec keys and policy to a set of IPsec
devices which are authorized to communicate using a Group Security
Association (GSA) defined in Multicat Group Security Architecture
[RFC3740].
--
1.2. Terminology
This
document uses a notation and conventions from [RFC7296] for
to
This
document uses a notation and conventions from IKEv2 [RFC7296] for
--
The following key terms are used throughout this document (mostly
borrowed from [RFC3740], [RFC5374] and [RFC6407]).
to
The following key terms are used throughout this document (mostly
borrowed from Multicast Group Security Architecture [RFC3740],
Multicast Extensions to Security Architecture [RFC5374] and GDOI
[RFC6407]).
--
Group Security Association (GSA)
A collection of Data-Security SAs and Rekey SA necessary for a
Group Member to receive key updates. A GSA describes the working
policy for a group. Refer to [RFC4046] for additional
information.
to
Group Security Association (GSA)
A collection of Data-Security SAs and Rekey SA necessary for a
Group Member to receive key updates. A GSA describes the working
policy for a group. Refer to MSEC Group Key Management
Achtecture [RFC4046] for additional information.
--
Logical Key Hierarchy (LKH)
A group management method defined in Section 5.4 of [RFC2627].
to
Logical Key Hierarchy (LKH)
A group management method defined in Section 5.4 of Key
Management for Multicast: Issues and Architectures [RFC2627].
--
2.1. G-IKEv2 Integration into IKEv2 Protocol
It is assumed that readers are familiar with the IKEv2 protocol, so
this document skips many details that are described in [RFC7296].
to
It is assumed that readers are familiar with the IKEv2 protocol, so
this document skips many details that are described in IKEv2
[RFC7296].
--
2.1.1. G-IKEv2 Transport and Port
As IKEv2 extension, G-IKEv2 SHOULD use the IKEv2 ports (500, 4500).
G-IKEv2 MAY also use TCP transport for registration (unicast) IKE SA,
as defined in [RFC9329].
to
As IKEv2 extension, G-IKEv2 SHOULD use the IKEv2 ports (500, 4500).
G-IKEv2 MAY also use TCP transport for registration (unicast) IKE SA,
as defined in TCP Encapsulation of IKEv2 and IPsec [RFC9329].
-
Section 2.23 of [RFC7296] describes how IKEv2 supports paths with
to
Section 2.23 of IKEv2 [RFC7296] describes how IKEv2 supports paths with
--
2.3. G-IKEv2 Member Registration and Secure Channel Establishment
... IKEv2 extensions based on [RFC9242] ...
to
... IKEv2 extensions based on IKE_INTERMEDIATE exchange [RFC9242] ...
--
2.3.1. GSA_AUTH exchange
(like [RFC6467]) can
also be used with the GSA_AUTH exchange.
to
(like Secure Password
authentication [RFC6467]) can also be used with the GSA_AUTH
exchange.
--
2.3.3. GM Registration Operations
... In particular,
the restriction from Section 3.3 of [RFC7296] that AEAD and
non-AEAD ...
to
... In particular,
the restriction from Section 3.3 of IKEv2 [RFC7296] that AEAD and
non-AEAD ...
-
... described in Section 1.3.2 of [RFC7296]. ...
to
... described in Section 1.3.2 of IKEv2 [RFC7296]. ...
--
2.3.4. GCKS Registration Operations
[RFC5374] defines two modes of operation for multicast Data-Security
to
Multicastd Extensions to the Security Architecture [RFC5374]
defines two modes of operation for multicast Data-Security
--
2.4.1. GSA_REKEY
windowing mechanism described in Section 2.3 of [RFC7296] MUST NOT be
to
windowing mechanism described in Section 2.3 of IKEv2 [RFC7296]
MUST NOT be
--
2.4.1.1. GSA_REKEY Messages Authentication
Length and the Integrity Checksum Data fields (see 3.14 of [RFC7296]
to
Length and the Integrity Checksum Data fields (see 3.14 of IKEv2 [RFC7296]
-
filled in, see [RFC7427].
to
filled in, see Authentication in IKEv2 [RFC7427].
--
2.4.1.2. IKE Fragmentation
IKE fragmentation [RFC7383] can be used to perform fragmentation of
to
IKEv2 fragmentation [RFC7383] can be used to perform fragmentation of
-
waiting for response. Section 2.5.1 of [RFC7383] contains
to
waiting for response. Section 2.5.1 of IKEv2 fragmentation
[RFC7383] contains
-
* PMTU mechanism, defined in Section 2.5.2 of [RFC7383], cannot be
to
* PMTU mechanism, defined in Section 2.5.2 of IKEv2 fragmentation
[RFC7383], cannot be
--
2.4.2. GSA_INBAND_REKEY Exchange
Because this is a normal IKEv2 exchange, the HDR is treated as
defined in [RFC7296].
to
Because this is a normal IKEv2 exchange, the HDR is treated as
defined in IKEv2 [RFC7296].
--
2.4.3. Deletion of SAs
changed. Deletion of SAs is accomplished by sending the G-IKEv2
Delete Payload [RFC7296], section 3.11 as part of the GSA_REKEY
to
changed. Deletion of SAs is accomplished by sending the G-IKEv2
Delete Payload as described in section 3.11 of IKEv2 [RFC7296] as
part of the GSA_REKEY
--
2.5. Counter-based modes of operation
* The GCKS uses the method described in [RFC6054], which assigns
to
* The GCKS uses the method described in Using Counter Modes with
ESP and AH to Protect Group Traffic [RFC6054], which assigns
--
2.6. Replay Protection for Multicast Data-Security SAs
possible to achieve (see Section 6.1 of [RFC3740]). In particular,
to
possible to achieve (see Section 6.1 of Multicast Group Security
Architecture[RFC3740]). In particular,
-
ESP header (see Section 2 of [RFC4303]) thus making it impossible for
to
ESP header (see Section 2 of ESP [RFC4303]) thus making it
impossible for
-
Numbers" transform, defined in Section 3.3.2 [RFC7296]. This
to
Numbers" transform, defined in Section 3.3.2 IKEv2 [RFC7296]. This
--
2.7. Encryption Transforms with Implicit IV
[RFC8750] for details). It requires replay protection to be enabled
to
Implicit IV for Counter-Based Ciphers in ESP [RFC8750] for
details). It requires replay protection to be enabled
--
4.4.2. Group Security Association Policy Substructure
Add title for [RFC5374] in Source & Destination Traffic selectors
description.
--
4.4.2.1.1. Authentication Method Transform
Add title for [RFC5280] and [RFC7427].
--
4.4.3.1.2. GAP_SENDER_ID_BITS Attribute
Add title for [RFC6054].
--
4.5.3.2. AUTH_KEY Attribute
Add titles for [RFC5280], [RFC8017], [RFC3279], and [RFC5480].
--
4.5.4. Key Wrapping
Add titles for [RFC5649] and [ARX-KW].
--
7. GDOI Protocol Extensions
Add titles for [RFC6407], [RFC8052] and [RFC8263].
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
