Hi,
I have had off the list discussion with Tobias Brunner and he has pointed out
to one potential issue
with draft-ietf-ipsecme-ikev2-intermediate. Currently the authentication of
IKE_INTERMEDIATE
exchanges is performed as follows:
InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI | IntAuth
ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR | IntAuth
IntAuth = IntAuth_1 [| IntAuth_2 [| IntAuth_3 ... ]]
IntAuth_1 = IntAuth_1_I | IntAuth_1_R
IntAuth_2 = IntAuth_2_I | IntAuth_2_R
IntAuth_3 = IntAuth_3_I | IntAuth_3_R
...
IntAuth_1_I = prf(SK_pi_1, IntAuth_1_I_A [| IntAuth_1_I_P])
IntAuth_2_I = prf(SK_pi_2, IntAuth_2_I_A [| IntAuth_2_I_P])
IntAuth_3_I = prf(SK_pi_3, IntAuth_3_I_A [| IntAuth_3_I_P])
...
IntAuth_1_R = prf(SK_pr_1, IntAuth_1_R_A [| IntAuth_1_R_P])
IntAuth_2_R = prf(SK_pr_2, IntAuth_2_R_A [| IntAuth_2_R_P])
IntAuth_3_R = prf(SK_pr_3, IntAuth_3_R_A [| IntAuth_3_R_P])
...
So, a new blob IntAuth is added to signature or MAC calculation.
Note, that the size of IntAuth blob depends on the number of IKE_INTERMEDIATE
exchanges that took place: each IKE_INTERMEDIATE exchange increases it by the
2x <size of prf>.
The potential problem with this scheme that Tobias pointed out to is that
if the number of IKE_INTERMEDIATE exchanges is controlled by the initiator
(this is not true for draft-ietf-ipsecme-ikev2-multiple-ke, but may be true for
other applications of IKE_INTERMEDIATE), then malicious initiator
may mount a memory exhaustion attack on responder by performing a large number
of IKE_INTERMEDIATE exchanges.
Besides this attack (which is more a theoretical concern, since the size of prf
is pretty
small and the number of IKE_INTERMEDIATE exchanges will not be counted by
thousands or even hundreds in any case), the inconvenience of the current
scheme for
the responder is that in case it uses some HSM with limited internal storage
for storing intermediate IntAuth_* and it doesn't know beforehand the number
of IKE_INTERMEDIATE exchanges (again, this is not true for
draft-ietf-ipsecme-ikev2-multiple-ke,
but may be true for other applications of IKE_INTERMEDIATE), then the internal
resources
of this HSM will be wasted. Again, this is more a theoretical concern, since
IntAuth_* are not secret and can pe pulled from HSM and stored in main memory.
The bottom line. The problem that IntAuth is growing with each IKE_INTERMEDIATE
exchange do exist, but in my opinion, the potential bad consequences from it
are mostly theoretical. That said, we can fix this problem by re-defining the
IntAuth calculation as follows (the scheme suggested by Tobias):
InitiatorSignedOctets = RealMsg1 | NonceRData | MACedIDForI | IntAuth
ResponderSignedOctets = RealMsg2 | NonceIData | MACedIDForR | IntAuth
IntAuth = IntAuth_N_I | IntAuth_N_R
IntAuth_1_I = prf(SK_pi_1, IntAuth_1_I_A [| IntAuth_1_I_P])
IntAuth_2_I = prf(SK_pi_2, IntAuth_1_I | IntAuth_2_I_A [| IntAuth_2_I_P])
IntAuth_3_I = prf(SK_pi_3, IntAuth_2_I | IntAuth_3_I_A [| IntAuth_3_I_P])
...
IntAuth_N_I = prf(SK_pi_N, IntAuth_N-1_I | IntAuth_N_I_A [| IntAuth_N_I_P])
IntAuth_1_R = prf(SK_pr_1, IntAuth_1_R_A [| IntAuth_1_R_P])
IntAuth_2_R = prf(SK_pr_2, IntAuth_1_R | IntAuth_2_R_A [| IntAuth_2_R_P])
IntAuth_3_R = prf(SK_pr_3, IntAuth_2_R | IntAuth_3_R_A [| IntAuth_3_R_P])
...
IntAuth_N_R = prf(SK_pr_N, IntAuth_N-1_R | IntAuth_N_R_A [| IntAuth_N_R_P])
This will make the size of IntAuth blob constant regardless of the number of
performed IKE_INTERMEDIATE exchanges.
The draft draft-ietf-ipsecme-ikev2-intermediate has passed WGLC and is now
waiting for AD review. There are few interoperable implementations,
but none are used in production yet (to my best knowledge).
So, the question to the WG is - what should we do with this:
1. Re-define calculation of IntAuth to make it constant in size.
This will most probably require another WGLC and will break
interoperablity of existing products. The latter seems not so
important (no product has been released yet), but the former
may delay publication process.
2. Leave calculation of IntAuth as is and add some text to the
Security Considerations section that describes potential
problems and makes advise to the responder (e.g.
limit the number of accepted IKE_INTERMEDIATE exchanges).
This will not change bits on the wire and hopefully
will not require another WGLC.
3. Ignore this issue (do nothing).
Opinions?
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
