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

Re: Summary of key derivation thread



Let me be a bit rude: the choice is (a) and everything else is noise!

The reason for  (a) is not that Charlie is busy with specifying other
stuff but because it is the technique with best cryptographic foundation
and with ZERO practical disadvantages.

The only reason to consider other alternatives is only for getting more
than 160 bit of security. This is noise since

1) no one needs that (if you do, use the "pigeons technique" that I
proposed in a previous message or enhance it by protecting the pigeons
with Sommerfeld's quantum black helicopters :)
2) the standard does not force you to do 160-bit security only.
The current specification is  defined to support stronger derivation
algorithms (i.e. stronger prf's). I mentioned SHA2-256 but you can also
use AES-CBC-MAC with 192 or 256 bits too as a prf (allowing the
support of block cipher-based prf's is one reason that I am AGAINST
defining the key derivation in terms of HMAC only as you refer to).

Then there is is the issue of using "prepended-key SHA1" instead of HMAC
for "performance gain". Since the latter performance is a non issue then
it makes no sense to go to weaker than HMAC mechanisms. Especially that I
completely disagree that for the MAC applications in IKEv2 prepended SHA1
is as good as HMAC. You argue that based on the specific details of the
protocol (e.g. last message has some particular form etc). This is a BAD
design approach. The cryptography has to do its work correctly even if
some later version of the protocol changes formats! Another pitfall in
your arguments is that in the key derivation the attacker does not see the
intermediate results. The whole idea of using a prf in key derivation is
to make sure that the keys to different algorithms are computationally
independent and if the key (say T1) derived for one algorithm is
discovered then the other derived keys (SAY T2) are still secure.

Finally, I would like to see the summary of the issue to be advil-free.
Cryptography has made a lot of progress in the last 20 years. One of them
is understanding that adding a key to a hash function is a tricky
business. In particular understanding what is the key to the function and
what is the input is fundamental for actual security and for analysis. No
one said that right cryptography must be intuitive or easy to digest
without a deeper understanding of the scientific fundaments. The history 
of security protocols is full of examples of intuitively correct yet
insecure protocols.

In particular, the current key derivation is based on the
best-analyzed cryptographic techniques that we know today. 
It includes:

1) smooting the entropy of the DH key to 160 bits via a hash function
(heuristically implemented via a prf)

2) using a prf for multiple-key derivation; in particular, making sure
that the keys to different algorithms maintain their computational
independence.

3) making the security depend on the generic properties of the prf rather
in the details of specific functions that may be thought secure today but
found insufficiently secure in the future.

Back to the bottom line: the only reasonable choice is (a) and the rest is
noise.

Hugo

On Thu, 5 Dec 2002, Radia Perlman - Boston Center for Networking wrote:

> 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
> 
> 
> 
>