Hi Scott,
However, if no better solution exists I'd prefer to live with a single fixed
crypto primitive, than with two. Is it possible to get rid of AES and to change
the indication of the ppk to use to something like the following?
HMAC_SHA256(HMAC_SHA256(ppk, "A"), random_bytes)
(disclaimer: I'm not a cryptographer)
Your proposal is perfectly sound from a cryptography perspective.
Actually, the reason we proposed the "entry in the AES codebook" approach,
rather than something like the above structure, is due to practical reasons.
When the responder receives the hint, he has no idea which ppk the initiator
is referring to (and he doesn't know the identity yet); our model is that the responder
has a list of ppk's that he knows about, and checks to see if the one that the initiator
had is on the list. It'd be nice if there was a way for the responder to search through
his databases of known ppk's quickly, however I don't know how to let him do it
in sublinear time (without leaking whether two exchanges used the same ppk,
which would leak information about the identities). So, what we settled on is to make
the linear scan for the right PPK as fast as possible. With our proposed solution,
an aggressive responder could have all the AES keys corresponding to the ppk preexpanded,
and just check each potential ppk by doing one AES block encryption (or decryption,
if they prefer); if the implementation has AES-NI, that is fairly fast.
With your proposal, they could preexpand the HMAC keys, but would still need
to do two SHA256 compression function evaluations.
I see the point, thank you. However AES support in hardware is not
always available, so I still think that having a single crypto primitive
is better in this situation.
But your explanations brings me to a conclusion, that the protocol
could me modified. Please see my logical chain.
The necessity to perform a linear serach of the ppk keys (and thus spending
some CPU power) makes a responder more succeptible to DoS attack,
because it must spend resources in response to any IKE_SA_INIT exchange
even from spoofed IP address. In this situation a sane responder would try
to defend itself sending a cookie request - this would guarantee that
the initiator is alive and the IP address is not spoofed. So, if the cookie
request is to be sent in most cases when the IKE_SA_INIT message
contains ppk extension anyway, then the protocol could be modified
to make cookie request mandatory in this situation. Then the IKE_SA_INIT
exchange would look like:
HDR, SAi1, KEi, Ni, N(PPK_SUPPORTED) -->
<-- HDR, N(COOKIE), N(PPK_SUPPORTED,
crypto=xxx, random_data=zzz)
The responder selects prf (and encryption, if it is used) algorithms from the
SAi1
payload. It also supplies random_data that the initiator must use when it
encodes
the ppk. The initiator computes an encoded ppk and retries the request.
HDR, N(COOKIE), SAi1, KEi, Ni, N(PPK_KEY) -->
<-- HDR, SAr1, KEr, Nr, [CERTREQ]
This variant has a disadvantage that ppk will always require an additional
round trip.
However it has the following benefits:
1. Full support for algorithms agility
2. No need to perform CPU-intensive operations until the initiator's IP is
confirmed
3. In this variant it is the responder who supplies random_data to initiator to
encode ppk,
so it is on the responder discretion how to choose them. For example,
it may precompute the encoded ppk values when it is idle, or it can
reuse random_data several times. This allow the responder to perform
the ppk search in sub-linear time in some circumstances.
4. The additional round trip requires a minimum change to IKEv2,
since cookie request must be supported anyway.
What do you think?
Regards,
Valery.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
