HI Russ, thank you for the follow-up. Please see inline (I snipped text where we are in agreement).
> -----Original Message----- > From: Russ Housley [mailto:[email protected]] > Sent: Tuesday, April 18, 2023 9:29 PM > To: Valery Smyslov > Cc: IETF SecDir; [email protected]; IETF IPsec > Subject: Re: Secdir early review of draft-ietf-ipsecme-g-ikev2-08 > >> 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. I've added a sentence into the Terminology section: This document uses a notation and conventions from [RFC7296] for describing G-IKEv2 payloads and exchanges. Is it enough? [snip] > >> 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. I've updated the second para in Section 2.1 as follows: G-IKEv2 is compatible with most IKEv2 extensions defined so far. In particular, it is assumed that, if necessary, the IKE_INTERMEDIATE exchanges [RFC9242] may be utilized while establishing the registration SA. It is also believed that future IKEv2 extensions will be possible to use with G-IKEv2, however, some IKEv2 extensions require special handling when used with G-IKEv2. See Section 6 for more details. Id it enough? [snip] > > >> 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. I'd rather not to give any concrete numbers in this document. Perhaps, we can refer to Section 2.5.1 of RFC 7383, which discusses how the threshold should be determined? Not all of its recommendations are applicable to multicast (e.g., there is no incoming traffic), but discussion there gives some hints even for such cases. So, how about the following (Section 2.4.1.2, second bullet): * The GCKS must always use IKE fragmentation based on a pre- configured fragmentation threshold, as there is no way to check if fragmentation is needed by first sending unfragmented messages and waiting for response. Section 2.5.1 of [RFC7383] contains recommendation on selecting the fragmentation threshold. Is it enough? > >> 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)" Good idea, thank you! Used this name. > >> 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. A new Section 2.7 is added: 2.7. Encryption Transforms with Implicit IV IKEv2 IANA registry for Encryption Algorithm Transform IDs [IKEV2-IANA] defines several transforms with implicit IV. These transforms rely on ESP Sequence Number for constructing IV (see [RFC8750] for details). It requires replay protection to be enabled for an ESP SA using these encryption transforms. Unless replay protection is active for a multicast ESP SA (see Section 2.6, encryption transforms that rely on Sequence Number for IV construction MUST NOT be used. In any case, such transforms MUST NOT be used for any G-IKEv2 SA (both unicast and multicast). Is it OK? [snip] > >> Minor Concerns: [snip] > >> 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. So, is your concerned addressed or more text is needed? > >> 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. Sure. But in IPSECME documents we are accustomed that IANA automatically changes referenced documents when it is published, so I see no problem here. I don't think we need to bother IANA with request to change references to the WG draft, since they will change them to the RFC anyway. And usually IANA considerations in IPSECME documents omit requests to "change the reference to RFCXXXX", somehow IANA do it automatically (I hope we don't put an additional workload on them) :-) Or am I missing your point here? > >> 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". Will change to "Key Bag", thank you. [snip] > >> Nits: [snip] Since there are quite a lot of changes, I'll publish a new version. Regards, Valery. > Russ= _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
