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

[Yoshihiro Ohba (yohba]

On Tue, May 17, 2005 at 12:47:44AM -0700, Bernard Aboba wrote:
> > 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.
> 
> The EAP Session-ID is effectively an SA name.  

I think naming the SA as a octetstring is over-specifying.  Isn't it
sufficient to say "the SA is identifed by Expanded EAP Type Code and
Method-ID"?


> If the peer and
> authenticator both have the same understanding of what the keys within the
> SA are used for, then I think there is no need to name the keys
> individually.

I agree.

> 
> For example, if we were to meet and shake hands, I would only need to
> greet you, I would not need to make up a name for each of your fingers :)
> 
> However, if it is possible that the keys within the SA will be used in
> different ways, then it seems possible that naming them separately might
> be needed.
> 
> For example, if it is possible that a given authenticator might have both
> the MSK and an AMSK derived from the EMSK, both derived from a
> conversation named by the same EAP Session-ID, and if the peer might be
> able to choose between them, then it would need to have separate names.
> 
> However, the usefulness of a label is not clear.  For example, the peer
> could say "I am selecting the MSK within the SA described by this EAP
> Session-ID" in many ways.

I agree.  

> 
> Note that it is the lower layer that needs to name keys, not EAP.  Since
> EAP does not cache keying material or parameters, it never needs to refer
> to them once they are created and pushed down the lower layer.
> 
> > 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?
> 
> I do not think that is needed because there is never a need to refer to
> the SA in that manner.  However, in key selection, a peer may need to
> indicate which specific key it is attempting to select, in case there are
> more than one.

I agree and please see below for some examples.

> 
> > 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.
> 
> This isn't necessary in IPsec because it is clearly defined what is used
> for what.  You can't use the encryption key for integrity or the integrity
> key for encryption.  Therefore one only needs to be clear about which SA
> is being used.
> 
> > 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.
> 
> I think this make sense, except for a situation in which it might be
> necessary to select between multiple keys within an SA (as in selection
> within a key cache).  Perhaps the right answer is to make sure such a
> situation never occurs (no mixed key caches).
> 

If a key caching is allowed, then I agree that we might need some
label for key versioning within an SA.  For example, PANA defines
Key-Id AVP for that purpose.  Similary, when an MSK is exported to a
particular EAP lower-layer session every time re-authentication is
performed for that session, each MSK for that session may be carried
with a key version information when it is carried from an EAP server
to an authenticator over a AAA protocol.

Yoshihiro Ohba