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
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
