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 9:50 AM
> To: Bernard Aboba
> Cc: Jari Arkko; eap [at] frascone.com
> Subject: [eap] Eap keying review: use of MSK/ EMSK for AMSK creation
> 
> 
> Hi Bernard,
> 
> I did some more reading in the 08 doc, and I am trying to put 
> all the pieces of the puzzle together. 
> 
> Section 2.2. of EAP keying 08 prohibits sending EMSK down to 
> the lower layer (section 2.2). 
> 
> I assume "lower layer" includes AAA layer (even though 3748 
> section 2.2.
> does not include AAA as a lower layer, even though 3579 is 
> dated before 3748). 

[Joe] In my opinion AAA is not an EAP lower layer.  The EAP lower layer
is in direct communication with the authenticator. 

> 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).

> 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. 

> 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. 


> 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.