Subject: RE: [eap] Eap keying review: use of MSK/ EMSK for AMSK creation

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Tue, 1 Nov 2005 18:04:17 -0500

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

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

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

> 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
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Salowey, Joe" <[email-masked]>
Date: Tue, 1 Nov 2005 15:55:02 -0800

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Tuesday, November 01, 2005 3:04 PM
> To: Salowey, Joe; Bernard Aboba
> Cc: Jari Arkko; [email-masked]; 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. 
> 
> 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.
> 
> [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).
> 
> 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. 

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

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

> [Joe] Yes the AAA server should, however it is also possible 
> to use EAP without AAA so we have to be careful with terminology. 
> 
> 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. 

> mentioned and 
> > it says, the AAA layer must delete an MSK that has been 
> transported to 
> > the authenticator. Problems:
> [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.
> 
>

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 9 Nov 2005 13:05:13 -0500

Yoshihiro,

I did not say I agree with that philosophy. I also think that is not
very practical to assume that the AAA layer knows about all the upcoming
applications or authorization a'priori. One example being may be you
want to move from one access technology to the next, both under the same
AAA server, and the second one suddenly with a lot more bandwidth than
the first (thanks Glen, for that example), so there are a lot of
practical implications to the existing assumptions.

Having said all that I think the HA-specific key can be derived from a
previously derived MIP-AMSK root, if we have to, assuming that our AAA
server was smart enough to ask for a MIP-AMSK when it had a chance
(certain amount of cynicism intended :)).
 
Madjid
-----Original Message-----
From: Yoshihiro Ohba [mailto:[email-masked]] 
Sent: Tuesday, November 08, 2005 4:42 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Jari Arkko; Bernard Aboba; [email-masked]
Subject: Re: [eap] Re: Eap keying review: use of MSK/ EMSK for AMSK
creation

On Tue, Nov 08, 2005 at 04:57:29PM -0500, Nakhjiri Madjid-MNAKHJI1
wrote:
> I think at least for handover or for MIP type applications we can work

> with this comfortably, i.e. have an HO-AMSK and a PMIP-AMSK and so on.
> And for HO, I will derive all the keys that are needed for HO-AMSK.
> 
> However, as we discussed during HOKEY meeting last night, this makes 
> the assumption that the AAA nows at the time authentication, about all

> the applications for which it needs AMSKs for.

I think this assumption has a limitation for MIPv6 bootstrapping.  In
some case, the AAA server may not know which HA is to be chosen by the
MN until an explicit request comes from HA x chosen by the MN.  In this
case, a key for HA x should be generated on-demand basis (but I am not
sure whether use of AMSK or MSK is appropriate for this case).

Yoshihiro Ohba

> This works for now, since we
> can say that a well designed system should make all AAA decisions 
> (especially authorization ones) at once. Still it would be nice if do 
> not add the limitation that prevents the AAA layer/ server to later 
> ask for another keys, to be exact, if we do not require deletion of 
> EMSK immediately after AMSK creation. I cannot come of a specific 
> example right now.
> 
> Madjid
> 
> 
> We may have discussed this already, but this is I believe correct. The

> EMSK should not be handed to the lower layer. But see below:
> 

> >that are needed for that application. 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. Should not be the AAA server to

> >make
> >  
> >
> I think we can easily arrange things so that the AAA layer asks for 
> AMSKs 1, 2, and 3, which fulfils security requirements (EMSK is not
> exposed) and does not require application knowledge from EAP layer. 
> Does this work for you?
> 
> --Jari
> 
> [email-masked]
> http://lists.frascone.com/mailman/listinfo/eap
> 
> 
> [email-masked]
> http://lists.frascone.com/mailman/listinfo/eap
> 
> 
_______________________________________________
eap mailing list
[email-masked]
http://lists.frascone.com/mailman/listinfo/eap

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 9 Nov 2005 14:25:42 -0500

Hi Michaela,

Yes, specifically with RADIUS that is a problem. During Hokey meeting, I
think Jari agreed that we may be able to lax that requirement (deletion
of a key immediately after transport).

Madjid 

-----Original Message-----
From: Vanderveen, Michaela [mailto:[email-masked]] 
Sent: Tuesday, November 08, 2005 4:53 PM
To: Yoshihiro Ohba; Nakhjiri Madjid-MNAKHJI1
Cc: Jari Arkko; Bernard Aboba; [email-masked]
Subject: RE: [eap] Re: Eap keying review: use of MSK/ EMSK for AMSK
creation

We are running into the problem that the keys necessary for fast handoff
though derived with no problems, are not ready to be transported until
the HA asks for them. Thus since it has been agreed last night that
AMSKs can be transported to more than one entity, the AAA server should
be able to cache these keys for a (short) while, until all entities that
need the key have obtained them.

Michaela

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Yoshihiro Ohba
Sent: Tuesday, November 08, 2005 2:42 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Jari Arkko; Bernard Aboba; [email-masked]
Subject: Re: [eap] Re: Eap keying review: use of MSK/ EMSK for AMSK
creation

Yoshihiro Ohba

===========================================================
This email may contain confidential and privileged material for the sole
use  of the intended recipient.  Any review or distribution by others is
strictly  prohibited.  If you are not the intended recipient please
contact the sender  and delete all copies.
===========================================================

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 9 Nov 2005 22:22:50 -0500

Jari, Madjid

Madjid wrote:

> Still it would be nice if do not 
> add the limitation that prevents the AAA layer/ server to 
> later ask for another keys, to be exact, if we do not require 
> deletion of EMSK immediately after AMSK creation. I cannot 
> come of a specific example right now.
> 
> Madjid

We *must* have the ability to ask for another key or keys.

Jari wrote:

> I think we can easily arrange things so that the AAA layer 
> asks for AMSKs 1, 2, and 3, which fulfils security 
> requirements (EMSK is not
> exposed) and does not require application knowledge from EAP 
> layer. Does this work for you?

This is good news!!! So if we can have it so that we can also select
keys anytime the EMSK is still alive, that would be very good news

Avi