Subject: Use of AES as prf in IKEv2

From: [email-masked]
Date: Tue, 11 Mar 2003 23:05:49 -0500

Hugo pointed out that the IKEv2 spec assumes that prf functions accept
variable (and arbitrary) size keys, which won't always be the case. I
thought the question was only theoretical because HMAC does and that was
the only prf we defined.

But I notice that we added an IKE Suite #5, which specifies: "AES-CBC MAC +
XCBC integrity and prf". I'm having multiple problems parsing that. I think
I know what AES-CBC MAC is as an integrity protection function. But what
does "+ XCBC" mean and how do we feed two variable length inputs into this
thing for the purpose of doing key expansion.

I suspect AES-CBC MAC + XCBC integrity is well defined and hopefully in an
RFC somewhere. But I'll bet we need to specify a fixed key size (we use 128
bits for encryption, that's probably the intent for integrity protection).
And I'll bet no one really thought about how to use it with a variable
length key for key expansion. IKEv2 computes SKEYSEED = prf ( Ni | Nr ,
g^xy). Nonces are variable length. We could specify (as Hugo recommended)
that each nonce be truncated at half the fixed key size. I'd be happier
using SHA-1(Ni | Nr) truncated as the key. I'd be happier still saying that
even if we're using AES-CBC + XCBC for integrity we still use SHA-1 as our
prf.

What do others think?

          --Charlie

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Uri Blumenthal <[email-masked]>
Date: Thu, 13 Mar 2003 13:50:39 -0500

> thought the question was only theoretical because HMAC does and that was

(:-)  Defined for now!

> thing for the purpose of doing key expansion.

I think Suite #5 is a Good thing, but requires details to be fleshed out.

> prf. What do others think?

I think that using SHA in this context sucks. But am not ready YET to
offer an acceptable variable-input AES-based hash. Talk to y'all at
the meeting.

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 18 Mar 2003 04:14:31 +0200 (IST)

> We could specify (as Hugo recommended)

Not clear that I qualify as "others" but let me express my view here. I am
always glad to see that you are a real fan of HMAC :), yet I do believe
that a serious, long-term, protocol must allow for use of other prf's.
Certainly prf's based on block ciphers. They may turn to be more secure
or more economic (as in the case of h/w implementations that want to save
a HMAC implementation). And, as you noted, we alreadyhave a block cipher
based prf in one of the ciphersuites.

I do not see a problem in requiring the nonces to be strongly random or
pseudorandom. Most implementation that are not able to produce good enough
nonces wil not produce strong enough DH exponents either (except, maybe,
if they generate those on-line). Yet, if this lack of quality randomness
is of real concern then you could opt to define the key as Ni xor Nr. 
The benefit here is that it is enough that one of the peers generates
a good (pseudo) random nonce for the xor to be good. The drawback is that
the responder can fix the xor to any value of his choice. I am not sure
that the latter is a real problem. After all if the (authenticated)
responder in a given session is corupted or malicious then there is no
much meaning to the security of that session. Moreover, contrary to some
seemingly popular belief, either peer can weaken the exchanged key via
their chosen DH exponents. (For example by chosing a 8-bit exponent...)

In any case, I would not leave it to an external per-prf specification to 
determine the way that the key is derived for use in the prf. This will 
probably create confusion and, in practice, will be a barrier to the use
of non-HMAC prfs.

Hugo

---

From: [email-masked]
Date: Tue, 18 Mar 2003 19:20:07 -0500

Having seen the alternatives, I withdraw my earlier objection to Hugo's
proposal for dealing with prf functions with fixed length keys. His
recommendation was that if the prf takes a fixed length key, we take the
first bits of the initiator's nonce as the first half and the first bits of
the responder's nonce as the second half. Not part of his suggestion, but
to make the proposal fully specified in all cases, I'd add that if either
nonce is shorter than half the fixed length key that it be padded with zero
bits.

Does anyone object?

          --Charlie

---

From: Uri Blumenthal <[email-masked]>
Date: Wed, 19 Mar 2003 13:05:24 -0500

Charlie,

I'm looking into this right now and would like a couple
of days - till SAAG meeting - to possibly make a proposal.
Out of hand, what you proposed looks OK.

---

From: Hugo Krawczyk <[email-masked]>
Date: Sat, 22 Mar 2003 01:19:20 +0200 (IST)

Charlie,

instead of stating that "if either nonce is shorter than half the fixed
length key that it be padded with zero bits." why not state that nonces 
MUST be at least of half the length of the prf key? 
This is not an onerous requirement and avoids accepting as "legal" the bad
practice of padding a short cryptographic key with 0s.

In a related issue, I'd also require the pre-shared key, Shared Secret,
to be (at least) of the length of the prf key (again to avoid padding
with zeros).

Hugo