Subject: [eap] EAP-Keying issue

From: [email-masked] (Joe Salowey)
Date: Tue, 4 Feb 2003 09:02:38 -0800

Description of issue: Inconsistency in EAP Keying
Submitter name: Joseph Salowey=20
Submitter email address: [email-masked]=20
Date first submitted: Feb 4, 2003
Reference:=20
Document: RFC2284bis, Keying Framework
Comment type: T=20
Priority: 1
Section: 7.9=20
Rationale/Explanation of issue:=20
Currently EAP provides a consistent interface to authentication data but
it does not provide a consistent interface  to deal with key data.  This
makes it difficult to treat EAP mechanisms similarly.  EAP mechanisms
end up needing to know more about applications then they should and
applications do not have a consistent way of deriving keys. The
following proposal addresses this.

Requested change:=20

In the description below the term "EAP Framework" controls the
interaction between and EAP mechanism and the environment.  The term
"application" refers to a consumer of EAP authentication service and key
material. An application may be a link layer protocol such as 802.11 or
another EAP mechanism chained into the EAP conversation after initial
authentication.

If an EAP mechanism derives keys then it MUST be able to export a
256-bit Master Session Key (MSK) to the EAP framework.  THis key must be
cryptographically independent of the Master Key (MK) established within
the authentication mechanism or any other key used by the authentication
mechanism.  In this case cryptographically independent means that
knowledge of the MSK will not give away information of the MK.   The
underlying entropy used to generate the key SHOULD be at least a 128
bits (more if greater than 128-bit ciphers are in use by applications).
The MSK is never used in an application directly rather it is used to
derive application specific master session keys and ciphering keys.  The
following describes the EAP key derivation mechanism.

The EAP key derivation function is as follows

Key  =3D PRF(MSK, key seed, length)

Where MSK is the master session keys described above, the key seed is an
application specific value which is unique to each application, and
length is the number of bytes of key material needed.  The PRF is a
suitable pseudo-random function.  Good candidates for the PRF are the
IKE PRF, the TLS PRF and possibly the SHS PRF.  The keys seed is an
octet string which should be assigned by IANA for application uses.
Examples of some key seeds are:

"IEEE 802.11i Master Session Key"
"IEEE 802.11 WEP session key"
"IEEE 802.11 WEP authentication key"
"Protected TLV master key"
"Blah Blah Re-authentication key"

Each application must register a key seed and a length. The EAP
framework implementation SHOULD provide a means for obtaining an
application specific key.  For example the framework may provide a
function:

byte[] getAppKey(byte[] seed, int length)

This would allow the MSK to be kept internally and only application
specific keys be returned to the requester.  A savy implementation my
restrict access to a particular key based on the caller. This function
would return null no keys have been generated.  If multiple EAP methods
have generated MSKs  then these MSKs are combined using the PRF in the
following way.

MSK =3D PRF(MSK1, MSK2, 32)

The new master session key is used to derive further keys. =20

It should be noted that a small amount of entropy is lost each time the
PRF is run.  This is not expected to be much of a problem since
typically only a few application specific keys will be required.  In
addition most application derived keying material is kept secret and
would only be exposed in th case of weak ciphering (as in WEP).=20

---

From: [email-masked] (Henrik Levkowetz)
Date: Tue, 4 Feb 2003 18:29:16 +0100

Joe,

	Is this issue regarding the rfc2284bis document: 
  http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-10.txt ,

or regarding the Keying Framework document:
  http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-05.txt ,

or do you propose changes to both documents?

	Henrik

On Tue, 4 Feb 2003 09:02:38 -0800, "Joe Salowey" <[email-masked]> wrote:
> Submitter name: Joseph Salowey 
> Submitter email address: [email-masked] 
> Reference: 
> Comment type: T 
> Section: 7.9 
> Rationale/Explanation of issue: 
> Requested change: 
> Key  = PRF(MSK, key seed, length)
> 
> MSK = PRF(MSK1, MSK2, 32)
> 
> The new master session key is used to derive further keys.  
> 
> would only be exposed in th case of weak ciphering (as in WEP). 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

		Henrik

-- 

Henrik Levkowetz +46708321608 [email-masked] www.ipunplugged.com
------------------------------------------------------------------------

  An elephant: A mouse built to government specifications. 
    -- Lazarus Long in 'Time Enough for Love'