Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-08.txt

[Daniel Migault <[e-mail]>]

Hi Valery,

Thanks for the follow-up please find inline my response to your comment.
Thank you for the clarifications  and all my comments have been responded
to.

Yours,
Daniel


On Wed, Apr 12, 2023 at 12:05 PM Valery Smyslov <[e-mail]>
wrote:

> Hi Daniel,
>
>
>
> thank you for your review. Please see inline (some text is snipped for
> readability).
>
>
>
> Hi,
>
>
>
> I have reviewed the document until section 3.2 (50% of the doc).  The
> document is on a good path. Most of my comments are editorial - and I am
> not expecting any response, and feel free to ignore them. I do have other
> comments labeled as DISCUSSION or CLARIFICATION that I think may need more
> attention - at least I am interested by the response ;-).
>
> There are no major issues and my expectation is that the remaining
> sections will have no specific issues at all but I need to go through them
> and I think the document can be moved forward without these comments.
>
>
>
> Yours,
>
> Daniel
>
>
>
>
> [snipped]
>
>
> 1.  Introduction and Overview
>
>    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].
> <mglt>
> This is a nit but I believe that saying striaght forward
> """
> This document presents an extension to
>    IKEv2 [RFC7296] called G-IKEv2, that allows to perform a group key
>    management.
>
> """
>
> may be clearer.
>
> </mglt>
>
>
>
>           This is exactly what is written a few lines below in the same
> para :-)
>
Absolutely, as far as I remember, what I meant is that mentioning this
sentence in the beginning tells upfront what the draft is about. Starting
with the notion of groups management is I think not the reason we have the
draft. Again that was just a nit.

  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
>    Controller/Key Server (GCKS).  This document presents an extension to
>    IKEv2 [RFC7296] called G-IKEv2, that allows to perform a group key
>    management.
>
>    G-IKEv2 conforms to the Multicast Group Security Architecture
>    [RFC3740], Multicast Extensions to the Security Architecture for the
>    Internet Protocol [RFC5374] and the Multicast Security (MSEC) Group
>    Key Management Architecture [RFC4046].  G-IKEv2 replaces GDOI
>
>
>
> Smyslov & Weis          Expires 10 September 2023               [Page 3]
>
> Internet-Draft                   G-IKEv2                      March 2023
>
>
>    [RFC6407], which defines a similar group key management protocol
>    using IKEv1 [RFC2409] (since deprecated by IKEv2).  When G-IKEv2 is
>    used, group key management use cases can benefit from the simplicity,
>    increased robustness and cryptographic improvements of IKEv2 (see
>    Appendix A of [RFC7296].
>
> <mglt>
> missing ")"
> </mglt>
>
>
>
>           Fixed, thank you.
>
>
>    A GM begins a "registration" exchange when it first joins the group.
> <mglt>
> I think I have a similar comment to my first comment. When I am reading th
> esentence I never know if this is a generla sentence or if that is specific
> to G-IKEv2.
> This is a nit, but I think we should make it clear that we only focuses on
> G-IKEv2. Maybe I am biaised as I am not familiar with other generic group
> frameworks.
> </mglt>
>
>
>
>           Changed to:
>
>
>
>      With G-IKEv2 a GM begins a "registration" exchange when it first
> joins the group.
>
>      The GCKS authenticates and authorizes GMs, then pushes
>
>       policy and keys used by the group to the GM.
>
>
> ok

>    With G-IKEv2, the GCKS authenticates and authorizes GMs, then pushes
>    policy and keys used by the group to the GM.  G-IKEv2 includes two
>    "registration" exchanges.  The first is the GSA_AUTH exchange (
> <mglt>
> do we have an extra space after the "(" ?
> </mglt>
>
>
>
>           Yes, fixed.
>
>
>    Section 2.3.1), which is used when a GM first conatcts a GCKS.
> <mglt>
> s/conatcts/contacts/
> </mglt>
>
>
>
>           Fixed.
>
>
>   The
>    second is the GSA_REGISTRATION exchange (Section 2.3.2), which a GM
>    can use within an established IKE SA.
> <mglt>
> I think that if we specify that GSA_REGISTRATION is withinan established
> IKE_SA we also need to specify GSA_AUTH where the GS_AUTH occurs.
> I also think it might be helpful to specify the IKE channel is between the
> GM and the GCKS as opposed to anything shared by all GMs.
> </mglt>
>
>
>
>           Changed to:
>
>
>
>    The first is the GSA_AUTH exchange
>
>    (Section 2.3.1), which is used when a GM first contacts a GCKS and is
>
>    creating an IKE SA between itself and the GCKS.  The second is the
>
>    GSA_REGISTRATION exchange (Section 2.3.2), which a GM can use within
>
>     the already established IKE SA.
>
>
> ok

>   Group rekeys are accomplished
>    using either the GSA_REKEY pseudo-exchange (a single message
>    distributed to all GMs, usually as a multicast message), or as a
>    GSA_INBAND_REKEY exchange delivered individually to group members
>    using existing IKE SAs).
> <mglt>
> Maybe s/group memebers/all group members/
> I also beleiev that it would be clearer to have s/existing SAs/their
> individual IKE SA/ just to make it clear that each GM has a single
> (individual) IKE SA shared with the GCKS.
> </mglt>
>
>           I disagree with the first proposal, since it is quite possible
> to use both GSA_REKEY and GSA_INBAND_REKEY
>
>           (e.g. to reliably deliver new keys to some GMs, e.g. senders,
> and using multicast transport for the rest).
>
I see. ok.

>
>
>           I don’t mind second proposed change.
>
>
>    Large and small groups may use different sets of these protocols.
>    When a large group of devices are communicating, the GCKS is likely
>    to use the GSA_REKEY message for efficiency.  This is shown in
>    Figure 1.  (Note: For clarity, IKE_SA_INIT is omitted from the
>    figure.)
>
>                                 +--------+
>                  +------------->|  GCKS  |<-------------+
>                  |              +--------+              |
>                  |                |    ^                |
>                  |                |    |                |
>                  |                | GSA_AUTH            |
>                  |                |   or                |
>                  |                | GSA_REGISTRATION    |
>                  |                |    |                |
>               GSA_AUTH            |    |             GSA_AUTH
>                 or           GSA_REKEY |               or
>           GSA_REGISTRATION        |    |         GSA_REGISTRATION
>                  |                |    |                |
>                  |   +------------+-----------------+   |
>                  |   |            |    |            |   |
>                  v   v            v    v            v   v
>                +-------+        +--------+        +-------+
>                |  GM   |  ...   |   GM   |  ...   |  GM   |
>                +-------+        +--------+        +-------+
>                    ^                 ^                ^
>                    |                 |                |
>                    +-------ESP-------+-------ESP------+
>
>                    Figure 1: G-IKEv2 used in large groups
>
> <mglt>
> It might be helpful to indicate (inidvidual) IKE channel while the ESP SA
> is shared between all GMs.
>
>
>
>           I think that individual IKE SAs are already shown (GSA_AUTH or
> GSA_REGISTRATION). Am I missing your point?
>
>           Or do you want to change them to “IKE SA”?
>
>
> I do not remember what I had exactly in mind, but I think it might be to
indicate just IKE  versus ESP to make it clear GSA messages are IKE
messages.

> While ESP is reasonable, we may also indicate if AH is excluded or if the
> IPsec communication can include ESP/AH.
> </mglt>
>
>
>
>           Changed to ESP/AH.
>
>
>
>
> Smyslov & Weis          Expires 10 September 2023               [Page 4]
>
> Internet-Draft                   G-IKEv2                      March 2023
>
>
>    Alternatively, a small group may simply use the GSA_AUTH as a
>    registration protocol, where the GCKS issues rekeys using the
>    GSA_INBAND_REKEY within the same IKE SA.  The GCKS is also likely to
>    be a GM in a small group (as shown in Figure 2.)
>
> <mglt>
> """ The GCKS is also likely to
>    be a GM in a small group (as shown in Figure 2.)"""
> is a bit confusing.
> I do not see why such p[roperty is restricted to small group nor what kind
> of advanatge thjis provides as my understanding is that Groups
> communication is only related to the ESP communication nor the IKE
> communication.
> On the other hand, Figure 1 and Figure 2 mostly highlight multicast IKE
> message versus individual IKE message.
> We probably need to specify if the GCKS is a GM is orthogonal to
> multicast/indiviudal IKE message or not and if that only applies to the
> small group why.
> </mglt>
>
>
>
>           This is a good point. I see no reason why GCKS cannot also be a
> GM in a large group (with multicast rekey operations).
>
>           So I moved this note to a para right after the figure.
>
>
>           [snip]
>
>
> 1.2.  Terminology
>
>    It is assumed that readers are familiar with the IPsec architecture
>    [RFC4301], its extension for multicast [RFC5374].  This document
>    defines an extension to the IKEv2 protocol [RFC7296], so it is
>    assumed that readers have good understanding of this protocol.
>
>
>
> Smyslov & Weis          Expires 10 September 2023               [Page 5]
>
> Internet-Draft                   G-IKEv2                      March 2023
>
>
>    The following key terms are used throughout this document (mostly
>    borrowed from [RFC5374] and [RFC6407]).
>
>    Group  A set of devices that work together to protect group
>       communications.
>
>    Group Member (GM)  An IPsec device that belongs to a group.  A Group
>       Member is authorized to be a Group Sender and/or a Group Receiver.
>
>    Group Receiver  A Group Member that is authorized to receive packets
>       sent to a group by a Group Sender.
>
>    Group Sender  A Group Member that is authorized to send packets to a
>       group.
>
>    Group Key Management (GKM) Protocol  A key management protocol used
>       by a GCKS to distribute IPsec Security Association policy and
>       keying material.  A GKM protocol is used when a group of IPsec
>       devices require the same SAs.  For example, when an IPsec SA
>       describes an IP multicast destination, the sender and all
>       receivers need to have the group SA.
>
>    Group Controller Key Server (GCKS)  A Group Key Management (GKM)
>       protocol server that manages IPsec state for a group.  A GCKS
>       authenticates and provides the IPsec SA policy and keying material
>       to GKM Group Members.
>
>    Data-Security SA  The security policy distributed by a GDOI GCKS
>       describing traffic that is expected to be protected by group
>       members.  This document described the distribution of IPsec AH and
>       ESP Data-Security SAs.
>
> <mglt>
> isn't Data-Security SA a kind of GSPD ?
> </mglt>
>
>          It is more like ESP/AH SA for multicast.
>
>          The definition is borrowed from RFC 6407.
>
>          I personally find it a bit weird, but that’s what we have :-)
>
>          To add more confusion, RFC 3740 contains a different definition
> of this term:
>
I see ;-)

>
>
>    -  Data Security SA (DATA): A multicast SA between each multicast
>
>       source speaker and the group's receivers.  There may be as many
>
>       data SAs as there are multicast sources allowed by the group's
>
>       policy.
>
>
>
>        which I like more. Should we use this instead?
>
>        Then the definition of Rekey SA must also be changed.
>
>
> I find it may be confusing to have policies in the definition of an SA, so
the second seems clearer to me, but I am not pushing too much. Pick
whatever you believe is better.


>    Rekey SA  The security policy protecting Group Key Management
>       Protocol.
>
>    Group Security Association (GSA)  A collection of Data-Security
>       Associations (SAs) and Rekey SAs necessary for a Group Member to
>       receive key updates.  A GSA describes the working policy for a
>       group.  Refer to [RFC4046] for additional information.
>
>    Traffic Encryption Key (TEK)  The symmetric cipher key used in a
>       Data-Security SA (e.g., IPsec ESP) to protect trafic.
> <mglt>
> isn't it simply the GSA key ?
> </mglt>
>
>
>
>           No, GSA is a collection of Data-Security SAs and Rekey SA, so
> there is no a single key.
>
>           TEK is a key for a single Data-Security SA.
>
>
> I see. I think I did not realize the GSA contains multiple SAs, so having
this explicitly even in the TEK definition makes sense - at least to me.

>
>    Key Encryption Key (KEK)  The symmetric cipher key used in a Rekey SA
>       to protect distribution of new keys.
>
> <mglt>
> isn't it simply the GIKE_SA or Rekey_SA key ?
> I am not suggesting to change the terminology - especially at that point -
> but I have the impression that some very generic terms could gain in
> clarity by having a more narrow IPsec/IKEv2 context. I also know it is very
> hard to find the right terminology and everyon ehas its own view - so just
> take it as a comment.
> </mglt>
>
>
>
>           Yes, KEK is a Rekey SA key.
>
>
>
>           The terminology for GDOI is a real mess with different existing
> RFCs defining the same terms differently.
>
>           I tried to borrow less controversial definitions, but in some
> cases I seemed to fail.
>
>
> you did pretty well ;-)

>
>    Key Wrap Key (KWK)  The symmetric cipher key used to protect another
>       key.
>
>
>
> Smyslov & Weis          Expires 10 September 2023               [Page 6]
>
> Internet-Draft                   G-IKEv2                      March 2023
>
>
>    Group Associated Policy (GAP)  Group-wide policy not related to a
>       particular SA.
>
>    Sender-ID  A unigue identifier of a Group Sender in the context of an
>       active GSA, used to form Initialization Vector (IV) in counter-
>       based cipher modes.
>
>    Logical Key Hierarchy (LKH)  A group management method defined in
>       Section 5.4 of [RFC2627].
>
> 2.  G-IKEv2 Protocol
>
> 2.1.  G-IKEv2 Integration into IKEv2 Protocol
>
>    G-IKEv2 is an extension to IKEv2 and uses its security mechanisms
>    (peer authentication, confidentiality, message integrity) to ensure
>    that only authenticated devices have access to the group policy and
>    keys.  G-IKEv2 further provides group authorization, and secure
>    policy and key download from the GCKS to GMs.
>
> <mglt>
> Reading the last sentence, I am interpretingh it as a consequence of
> provindin a GSA. If that is the case, I see this a a much simpler way to
> describve what it does. group authorization might be perceived as something
> like OAUTH, policies as something more complex. Typically ACE has defined
> some quite complex messaging for managing group communications, so stiking
> to IPsec might limit such confusion.
> </mglt>
>
>
>
>           Authorization here is an access control for GM entering the
> group. How about:
>
>
>
>         G-IKEv2 is an extension to IKEv2 and uses its security mechanisms
> (peer authentication,
>
>         confidentiality, message integrity) to ensure that only
> authenticated and authorized
>
>         devices have access to the group policy and keys.
>
>          G-IKEv2 provides secure policy and keys download from the GCKS to
> GMs.
>
>
>
>           Or can you provide a better text?
>
I think that what I would propose could be:
  G-IKEv2 is an extension to IKEv2 that provides group authorization, secure
   policy and key download from the GCKS to GMs.
>
>
>    G-IKEv2 is compatible with most IKEv2 extensions defined so far and
>    it is believed that future IKEv2 extensions will also be possible to
>    use with G-IKEv2.  However some IKEv2 extensions require special
>    handling if used with G-IKEv2.  See Section 6 for more details.
>
>    It is assumed that readers are familiar with the IKEv2 protocol, so
>    this document skips many details that are described in [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].  G-IKEv2 MAY also use UDP port 848, the same
>    as GDOI [RFC6407], because they serve a similar function.  The
>    version number in the IKE header distinguishes the G-IKEv2 protocol
>    from GDOI protocol [RFC6407].
>
>    Section 2.23 of [RFC7296] describes how IKEv2 deals with NATs.
>    Despite the fact, that with G-IKEv2 the registration SA doesn't
>    create any unicast IPsec SAs and thus there is no unicast ESP traffic
>    between the GM and the GCKS to encapsulate in UDP if NAT is present,
>    the actions described in this section concerned with the IKE SA MUST
>    be honored.
> <mglt>
> Actually the only question I am wondering if whether ther is a child SA or
> not.
> </mglt>
>
>
>
>           Data-Security SAs are Child SAs.
>
>
> that was not clear to me when I made the comment.  As mentioned earlier, I
believe that I missed that GSA contains multiple SA"s".

>
>           [snip]
>
>
> 2.3.  G-IKEv2 Member Registration and Secure Channel Establishment
>
>    The registration protocol consists of a minimum of two exchanges,
>    IKE_SA_INIT and GSA_AUTH; member registration may have a few more
>    messages exchanged if the EAP method, cookie challenge (for DoS
>    protection), negotiation of Diffie-Hellman group or IKEv2 extensions
>    based on [RFC9242] are used.  Each exchange consists of request/
>    response pairs.
> <mglt>
> consist of "a" ? -- knowing that english is not my native language... so
> just mentioning it in case this makes sense.
> </mglt>
>
>
>
>           It neither is mine, so I leave this to more knowledgeable people
> (I suspect this text was written by Brian or some of previous authors).
>
>
>
>   The first exchange IKE_SA_INIT is defined in IKEv2
>    [RFC7296].  This exchange negotiates cryptographic algorithms,
>    exchanges nonces and computes a shared key between the GM and the
>    GCKS.
>
>    The second exchange GSA_AUTH authenticates the previously exchanged
>    messages, exchanges identities and certificates.  The GSA_AUTH
>    messages are encrypted and integrity protected with keys established
>    through the previous exchanges,
> <mglt>
> Should we say like the regular IKE_AUTH ?
> </mglt>
>
>
>
>           OK, will clarify.
>
>
>
>
> so the identities are hidden from
>    eavesdroppers and all fields in all the messages are authenticated.
>    The GCKS SHOULD authorize group members to be allowed into the group
>    as part of the GSA_AUTH exchange.
> <mglt>
> The "SHOULD" sounds strange to me as I have the impression that completing
> the exchange implicilt provides the authorization.
> </mglt>
>
>
>
>           Hm, as far as I understand, the intended meaning is that the
> GCKS must authorize the GM unless
>
>           the group is completely public (no restriction on membership).
> Can you propose a better text if this is not clear?
>
>
>
I would have proposed:
The GCKS authorizes group members to be allowed into the group as part of
the GSA_AUTH exchange.

>
>   Once the GCKS accepts a group
>    member
> <mglt>
> s/group member/GM
> </mglt>
>
>
>
>           OK.
>
>
> to join a group it will download the data security keys (TEKs)
>    and/or group key encrypting key (KEK) as part of the GSA_AUTH
>    response message.
> <mglt>
> I am finding "download" confusing here as I see teh GS_AUTH response
> providing the TEK and KEK.
> </mglt>
>
>           That is correct. s/download/provide ?
>
I prefer - but please just change it if you find it useful otherwise, just
leave it as it is.

>
>
> Smyslov & Weis          Expires 10 September 2023               [Page 9]
>
> Internet-Draft                   G-IKEv2                      March 2023
>
>
> 2.3.1.  GSA_AUTH exchange
>
>    After the group member and GCKS negotiate cryptographic algorithms,
>    exchange nonces, and compute shared keys as defined in IKEv2
>    [RFC7296], the GSA_AUTH exchange MUST complete before any other
>    exchanges defined in this document can be done.  GSA_AUTH is used to
>    authenticate the previous exchanges, exchange identities and
>    certificates.  G-IKEv2 also uses this exchange for group member
>    registration and authorization.
>
>    The GSA_AUTH exchange is identical to the IKE_AUTH exchange with the
>    difference that its goal is to establish multicast Data-Security SAs
>    and optionally provide GM with the keys for Rekey SA.  The set of
>    payloads in the GSA_AUTH exchange is slightly different, because
>    policy is not negotiated between the group member and the GCKS, but
>    instead downloaded from the GCKS to the group member.
> <mglt>
> I think we shoudl avoid identicial as there are some difference. Perhaps
> something around:
> he GSA_AUTH exchange is a specific exchange with a given exchange type
> whose purpose is very similar to IKE_AUTH.
>
>
>
>           May I propose simply:
>
>
>
>         The GSA_AUTH exchange is similar to the IKE_AUTH exchange with the
>
>         difference that its goal is to establish multicast Data-Security
> SAs
>
>           and optionally provide GM with the keys for Rekey SA.
>
>
> There are in my opinion 2 goals, including authenticating the GM which
> seems to be missing in the text.
>
>
>
>           In my reading this goal is hidden inside “similar to the
> IKE_AUTH”.
>
>
> sounds good to me.

>
> I am reading downloaded as defined or dictated by the GCKS. I think that
> is good to mention the GIKE_SA is not "agreed".
>
>
>
>           What is your proposal here?
>
>
> I see more "download" as "provided".

> </mglt>
>
>
>
>
>
>
>   Note also,
>    that GSA_AUTH has its own exchange type, which is different from the
>    IKE_AUTH exchange type.
> <mglt>
> The text above seems to have been introduces since we mentions GSA_AUTH
> and IKE_AUTH are "identiical" but not. It opposes what is before and what
> follows, so I we should probably remove that paragraph.
> </mglt>
>
>
>
>           If you believe this is obvious, I’ll remove this text.
>
>
> I think we should keep it now that we stated the exchanges are not
identical. Let's wait if someone complains.

>
>    Nevertheless, the security properties of the GSA_AUTH exchange are
>    the same as the properties of the IKE_AUTH exchange and most IKEv2
>    extensions to the IKE_AUTH exchange (like [RFC6467]) can also be used
>    with the GSA_AUTH exchange.
> <mglt>
> The text above is in my opinion a "simple note". It think it is valuable
> but the begining shoudl in my opinion being smoothed or even omitted.
>
> Note that due to the similarities between IKE_AUTH and GSA_AUTH, most IKEv2
>    extensions to the IKE_AUTH exchange (like [RFC6467]) can also be used
>    with the GSA_AUTH exchange.
> </mglt>
>
>
>
>           OK.
>
>
>
>     Initiator (GM)                                  Responder (GCKS)
>    --------------------                            ------------------
>     HDR, SK{IDi, [CERT,] [CERTREQ,] [IDr,]
>              AUTH, IDg, [SAg,] [N]}        -->
>
>                          Figure 3: GSA_AUTH Request
>
>
>    A group member initiates a GSA_AUTH request to join a group indicated
> <mglt>
> Note that all nits and synthax comments I am providing are very much
> subject to be ignored, and I just provide them as a personnal suggestion
> which could be very wrong - especially as I am not so fluent in english.
>
> I am wondering if "designated" is not more appropriated than "indicated"
> </mglt>
>
>
>
>           Will leave this to native speakers.
>
>
>    by the IDg payload.  The GM MAY include an SAg payload declaring
>    which Transforms it is willing to accept.
> <mglt>
> I tend to think that MAY means that SAg is useless ;-) Thinking of it, I
> do not see any negotiation possible here, so I am wondering if we shoudl
> not simply omit SAg.
> </mglt>
>
>
>
>           No, it is not useless. It’s true that there is no negotiation,
> but SAg allows a GM to inform GCKS about its capabilities.
>
>           See Section 2.3.3. Actually, this should be “may” instead of
> “MAY” here, since later (2.3.3) including an SAg payload is “RECOMMENDED”.
>
>
> Much better works to me.

>
>  A GM that intends to act
>    as Group Sender SHOULD include a Notify payload status type of
>    SENDER, which enables the GCKS to provide any additional policy
>    necessary by group senders.
>
> <mglt>
> SENDER shoudl be added to Fig3.
> </mglt>
>
>           Done.
>
>
>
>     Initiator (GM)                 Responder (GCKS)
>    --------------------           ------------------
>                              <--   HDR, SK{IDr, [CERT,]
>                                    AUTH, [GSA, KD,] [N,]}
>
>                      Figure 4: GSA_AUTH Normal Response
>
> <mglt>
> optional payload. I have the impression I would have written  "[CERT],"
> instead of  "[CERT,]". The latest looks strange to me but I might be
> completly wrong.
> </mglt>
>
>
>
>           There are different styles :-) RFC 7296 uses the latter (See
> Appendix C), so we use the same for G-IKEv2.
>
>
> ok I never paid attention to that; -)

>
>
> Smyslov & Weis          Expires 10 September 2023              [Page 10]
>
> Internet-Draft                   G-IKEv2                      March 2023
>
>
>    The GCKS responds with IDr, optional CERT, and AUTH payloads as if it
>    were an IKE_AUTH.
> <mglt>
> I think that "as if it were an IKE_AUTH" means "with the same meaning as
> in IKE_AUTH".
> </mglt>
>
>
>
>           OK, use this wording.
>
>
>
>   It also informs the group member of the
>    cryptographic policies of the group in the GSA payload and the key
>    material in the KD payload.
> <mglt>
> My understanding so far is that responses are different when the SENDER
> notification is provided, but I do not see these differences. I think that
> figure 4 should be split into a response to a request with an (accepted)
> SENDER and one without or an ignored SENDER.
> </mglt>
>
>
>
>           No, they are not different (at least at this level of
> presentation).
>
>           GCKS provides senders with additional information, such as
> Sender-ID
>
>           and may treat them differently while re-keying (e.g use
> GSA_INBAND_REKEY
>
>           for reliability). Otherwise there is no difference.
>
>
> ok

>
>    In addition to the IKEv2 error handling, the GCKS can reject the
>    registration request when the IDg is invalid or authorization fails,
>    etc.  In these cases, see Section 4.7, the GSA_AUTH response will not
>    include the GSA and KD, but will include a Notify payload indicating
>    errors.  If a GM included an SAg payload, and the GCKS chooses to
>    evaluate it, and the GCKS detects that the group member cannot
>    support the security policy defined for the group, then the GCKS
>    SHOULD return a NO_PROPOSAL_CHOSEN.  Other types of error
>    notifications can be INVALID_GROUP_ID, AUTHORIZATION_FAILED or
>    REGISTRATION_FAILED.
>
> <mglt>
> SENDER introduces some roles a GM can play, and I beleive we need to
> explicitly mention if there is an error associated to that role or not.
> </mgt>
>
>
>
>           I don’t think there is any specific errors for senders. Am I
> missing your point?
>
I think I was thinking a GM may only be allowed to listen and not to send,
in which case, the GCSK may notify this to the GM.

>
>
>     Initiator (GM)                   Responder (GCKS)
>    --------------------             ------------------
>                               <--   HDR, SK{IDr, [CERT,] AUTH, N}
>
>                      Figure 5: GSA_AUTH Error Response
>
>
>    If the group member finds the policy sent by the GCKS is
>    unacceptable, the member SHOULD initiate GSA_REGISTRATION exchange
>    sending IDg and the Notify NO_PROPOSAL_CHOSEN (see Section 2.3.2)).
>
> 2.3.2.  GSA_REGISTRATION Exchange
>
>    When a secure channel is already established between a GM and the
>    GCKS, the GM registration for a group can reuse the established
>    secure channel.  In this scenario the GM will use the
>    GSA_REGISTRATION exchange.  Payloads in the exchange are generated
>    and processed as defined in Section 2.3.1.
>
> <mglt>
> My impression is that GSA_REGISTRATION is not needed as it does not
> provides additional functionalities than GSA_AUTH. I am wondering if that
> exchange MUST be supported by implementations or if it could be optional -
> especially for minimal implementations.
> </mglt>
>
>
>
>           GSA_REGISTRATION may be used if the GM wishes to join several
> groups hosted by a single GCKS.
>
>           It is also used to re-register GM to the group in case of
> missing GSA_REKEY message (provided IKE SA is up) and to perform some
> housekeeping
>
>           (e.g to allow GM to explicitly unregister itself from the
> group). I don’t think it is optional to support.
>
>
>           [snip]
>
Actually I was thinking that one method could be mandatory, while the other
remains optional to ease implementation. The current specification mandates
the two methods.  I was basically suggesting that IoT devices may only
implement the one that does not require to maintain an IKE_SA over time.

>
>
>    Next the GM sends the GSA_AUTH request message with the IKEv2
>    payloads from IKE_AUTH (without the SAi2, TSi and TSr payloads) along
>    with the Group ID informing the GCKS of the group the initiator
>    wishes to join.
> <mglt>
> I think the latest sentence can be removed - in my opinion.
> </mglt>
>
>
>
>           Hmm. Unless there is any harm from it, I’d rather to keep it.
>
>
> sure.

>  An initiator intending to emit data traffic SHOULD
>    send a SENDER Notify payload status.  The SENDER notification not
>    only signifies that it is a sender, but provides the initiator the
>    ability to request Sender-ID values,
> <mglt>
> I think this is the first time the Sender-ID notion is introduced. I
> expect this to be described in more details in  section  2.5) but since the
> explanation is quite deep involving counter mode... maybe that would be
> clarifying to have an short sentence explaining these Sender-IDs.
> </mglt>
>
>
>
>           The Sender-ID is introduced in Section 1.2.
>
>
> I probably forgot then ;-)

>  in case the Data-Security SA
>    supports a counter mode cipher.  Section 2.5) includes guidance on
>    requesting Sender-ID values.
>
>    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
>    Transforms it is willing to accept for different security protocols
>    by including the SAg payload into the request message.  Proposals for
>    Rekey SA (with protocol GIKE_REKEY) and for Data-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 and
>    willing to support for that protocol.  Valid transform types depend
>    on the protocol and are defined in Figure 16.  Other transform types
>    SHOULD NOT be included.  The SPI length of each Proposal in an SAg is
>    set to zero, and thus the SPI field is empty.  The GCKS MUST ignore
>    SPI length and SPI fields in the SAg payload.
>
> <mglt>
> I think protocol coudl be expanded (AH, ESP, GIKE,) for clarity - but that
> is very personnal.
>
>
>
>           Expanded.
>
>
> SHOULD NOT seems to me related to transforms that are unrelated to the
> protocol. If that is the case, I tend to think MUST is nmore
> appropriated, followed by GCKS  MUST ignore them.
> </mglt>
>
>
>
>           The GCKS may ignore any information from the SAg payload. SHOULD
> NOT here just saves some space,
>
>           but allows implementations to simplify their code base (e.g. use
> the same code as for forming SA payload).
>
>           So I think SHOULD NOT is the right keyword here.
>
>
>           [snip]
>
 ok

>
>    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
>    select an appropriate policy.
> <mglt>
> I remain to be convinced SAg provides any benefit. The only usage I see is
> that it enables a GCKS to check that all nodes support a new algorithm when
> that one will be introduced... but will that information prevent a roll
> over ?...
>
> Note that I am fine with the current text as it would enable me not to
> implement such exchange. Maybe what I woudl like to understand is whether I
> am missing something regarding th eneed of such exchange.
> </mglt>
>
>
>
>           Consider the following use case. Suppose that most of group
> members support algorithms A and B, but some support only B.
>
>           When the group is formed the GCKS selects A as the algorithm for
> this group (for any reason). If GCKS
>
>           keeps a list of current group members, then it will check if any
> new encounter supports A (via the SAg payload).
>
>           In case those few that supports only B try to join the group,
> the GCKS may let them in and initiate an immediate
>
>           rekey of the group SA switching algorithm from A to B. This is
> very important scenario for algorithm rollover,
>
>           which is impossible without SAg payload.
>
>
> The scenario I had in mind is GM not being updated so the GCKS remain
forced to use the oldest transform as opposed to have a policy only connect
if you are up-to date.  So the reason I raise that comment is that by
allowing the nodes to express what they support we force the GCKS to takes
the weakest algo as opposed to being updated by itself -- following
recommendations.
Now, that is also not correct since if one knows there might be some nodes
not upgraded - it will only allow the weakest algo independently if other
nodes support a new algo.

In a word, I am convinced ;-)

>
>    A GM may also indicate the support for IPcomp by inclusion one or
>    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 GCKS.
>
> <mglt>
> s/may/MAY/ ?
> </mglt>
>
>
>
>           Perhaps (“MAY” is an uneasy keyword). Changed to MAY.
>
>
>    Upon receiving the GSA_AUTH response, the initiator parses the
>    response from the GCKS authenticating the exchange using the IKEv2
>    method, then processes the GSA and KD payloads.
>
>    The GSA payload contains the security policy and cryptographic
>    protocols used by the group.  This policy describes the optional
>    Rekey SA (KEK), Data-security SAs (TEK), and optional Group
>    Associated policy (GAP).  If the policy in the GSA payload is not
>    acceptable to the GM, it SHOULD notify the GCKS by initiating a
>    GSA_REGISTRATION exchange with a NO_PROPOSAL_CHOSEN Notify payload
>    (see Section 2.3.2).  Note, that this should normally not happen if
>    the GM includes SAg payload 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.  The GM interprets the KD
>    key packets, where each key packet includes the keying material for
>    SAs distributed in the GSA payload.
> <mglt>
> At that stage of reading the document, the text is bit hard to parse for
> me.
>
>
>           This is an unfortunate result of many edit iterations :-)
>
>
> I do have an idea of what GSA is but KD remains quite obsure at that
> point. Note that maybe I missed where in the document it was explained.
>
> The trext mentions 1 KD payload for TEk KEK - so I interpret the KD as a
> list of keys. Next sentence, it mentions "KD key packets" which suggests
> that there are multiple KD payloads or that the text refers to keys being
> provided outside the  GS_AUTH exchange.
>
>           No, there is a single KD payload which contains list of key
> packets.
>
>           So, “key packet” is not an IKEv2 payload, it is a substructure
> inside the KD payload.
>
>           See section 4.5.
>
>
>
>           Changed this sentence to:
>
>
>
>          The KD payload contains a list of key packets, where each key
> packet includes the
>
>           keying material for SAs distributed in the GSA payload.
>
>
> much clearer to me.

> </mglt>
>
>
>
>
>   Keying material is matched by
> <mglt>
> I suspect that the key material here refers to the key material associated
> toan esp packet. If I am completly lost, maybe I missed a track, if that
> is the case, it might be said clearly as the discussion is for the IKE
> exchange in this section.
> </mglt>
>
>
>
>           Key material is for each multicast SA specified in the GSA
> payload, which can be ESP, AH or GIKE_REKEY.
>
ok

>
>    comparing the SPIs in the key packets to SPIs previously included in
>    the GSA payloads.  Once TEK keys and policy are matched, the GM
>    provides them to the data security subsystem, and it is ready to send
>    or receive packets matching the TEK policy.
>
>    The GSA KEK policy MUST include the attribute GSA_INITIAL_MESSAGE_ID
>    with a first Message ID the GM should expect to receive if it is non-
>    zero.  The value of the attribute MUST be checked by a GM against any
>    previously received Message ID for this group.  If it is less than
>    the previously received number, it should be considered stale and
>    ignored.
> <mglt>
> I have the impression "should" shoudl be replaced by "MUST be ignored"
> </mglt>
>
>
>
>           I agree.
>
>
>   This could happen if two GSA_AUTH exchanges happened in
>    parallel, and the Message ID changed.  This attribute is used by the
>    GM to prevent GSA_REKEY message replay attacks.  The first GSA_REKEY
>    message that the GM receives from the GCKS must have a Message ID
>    greater or equal to the Message ID received in the
>    GSA_INITIAL_MESSAGE_ID attribute.
>
>    Once a GM successfully registers to the group it MUST replace any
>    information related to this group (policy, keys) that it might have
>    as a result of a previous registration with a new one.
>
>
>
>
>
>
> Smyslov & Weis          Expires 10 September 2023              [Page 14]
>
> Internet-Draft                   G-IKEv2                      March 2023
>
>
>    Once a GM has received GIKE_REKEY policy during a registration the
>    IKE SA may be closed.  However, the GM SHOULD NOT close IKE SA,
> <mglt>
> IKE_SA.
>
> I have the impression the only reason to have the IKE_SA open is for rekey
> purpose (GSA_REKEY) or not and I do not see this function being negotiated
> or advertised.
> I think we should assume GSA_REKEY is supported by all modes and if the
> GSKS is willing to us ethe IKE channel it MUST mention it somewhere. I also
> tend to think the GM should advertise GSA_INBAND_REKEY is supported by the
> GM.
>
> In other words, I thinkl it is important the GCKS is aware of what rekey
> method is supported by the GM and it is important the GM does not have to
> maintain alive its IKE_SA.
> </mglt>
>
>
>
>           I see your point. It’s true that currently no negotiation is
> performed.
>
>           It is assumed that any GM supports both GSA_REKEY and
> GSA_INBAND_REKEY.
>
>           It is the GCKS which decides which method to use. For this
> reason the GM should keep IKE SA.
>
>           Either the GCKS will close it and use GSA_REKEY or will use it
> for GSA_INBAND_REKEY.
>
>           The GCKS may use  GSA_INBAND_REKEY only for some GMs (e.g.
> senders, if there are few of them)
>
>           and GSA_REKEY for the rest of the group.
>
>
> I can live with it.

> it is
>    the GCKS who makes the decision whether to close or keep it, because
>    depending on the policy the IKE SA may be used for inband rekeying
>    for small groups.  If inband rekeying is used, then the initial IKE
>    SA is rekeyed (when necessary) via standard IKEv2 mechanism described
>    in Section 1.3.2 of [RFC7296].  If for some reason this SA is teared
>    down and no GIKE_REKEY policy was received during the registration
>    process, the GM MUST consider itself excluded from the group.  To
>    continue participating in the group the GM should re-register.
> <mglt>
> In my mind, the GCKS could use concurent methods depending on the
> capabilities of the GM - not the reverse.
> </mglt>
>
>
>
>           It may use concurrent methods, but it is assumed that both
> GSA_REKEY and GSA_INBAND_REKEY are supported by GMs.
>
>
>
> 2.3.4.  GCKS Registration Operations
>
>    A G-IKEv2 GCKS passively listens for incoming requests from group
>    members.  When the GCKS receives an IKE_SA_INIT request, it selects
>    an IKE proposal and generates a nonce and DH to include them in the
>    IKE_SA_INIT response.
>
>    Upon receiving the GSA_AUTH request, the GCKS authenticates the group
>    member using the same procedures as in the IKEv2 IKE_AUTH.
> <mglt>
> s/ using the same procedures as in the IKEv2 IKE_AUTH. /via the GSA_AUTH
> exchange.
> I think we shoudl stop refering to IKE_AUTH ;-)
> </mglt>
>
>
>
>           OK.
>
>
>
>   The GCKS
>    then authorizes the group member according to group policy before
>    preparing to send the GSA_AUTH response.  If the GCKS fails to
>    authorize the GM, it will respond with an AUTHORIZATION_FAILED notify
>    message.  The GCKS may also respond with an INVALID_GROUP_ID notify
>    message 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 example the capacity of the group is exceeded).
>
>    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
>    group rekey option, it MUST include the GSA_INITIAL_MESSAGE_ID
>    attribute, specifying the starting Message ID the GCKS will use when
>    sending the GSA_REKEY message to the group members if this Message ID
>    is non-zero.  This Message ID is used to prevent GSA_REKEY message
>    replay attacks and will be increased each time a GSA_REKEY message is
>    sent to the group.  The GCKS data traffic policy is included in the
>    GSA TEK and keys are included in the KD TEK.  The GAP MAY also be
>    included to provide the ATD and/or DTD (Section 4.4.3.1) specifying
>    activation and deactivation delays for SAs generated from the TEKs.
>    If the group member has indicated that it is a sender of data traffic
>    and one or more Data Security SAs distributed in the GSA payload
>    included a counter mode of operation, the GCKS responds with one or
>    more Sender-ID values (see Section 2.5).
>
>    [RFC5374] defines two modes of operation for multicast Data-Securirt
> <mglt>
> Security
> </mglt>
>
>
>
>           Fixed.
>
>
>    SAs: transport mode and tunnel mode with address preservation.  In
>    the latter case outer source and destination addresses are taken from
>    the inner IP packet.
>
>
>
> Smyslov & Weis          Expires 10 September 2023              [Page 15]
>
> Internet-Draft                   G-IKEv2                      March 2023
>
>
>    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 with
>    the new group (IDg) and respond with the corresponding group 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 an INVALID_GROUP_ID or REGISTRATION_FAILED notify
>    messages for the reasons described above.
>
>    If a group member includes an SAg in its GSA_AUTH or GSA_REGISTRATION
>    request, the GCKS may evaluate it according to an implementation
>    specific policy.
>
>    *  The GCKS could evaluate the list of Transforms and compare it to
>       its current policy for the group.  If the group member did not
>       include all of the ESP or AH Transforms that match the current
>       group policy, then the GCKS SHOULD return a NO_PROPOSAL_CHOSEN
>       Notification.
>
>    *  The GCKS could store the list of Transforms, with the goal of
>       migrating the group policy to a different Transforms when all of
>       the group members indicate that they can support that Transforms.
>
>    *  The GCKS could store the list of Transforms and adjust the current
>       group policy based on the capabilities of the devices as long as
>       they fall within the acceptable security policy of the GCKS.
>
>    Depending on its policy, the GCKS may have no need for the IKE SA
>    (e.g., it does not plan to initiate an GSA_INBAND_REKEY exchange).
>    If the GM does not initiate another registration exchange or Notify
>    (e.g., NO_PROPOSAL_CHOSEN), and also does not close the IKE SA and
>    the GCKS is not intended to use the SA, then after a short period of
>    time the GCKS SHOULD close the IKE SA.
> <mglt>DISCUSSION
> I remain not convinced SAg is useful - but will not fight for it ;-). This
> is more for a disucssion.
> I do have in mind that having the GM undergoing the GCKS is not
> appropriated, and that it shoudl be the GCKS instead that adapts to the GMs.
> </mglt>
>
>
>
>           With regard to SAg – see my example above.
>
>
>
>           Actually this is the GCKS that adapts to the capabilities of GMs
> – see second and third clauses.
>
>
>
>           I changed the first clause to:
>
>
>
>    *  The GCKS could evaluate the list of Transforms and compare it to
>
>       its current policy for the group.  If the group member did not
>
>       include all of the ESP, AH or GIKE_REKEY Transforms that match the
>
>       current group policy or the capabilities of all other currently
>
>       active GMs, then the GCKS SHOULD return a NO_PROPOSAL_CHOSEN
>
>       Notification.
>
>
> understood

>
> 2.4.  Group Maintenance Channel
>
>    The GCKS is responsible for rekeying the secure group per the group
>    policy.  Rekeying is an operation whereby the GCKS provides
>    replacement TEKs and KEK, deleting TEKs, and/or excluding group
>    members.  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 group members.
>
>    GSA_REKEY  The GSA_REKEY is a pseudo-exchange, consisting of a one-
>          way IKEv2 message sent by the GCKS, where the rekey policy is
>          delivered to group members using IP multicast as a transport.
>          This method is valuable for large and dynamic groups, and where
>          policy may change frequently and a scalable rekeying method is
>
>
>
> Smyslov & Weis          Expires 10 September 2023              [Page 16]
>
> Internet-Draft                   G-IKEv2                      March 2023
>
>
>          required.  When the GSA_REKEY is used, the IKE SA protecting
>          the member registration exchanges is usually terminated, and
>          group members await policy changes from the GCKS via the
>          GSA_REKEY messages.
>
>    GSA_INBAND_REKEY  The GSA_INBAND_REKEY is a normal IKEv2 exchange
>          using the IKE SA that was setup to protecting the member
>          registration exchange.  This exchange allows the GCKS to rekey
>          without using an independent GSA_REKEY pseudo-exchange.  The
>          GSA_INBAND_REKEY exchange provides a reliable policy delivery
>          and is useful when G-IKEv2 is used with a small group of
>          cooperating devices.
>
>    Depending on its policy the GCKS MAY combine these two methods.  For
>    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
>    delivery), and the GSA_REKEY for the rest GMs.
>
> 2.4.1.  GSA_REKEY
>
>    The GCKS initiates the G-IKEv2 Rekey securely, usually using IP
>    multicast.  Since this rekey does not require a response and it sends
>    to multiple GMs, G-IKEv2 rekeying MUST NOT use IKE SA windowing
>    mechanism, described in Section 2.3 of [RFC7296].  The GCKS rekey
>    message replaces the rekey GSA KEK or KEK array, and/or creates a new
>    Data-Security GSA TEK.  The GM_SID attribute in the Key Download
>    payload (defined in Section 4.5.3.3) MUST NOT be part of the Rekey
>    Exchange as this is sender specific information and the Rekey
>    Exchange is group specific.  The GCKS initiates the GSA_REKEY pseudo-
>    exchange as following:
>
>
>     GMs (Receivers)              GCKS (Sender)
>    -----------------            ---------------
>                            <--  HDR, SK{GSA, KD, [N,] [D,] [AUTH]}
>
>                     Figure 9: GSA_REKEY Pseudo-Exchange
>
>
>    HDR is defined in Section 4.1.
> <mglt>
> probably "discussed" is more appropriated than "defined".
> </mglt>
>
>
>
>           Why? Isn’t it defined there?
>
I think I meant "described" at that time and the spell checker transformed
it to "discussed" which does not make sense. That said, I cannot
remember why I made the comment.

>
>   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 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.
>
>    The GSA payload contains the current policy for rekey and Data-
>    Security SAs.  The GSA may contain a new Rekey SA and/or a new Data-
>    Security SAs Section 4.4.
>
>
>
> Smyslov & Weis          Expires 10 September 2023              [Page 17]
>
> Internet-Draft                   G-IKEv2                      March 2023
>
>
>    The KD payload contains the keys for the policy included in the GSA.
>    If the Data-Security SA is being refreshed in this 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 LKH KEK array
>    is updated in the KD payload.
>
>    A Delete payload MAY be included to instruct the GM to delete
>    existing SAs.  See Section 4.6 for more detail.
>
>    The AUTH payload MUST be included to authenticate the GSA_REKEY
>    message if the authentication method is based on public key
>    signatures and MUST NOT be included if authentication is implicit.
> <mglt>
> It is unclear to me what "authentication is implicit" means. I suppose it
> means "we assumes the origin is the KSCS" but we cannot real check that.
> </mglt>
>
>
>
>           Sort of. If no AUTH payload is included, then the receiver only
> knows that
>
>           the message was sent by someone who knows the current group key,
> i.e. some group member.
>
>           There is no real authentication of the GCKS, the receiver just
> trusts that the sender of the
>
>           message is GCKS. Can only be used in small groups of mutually
> trusted members.
>
>
>    In the latter case, the fact that a GM can decrypt the GSA_REKEY
>    message and verify its ICV proves that the sender of this message
>    knows the current KEK, thus authenticating the sender as a member of
>    the group.  Note, that implicit authentication doesn't provide source
>    origin authentication.  For this reason using implicit authentication
>    for GSA_REKEY is NOT RECOMMENDED unless source origin authentication
>    is not required (for example, in a small group of highly trusted
>    GMs).  The value of the Auth Method field in the AUTH payload in the
>    GSA_REKEY message MUST NOT be NULL Authentication.
> <mglt> DISCUSSION
> I am wondering if I am correct in saying that any GM can perform a
> GSA_REKEYunless AUTH is provided. If so, I am wondering if one should even
> consider that implicit authentication is permitted.
> </mglt>
>
>
>
>           Yes. See above.
>
>
>
>           What about whether it is permitted – the GCKS includes
> Authentication Method attribute into the GSA payload.
>
>           So, it is the GCKS who decides whether this is permitted or not.
> Of course, once it indicated that
>
>           authentication is implicit, any GM may impersonate it.
>
>
>
>           [snip]
>
>
> It seems strange to me ;-)

>
>    Because GSA_REKEY messages are not acknowledged and could be
>    discarded by the network, one or more GMs may not receive the new
>    policy.  To mitigate such lost messages, during a rekey event the
>    GCKS may transmit several GSA_REKEY messages with the new policy.
>    The retransmitted messages MUST be bitwise identical and SHOULD be
>    sent within a short time interval (a few seconds) to ensure that
>    time-to-live would not be substantially skewed for the GMs that would
>    receive different copies of the messages.
>
> <mglt> CLARIFICATION
> I suspect that bitwise identical concerns the clear text messag ethat is
> once decrypted. I am wondering if a version number for the rekey would not
> be easier to prevent unecessary replay operations.
>
>
>
>           This is the same rekey message, that is just sent several times
> with a short interval to increase
>
>           the probability of successful delivery. It must be bitwise
> identical on the network (after encryption etc.)
>
ok

>
> I am also wondering if replaying a rekey message would not open the path
> to IV/counters being replayed.
>
>
>
>           No, since it contains the same encrypted data. No new encryption
> operation is performed.
>
>
> That is the reason I was thinking of the clear text. I am not saying that
is not clear, but I think mentioning bitwise of the encrypted message may
even be clearer.

> <mglt>
>
>
>
>
> Smyslov & Weis          Expires 10 September 2023              [Page 21]
>
> Internet-Draft                   G-IKEv2                      March 2023
>
>
>    GCKS may also include one or several GSA_NEXT_SPI attributes
>    specifying SPIs for the prospected rekeys, so that listening GMs are
>    able to detect lost rekey messages and recover from this situation.
>    See Sections Section 4.4.2.2.3 for more detail.
>
> 2.4.1.4.  GSA_REKEY GM Operations
>
>    When a group member receives the Rekey Message from the GCKS it
>    decrypts the message using the current KEK, validates its
>    authenticity using the key retrieved in a previous G-IKEv2 exchange
>    if AUTH payload is present, verifies the Message ID, and processes
>    the GSA and KD payloads.  The group member then downloads the new
>    Data-Security SA and/or new Rekey SA.  The parsing of the payloads is
>    identical to the parsing done in the registration exchange.
>
>    Replay protection is achieved by a group member rejecting a 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 in the first
>    GSA_REKEY message it receives to be equal or greater than the Message
>    ID it receives in the GSA_INITIAL_MESSAGE_ID attribute.  Note, that
>    if no this attribute was received for the Rekey SA, the GM MUST
> <mglt>
> I suspect a nit "if no this" shoudl probably means "if this"
> </mglt>
>
>
>
>           Why? The intended meaning is that if no GSA_INITIAL_MESSAGE_ID
> is sent, then 0 is assumed as initial Message-ID.
>
>
>
>           Probably “If no such attribute” is more clear...
>
maybe:   if the GSA_INITIAL_MESSAGE_ID attribute is not received

>
>    assume zero as the first expected Message ID.  The GM expects the
>    Message ID in subsequent GSA_REKEY messages to be greater than the
>    last valid GSA_REKEY message ID it received.
>
>    If the GSA payload includes a Data-Security SA using cipher in a
>    counter-modes of operation and the receiving group member is a sender
>    for that SA, the group member uses its current Sender-ID value with
>    the Data-Security SAs to create counter-mode nonces.  If it is a
>    sender and does not hold a current Sender-ID value, it MUST NOT
>    install the Data-Security SAs.  It MAY initiate a GSA_REGISTRATION
>    exchange to the GCKS in order to obtain an Sender-ID value (along
>    with the current group policy).
>
>    Once a new Rekey SA is installed as a result of GSA_REKEY message,
>    the current Rekey SA (over which the message was received) MUST be
>    silently deleted after waiting DEACTIVATION_TIME_DELAY interval
>    regardless of its expiration time.
> <mglt>
> I suspect DEACTIVATION_TIME_DELAY is a local policy. If that is correct,
> it shoudl probably be indicated explicitly.
> </mglt>
>
>
>
>           Currently it is indicated by the GCKS.
>
>
>
>           [snip]
>
>
>
>    *  The GCKS uses the method described in [RFC6054], which assigns
>       each sender a portion of the IV space by provisioning each sender
>       with one or more unique Sender-ID values.
>
> <mglt>CLARIFICATION
> Please add rfc8750. I do not see any issue for now, but Sender-ID seems
> problematic.
> </mglt>
>
>
>
>           I do not think RFC 8750 is relevant here. Implicit IVs generally
> cannot be used for
>
>           multicast SAs because there may be several senders for a single
> such SA.
>
>           Since replay protection in this case cannot be achieved,
> sequence numbers
>
>           used by those senders are not coordinated and may overlap.
>
>           For this reason explicit IV is used and the IV includes
> Sender-ID value
>
>           that is unique for each sender, making sure no overlap ever
> happens.
>
>
> ;-(

>
> 2.5.1.  Allocation of Sender-ID
>
>    When at least one Data-Security SA included in the group policy
>    includes a counter-based mode of operation, the GCKS automatically
>    allocates and distributes one Sender-ID to each group member acting
>    in the 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 sender uses the same Sender-ID for each Data-Security SA
>    specifying the use of a counter-based mode of operation.  A GCKS MUST
>    distribute unique keys for each Data-Security SA including a counter-
>    based mode of operation in order to maintain unique key and nonce
>    usage.
>
>    During registration, the group sender can choose to request one or
>    more Sender-ID values.  Requesting a value of 1 is not necessary
>    since the GCKS will automatically allocate exactly one to the group
>    sender.  A group sender MUST request as many Sender-ID values
>    matching the number of encryption modules in which it will be
>    installing the TEKs in the outbound direction.  Alternatively, a
>    group sender MAY request more 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- Security SA nonces using a
>    single Sender-ID too quickly (e.g., before the time-based policy in
>    the TEK expires).
> <mglt>DISCUSSION
> Not sur ethis applies, but if time based policiy is enforced, I think we
> shoudl recommend byte-sent based policies as well.
> </mglt>
>
>
>
>           For bye-sent based policies the GCKS must be also a GM and must
>
>           count the number of bytes received. In this case it can initiate
> rekey whenever it wants.
>
>
>
>           Should we mention this explicitly?
>
>
>
>           [snip]
>
>
>
> I think so unless you believe that  is not necessary.

>
> 2.5.2.  GM Usage of Sender-ID
>
>    A GM applies the Sender-ID to Data-Security SA as follows.
>
>    *  The most significant bits NUMBER_OF_SID_BITS of the IV are taken
>       to be the Sender-ID field of the IV.
>
>    *  The Sender-ID is placed in the least significant bits of the
>       Sender-ID field, where any unused most significant bits are set to
>       zero.  If the Sender-ID value doesn't fit into the
>       NUMBER_OF_SID_BITS bits, then the GM MUST treat this as a fatal
>       error and re-register to the group.
>
>
> <mglt>DISCUSSION
> If I got it correctly, the IV is carrying the Sender-ID. Because of the
> implicit IV, I am wondering if SPI or SN may be not used instead.
> </mglt>
>
>
>
>           No. SPI indicates the SA, so it is the same for all senders in
> this SA.
>
>           SN is not used in most cases (no replay protection if there are
> multiple senders in the SA)
>
>           and may overlap, since senders increment it by their own.
>
>
>
> ok. ;-(

>
>
> Smyslov & Weis          Expires 10 September 2023              [Page 26]
>
> Internet-Draft                   G-IKEv2                      March 2023
>
>
> 2.6.  Replay Protection for Multicast Data-Security SAs
>
>    IPsec provides replay protection as part of its security services.
>    With multicast extension for IPsec replay protection is not always
>    possible to achieve (see Section 6.1 of [RFC3740]).  In particular,
>    if there are many group senders for a Data-Security SA, then each of
>    them will independently increment the Sequence Number field in the
>    ESP header (see Section 2 of [RFC4303]) thus making it impossible for
>    the group receivers to filter out replayed packets.  However, if
>    there is only one group sender for a a Data-Security SA, then it is
> <mglt>
> "a a Data-Security" repeating the word "a".
> </mglt>
>
>
>
>           Fixed.
>
>
>
>           [snip]
>
>
>
> 3.1.1.  Default Key Wrap Key
>
>    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.  The GSK_w is used with the algorithm from the
>    Encryption Algorithm transform for the SA the GSK_w is used in the
>    context of.  The size of GSK_w MUST be of the key size of this
>    Encryption Algorithm transform (taking into consideration the Key
>    Length attribute for this transform if present).
>
>    For the unicast IKE SA (used for the GM registration and for the
>    GSA_INBAND_REKEY exchanges, if they are take place) the GSK_w is
>    computed as follows:
>
>
>
>
> Smyslov & Weis          Expires 10 September 2023              [Page 28]
>
> Internet-Draft                   G-IKEv2                      March 2023
>
>
>    GSK_w = prf+(SK_d, "Key Wrap for G-IKEv2")
>
>    where the string "Key Wrap for G-IKEv2" is 20 ASCII characters
>    without null termination.
>
>    For the multicast Rekey SA the GSK_w is provided along with other SA
>    keys as defined in Section 3.4.
>
> <mglt>CLARIFCATION
> I am wondering why do we have KWK for INBAND_REKEY ? The way I see it, is
> that KWK is used to wrap TEK KEK to protect them. In INBAND_REKEY, these
> keyu woudl already be protected by the IKE channel.
> </mglt>
>
>
>
>           They are protected in case of GSA_REKEY as well.
>
>
>
>           The reason is to isolate sensitive information (keying material)
> from the IKE code.
>
>           KWK allows to hide the keys from all the IKE code that parses
> payloads, forms messages,
>
>           deals with transforms, attributes and so on. So IKE level sees
> only encrypted keys,
>
>           that it can pass to crypto module (which is presumably be more
> protected), which will
>
>           decrypt the keys using KWK and install them for the
> corresponding SAs.
>
>
>
>           Thank you for the very thorough review,
>
>           looking forward for the second part.
>
>
>
>           The changes made so far are available at
> https://github.com/smyslov/G-IKEv2
>
>           They also incorporate some other changes (inspired by Gorry’s
> review, Michael’s review and my own findings).
>
>
>
>           Regards,
>
>           Valery.
>
>
>
> On Thu, Mar 9, 2023 at 8:44 AM Valery Smyslov <[e-mail]>
> wrote:
>
> Hi,
>
> the new version of G-IKEv2 draft is published. It mostly addresses
> comments made by Michael.
> Still waiting for more reviews...
>
> Regards,
> Valery (for the authors).
>
> > -----Original Message-----
> > From: IPsec [mailto:[e-mail]] On Behalf Of
> [e-mail]
> > Sent: Thursday, March 09, 2023 4:37 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-08.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This Internet-Draft is a work item of the IP Security Maintenance and
> Extensions WG of the IETF.
> >
> >         Title           : Group Key Management using IKEv2
> >         Authors         : Valery Smyslov
> >                           Brian Weis
> >   Filename        : draft-ietf-ipsecme-g-ikev2-08.txt
> >   Pages           : 70
> >   Date            : 2023-03-09
> >
> > Abstract:
> >    This document presents an extension to the Internet Key Exchange
> >    version 2 (IKEv2) protocol for the purpose of a group key management.
> >    The protocol is in conformance with the Multicast Security (MSEC) key
> >    management architecture, which contains two components: member
> >    registration and group rekeying.  Both components require a Group
> >    Controller/Key Server to download IPsec group security associations
> >    to authorized members of a group.  The group members then exchange IP
> >    multicast or other group traffic as IPsec packets.  This document
> >    obsoletes RFC 6407.  This documents also updates RFC 7296 by renaming
> >    one of transform types defined there.
> >
> >
> > The IETF datatracker status page for this Internet-Draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-g-ikev2/
> >
> > There is also an htmlized version available at:
> > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-g-ikev2-08
> >
> > A diff from the previous version is available at:
> > https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-g-ikev2-08
> >
> >
> > Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
> >
> >
> > _______________________________________________
> > IPsec mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipsec
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
>
>
>
>
> --
>
> Daniel Migault
>
> Ericsson
>


-- 
Daniel Migault
Ericsson