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

[Daniel Migault <[e-mail]>]

On Mon, Apr 17, 2023 at 4:51 AM Valery Smyslov <[e-mail]>
wrote:

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

>    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 (==========)?
>
unless there is something obvious to do, we can leave this as it is.

>    [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...
>
>
>
>
>
seems fine if we know it is in the SA side (not SP), we can understand what
policies mean at the other places. I think that it is reasonable to not
change everywhere.  ;-)

>           [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?
>
No, I think previous comments addressed that concern.

>
>           [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.
>
>
>
seems fine to me.

>
>
> 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?
>
I think so.

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

>
>
>     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...
>
>
>
probably a bis draft ;-)

>           [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?
>
>
>
I suspect that we have this unauthenticated mode for some reason... so just
keep it.

>           [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?
>
>
>
I think /retransmitted/ (encrypted) retransmitted/ in any of the sentences
would address my concern.

>           [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
>
>
>
Let's hope I can make it this week!

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


-- 
Daniel Migault
Ericsson