I also think that separate document is a right way to go.
From: mglt.i...@gmail.com [mailto:mglt.i...@gmail.com] On Behalf Of Daniel Migault Sent: Wednesday, November 15, 2017 5:10 AM To: Valery Smyslov Cc: Yoav Nir; IPsecME WG Subject: Re: [IPsec] Proposal for using Implicit IV for IKE 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> 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] 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> 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] 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 https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
