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.
> 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.
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.
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.
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...
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
