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. 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 <[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
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
