> -----Original Message----- > From: Valery Smyslov [mailto:[email protected]] > Sent: Friday, January 15, 2016 3:48 AM > To: Scott Fluhrer (sfluhrer); Michael Richardson; [email protected] > Subject: Re: [IPsec] NIST question concerning IKEv2 and quantum resistance > > 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?
I like it. Someone acting as an active server could determine if two people have the same ppk (by giving them the same random data); however an active server can determine their identities anyways, and so that's not a concern. That does mean that we're allowing the server to make the trade-off between computational complexity and client privacy; if everyone else is OK with that, so am I. The one part that I would ask is that the crypto=xxx be a simple field (for example, it's a 32 bit value in the payload), and not a more complicated payload. My fear is that if we make that parsing more complex, that would add little-used complexity to the protocol (and parts of the protocol that are little used/tested are just havens for exploitable bugs). Ok, I think I'll got ahead and (with my coauthors) revise the draft... > > Regards, > Valery. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
