[IPsec] Puzzle algorithm negotiation

[Yoav Nir <[e-mail]>]

Pull Request: https://github.com/ietf-ipsecme/drafts/pull/2 <https://github.com/ietf-ipsecme/drafts/pull/2>

Hi,

Valery has created this pull request. During the meeting in Honolulu and subsequent discussion on the list, several people requested that there be a negotiation of the algorithm used in the puzzle rather than fixing it to SHA-256.

The pull request suggests figuring out which algorithms the Initiator supports by examining the SA payload in the IKE_SA_INIT request, and using the PRF algorithms.

I’m posting this to the list, even thought we’re not sure about this. Specifically, PRF_AES128_XCBC and (I think) PRF_AES128_CMAC won’t work with the bitcoin-like puzzle that is currently in the draft.

Why?

For convenience assume a 16-byte cookie, a fixed zero IV (as always in AES-XCBC) and fixed zero key.

So let Y = AESENC(key, IV XOR COOKIE) = AESENC(zero, COOKIE)
Let Z = AESDEC(key, zero) = AESDEC(zero, zero)
Extend the cookie by Y XOR Z.

The result will give you a 128-bit tag of all zeros. Way too easy.

Another way to do this is to add a notification in the Initiator’s request listing the hash algorithms that it supports. We could reuse the RFC 7427 registry of hash algorithms. 

Personally, I really don’t like this algorithm agility, because we don’t want to give the Initiator the options of a hard vs easy puzzle. So suppose the Responder supports two algorithms, SHA-256 and SHA-512, and that the latter is half as fast as the former, then a SHA-512 puzzle would have to have 1 bit less than the SHA-256 puzzle. But in fact, we know that SHA-512 is faster on 64-bit platforms, while SHA-256 is faster on 32-bit platforms. Add some GOST-certified hash to the mix, and the administrator’s task becomes that much harder. OTOH often when a protocol is published without algorithm agility, we end up extending it later.

Yoav