This has been updated on my local copy... I was waiting to clarify how we handle the iKEv2 issue before publishing the update.
On Tue, Nov 14, 2017 at 9:40 PM, Yoav Nir <[email protected]> wrote: > Oh, and if you’re updating the draft anyway, you should update the > references now that 8221 and 8247 have been published. > > Yoav > > > On 15 Nov 2017, at 10:30, Yoav Nir <[email protected]> wrote: > > 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 <[email protected]> > 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 <[email protected]> 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:[email protected]] >> *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 <[email protected]> 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:[email protected] <[email protected]>] *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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > > > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec > >
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
