Hi Tero,
On Tue, Jan 11, 2022 at 02:22:53PM +0200, Tero Kivinen wrote:
> Benjamin Kaduk writes:
> > I'd also like to confirm that the current (lack of) Updates:
> > relationship between this document and RFC 7296 is correct. In §3.2, we
> > reaffirm that the normal IKE rules for assigning Message IDs apply, so
> > "it is set to 1 for the first IKE_INTERMEDIATE exchange, 2 for the next
> > (if any) and so on". But in §2.2 of RFC 7296 it is claimed that "the
> > first pair of IKE_AUTH messages will have an ID of 1, the second (when
> > EAP is used) will be 2, and so on", where we now have competing claims
> > about what exchange will get Message ID 1. I can see a case to be made
> > that neither of these statements is intended to be normative, and thus
> > that there is no conflict, but wanted to confirm that the WG had
> > considered this topic.
>
> The text in RFC7296 section 2.2 is not normative, it is example of
> what will happen when the normal case. I.e., first exchange will have
> message id 0, and second exchange will have message id 1 etc, for
> normal use of IKEv2 the first exchange will be IKE_SA_INIT and second
> exchange will be IKE_AUTH.
>
> In case IKE_INTERMEDIATE, the first exchange (message id 0) will be
> IKE_SA_INIT, and second exchange (message id 1) will be
> IKE_INTERMEDIATE. For the G-ikev2 the first exchange (message id 0)
> will be IKE_SA_INIT and second exchange (message id 1) will be
> GSA_AUTH. For RFC5723 (Resumption) the first exchange (message id 0)
> will be IKE_SESSION_RESUMPTION, and second exchange (message id 1)
> will be IKE_AUTH.
Thanks for confirming!
> > In a similar vein, it would be good to see some more formal analysis
> > that confirms that this construction authenticates the number of
> > intermediate exchanges that have occurred. I am not sure that I could
> > sketch an attack that uses such a mismatch, but if we are using a threat
> > model where IKE_INTERMEDIATE is used to provide protection against a
> > quantum computer that could break the initial IKE_SA_INIT key exchange,
> > it seems like we need to be sure to protect against "truncation" attacks
> > that cut the quantum-resistant key-exchange out of the authenticated
> > transcript.
>
> Note, that you are here mixing properties from two different
> protocols, ikev2 intermediate and ikev2 multiple ke. IKEv2
> intermediate is supposed to be used to transport large data between
> IKE_SA_INIT and IKE_AUTH. It is not supposed to be quantum resistant
> by itself.
Agreed. This was just an attempt to motivate a sketch of a scenario where
the "truncation attack" might be relevant.
> Quantum resistant part is provided by the multiple key exchanges.
> I.e., every single key exchange run between IKE_SA_INIT and IKE_AUTH
> will provide new cryptographic keys to be used for all future
> IKE_INTERMEDIATE exchanges and those new keys depends on all previous
> key exchanges done.
>
> I.e., when using multiple ke only the first IKE_INTERMEDIATE exchange
> uses the diffie-hellman from the IKE_SA_INIT. The end result of the
> that IKE_INTERMEDIATE is to generate new cryptographic keys using the
> fomula from 3.2.2 of draft-ietf-ipsecme-ikev2-multiple-ke:
>
> SKEYSEED(n) = prf(SK_d(n-1), SK(n) | Ni | Nr)
>
> and
>
> {SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) |
> SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr)
>
> where the SK_d(n-1) is the key derivation key generated by the
> previous step, i.e., in this case the Diffie-Hellman of the
> IKE_SA_INIT.
>
> So every single multiple key exchange run between the IKE_SA_INIT and
> IKE_AUTH will contribute to the final encryption and authentication
> keys used for IKE_AUTH.
Agreed. But prior to that point, the Nth IKE_INTERMEDIATE exchange can be
attacked if the initial IKE_SA_INIT exchange and all IKE_INTERMEDIATE
exchanges prior to the Nth are compromised in realtime. (Admittedly a
strong assumption.)
> This protects against attacks where attacker tries to remove any of
> the multiple key exchanges from the transcript.
>
> On the other hand IKE_INTERMEDIATE might also be used for use cases
> which do not generate keys, for example to transfer some kind of
> policy configuration information before IKE_AUTH etc. The
> IKE_INTERMEDIATE needs to provide the protection against those
> exchanges too, and adding them to the signed data should provide
> protection against attackers.
The question I want to probe here focuses more on the non-cryptographic
input to the signature/MAC, as distinct from the actual key used to make the
MacedIDfor* input. This question remains relevant even if we have some
uses of IKE_INTERMEDIATE other than multiple-ke. In short, I expect that
we have defense in depth, and one part of that (for multiple-ke) is the
actual key used for the MACedIDFor* MAC. Is there another part of that
defense in depth that, say, authenticates the Message ID of the AUTH
message? I think that there are new avenues for attack available if the
attacker is able to cause the initiator and responder to use
InitiatorSignedOctets/ResponderSignedOctets that are of different lengths
on the two parties. (These are not complete attacks on their own, of
course, due to the defense in depth.)
> If I remember correct TLS does the same, the final transcript hash is
> hash of all messages concatenated together including the handshake
> message header, but exlucing record layer headers...
Yes, the TLS transcript hashes all messages concatenated together, but in
TLS there's a clear "end" signal in the Finished message (and the pretty
static handshake structure). Any new messages added to the handshake by
extensions are explicitly negotiated, and that negotiation itself is
protected by the transcript hash. Here, we just have "the usual stuff,
followed by one or more IntAuth_N chunks", with no clear "end" marker.
-Ben
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
