Hi Paul,
Is it possible to use the already negotiated IKEv2 prf inside the modified
crypto formulas?
In this case they would look like:
SKEYSEED = prf(prf(ppk, Ni) | prf(ppk, Nr), g^ir)
(SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr) =
prf+(SKEYSEED, prf(ppk, Ni) | prf(ppk, Nr) | SPIi | SPIr)
and so on. I'm not a cryptographer, but it seems to me that this is safe, isn't
it?
In this case no additional negotiation is required since prf is negotiated in
IKEv2 anyway and thus we would have algorithm agility in KDF for free.
I like this -- I'm stealing this idea.
Note that using a hash of a hash is frowned upon. See the latest SLOTH
on TLS for an example of a collision attack that used the fact that a
hashed message got hashed again (unlike IKE which hashes only the data)
Not really. IKE does use prf inside prf. Let's expand SK_* computation formula:
SK_* = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) =
prf (prf(Ni | Nr, g^ir), Ni | Nr | SPIi | SPIr | 0x01) |
prf (prf(Ni | Nr, g^ir), prf (prf(Ni | Nr, g^ir), Ni | Nr | SPIi | SPIr | 0x01) | Ni | Nr | SPIi | SPIr | 0x02)
and so on.
I don't think it's wrong from cryptography point of view if the prf is not broken
(usual disclaimer: I'm not a cryptographer).
However, thank you for bringing in the SLOTH attack.
As fas as I understand from the paper http://www.mitls.org/downloads/transcript-collisions.pdf
it is based on the ability for an attacker to find collisions in a weak hashes
(md5 and sha1). In particular the authors uses chosen-prefix collision attacks
to break some security protocols. They mostly focused on breaking TLS,
but Section VI contains description of a possible attack on IKEv2.
As far as I understnd the attack on IKEv2 it is based on the cookie request
feature. The attacker makes a cookie request to the initiator
with the cookie crafted in such a way, that the hash of the IKE_SA_INIT message
containing this cookie would collide with the hash of the IKE_SA_INIT message
containing attacker-chosen KE payload. It would allow the attacker
to impersonate the initiator.
If I got it right the ability for an attacker to quickly find a hash collision
is based (besides using weak hashes) on presumption that
the cookie is always the very first payload in the message,
as depicted in the Section 2.6 in the RFC 7296. So it is
presumed that the cookie always preceedes any unpredictable
for the attacker values in the message, that allows to perform
an effective chosen-prefix attack on a hash.
So, I think that we can completely thwart this attack (regardless
on the possible weakness of the used hashes) if we make
a recommendation for implementers to put the cookie at the
end of the message. RFC 7296 doesn't imply any restrictions
on the payloads order. However the Section 2.6 states:
If the IKE_SA_INIT response
includes the COOKIE notification, the initiator MUST then retry the
IKE_SA_INIT request, and include the COOKIE notification containing
the received data as the first payload, and all other payloads
unchanged.
It's a bit unclear for me whether this MUST is concerned with
the requirement to retry request only, in which case it is only
a recommendation to place the COOKIE before other payloads,
or the MUST is also applied to the text that COOKIE is the
first payload (that would be unfortunate).
What does IPsec community think of it? Should we fix the protocol
to thwart this attack completely? Is the recommendation to
move the COOKIE to the end of the message enough to achive that?
Will this change break many existing implementations?
Regards,
Valery Smyslov.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
