eap Mailing List: Re: Key derivation and the principle of equivalence

[Yoshihiro Ohba (yohba]

On Sun, May 15, 2005 at 05:57:05PM -0700, Bernard Aboba wrote:
> Here is some revised text which adds in support for Channel Bindings,
> removes the dangling AAA references, and cleans up other miscellaneous
> issues.  Next, I'll work on cleaning up the text relating to the lower
> layer.

(snip)

> 
> Key Naming
> 
>    The naming of keys within the EAP key hierarchy is based on the EAP
>    Session-ID.

I have a fundamental question on why we need to define a name to each
of key derived from a given SA.  This question has came up while I was
reviewing IEEE 802.16e document in which a bunch of key names are
defined.

For example, in RFC 2401, an IPsec SA is identified with three
parameters, i.e., an SPI, an Destination IP Address and a security
protocol(*).  What is the importance of concatenating those parameters
into a string?

Also, an IPsec SA has several ciphering keys such as encryption keys
and integriry keys, but once an SA is identified with the above
parameters, I don't see an importance to give a name to each ciphering
key within the SA.

It seems to me that defining, for each SA type, a set of parameters
that are needed to identifiy an SA among different SAs of the same
type, seems to be important and sufficient.  Giving a name to every
key that belongs to the same SA does not make much sense.

(*) In rfc2401bis, an IPsec SA is identified just with an SPI.

Yoshihiro Ohba


> 
>    MSK Name
> 
>       This key is created between the EAP peer and EAP server, and can
>       be referred to using the string "MSK:", concatenated with the EAP
>       Session-ID.
> 
>    EMSK Name
> 
>       The EMSK can be referred to using the string "EMSK:", concatenated
>       with the EAP Session-ID.
> 
>    IV Name
> 
>       Use of the IV is deprecated.  However, if necessary the IV can be
>       referred to using the string "IV:" concatenated with the EAP
>       Session-ID.
> 
>    PMK Name
> 
>       This document does not specify a naming scheme for the PMK.  The
>       PMK is only identified by the key from which it is derived.
> 
>       Note: IEEE 802.11i names the PMKID for the purposes of being able
>       to refer to it in the Secure Association protocol; this naming is
>       based on a hash of the PMK itself as well as some other parameters
>       (see Section 8.5.1.2 [IEEE-802.11i]).
> 
>    TEKs
> 
>       The TEKs may or may not be named. Their naming is specified in the
>       EAP method.
>