Hi Tero,
> I finally managed to finish my G-IKEv2 review. Here are my comments:
many thanks for this epic effort :-)
> ----------------------------------------------------------------------
> 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.
Added them to the list of terms.
> --
>
> 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.
This text seems to be a leftover from early versions of the draft. Deleted.
> --
>
> 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.
Fixed.
> --
>
> 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)?
I see your point. I would leave GSA as is, and perhaps would change
GAP to Group Related policy (GR policy). "Policy" will not be part
of abbreviation in both cases. Your opinion? I didn't make any changes
yet...
> --
>
> 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.
Note, that a new IKE protocol GIKE_REKEY is used here,
for which the size of SPI is 16 octets. I see no problem here.
> --
>
> 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".
Added titles.
> 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.
Added such text.
> 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.
Done.
> --
>
> 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.
Done.
> --
>
>
> 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.
The sender cannot rekey GSA, it is the GCKS who can only do it.
If for any reason the connectivity with the GCKS is lost
or it unexpectedly goes offline, then the group continues to live
on its own and the SA lifetime can be exceeded. This attribute is a
safeguard for this case -
each group sender will know the lifetime of the SA and stops using it after
that time even if no new SA is established by the GCKS.
> --
>
> 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?
This will reliably only work if the GCKS is the only sender in the group.
I'm not sure we should add support only for this particular case.
> --
>
> 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.
Changed this text to:
GCKS implementations that care about these issues MUST NOT send GSA
and KD payloads in the GSA_AUTH response message and MUST return a
new notification REKEY_IS_NEEDED instead.
> --
>
> 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.
Done.
> Typo in Figure 22, it says "DR, SAr1,..." when it should say "HDR, SAr1,
..."
Fixed.
> --
>
> 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.
I guess that if an attacker can break IKEv2 encryption and authentication it
can
do a lot of bad things, right? E.g. craft a message that deletes GSA...
> --
>
> 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.
No special indication is needed. The GCKS sends either a single group
protection key
wrapped with GSK_w to all members (no LKH) or provides each GM with its own
key (protected with GSK_w)
and with an array of keys where each subsequent key is protected by the
previous one in the array,
ending up with the group protection key. The GMs logic is the same in both
cases - it must find the group
protection key using all the keys supplied by the GCKS, starting from GSK_w
which
the GM always knows. See also Section 3.2.
> ----------------------------------------------------------------------
>
> 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].
Done.
> --
>
> 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
Done.
> --
>
> 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]).
Done.
> --
>
> 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.
Done.
> --
>
> 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].
Changed to:
Logical Key Hierarchy (LKH)
A group management method defined in Section 5.4 of Key
Management for Multicast [RFC2627].
to avoid colons in the text.
> --
>
> 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].
Done.
> --
>
> 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].
Done.
> -
>
> Section 2.23 of [RFC7296] describes how IKEv2 supports paths with
>
> to
>
> Section 2.23 of IKEv2 [RFC7296] describes how IKEv2 supports paths with
Done.
> --
>
> 2.3. G-IKEv2 Member Registration and Secure Channel Establishment
>
> ... IKEv2 extensions based on [RFC9242] ...
>
> to
>
> ... IKEv2 extensions based on IKE_INTERMEDIATE exchange [RFC9242] ...
Changed to:
... IKEv2 extensions based on the IKEv2 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.
Done.
> --
>
> 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 ...
Done.
> -
>
> ... described in Section 1.3.2 of [RFC7296]. ...
>
> to
>
> ... described in Section 1.3.2 of IKEv2 [RFC7296]. ...
Done.
> --
>
> 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
Done.
> --
>
> 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
Done.
> --
> 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]
Done.
> -
>
> filled in, see [RFC7427].
>
> to
>
> filled in, see Authentication in IKEv2 [RFC7427].
Changed to:
... filled in, see Signature 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
Done.
> -
>
> waiting for response. Section 2.5.1 of [RFC7383] contains
>
> to
>
> waiting for response. Section 2.5.1 of IKEv2 fragmentation
> [RFC7383] contains
Done.
> -
>
> * 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
Done.
> --
>
> 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].
Done.
> --
>
> 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
Changed to:
Deletion of SAs is accomplished by sending the Delete
Payload described in Section 3.11 of IKEv2 [RFC7296] as part of the
GSA_REKEY pseudo-exchange as shown below.
> --
>
> 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
Done.
> --
>
> 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,
Done.
> -
>
> 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
Done.
> -
>
> Numbers" transform, defined in Section 3.3.2 [RFC7296]. This
>
> to
>
> Numbers" transform, defined in Section 3.3.2 IKEv2 [RFC7296]. This
Changed to:
Numbers" transform, defined in Section 3.3.2 of 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
Done.
> --
>
> 4.4.2. Group Security Association Policy Substructure
>
> Add title for [RFC5374] in Source & Destination Traffic selectors
description.
OK.
> --
>
> 4.4.2.1.1. Authentication Method Transform
>
> Add title for [RFC5280] and [RFC7427].
Done.
> --
>
> 4.4.3.1.2. GAP_SENDER_ID_BITS Attribute
>
> Add title for [RFC6054].
OK.
> --
>
> 4.5.3.2. AUTH_KEY Attribute
>
> Add titles for [RFC5280], [RFC8017], [RFC3279], and [RFC5480].
OK.
> --
>
> 4.5.4. Key Wrapping
>
> Add titles for [RFC5649] and [ARX-KW].
Done.
> --
>
> 7. GDOI Protocol Extensions
>
> Add titles for [RFC6407], [RFC8052] and [RFC8263].
Done.
I've submitted a new version.
Thank you,
Valery.
> --
> kivi...@iki.fi
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
