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