Hi, Daniel I think your text is confusing without the suggestion to use Message ID as a nonce. This suggestion is not in the text, it was only in this email thread.
So I think the text should be (new paragraph at the end of IANA Considerations): These algorithms should be added with this document as ESP Reference and “Not Allowed” for IKEv2 Reference. This seems fitting for https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5 A new document will change that. > On 15 Nov 2017, at 10:10, Daniel Migault <daniel.miga...@ericsson.com> wrote: > > I am more incline to have IIV for iKEv2 in another document and as such we > request the IANA to set the "IKEv2 Reference" to UNDEFINED. > > What about the following text ? > > [RFC8247] recommends the same suites for IKEv2. However some IKEv2 > extensions such as [RFC6311] or [RFC7383] allow the Message ID to be > re-used, which is incompatible with the uniqueness property of > the nonce, and makes these suites highly insecure. As a result, the suites > defined is this document does not apply to IKEv2. The IANA is expected to > put "UNDEFINED" in the column "IKEv2 Reference" for these transforms. > > Yours, > Daniel > > On Tue, Nov 14, 2017 at 8:42 PM, Valery Smyslov <sva...@gmail.com > <mailto:sva...@gmail.com>> wrote: > Hi, > > > > I’m a bit nervous since we are trying to find a quick solution > > to an apparently not-so-easy problem in a rush time of WGLC. > > > > I think we need more time for that, so we either should > > drop the IIV for IKE and proceed with the current document > > for ESP only (and probably creating a new work item – IIV for IKEv2) > > or hold on the draft until we found a solution for IKEv2 too. > > > > What about the way how to make IIV work with RFC6311, I can > > imaging the following solution. Cluster failover generally occurs > > rarely, so we may not worry about the overhead associated > > with sending RFC6311 messages. So we can introduce a combine > > mode, when some messages have implicit IV and some (e.g.RFC6311 messages) > > have explicit IV. Obviously we need to differentiate between them, > > so I presume we need to grab one of reserved bits in IKE header flags > > for this purpose. I admit it looks complicated, but I cannot come up > > with a simpler solution (except for not using IIV in IKEv2 at all). > > > > Regards, > > Valery. > > > > > > From: Yoav Nir [mailto:ynir.i...@gmail.com <mailto:ynir.i...@gmail.com>] > Sent: Tuesday, November 14, 2017 5:36 PM > To: Valery Smyslov > Cc: IPsecME WG > Subject: Re: [IPsec] Proposal for using Implicit IV for IKE > > > > Having re-read RFC 6311, Valery’s right. The synchronization messages in 6311 > all have Message ID zero and are encrypted. There do not seem to be any > cleartext bits that differentiate one such message from another (which is why > the RFC admits that they are replayable). > > > > So I’m kind of stuck. Support IIV or RFC 6311 but not both? Drop the whole > thing? Something else that I’m missing? > > > > Yoav > > > > > On 13 Nov 2017, at 11:30, Valery Smyslov <sva...@gmail.com > <mailto:sva...@gmail.com>> wrote: > > > > Hi, > > > > there is also an RFC6311, which allows messages > > with the MessageID (0) to be sent over the same IKE SA > > in case of cluster failover. If the IKE SA is a result of a rekey > > (not IKE_SA_INIT), then its first encrypted message > > will have MessageID of 0, so if failover happens later, > > the MessageID of zero will repeat, breaking the security. > > You should consider this case also. > > > > Regards, > > Valery. > > > > From: IPsec [mailto:ipsec-boun...@ietf.org <mailto:ipsec-boun...@ietf.org>] > On Behalf Of Yoav Nir > Sent: Monday, November 13, 2017 5:35 AM > To: IPsecME WG > Subject: [IPsec] Proposal for using Implicit IV for IKE > > > > Hi. > > > > So following Daniel’s message in the room, here’s how I think we can make > this work. > > > > The IKE header has a “Message ID” field that is a counter. It’s tempting to > use this as a counter, same as we use the replay counter in IPsec. However, > as Tero pointed out on Jabber, each such message ID can be used several times: > > All responses have the same Message ID as the requests. > The Message ID is one sided. The n-th request from the original Responder > has the same Message ID as the n-th request from the original Initiator. > When a message is fragmented as in RFC 7383, all fragments that are part of > the same message are transmitted (and encrypted) with the same Message ID. > > > Re-using the Message ID makes us re-use the AEAD nonce. Not good. > Fortunately, all the algorithms that the IIV draft mentions require an > 8-octet IV while the Message ID is 4-octet. We can use the 32 “spare” bits > to differentiate these messages. I have two proposals for constructing the > 8-octet IV: > > > > Proposal #1: > > ========== > > | 24 zero bits | Flags (8 bits) | Message ID (32 bits)| > > > > And use IIV only for regular Encrypted Payload, not for Encrypted Fragment. > The reasoning is that if you use fragmentation you’ve already solved the > message-too-big issue. > > > > The Flags octet includes the I(nitiator) and R(esponse) bits, which > differentiate the cases that are not related to fragmentation. > > > > Proposal #2: > > ========== > > | Next Payload (8 bits) | Fragment Counter (16 bits) | Message ID (32 bits)| > > > > The Fragment Counter is the same as in the RFC 7383 fragment payload, or zero > if we are using the regular encrypted payload. > > > > The Flags octet includes the I(nitiator) and R(esponse) bits, which > differentiate the cases that are not related to fragmentation. > > > > The Fragment Counter differentiates between different part of the same > message. > > > > The Next Payload differentiates between sending a message fragmented and > sending it unfragmented. > > > > > > So in summary, I think it’s doable and can be added to the draft if we have > consensus. > > > > Yoav > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org <mailto:IPsec@ietf.org> > https://www.ietf.org/mailman/listinfo/ipsec > <https://www.ietf.org/mailman/listinfo/ipsec> > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
