On Mon, Apr 17, 2023 at 4:51 AM Valery Smyslov <[email protected]> wrote:
> HI Daniel, > > > > thanks for the follow-up, please see inline (some text is snipped, where > we are in agreement). > > > > *From:* Daniel Migault [mailto:[email protected]] > *Sent:* Friday, April 14, 2023 11:39 PM > *To:* Valery Smyslov > *Cc:* [email protected] > *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 <[email protected]> > 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:[email protected]] On Behalf Of > [email protected] > > Sent: Thursday, March 09, 2023 4:37 PM > > To: [email protected] > > Cc: [email protected] > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > > > > > -- > > Daniel Migault > > Ericsson > > > > > -- > > Daniel Migault > > Ericsson > -- Daniel Migault Ericsson
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
