Subject: [eap] EAP-AKA Key derivation

From: Thomas Otto <[email-masked]>
Date: Sat, 7 Jan 2006 09:46:37 +0100

Hi all,

EAP-AKA uses the DSS key derivation function (KDF) to derive
export keying material.

Although the draft describes the KDF briefly (see below), I would
not be able to ... say implement this function. Rather I would have
to look in NIST publication what the SHS actually is ... :-(

So, does anyone know why this burden is in EAP-AKA?

Thomas

__________________
   Step 1: Choose a new, secret value for the seed-key, XKEY

   Step 2: In hexadecimal notation let
       t = 67452301 EFCDAB89 98BADCFE 10325476 C3D2E1F0
       This is the initial value for H0|H1|H2|H3|H4
       in the FIPS SHS [SHA-1]

   Step 3: For j = 0 to m - 1 do
         3.1 XSEED_j = 0 /* no optional user input */
         3.2 For i = 0 to 1 do
             a. XVAL = (XKEY + XSEED_j) mod 2^b
             b. w_i = G(t, XVAL)
             c. XKEY = (1 + XKEY + w_i) mod 2^b
         3.3 x_j = w_0|w_1

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Jari Arkko <[email-masked]>
Date: Mon, 09 Jan 2006 10:03:22 +0200

Clarifying question:

Is the problem that the KDF specification is unclear,
or that a NIST publication is needed to implement it?

---

From: Thomas Otto <[email-masked]>
Date: Mon, 9 Jan 2006 09:40:08 +0100

Hi Jari, all, 

> or that a NIST publication is needed to implement it?

I was wondering why EAP-SIM and EAP-AKA use such a complicated
key derivation function. I do not know what the Secure Hash Standard is,
so I would have to read in NIST documents about it.

I think the construction used by IKEv2

prf+(K,S) = T1 + T2 + T3 + T4 + ...
where
T1 = prf (K, S + 0x01)
T2 = prf(K, T1 + S + 0x02)
T3 = prf(K, T2 + S + 0x03)
T4 = prf(K, T3 + S + 0x04)
...

is more convenient for key derivation. It seems to work nicely. 
Note that DSS-KDF has already patched one time, namely after Daniel
Bleichenbacher found an attack on the first version. Apparently, the
construction of the KDF has been long time not well understood.

What I am just interested in, is the reason of the authors of EAP-SIM
and EAP-AKA for having adopted the DSS-KDF. 

Thomas

_________
PS. The IPsec Working Group has discussed the IKEv2-KDF very
extensively, e.g. in November 2002 here
http://www.vpnc.org/ietf-ipsec/02.ipsec/msg02655.html

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 09 Jan 2006 05:02:02 -0800

It is very common for IETF specifications to reference cryptographic 
functions defined outside of the IETF.  Examples include AES and DES, both 
of which are defined in NIST documents.

>From: Jari Arkko <[email-masked]>
>To: Thomas Otto <[email-masked]>
>CC: [email-masked]
>Subject: Re: [eap] EAP-AKA Key derivation
>Date: Mon, 09 Jan 2006 10:03:22 +0200
>
>Clarifying question:
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 09 Jan 2006 05:05:11 -0800

>and EAP-AKA for having adopted the DSS-KDF.

I'm actually more concerned about the ability to negotiate KDFs.  As you 
note, KDFs are increasingly encountering security issues.  Unless they can 
be negotiated, this is going to cause a problem.

As I understand it, the IETF is going to be looking at negotiation of KDFs 
within protocols such as TLS or IKE.  Also, the implication is that future 
protocols should enable KDF negotiation.

---

From: Thomas Otto <[email-masked]>
Date: Mon, 9 Jan 2006 16:57:56 +0100

Hi Bernard, all,  

> of which are defined in NIST documents.

This may be, but in the IETF, also appropriate mechanisms have been developed.
As I said before, for instance the prf+ in IKEv2. 

So why abstain from using this PRF? The HMAC construction seems much more
comprehensible than the DSS-PRF. 

Is there a particular advantage which I haven't recognized? IS the DSS-PRF 
built-in in the USIM, for instance? This would be an argument, to re-use the
implementation.
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: Thomas Otto <[email-masked]>
Date: Mon, 9 Jan 2006 17:08:31 +0100

Hi Bernard, all, 

> protocols should enable KDF negotiation.

Indeed negotiation seems to be an crucial feature of protocols.
I think all this what we discuss here is preparational work for the upcoming
EMU work ... if the goal is to standardize EAP methods, then this and similar
questions will arise.

Let's look at TLS. At the beginning of the handshake, cryptographic parameters
are negotiated (actually, a bundle of key exchange, encryption and hash 
algorithm). But unfortunately, the pseudo-random function relies on MD5 and 
SHA1. TLS misses to negotiate a PRF. And this is what TLS suffers from.

So, I agree with your argument, to consider KDF negotiation as very important 
feature.