RE: [Emu] MSK but no EMSK
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Emu] MSK but no EMSK



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.

   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.


Ray


-----Original Message-----
From: Alper Yegin [mailto:alper.yegin at yegin.org] 
Sent: Tuesday, November 21, 2006 8:21 AM
To: 'Bernard Aboba'; hokeyp at opendiameter.org
Cc: emu at ietf.org
Subject: RE: [Emu] MSK but no EMSK

Thank you for this survey. 

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?

Alper



> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba at hotmail.com]
> Sent: Sunday, November 19, 2006 8:44 PM
> To: alper.yegin at yegin.org; hokeyp at opendiameter.org
> Cc: emu at ietf.org
> Subject: RE: [Emu] MSK but no EMSK
> 
> >I remember someone in Hokey WG meeting mentioned that not all methods
> >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.
> 



_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu


_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.