Subject: More on key derivation for SRP

From: Robert Moskowitz <[email-masked]>
Date: Sun, 04 Nov 2001 08:53:02 -0500

I was at the Key management workshop at NIST last week (www.nist.gov/kms).

This workshop is moving toward KM schemes that will be acceptable for US 
gov stuff.  Although the basis for this work is ANSI x9.42 and 9.63, they 
have developed a scheme expression that can represent the 2 ephemeral, 1 
static DH key exchange method.

However, section 6.3 deals with key derivation.  IMHO, it needs some 
work.  IKE's method is VERY close.  The key derivation in sec 5 of rfc 2409 
pretty much fits (different order), and appendix B is a bit different (no 
counter and HMAC instead of HASH).

2409's method is not even in the ball park and is unlikely to be accepted 
by NIST as a good key deriviation method.

Thus I would recommend that following be used:

First NIST may end up REQUIRING key derivation from a master key.  So given:

S is the computed master key.

the derived key is:

K1 = SHA1( S || 1 || clientname || servername )
K2 = SHA1( S || 2 || K1 )
K3 = SHA1( S || 3 || K2 )
.
.

and K = K1 || K2 || K3 || ....

This method will most likely be added as a result of last week's meeting.

BTW, the only current 'approved' method (from 9.42) would be:

K1 = SHA1( S || 1 || clientname || servername )
K2 = SHA1( S || 2 || clientname || servername || K1 )
K3 = SHA1( S || 3 || clientname || servername || K2 )

where K1 K2 etc within the hash is 'shareddata'.

Oh, and Hugo Kracyzk would say that HMAC is better to use in all of this 
over SHA1.  So it is possible that key macs will be allowed in place of a hash.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 4 Nov 2001 10:10:50 -0800 (PST)

The problem of session key derivation from a master key is more general
than just SRP. 

In my opinion, there should be a standard way of deriving session keys
from master keys, that should apply to *all* EAP methods. 

That way, each EAP method doesn't need its own individual session key
derivation algorithm. 

Note that there are issues with applying the algorithm below as a general
EAP key derivation mechanism. 

The algorithm assumes that the master key is accessible and that
operations can be directly performed on it. 

This is not the case for all EAP methods. For example, TLS
and GSS-API implementations typically do not enable direct access to the
master key. However, operations can be performed using functions of the
master key, such as GSS_Wrap(), and GSS_GetMIC(). 

So to make this more general, it would appear necessary to derive
another quantity S', which would then be plugged into the formulas below
in place of S. S' would be a function of S, derived via operations that
are permitted on the master key.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 05 Nov 2001 08:08:17 -0500

At 08:53 AM 11/4/2001 -0500, Robert Moskowitz wrote:

oops one error.  So much for writing this at the Baltimore airport, waiting 
for a flight.

>by NIST as a good key deriviation method.

that is 2945.  The Interleave SHA method.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 05 Nov 2001 08:24:55 -0500

>are permitted on the master key.

By 'Master Key' in this algorithm it refers to a key available to the two 
parties.  Thus a method of key transport or other appropriate mechanism is 
first needed by MOST EAP types to get a Master Key.

For example the practice of the RADIUS server to randomly create a master 
key and then wrap it with the EAP calculated key is one approach.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 05 Nov 2001 08:44:06 -0500

>from master keys, that should apply to *all* EAP methods.

What userinfo is consistant across EAP types or can be made consistant for 
all future types.

Obviously there is the client identity.  Or at least I hope so.  The SRP ID 
has the pseudo ID that can still be used.  What about the servername?  Is 
that consistant?  Somehow, I don't think the Radius Client (NAS, AP, etc) 
name is typically known to the client, but I bet it should.

The thing is, in a key derivation, the crypto people like to have some 
shared data to mix in with the key.  It CAN be public information, like IP 
or MAC addresses, or synced time.  But this mixing has been shown to be 
important.

If you want a general function that can be referenced you need to have such 
things.

Otherwise you have a general algorithm like I showed and a specific use for 
each type.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 5 Nov 2001 08:47:39 -0800 (PST)

> Obviously there is the client identity.  Or at least I hope so.  

Some sort of client identity is always available. This may be garnered
from the EAP-Response/Identity, but this is not required; in some cases it
may be presumed from the calling-station-id. 

> The SRP ID 

The identity of the authenticator is not always known. The question is
whether it is likely to be known for mutually authenticating methods
that derive keys:

   a. It is known in EAP TLS. 
   b. It *may* be known for EAP GSS, depending on the GSS-API method
        selected. 
> Otherwise you have a general algorithm like I showed and a specific use for 

Even if it is necessary to have "classes" of algorithms and a standard key
derivation method for each class, this is better than having a custom
algorithm for each EAP method.

---

From: Robert Moskowitz <[email-masked]>
Date: Mon, 05 Nov 2001 12:23:16 -0500

>algorithm for each EAP method.

Want to whip up a draft?

I probably can get some help from Russ Housley (he was also at the 
meeting), and a NIST person or two.  Tim Polk was also there and has worked 
on this doc.

I suggest you go to www.nist.gov/kms and pull down the schemes workshop 
doc.  Section 6.3 is set up as a function call....

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 06 Nov 2001 11:23:59 -0500

For those of you that have not gotten around to looking at the NIST schemes 
document, I was sent it in editable format (as they are expecting comments 
from me!), and here is section 6.3:

Function call: kdf(Z,OtherInput), where OtherInput is U, V, keydatalen, 
hashlen, [SharedInfo].

Input description:
1.	A bit string Z that is the shared secret.
2.	Bit strings U and V that denote the identities of the participating 
parties, where U is the party that initiated the key establishment process, 
and V is the responder in the key establishment process.
3.	An integer keydatalen that is the length in bits of the keying material 
to be generated. keydatalen must be less than hashlen ? (232-1).
4.	An integer hashlen that is the length in bits of the hash function to be 
used to derive the keying material.
5.	An optional bit string SharedInfo that consists of data shared by 
parties U and V.
Process:
a. Initiate a 32-bit, big-endian bit string counter as 0000000116.
b. For i=1 to i= , do the following:
	Compute Hashi = H(Z||counter||U||V||[SharedInfo])
	Increment counter
	Increment i.
c. Let Hhashj denote Hashj if keydatalen/hashlen is an integer, and let it 
denote the (keydatalen-(hashlen (j-1))) leftmost bits of Hashj otherwise.
d. Set DerivedKeyingMaterial = Hash1||Hash2||…||Hashj-1||Hhashj.
Output: The bit string DerivedKeyingMaterial of keydatalen bits.

[Question: Since both parties need to compute the same derived keying 
material, does the necessity to provide U and V create a problem? For 
example, can all applications determine who the initiator and responder are 
so that they would know in what order to place the identities? Or would it 
be better to alphabetize the identities? Rather than using “U||V”, would it 
be better to use a function of the two entities, such as “(U OR V)||(U AND 
V)”, where “OR” and “AND” are bit-wise logical operators?]

The derived keying material may be parsed into one or more keys or other 
cryptographic keying material (e.g., IVs).

Any scheme attempting to call the key derivation function  for a bit string 
of length greater than or equal to hashlen (232-1) bits must output 
“invalid” and stop.

Note: The security provided by the derived keying material is limited by 
the cryptographic strength of the key establishment scheme. For example, if 
an elliptic curve scheme is used with a 160 bit private key, a strength of 
roughly 80 bits is provided to the derived keying material, i.e., a 128 bit 
AES key derived from such a scheme provides no more than 80 bits of 
security to the information it protects, not the 128 bits of security that 
might be expected when using AES with a truly random key.

Note: This technique differs from the key derivation functions defined in 
ANSI X9.42 and X9.63. In this workshop document, the identities of the 
initiating party (U) and the recipient (V) are included in the data that is 
hashed. In ANSI X9.42 and X9.63, these identities could be considered a 
part of the SharedInfo, which is optional and not defined. ANSI X9.42 also 
includes a second key derivation function that is based on ASN.1 DER encoding.

In the meeting, Russ Housley pointed out that actually 9.42 uses DER 
encoding to sort the order of U and V and thus eliminating the difference 
and potential interop problem between an inititator and responder.

Also RFC 2407 uses HMAC instead of HASH and feeds the result of HASHi into 
HASH(i+1).