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

[Valery Smyslov <[e-mail]>]

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 :-)


  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.


   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.


  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 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”?


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:

 

   -  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.


   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.       



   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.



   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?


   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.



          [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?

 


  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 ?



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”.



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?


</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.



   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”.



 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.




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.



   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?



    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]

   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.


 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.


 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]


   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.



   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.


</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.


   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.


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.



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?


  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]



   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.)


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.


<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...


   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]




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.





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