Subject: [eap] EAP-Keying issue

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

Hi Henrik,

I am targeting the changes to rfc2284bis, however it may impact the
keying document as well.  I don't have specific information for the
keying document, so I guess we should mark it as 2284bis and if it
results in changes in the keying document we can make it a separate
issue.

Joe

> -----Original Message-----
> From: Henrik Levkowetz [mailto:[email-masked]]=20
> Sent: Tuesday, February 04, 2003 9:29 AM
> To: Joe Salowey
> Cc: [email-masked]
> Subject: Re: [eap] EAP-Keying issue
>=20
>=20
> Joe,
>=20
> 	Is this issue regarding the rfc2284bis document:=20
>  =20
> http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284b
> is-10.txt ,
>=20
> or regarding the Keying Framework document:
>  =20
> http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-pro
> blem-05.txt ,
>=20
> or do you propose changes to both documents?
>=20
> 	Henrik
>=20
> On Tue, 4 Feb 2003 09:02:38 -0800, "Joe Salowey"=20
> <[email-masked]> wrote:
> > Description of issue: Inconsistency in EAP Keying
> > Submitter name: Joseph Salowey
> > 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=20
> authentication data but
> > it does not provide a consistent interface  to deal with=20
> key data.  This
> > makes it difficult to treat EAP mechanisms similarly.  EAP=20
> 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.
> >=20
> > Requested change:
> >=20
> > In the description below the term "EAP Framework" controls the=20
> > interaction between and EAP mechanism and the environment. =20
> The term=20
> > "application" refers to a consumer of EAP authentication=20
> service and=20
> > key material. An application may be a link layer protocol such as=20
> > 802.11 or another EAP mechanism chained into the EAP conversation=20
> > after initial authentication.
> >=20
> > If an EAP mechanism derives keys then it MUST be able to export a=20
> > 256-bit Master Session Key (MSK) to the EAP framework. =20
> THis key must=20
> > be cryptographically independent of the Master Key (MK) established=20
> > within the authentication mechanism or any other key used by the=20
> > authentication mechanism.  In this case cryptographically=20
> 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=20
> least a 128=20
> > bits (more if greater than 128-bit ciphers are in use by=20
> > applications). The MSK is never used in an application=20
> directly rather=20
> > it is used to derive application specific master session keys and=20
> > ciphering keys.  The following describes the EAP key derivation=20
> > mechanism.
> >=20
> > The EAP key derivation function is as follows
> >=20
> > Key  =3D PRF(MSK, key seed, length)
> >=20
> > Where MSK is the master session keys described above, the=20
> key seed is=20
> > an application specific value which is unique to each=20
> application, and=20
> > length is the number of bytes of key material needed.  The PRF is a=20
> > suitable pseudo-random function.  Good candidates for the=20
> PRF are the=20
> > IKE PRF, the TLS PRF and possibly the SHS PRF.  The keys seed is an=20
> > octet string which should be assigned by IANA for application uses.=20
> > Examples of some key seeds are:
> >=20
> > "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"
> >=20
> > Each application must register a key seed and a length. The EAP=20
> > framework implementation SHOULD provide a means for obtaining an=20
> > application specific key.  For example the framework may provide a
> > function:
> >=20
> > byte[] getAppKey(byte[] seed, int length)
> >=20
> > This would allow the MSK to be kept internally and only application=20
> > specific keys be returned to the requester.  A savy=20
> implementation my=20
> > restrict access to a particular key based on the caller.=20
> This function=20
> > would return null no keys have been generated.  If multiple EAP=20
> > methods have generated MSKs  then these MSKs are combined using the=20
> > PRF in the following way.
> >=20
> > MSK =3D PRF(MSK1, MSK2, 32)
> >=20
> > 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=20
> > the PRF is run.  This is not expected to be much of a problem since=20
> > typically only a few application specific keys will be=20
> required.  In=20
> > addition most application derived keying material is kept=20
> secret and=20
> > would only be exposed in th case of weak ciphering (as in WEP).=20
> > _______________________________________________
> > eap mailing list
> > [email-masked] http://mail.frascone.com/mailman/listinfo/eap
>=20
>=20
> 		Henrik
>=20
> --=20
>=20
> Henrik Levkowetz +46708321608 [email-masked]=20
www.ipunplugged.com
------------------------------------------------------------------------

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