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

[Valery Smyslov <[e-mail]>]

HI Daniel,

 

thanks for the follow-up, please see inline (some text is snipped, where we are in agreement).

 

From: Daniel Migault [mailto:[e-mail]] 
Sent: Friday, April 14, 2023 11:39 PM
To: Valery Smyslov
Cc: [e-mail]
Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-g-ikev2-08.txt

 

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

 

 

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

 

          OK, I moved this sentence to the beginning of the section.

 

   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.

 

          I’m a bit unsure how to better do it. I’ve added labels indicating IKE SAs, probably this suffice?

          Formally we should also label multicast communications, but I’m not sure how to do it.

          Make them in double lines (==========)?

   [snip]

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

 

          I changed definitions of Data-Security SA and Rekey SA to better match RFC 3740 (which is clearer in my opinion).

          But still, the draft uses “policy” as synonym for “SA” very extensively (alas). I find this  confusing too, but this text was there from ancient times...

 

 

          [snip]

 

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.

 

          OK, will use this, thank you.


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

 

          So, do you think any clarification is needed?


          [snip]



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.

 

          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. 

 

          I changed to:

 

         Once the GCKS accepts a GM to join a

        group it will provide the GM with the data security keys (TEKs) and/or group key

        encrypting key (KEK) as part of the GSA_AUTH response message.

 



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

 

          Changed to:

 

         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

          provided by the GCKS for the GM.

 

          Is it better?

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

 

 

          OK.


   [snip]


   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. 

 

          An AUTHORIZATION_FAILED or REGISTRATION_FAILED may be used in this case (but they are not specific to senders).

 



    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.  

 

 

          I see your point. Probably we should hear from others...

 

          [snip]

   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.  

 

          :-)

 

          [snip]

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

 

          Any suggestions?

 

          [snip]


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. 

 

          Hmm, doesn’t the text “The retransmitted messages MUST be bitwise identical” implies that we are talking about encrypted messages?

          I can change the text to:

 

          To mitigate such lost messages, during a rekey event the

           GCKS may transmit several copies of an encrypted GSA_REKEY message with the new

            policy. The retransmitted messages MUST be bitwise identical...

 

          Is it better?

 

          [snip]

   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

 

          OK.

 

          [snip]

 

          Thank you, and still waiting for the second part :-)

          The changes made so far are available at https://github.com/smyslov/G-IKEv2

 

 

          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