Re: [secdir] Secdir early review of draft-ietf-ipsecme-g-ikev2-08
Russ Housley <housley@vigilsec.com> Tue, 18 April 2023 18:29 UTC
Return-Path: <housley@vigilsec.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699FCC14CE38; Tue, 18 Apr 2023 11:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyInlMC6DiWs; Tue, 18 Apr 2023 11:29:19 -0700 (PDT)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683E0C258609; Tue, 18 Apr 2023 11:29:19 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id 8630D14CF2C; Tue, 18 Apr 2023 14:29:18 -0400 (EDT)
Received: from [192.168.1.161] (unknown [96.241.2.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 662CA14CE68; Tue, 18 Apr 2023 14:29:18 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <06c301d97202$6a31a600$3e94f200$@elvis.ru>
Date: Tue, 18 Apr 2023 14:29:18 -0400
Cc: IETF SecDir <secdir@ietf.org>, draft-ietf-ipsecme-g-ikev2.all@ietf.org, IETF IPsec <ipsec@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <DD98A077-3F7E-43DB-B3B1-D46692542614@vigilsec.com>
References: <168147693267.48130.18098759290140691185@ietfa.amsl.com> <06c301d97202$6a31a600$3e94f200$@elvis.ru>
To: Valery Smyslov <svan@elvis.ru>
X-Mailer: Apple Mail (2.3445.104.21)
X-Scanned-By: mailmunge 3.11 on 66.39.134.11
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/upcMavKSAyqlDRa9_MHaqbHr7ks>
Subject: Re: [secdir] Secdir early review of draft-ietf-ipsecme-g-ikev2-08
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Apr 2023 18:29:23 -0000
> On Apr 18, 2023, at 10:31 AM, Valery Smyslov <svan@elvis.ru> wrote: > > Hi Russ, > > thank you for your review. Please see inline. > >> -----Original Message----- >> From: Russ Housley via Datatracker [mailto:noreply@ietf.org] >> Sent: Friday, April 14, 2023 3:56 PM >> To: secdir@ietf.org >> Cc: draft-ietf-ipsecme-g-ikev2.all@ietf.org; ipsec@ietf.org >> Subject: Secdir early review of draft-ietf-ipsecme-g-ikev2-08 >> >> Reviewer: Russ Housley >> Review result: Not Ready >> >> I reviewed this document as part of the Security Directorate's ongoing >> effort to review all IETF documents being processed by the IESG. These >> comments were written primarily for the benefit of the Security Area >> Directors. Document authors, document editors, and WG chairs should >> treat these comments just like any other IETF Last Call comments. >> >> Document: draft-ietf-ipsecme-g-ikev2-08 >> Reviewer: Russ Housley >> Review Date: 2023-04-05 >> IETF LC End Date: 2022-04-30 >> IESG Telechat date: Unknown >> >> Summary: Not Ready >> >> Major Concerns: >> >> Throughout: RFC 7296 says that SK operations are "Encrypted and >> Authenticated". However, several places we see SK{}. What is being >> authenticated and encrypted in such cases. Similarly, there are >> several places where all of the items in SK{ ... } are optional. >> What is being authenticated and encrypted if they are all absent? >> Maybe I am missing something, but I think some discussion of the >> notation would be helpful. > > SK{...} denotes the "Encrypted payload" (Section 3.14 of RFC 7296). > An empty Encrypted Payload is used in RFC 7296 in several cases - > when peer should send something to complete the exchange, but > there is really nothing meaningful to send. In reality the content > of the "empty" payload is not null - it contains the mandatory Pad Length > field and an optional padding (for counter-based encryption algorithms > there is no padding). So, when sending SK{}, a peer actually sends > one encrypted zero byte (for counter-based modes) and authenticates > the whole message including the IKE header. > > There is nothing new in G-IKEv2 with this regard comparing to RFC 7296. > I don't think any clarification about notation is needed - we have dozens of IKEv2 > extension RFCs which already use this notation with no clarification and in addition > readers are supposed to be familiar with RFC 7296. Or should we say this explicitly? Thanks. I would say near the beginning that the conventions from RFC 7296 are used here. That would have caused me to look more carefully. >> Section 1: RFC 3740 defines a GSA as: >> >> A bundling of Security Associations (SAs) that together define how >> a group communicates securely. The GSA may include a registration >> protocol SA, a rekey protocol SA, and one or more data security >> protocol SAs. >> >> However, this introduction only talks about two aspects of the GSA. >> Please state which data security protocol will be used. I assume it >> supports both ESP and AH. > > That's true. I've added a clarification: > > This specification relies on ESP and AH as protocols for Data-Security SAs. That resolves my concern. >> Section 1: The IKE_INTERMEDIATE exchange is discussed later in the >> document, but the Introduction does not lay the ground work for it. > > The introduction is mostly concerned with group key management > architecture and terminology, since they a bit different from what > IPsec folks are accustomed to. IKE_INTERMEDIATE is not specific > to group key management, so it is not mentioned there. > It is mentioned later to make clear that besides IKE_SA_INIT+GSA_AUTH > other exchanges, defined as IKEv2 extensions, can also be used. > > If I missed your point, then can you please elaborate? I think the Introduction needs to says that IKE_INTERMEDIATE can be used and provide a reference. I was a bit surprised when it came up much later in the document. >> Section 2.4.1.1: Please provide some explanatory text prior to: >> >> DataToAuthenticate = A | P >> GsaRekeyMessage = GenIKEHDR | EncPayload >> GenIKEHDR = [ four octets 0 if using port 4500 ] | AdjustedIKEHDR >> AdjustedIKEHDR = SPIi | SPIr | . . . | AdjustedLen >> EncPayload = AdjustedEncPldHdr | IV | InnerPlds | Pad | PadLen | ICV >> AdjustedEncPldHdr = NextPld | C | RESERVED | AdjustedPldLen >> A = AdjustedIKEHDR | AdjustedEncPldHdr >> P = InnerPlds > > This notation follows a similar one from RFC 7296 (Section 2.15) > and RFC 9242 (3.3.2). > > We can add some text before this, for example: > > The input to the authentication algorithm that computes > the content of the AUTH payload can be described as: > > Is it enough? Yes. That resolves my concern. >> Section 2.4.1.2: The following seems impossible to implement: >> >> * The GCKS must always use IKE fragmentation based on a known >> fragmentation threshold (unspecified in this memo), as there is no >> way to check if fragmentation is needed by first sending >> unfragmented messages and waiting for response. >> >> There is no hint about how to learn the fragmentation threshold, but >> the GCKS MUST NOT use fragmentation unless the fragmentation threshold >> is known. > > It is assumed that fragmentation threshold in this case is pre-configured by administrator. > > Should we clarify this? For example: > > * The GCKS must always use IKE fragmentation based on a pre-configured > fragmentation threshold (unspecified in this memo), as there is no > way to check if fragmentation is needed by first sending > unfragmented messages and waiting for response. > > Is it enough? This helps, but it does not fully resolve my concern. Based on this, an implementer is supposed to provide a configuration setting for the fragmentation threshold. Some guidance about the value is needed. If it is too small, then you needlessly fragment. If too big, some packets will get dropped. >> Section 4.4.2.1.1: It says: "To specify the details of the signature >> algorithm a new attribute Algorithm Identifier (<TBA by IANA>) is >> defined." Shouldn't this simply reference RFC 7427? > > No, it is irrelevant here. Here the draft discusses the way the GCKS informs the GMs about the authentication > method it will use for multicast rekey messages. This is accomplished via the newly defined > IKEv2 Transform Type "Authentication Method (AUTH)" (not to be mixed with "Authentication Payload (AUTH)"). > In case this transform specifies a digital signature algorithm as an authentication method, a newly defined > IKEv2 Transform Attribute "Algorithm Identifier" inside this transform further specifies which digital signature > algorithm to use. IKEv2 transforms and attributes and their use in IKEv2 are defined > in Sections 3.3.1 and 3.3.5 of RFC 7296. > > RFC 7427 is referenced later in this para, when the content of this attribute is discussed. Maybe change the name to avoid the same mistake by others: IKEv2 Transform Type "Authentication Method (AUTHMETH)" >> Section 4.5.1: Some key wrap algorithms do not have an an explicit IV. >> See RFC 3394 for one example. How is a zero-length IV handled? > > Generally, there is no problem if IV is not used - the draft says: > > * IV (variable) -- Initialization Vector used for encryption. The > size and the content of IV is defined by the employed encryption > transform. > > So, if the algorithm doesn't require IV, then this field is absent (implicitly has zero length). > > However, RFC 3394 is not relevant in this case. The draft says: > > The keys are encrypted using algorithm that is used to encrypt the > message the keys are sent in. It means, that in case of unicast IKE > SA (used for GMs registration and rekeying using GSA_INBAND_REKEY) > the encryption algorithm will be the one negotiated during the IKE SA > establishment, while for a GSA_REKEY message the algorithm will be > provided by the GCKS in the Encryption Algorithm transform in the GSA > payload when this multicast SA was being established. > > It means that the key wrapping algorithm must be from the > IKEv2 encryption transforms, i.e. it is must be among those defined in > https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5 > > Actually, there are some algorithms with implicit IV in this registry , but they are prohibited > for using in IKEv2 (and thus in G-IKEv2), they can only be used in ESP. With regard > to multicast ESP SAs, there is further restrictions on using these transforms - > Replay protection must be on (which implies that there is the only sender for multicast SA). > This should be explicitly spelled out in the draft, I'll add a new section. > > Bottom line - there is currently no algorithms defined for use in G-IKEv2 rekey SA without explicit IV > (and I believe algorithms with no/implicit IV must be prohibited there). Please say that the algorithm MUST use an explicit IV. >> Section 5: It says: >> >> S A single attribute of this type must be present >> >> M Multiple attributes of this type may be present >> >> [] Attribute is optional >> >> - Attribute must not be present >> >> I think these should be MUST, MAY, OPTIONAL, and MUST NOT statements. > > Perhaps. Let it be so. Thanks. >> Minor Concerns: >> >> Section 1.2: Please add some punctuation between the term being >> defined and the definition. >> Section 2.2 uses "--" for this purpose. > > Actually, this is more a tooling issue. I tried to use some xml2rfc v3 syntax, > since using v3 is generally being promoted by IESG. > With v3 there is a special tag for definitions and this tag doesn't provide > any means for specifying a punctuation delimiter between the term > and its definition. The only option is to make definition starting from > new line. I'll add the newline attribute if it's OK with you. Sure. New line would be fine. >> Further, it would be very helpful to >> the reader if you say the source of each defined term, instead of >> the catch all phrase at the top of the list of defined terms. > > It is a bit difficult. Same terms are often defined differently in RFC 3740, > RFC 5374, RFC 4046 and RFC 6407. The problem is also that each of those > sources doesn't use terms from the previous RFCs, instead it redefines them :-( > I tried to pick most appropriate ones (from my POV), sometimes compiled > a definitions from different sources or truncated them. > If more strict definitions are needed, then I'd rather ask for help - > currently there seems to be a mess in related RFCs. I understand. Thanks for considering it. >> Section 1.2: Please add "CPI", "LKH", and "NULL Authentication" to >> the definitions. > > LKH is there (the last term). > > For the CPI I prefer to expand on first (and the only) use in the document. > > With regard to "NULL Authentication" -- the more I think about this, > the more I'm sure that referring to "NULL Authentication" in the draft > was a wrong idea. The draft re-uses the code point for NULL Authentication, > which is wrong. I'll re-write the related text and use value 0 (currently "Reserved", > can be renamed to "NONE") to refer to the implicit authentication. > Thank you for bringing my attention to this issue. Thanks. I think the document will be better with these changes. >> Section 2.1.1, 2nd paragraph: I cannot parse it. I think it is trying >> to say: >> >> Section 2.23 of [RFC7296] describes how IKEv2 deals with NATs. >> G-IKEv2 registration doesn't create any unicast IPsec SAs, thus if >> a NAT is present between the GM and the GCKS, there is no unicast >> ESP traffic to encapsulate in UDP. However, the actions described >> in this section regarding the IKE SA MUST be honored. If the GM >> and the GCKS use UDP port 848 for the IKE_SA_INIT exchange, they >> MUST behave in the same manner as if they had used UDP port 500. > > This para is already changed as per Gorry proposed. How about (combining his and yours changes): > > Section 2.23 of [RFC7296] describes how IKEv2 supports paths with NATs. > G-IKEv2 registration SA doesn't create any unicast IPsec SAs, thus if > a NAT is present between the GM and the GCKS, there is no unicast > ESP traffic to encapsulate in UDP. However, the actions described > in this section regarding the IKE SA MUST be honored. > The behavior of GMs and GCKS MUST NOT depend on the port used to create the initial IKE SA. > For example, if the GM and the GCKS used UDP port 848 for the IKE_SA_INIT exchange, they > will operate the same as if they had used UDP port 500. > > Is it OK? Yes. That resolves my concern. >> Section 2.3.2: It says: "When a secure channel is already established >> between a GM and the GCKS, ...". I think it would be more clear to >> say: "After the successful completion of the GSA_AUTH exchange, ...". >> If there is some detail that is not captured by this alternate wording, >> then that detail needs to be explained in this first paragraph of this >> section. > > OK, changed to: > > After the successful completion of the GSA_AUTH exchange, the GM > registration for a group can reuse the established IKE SA. > 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. Yes. That resolves my concern. >> Section 2.3.3: The text mixes the terms "GM" and "initiator". It would >> be more clear to use one term throughout. > > Cleaned up (s/initiator/GM). Thanks. >> Section 2.3.3: It says: >> >> In the simplest case when no dependency between transforms exists, >> all Proposals in SAg payload will have the same value in Proposal Num >> field. >> >> This is a contradiction to other text, especially this: "Proposals >> of different types having the same value in Proposal Num field are >> treated as a set.". So, if there are no dependencies at all, I would >> expect each proposal to have a unique value in Proposal Num field. > > There is no contradiction, there is poor wording :-( > > If IKEv2 each Proposal substructure describes transforms for a particular protocol. > In the case of IKEv2 this would be GIKE_REKEY, AH or ESP. So, the GM will > send at least two proposals - one for GIKE_REKEY and the other for Data-Security SA, > let it be ESP. Then, the Proposal Num allows the GM to express, that there > is a dependency between the transforms for different protocols. For example, > if the GCKS selects algorithm X for GIKE_REKEY, then it must also select > algorithm X for ESP (for example, in case these algorithms are implemented in > HSM and it doesn't allow to export derived keys - so you are stick > to using it for all protocols). To express this the GM will mark proposal > for GIKE_REKEY containing transform X and proposal for ESP containing > transform X with the same Proposal Num. The GM may include > another proposal for these protocols (say, containing transform Y) > with a different Proposal Num. > Un the simplest case, when no dependency exists, proposals for all protocols > will have the same Proposal Num field and each will contain all supported > transforms for a corresponding protocol. > > Please, let me know how the wording can be made more clear. > Currently I made some minor changes for the sake of accuracy: > > Proposal Num field in Proposal substructure is treated specially in > SAg payload: it allows a GM to indicate that algorithms used in Rekey > SA and in Data-Security (AH and/or ESP) SAs are dependent. In > particular, Proposals for different protocols having the same value > in Proposal Num field are treated as a set, so that if GCKS uses > transforms from one of such Proposal for one protocol, then it MUST > only use transforms from one of the Proposals with the same value in > Proposal Num field for other protocols. For example, a GM may > support algorithms X and Y for both Rekey and Data-Security SAs, but > with a restriction that if X is used in Rekey SA, then only X can be > used in Data-Security SAs, and the same for Y. To indicate this the > GM sends several Proposals marking those of them that must be used > together by putting the same value in their Proposal Num field. In > the simplest case when no dependency between transforms exists, all > Proposals in SAg payload will have the same value in Proposal Num > field. Thanks. This is much more clear. >> Section 2.3.3, last paragraph: It is very hard to understand. Perhaps: >> >> Once a GM has received GIKE_REKEY policy during a registration, the >> IKE SA MAY be closed. By convention, the GCKS closes IKE SA. The >> GKCS MAY choose to keep the IKE SA open for inband rekeying, >> especially for small groups. If inband rekeying is used, then the >> initial IKE SA can be rekeyed with the standard IKEv2 mechanism >> described in Section 1.3.2 of [RFC7296]. If for some reason the >> IKE SA is closed before a GIKE_REKEY policy is received during the >> registration process, the GM MUST consider itself excluded from the >> group. To continue participating in the group, the GM needs to >> re-register. > > OK, will use this text with one correction: > > s/before a GIKE_REKEY policy is received/and no GIKE_REKEY policy is received > > This cannot be "before", since it happens at the time of registration (GSA_AUTH). > But GCKS may omit sending GIKE_REKEY policy (including keys) to this particular > GM for some reason (e.g. the GCKS intends to use inband rekey). > In this case, if IKE SA is closed for any reason, the GM should re-register. Thanks. I'm glad you caught my mistake. >> Section 2.3.4: s/The GCKS may also respond with an INVALID_GROUP_ID/ >> /The GCKS SHOULD respond with an INVALID_GROUP_ID/ > > I don't mind, but in this case in addition: > > s/it will respond with an AUTHORIZATION_FAILED/it SHOULD respond with an AUTHORIZATION_FAILED Thanks. Good improvement. >> Section 2.4: Please add some punctuation between the type of group >> maintenance channel and the description of that channel. Section 2.2 >> uses "--" for this purpose. > > See above about the tooling issue. I added an attribute that puts definition on the next line. Yes. That resolves my concern. >> Section 2.4.1: It says: >> >> 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]. >> >> I was not able to get the meaning on first reading. Perhaps: >> >> Since the Rekey message does not require a response and it is sent >> to multiple GMs, the GCKS MUST NOT use the IKE SA windowing >> mechanism described in Section 2.3 of [RFC7296] for the Rekey >> message. > > I prefer: > > Since the Rekey messages do not require responses and they are sent > to multiple GMs, the windowing mechanism described in Section 2.3 > of [RFC7296] MUST NOT be used for the Rekey messages. > > Does it work for you? Yes. That resolves my concern. >> Section 2.4.1.4: It says: >> >> 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. >> >> It is unclear which part of the processing depends on the presence of >> the AUTH payload. Please reword to be clear which parts are always >> done and which parts are done only if the AUTH payload is present. > > How about the following: > > When a group member receives the Rekey message from the GCKS it > decrypts the message and verifies its integrity using the current KEK. If the AUTH payload is present > in the decrypted message, then the GM validates authenticity of the message using the key retrieved > in a previous G-IKEv2 exchange. Then the GM verifies the Message ID, and processes > the GSA and KD payloads. Thanks. This is much more clear to me. >> Section 3.3: It says: >> >> ... In particular, the GM's task >> is to find a way to decrypt at least one of the SA_KEY attributes >> using either the GSK_w or the keys from the WRAP_KEY attributes that >> are present in the same message or were receives in previous >> messages. >> >> This is really a transition sentence to prepare the reader for the >> following paragraphs. On my first reading, it sounds more like a >> challenge or goal. I suggest: >> >> ... The GM decrypts at least one of the SA_KEY attributes using >> either the GSK_w or the keys from the WRAP_KEY attributes that >> are present in the same message or were received in previous >> messages as described below. > > I propose: > > ... The GM tries to decrypts at least one of the SA_KEY attributes using > either the GSK_w or the keys from the WRAP_KEY attributes that > are present in the same message or were received in previous > messages as described below. > > (if GM is being excluded from the group using LKH, then it cannot decrypt any SA_KEY, > but since it doesn't know this, it will try to do it). > > Is it OK? Yes. That resolves my concern. >> Section 3.4: The text talks about "first bits", which is ambiguous. >> Perhaps "most significant bits" or "leftmost bits in Network Byte >> Order". > > Changed to "leftmost bits" (I believe byte order is irrelevant here since we're talking about strings, not integers). Okay. That resolves my concern. >> Section 4: I find the structure of this section difficult. The >> discussion mixes the payloads that are reused from IKEv2 and the new >> ones that are defined for G-IKEv2. I think it would be easier to >> follow if the ones that are reused from IKEv2 were discussed in a >> subsection and then a separate subsection talked about the new >> payloads. > > Hmm, I'm a bit confused. All Section 4 is about new payloads, > specific to G-IKEv2, with the exception of the G-IKEv2 header, > which is identical to IKEv2 header. Two payloads (SAg and IDg) > have the same format as existing IKEv2 payloads, but different semantics. > > The problem with subsections is that in this case the nesting level > for new payloads will be too deep: currently there exists 4.4.2.1.1., > will be one level deeper. > > Perhaps it is sufficient if I add the following text to the beginning of Section 4: > > G-IKEv2 header (Section 4.1), > IDg payload and SAg payload reuse IKEv2 format for the IKEv2 header, > IDi/IDr payloads and SA payload respectively. > > Does it help or not? Maybe I am being confused by this part of the first paragraph: ... New exchange types GSA_AUTH, GSA_REGISTRATION, GSA_REKEY and GSA_INBAND_REKEY are also added. The addition of "(Section 4.1)" is helpful. >> The identifiers for the new payloads have already been >> assigned by IANA, but the IANA registries point to draft-yeung-g-ikev2. > > That's true, they were assigned a long ago. Yes, but you want the IANA registries to point to this document once it is approved. >> Section 4.5: I find the term "Key Packets" confusing. I suggest a >> better term might be "Wrapped Keys". Similarly, the use of "packet" >> should be changed in "Group Key Packet" and "Member Key Packet". > > Perhaps "Key Bag"? Or "Key Bundle"? > > By definition Key Packet contains several related keys, > and is referred to some substructure, so "Wrapped Key" > seems to be not a good substitution. > > No changes made so far, waiting for more discussion. Either "Key Bag" or "Key Bundle" could resolve my concern. I have a mild preferences for "Key Bag". >> Section 6.1: Its says: "Below are possible scenarios involving using >> PPK." Some of them do not use PPK. Please reword. > > Changed to: > > This is illustrated below. > > I also removed some unnecessary stuff (optional PPK). This change resolves my concern. >> Section 7.2.1: I understand that implicit authentication doesn't >> provide source origin authentication, but there is a bit more that >> can be said here. Can the GM determine that each message came from >> the same entity, even if the GM cannot be sure that entity is the >> GCKS? > > I don't think it can. With implicit authentication any member of the group > can impersonate the GCKS. The source IP address can be set to any value, > since no reply is needed. Okay. No change needed. >> Nits: >> >> All: Some places the document uses "Data Security SAs" and other >> places it uses "Data-Security SAs". Please pick one. > > Changed to Data-Security SAs. Thanks. >> Section 1: It says: "... that allows to perform a group key ...". >> What entity does it allow to perform group key management? I think >> is should say: "... that allows the GCKS to perform a group key ...". > > This text is already changed to (by other reviewer's request): > > This document presents an extension to IKEv2 [RFC7296] called > G-IKEv2, which allows performing a group key management. > > Is it OK? Yes. That resolves my concern. >> Section 1: It says: "... (see Appendix A of [RFC7296]." Please add a >> closing parenthesis. > > Done (also caught by other reviewer). Okay. >> Section 1: It says: "Large and small groups may use different sets of >> these protocols." I think that "protocols" is the wrong word. I think >> that "exchanges" is a better word. > > I prefer "Large and small groups may use different sets of these mechanisms." > > (since GSA_REKEY is not an exchange, it is one-way message). > > Is it better? Yes. That resolves my concern. >> Section 1.2: s/[RFC4301], its extension/[RFC4301], and its extension/ > > OK. > >> Section 1.2: s/good understanding/an understanding/ > > Don't mind. > >> Section 2.1: s/However some/However, some/ > > Fixed. > >> Section 2.1.1: s/As IKEv2 extension G-IKEv2/As IKEv2 extension, G-IKEv2/ > > Done. > >> Table 1 caption: s/the protocol/G-IKEv2/ > > OK. > >> Section 2.3: s/The registration protocol consists/Registration consists/ > > Well, let it be so. > >> Section 2.3.3: s/Section 2.5)/Section 2.5/ > > Fixed. > >> Section 2.3.3: s/AEAD and non-AEAD transforms must not be combined in/ >> /AEAD and non-AEAD transforms not be combined in/ > > Well, this change is less obvious for my non-native ear, but I trust you here. > >> Section 2.3.3: It says: "... those of them that must be used ...". >> Please reword. The use of the word "must" here caused me to miss the >> meaning on first reading. Perhaps: >> >> Use of the same value in the Proposal Num field of different >> proposals indicates that the GM expects these proposals to be >> used in conjunction with each other. > > OK, will use this text. > >> Section 2.3.3: s/SHOULD NOT close IKE SA/SHOULD NOT close the IKE SA/ > > I cannot find this particular text, probably it is gone in the process of editing. > Anyway, I got the idea with "the" and fixed whenever found. Okay. >> Section 2.3.4: s/Data-Securirt/Data-Security/ > > Cannot find, probably fixed earlier. Okay. > >> Section 2.3.4: s/GCKS may have no need/GCKS may have no further need/ > > OK. > >> Section 2.4.1: s/Rekey securely, usually using/Rekey, usually using/ > > I understand that the current wording is weird, but shouldn't we emphasis > that rekey messages are sent over secure (one-way) channel? > > Perhaps: > > The GCKS initiates the G-IKEv2 Rekey by sending a protected message to the GMs, > usually using IP multicast. Thanks. Much better, I think. >> Section 2.4.1.1: s/The chunk A lasts from/The chunk a starts with/ > > OK. > >> Section 2.4.1.1: s/to the last octet/and continues to the last octet/ > > Ditto. > >> Section 2.4.1.2: s/ messages, however when/ messages; however, when/ > > Done. > >> Section 2.4.1.3: s/must have the Message ID 0/MUST use Message ID of 0/ > > Fixed. > >> Section 3.2: s/individual GMs' keys/keys for each GM./ > > OK. > >> Section 3.3: s/GCKS's key management method/ >> /key management method use by the GCKS/ > > Sorry, perhaps > > key management method used by the GCKS > > ? Yes. That is better. >> Section 4: The punctuation needs corrections. I suggest: >> >> ... However, the processing of some payloads are >> different. Several new payloads are defined: Group Identification >> (IDg), Group Security Association (GSA), and Key Download (KD). > > OK. This text is also addressed in Minor Issues. > >> Section 4.4.2.1: s/Method (AUTH)and/Method (AUTH) and/ > > Already fixed. > >> Section 4.5: s/a keys and/keys and/ > > Fixed. > >> Section 7.1: s/in [RFC7296] section 5 Security Considerations/ >> /in the Section 5 of [RFC7296]/ > > Done. > >> Note: I did not review the Appendix. > > Thank you for the thorough review. > > The changed made so far are available at: > https://github.com/smyslov/G-IKEv2 Russ
- [secdir] Secdir early review of draft-ietf-ipsecm… Russ Housley via Datatracker
- Re: [secdir] Secdir early review of draft-ietf-ip… Valery Smyslov
- Re: [secdir] Secdir early review of draft-ietf-ip… Russ Housley
- Re: [secdir] Secdir early review of draft-ietf-ip… Valery Smyslov