[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Summary of key derivation thread



Sorry about that...forgot to put a subject line on
my previous post...my excuse is that it's after midnight,
and my mailer crashed once in the middle. Anyway, here's
a repeat of my previous note, so people can have a note
with the proper subject line.

**************************
I'm always urging mailing lists to have someone
summarize a thread that has gone on for awhile, so
I'll try to do so in this case. The intention is
that this email will enable everyone to catch up
with all the arguments, so they wouldn't need to
read any earlier emails on the thread. If anyone
thinks I missed anything, or got anything wrong,
then feel free to correct me, and if the thread
gets long after this summary, we can do another
summary. But I'd like the WG to be able to clearly
reach consensus on these issues.

Basically, the argument is whether the key derivation
should be the Way It Is Now (which I'll call WIIN)
or a different way, which l'll call SD for "Something
Different".

A summary of WIIN:
   SKEYSEED is HMAC of the nonces and the D-H value
   The first 160 bits of key for the IKE-SA is HMAC of SKEYSEED, the
         nonces, the cookies, the one byte constant "1"
   The next 160 bits of key is HMAC of SKEYSEED, the
         previous 160 bits of key, the nonces, and
         the cookies, with the one byte constant incrementing
         for each block of key
   and so on

   The first 160 bits is also called SK_d, and is used in
        the computation of the keying material for child-SAs
   
   Keying material for child-SAs is:
    each 160 bits is HMAC (SK_d, {previous 160 bits of key except for
      first block}, child-SA's nonces, [child-SA's DH], counter)
    
******************
The objections to WIIN are:

. performance: HMAC is, (approximately) two hashes,
  so on small quantities (like
  here) it's twice as slow as a hash. The argument is that SD
  could use any hash, e.g., SHA-1, with twice the performance.
  The counter-argument is that the performance of doing twice
   as many hashes is negligible compared to D-H.

. security: WIIN, no matter what the entropy of the input (e.g.,
   a 2048 bit D-H value), only generates 160 bits of entropy
   for the keys. This is because the only secret value is SKEYSEED,
   which is 160 bits, which generates all the rest of the keying
   bits. The argument is that SD could get more bits by putting
   the D-H value, or parts of it, into each block of key derived.
   This somewhat impacts the performance argument, of course, because
   SHA of something which is twice as many blocks long is twice
   the work. The counter argument is that who needs more than
   160 bits of entropy, and if you do, use HMAC using SHA-256.

. ease of understanding: (this is my opinion, and was not expressed
    in the thread, but I guess I'll throw it in). I found it very
    confusing having the stuff specified as a prf, with exactly two
    inputs, one "secret" and one not, so that one had to figure
    out for each input whether it ought to be considered secret or
    not, and concatenating all the secret values together to form
    one input, and all the nonsecret ones together to form the
    other input. It would have taken fewer reads of the spec, and
    fewer ibuprofen tablets for me, if it had merely been expressed as
    a hash of n inputs.

*******************************
The arguments for WIIN are:

There is a well-known problem with using a keyed hash such as SHA or MD5
that if one knows the value of the hash of (key,data), one can append
stuff to the end of the data and compute the correct hash of the bigger
message without knowing the key. That is the rationale for using HMAC.
If one gets in the habit of using HMAC, you won't "accidentally" have
that problem. However, in all the uses of HMAC in IKE, the appending
attack is not relevant or not possible (for instance, because the
encoding does not allow extra stuff appended without modifying the
message, since the final payload would have said "this is the final
payload". And in computation of the keying material it's totally irrelevant.
No attacker sees the intermediate values.

Another argument for WIIN is that HMAC is already used in so many other
places in IKE, that for ease of coding, it should be used everywhere. The
counter-argument to this is that HMAC requires SHA, so SHA has to be
there anyway, and one could argue (I did in the previous paragraph)
that IKE doesn't really need HMAC at all.

**********************
So, it's not fair to compare a concrete proposal with envisioned
properties of an ideal protocol, especially with just a few months
before we'd the spec done. Russ Housley's proposal meets the
desire of twice-the-performance, but at the same security level
(not getting more than 160 bits of entropy, unless you go to
SHA-2). His proposal is to replace each instance of HMAC with SHA-1.

If we wanted to make it more secure, instead of computing SKEYSEED
to compress the initial bits down to the size of a block, we could
throw the D-H value, or parts of it, into each block of keying material
computation. This would make more bits to hash, so could wind up
losing on the performance argument.

******************
Anyway, hopefully people will find this summary useful, so that people
can express opinions. I suspect Charlie will vote for not changing
things, since he has an awful lot of editing to do in not much time
(including legacy authentication, and the NAT traversal
stuff is wonderously quirky and complicated). But I think the
possibilities are:

a) leave it as it is
b) replace HMAC with SHA-1, thereby increasing performance, but not
   changing the security properties
c) design something that has enhanced security, but does not attempt
   to simultaneously enhance performance (might even be slower)
d) design something that meets both the enhanced performance, and
   enhanced security goals.

Radia