eap Mailing List: RE: Eap keying review: use of MSK/ EMSK for AMSK creation

[Salowey, Joe (jsalowey]

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri [at] motorola.com] 
> Sent: Tuesday, November 01, 2005 3:04 PM
> To: Salowey, Joe; Bernard Aboba
> Cc: Jari Arkko; eap [at] frascone.com; Nakhjiri Madjid-MNAKHJI1
> Subject: RE: [eap] Eap keying review: use of MSK/ EMSK for 
> AMSK creation
> 
> Hi Joe, 
> 
> 
> <snip>
> [Joe] In my opinion AAA is not an EAP lower layer.  The EAP 
> lower layer is in direct communication with the authenticator. 
> 
> Madjid>>Well,... You got two RFCs to deal with: EAP over 
> RADIUS and EAP
> over Diameter :) but joking aside, so far I have not been 
> concerned about the definition of lower layer. I just want to 
> allow the AAA server to take more benefit from the EAP key 
> hierarchy by letting the AMSK generation be handled by the AAA server.
> 
> > So this prohibits the AAA server to take EMSK and create new keys
> > (AMSKs) for new applications or services.  This means the EAP layer 
> > must itself authorize each service application and 
> calculate any AMSK 
> > that are needed for that application.
> 
> [Joe] What is important is that the EMSK be contained.  It 
> MUST NOT be passed down directly to the lower layer.  It 
> should be maintained as close to the EAP Server as possible. 
> Personally I think another entity should be defined that 
> manages this derivation.  Controlling access to keys requires 
> authorization (although not necessarily service authorization).
> 
> Madjid>> Not sure why we cannot trust AAA server and want to overload
> the EAP server this way. Plus it seems that EMSK is most of 
> the time considered as "for future use", so why would the 
> EMSK have to be contained, if it could be passed to AAA 
> server for future use (I know we are talking about different 
> time frames here :) ).
>

[Joe] One problem we have is that AAA is not an EAP entity which makes
this discussion rather difficult.  I'm OK with defining another entity
that can handle the key derivation, but its not the AAA.  It may be
contained within the AAA and accessed by the AAA etc.  

Perhaps the EAP server exports a KDF that can be used to retrieve AMSKs
based on the EMSK. This EAP-KDF component controls access to the keying
material by restricting which other components can obtain keys for a
certain application so that one application can retrieve another
applications keys. Beyond this the application is responsible for access
control of the AMSK and any keys derived from it. 

> 
> > Not
> > only we are including a role of authorization into an EAP 
> server, but 
> > also we are saying the EAP layer must anticipate all 
> applications that
> 
> > need to derive their keys based on the EAP keying process.
> 
> [Joe] From a security point of view it would be best if the 
> AMSK were derived from the EMSK as soon as possible so the 
> EMSK can be deleted.
> So I think that the possible need for AMSKs should be anticipated. 
> 
> Madjid>>What if you need AMSK for multiple applications. Why are we
> using the "M" is the MSK and EMSK then? 
> 

[Joe] Not sure what you mean.  The EMSK is used to derive AMSK. That is
its sole purpose.  Once the keys are derived it can be removed. Using
the EMSK directly  can lead to a problem where a compromise in one
application compromises all applications. 


> > Should not be the AAA server to make
> > authorization decisions and generate keys for the services 
> accordingly
> 
> > (say a master key for an access technology or a master key 
> to provide 
> > handover support)?
> > 
> 
> [Joe] Yes the AAA server should, however it is also possible 
> to use EAP without AAA so we have to be careful with terminology. 
> 
> Madjid>>What key could the AAA server use. It does not get 
> the EMSK and
> it has to dump MSK or AMSK as soon as it transports it, what 
> if another application comes along and now you don't have any 
> keys left?
> 

[Joe] The AAA can do what it wants with a AMSK it receives according to
the definition of the application that uses the AMSK.  Caching or
deriving other keys from the AMSK is entirely possible. 

> > Furthermore in section 2.3 under AAA, a "AAA layer" is 
> mentioned and 
> > it says, the AAA layer must delete an MSK that has been 
> transported to 
> > the authenticator. Problems:
> > 1) The EAP RFC does not distinguish between authenticator and 
> > authentication server (the EAP server).
> 
> [Joe] This is OK the EAP Authenticator and EAP Server can be 
> viewed as part of the same logical entity with repsec to the 
> lower layer.  It probably should say that once the key is 
> delivered to the lower layer it should be deleted from the 
> EAP Authenticator and EAP server.
> 
> 
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>