Subject: [Emu] Re: [Hokeyp] MSK but no EMSK

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 16 Nov 2006 09:27:58 -0500

I made one comment around this in the HOKEY session.  The intent of my
comment was that use of EMSK is optional.  There would be an
interoperability issue if peer and server do not negotiate on the use
of EMSK before actually using it.

Yoshihiro Ohba

On Thu, Nov 16, 2006 at 11:01:15AM +0200, Alper Yegin wrote:
> 
> I remember someone in Hokey WG meeting mentioned that not all methods
> generate EMSK (even though they generate MSK). Is that accurate?
> 
> Despite this RFC 3748 text?
> 
>    In order to provide keying material for use in a
>    subsequently negotiated ciphersuite, an EAP method supporting key
>    derivation MUST export a Master Session Key (MSK) of at least 64
>    octets, and an Extended Master Session Key (EMSK) of at least 64
>    octets.  
> 
> Alper
> 
> 
> _______________________________________________
> Hokeyp mailing list
> [email-masked]
> http://www.opendiameter.org/mailman/listinfo/hokeyp
> 

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 16 Nov 2006 09:38:10 -0800

At 06:27 AM 11/16/2006, Yoshihiro Ohba wrote:
>comment was that use of EMSK is optional.

Hi Yoshi,

Which document says that the "use" of EMSK is optional?

>There would be an

The interoperability issue would only come up if there is ambiguity or options.

Lakshminath

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 16 Nov 2006 13:30:36 -0500

Hi Lakshminath,

RFC 3748 says:

"
   Extended Master Session Key (EMSK)
      Additional keying material derived between the EAP client and
      server that is exported by the EAP method.  The EMSK is at least
      64 octets in length.  The EMSK is not shared with the
      authenticator or any other third party.  The EMSK is reserved for
      future uses that are not defined yet.
"

Since EMSK usage is not defined yet, the use of EMSK is virtually
optional at this momement.  Since it was not mandated in the
beginning, it is not possible to change it mandatory for a particular
use in a future without loss of interoperability with the existing
deployment.

Am I missing something?

Yoshihiro Ohba

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 16 Nov 2006 10:54:20 -0800

>use in a future without loss of interoperability with the existing

I read it differently.  The EMSK is reserved for future uses.  It is 
of course mandatory to derive the EMSK, but the use of it is simply 
not defined.  It is not optional to use.  It is not mandatory either, 
it simply is unused.  When the EMSK is defined for a specific use 
case, then the question of whether the use is optional, recommended 
or mandatory comes up.

Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 16 Nov 2006 11:18:05 -0800

Hi Yoshi,
As Alper pointed out in the text from RFC3748, it is not optional to
produce an EMSK. Its usage is undefined at the moment, but, a compliant
implementation should be producing the EMSK, nevertheless. 

Regards,
Vidya

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Thursday, November 16, 2006 10:31 AM
> To: Dondeti, Lakshminath
> Cc: Alper Yegin; [email-masked]; [email-masked]
> Subject: Re: [Hokeyp] [Emu] Re: MSK but no EMSK
> 
> Hi Lakshminath,
> 
> RFC 3748 says:
> 
> "
> Since EMSK usage is not defined yet, the use of EMSK is 
> virtually optional at this momement.  Since it was not 
> mandated in the beginning, it is not possible to change it 
> mandatory for a particular use in a future without loss of 
> interoperability with the existing deployment.
> 
> Am I missing something?
> 
> Yoshihiro Ohba
> 
> 
> > >I made one comment around this in the HOKEY session.  The 
> intent of 
> > >my comment was that use of EMSK is optional.
> > 
> > Hi Yoshi,
> > 
> > > > I remember someone in Hokey WG meeting mentioned that not all 
> > > > methods generate EMSK (even though they generate MSK). 
> Is that accurate?
> > > >

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 16 Nov 2006 14:26:14 -0800

>implementation should be producing the EMSK, nevertheless.

It's worth keeping in mind that there are very few existing RFC 
3748-compliant EAP implementations.  So most existing EAP method 
implementations do not generate an EMSK, and most existing EAP 
implementations would not do anything with the EMSK if it were to be 
generated.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 16 Nov 2006 17:57:09 -0500

> case, then the question of whether the use is optional, recommended 

I agree that this is more precise reading.  However, even after
defining a usage of EMSK, it is difficult to assume that all peers and
servers will always support the usage of EMSK unless we can upgrade
the existing EAP implementations which do not use EMSK to the new ones
*at one time*.  Thus, as a proactive answer to the question, I don't
really believe that a specific use of EMSK can be mandated without
breaking interoperability with existing EAP implementations.

Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 16 Nov 2006 18:35:25 -0800

> 
> It's worth keeping in mind that there are very few existing 
> RFC 3748-compliant EAP implementations.  So most existing EAP 
> method implementations do not generate an EMSK, and most 
> existing EAP implementations would not do anything with the 
> EMSK if it were to be generated.
> 

Well, the question is this - is the requirement to interoperate with
existing standards or existing implementations? Given that we have a
spec that says what it does, it seems to make sense to interoperate with
that. If we are going by existing implementations, there is probably
more than one flavor and then there is the question of when the MSK is
directly delivered to the authenticator and when it isn't and how the
peer knows that. 

In this case, I tend to agree with Charles that it is better to have to
fix non-compliant implementations than try to design around them. Also,
if we choose to ignore the standard and use the implementations that
don't produce an EMSK as a data point, the standard doesn't seem to be
serving a purpose then - perhaps, we should then consider revising
RFC3748 to reflect what we want to use as a starting point for
requirements? 

Vidya

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 17 Nov 2006 13:48:54 -0500

> RFC3748 to reflect what we want to use as a starting point for

Revising RFC 3748 to add a mandatory usage of EMSK would break
interoperability with existing EAP implementations, because EAP does
not define a *version* field used for distinguishing old and new
specifications.

Yoshihiro Ohba

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 17 Nov 2006 11:04:29 -0800

Yoshi,
I am NOT suggesting any revisions. 

Regards,
Vidya 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Yoshihiro Ohba
> Sent: Friday, November 17, 2006 10:49 AM
> To: Narayanan, Vidya
> Cc: Bernard Aboba; [email-masked]; [email-masked]
> > spec that says what it does, it seems to make sense to interoperate 
> > with that. If we are going by existing implementations, there is 
> > probably more than one flavor and then there is the 
> question of when 
> > the MSK is directly delivered to the authenticator and when 
> it isn't 
> > and how the peer knows that.
> > 
> > In this case, I tend to agree with Charles that it is 
> better to have 
> > to fix non-compliant implementations than try to design 
> around them. 
> > Also, if we choose to ignore the standard and use the 
> implementations 
> > that don't produce an EMSK as a data point, the standard 
> doesn't seem 
> > to be serving a purpose then - perhaps, we should then consider 
> > revising
> Revising RFC 3748 to add a mandatory usage of EMSK would 
> break interoperability with existing EAP implementations, 
> because EAP does not define a *version* field used for 
> distinguishing old and new specifications.
> 
> Yoshihiro Ohba
> 
> 
> 
> > 
> > Vidya
> >

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 18 Nov 2006 09:43:40 -0800

>If we are going by existing implementations, there is probably

The Wifi Alliance (WFA) WPA2 certification includes EAP interoperability 
testing.  Quite a few implementations have passed certification, including 
most of the major ones.

The WFA EAP certification requires that EAP implementations support the 
generation of the MSK as specified in RFC 2716.  Authenticators/APs are 
required to support transport of the MSK as described in RFC 2548.

Existing EAP lower layers that utilize EAP keying (802.11i, IKEv2, PPP, 
802.16e) base their key hierarchies on the MSK.  Since the key hierarchy is 
based on the MSK, if it were not delivered to the authenticator, the 
exchange of data frames between the peer and authenticator would not be 
possible.

>fix non-compliant implementations than try to design around them.

RFC 2284 was approved in March 1998; the first widely available 
implementation shipped in December 1999.  Major interoperability and 
security issues were being resolved as late as 2003; testing and 
certification began in 2005.  So it took 7 years to go from initial 
specification to certified interoperable implementations.

While I would expect that RFC 3748-compliant implementations will take less 
than 7 years to appear, we are still only at the beginning of the road.  For 
example, there are no RFC 3748-compliant implementations shipping yet; we 
have not had an RFC 3748 bakeoff demonstrating interoperability between two 
distinct implementations with respect to new RFC 3748 features (including 
the EMSK); no open source RFC 3748-compliant implementations exist yet.

---

From: Jouni Malinen <[email-masked]>
Date: Sat, 18 Nov 2006 10:10:04 -0800

(sorry for the duplicate; I sent this first with incorrect email
address which did not go through to the mailing list)

On Sat, Nov 18, 2006 at 09:43:40AM -0800, Bernard Aboba wrote:

> than 7 years to appear, we are still only at the beginning of the road.  
> For example, there are no RFC 3748-compliant implementations shipping yet; 
> we have not had an RFC 3748 bakeoff demonstrating interoperability between 
> two distinct implementations with respect to new RFC 3748 features 
> (including the EMSK); no open source RFC 3748-compliant implementations 
> exist yet.

The current development branch for wpa_supplicant (EAP peer) and hostapd
(EAP server) includes support for most of RFC 3748, including EMSK
derivation in many of the EAP methods and use of expanded types. Sure,
EMSK is not currently used for anything, but at least it is included in
the EAP method interface and the programs are ready to start using it
once suitable use of EMSK is specified.

I would be interested in running interoperability tests for RFC 3748
features with other implementations. I haven't tested EMSK derivation
with another implementation, but expanded types have been tested with
other implementations.

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 16 Nov 2006 11:01:15 +0200

Alper

---

From: Michael Ye <[email-masked]>
Date: Fri, 17 Nov 2006 09:05:12 +0800

I don't understand why was a unused key defined in advance ?

  Michael

> Sent: Friday, November 17, 2006 6:57 AM
> To: Lakshminath Dondeti
> Cc: Yoshihiro Ohba; Alper Yegin; [email-masked]; [email-masked]
> > case, then the question of whether the use is optional, 
> recommended or 
> > mandatory comes up.
> 
> I agree that this is more precise reading.  However, even 
> after defining a usage of EMSK, it is difficult to assume 
> that all peers and servers will always support the usage of 
> EMSK unless we can upgrade the existing EAP implementations 
> which do not use EMSK to the new ones *at one time*.  Thus, 
> as a proactive answer to the question, I don't really believe 
> that a specific use of EMSK can be mandated without breaking 
> interoperability with existing EAP implementations.
> 
> Yoshihiro Ohba
> 
> 
> > 
> > Lakshminath
> > 
> > 
> > >Am I missing something?
> > >
> > >Yoshihiro Ohba
> > >
> > >
> > >> >I made one comment around this in the HOKEY session.  
> The intent 
> > >> >of my comment was that use of EMSK is optional.
> > >>
> > >> Hi Yoshi,
> > >>
> > >> >interoperability issue if peer and server do not 
> negotiate on the 
> > >> >use of EMSK before actually using it.
> > >>
> > >> > > methods generate EMSK (even though they generate 
> MSK). Is that accurate?
> > >> > >

---

From: Michael Ye <[email-masked]>
Date: Fri, 17 Nov 2006 09:05:12 +0800

Michael

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 19 Nov 2006 10:44:25 -0800

>generate EMSK (even though they generate MSK). Is that accurate?

The simple answer is "we don't know" because prior to RFC 3748, EAP Type 
Codes could be allocated without a specification.

However, for methods published as RFCs or in the RFC Editor Queue, we know 
the following:

a) None of the RFC 3748-specified EAP methods generate keys (EAP MD5, OTP, 
GTC).

b) All of the key generating EAP methods published as RFCs specify how to 
derive the MSK and EMSK.   This includes EAP TLS (RFC 2716), EAP SIM (RFC 
4186), and EAP AKA (RFC 4817).   The generation of the Session-Id, Peer-Id 
and Server-Id is also specified for these methods in the Key Management 
Framework document.

c) All of the key generating EAP methods currently in the RFC Editor queue 
specify how to derive both the MSK and EMSK.  This includes EAP PSK 
(draft-bersani-eap-psk-11.txt), EAP SAKE (draft-vanderveen-eap-sake-02.txt), 
EAP PAX (draft-clancy-eap-pax-11.txt), EAP POTP 
(draft-nystrom-eap-potp-07.txt).  None of these methods specify how to 
derive the Peer-Id, Server-Id and Session-Id (e.g. they are non-compliant 
with the EAP Key Management Framework).

d) Allocation of an EAP Type Code requires specification of the MSK, EMSK, 
and Session-Id and Peer-Id/Server-Id if known.

---

From: Charles Clancy <[email-masked]>
Date: Mon, 20 Nov 2006 20:54:14 -0500

> None of these methods specify how to
 > derive the Peer-Id, Server-Id and Session-Id (e.g. they are
 > non-compliant with the EAP Key Management Framework).

EAP-PAX does indeed specify the Peer-ID, Server-ID, and Session-ID.

Section 2.4 states:

    The EAP Key Management Framework [I-D.ietf-eap-keying] recommends
    specification of key names and scope.  The EAP-PAX Method-ID is the
    MID value computed as described above.  The EAP peer name is the CID
    value exchanged in PAX_STD-2 and PAX_SEC-2.  The EAP server name is
    an empty string.

-- 
t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 22 Nov 2006 08:17:02 -0800

>One question though. I couldn't find any mention of "MSK" or "EMSK" in RFC
>2716. Can you tell us how to get those keys out of that spec?

RFC 2716bis explains how the send and receive keys map to the MSK/EMSK:
http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-05.txt

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 21 Nov 2006 18:21:16 +0200

Thank you for this survey. 

Alper

> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Sunday, November 19, 2006 8:44 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [Emu] MSK but no EMSK
>

---

From: "Alper Yegin" <[email-masked]>
Date: Tue, 21 Nov 2006 18:21:16 +0200

Alper

---

From: "Ray Bell" <[email-masked]>
Date: Sun, 26 Nov 2006 23:08:26 -0800

RFC 3748 - Extensible Authentication Protocol (EAP), June 2004

Page 6:

   Master Session Key (MSK)
      Keying material that is derived between the EAP peer and server
      and exported by the EAP method.  The MSK is at least 64 octets in
      length.  In existing implementations, a AAA server acting as an
      EAP server transports the MSK to the authenticator.

Ray

-----Original Message-----
From: Alper Yegin [mailto:[email-masked]] 
Sent: Tuesday, November 21, 2006 8:21 AM
To: 'Bernard Aboba'; [email-masked]
Cc: [email-masked]
Subject: RE: [Emu] MSK but no EMSK

Alper