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 > > <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] >> <mailto:[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] >> <mailto:[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] <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] >> <mailto:[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] <mailto:[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] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/ipsec >> <https://www.ietf.org/mailman/listinfo/ipsec> >> >> >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
