[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