Subject: RE: [eap]the outcome of EMSK and AMSK discussion?

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 23 Nov 2005 14:36:57 -0500

Hi Joe,

Just following up some old discussions. I am assuming we are close to
the end of last call, so What was the result of all the discussions and
its impact on the document. Will you send another rev?

Qs: 
AAA server versus EAP server? Their roles? Are you adding the KDF as
another entity?
Does the AAA server (lower layer at backend EAP server) get the AMSK
after requesting it from the EAP layer (which holds the EMSK)? Is EMSK
cached at all or is it deleted right away?
Can we assume one AMSK per applications authorized by AAA server?

Thanks,

Madjid

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

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

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/options/eap/eap-archive%40lists.ietf.org

---

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 28 Nov 2005 21:04:39 -0800

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Wednesday, November 23, 2005 11:37 AM
> To: Salowey, Joe
> Cc: [email-masked]
> Subject: RE: [eap]the outcome of EMSK and AMSK discussion?
> 
> Hi Joe,
> 
> Just following up some old discussions. I am assuming we are 
> close to the end of last call, so What was the result of all 
> the discussions and its impact on the document. Will you send 
> another rev?
> 

[Joe] It seemed like we were converging based on what was on the list,
but I'm not sure we closed on all these issues.  I'll try to go through
the document and make recommendations by the end of the week, but it is
up to the authors and chairs as to the next steps. 

> Qs: 
> AAA server versus EAP server? Their roles? Are you adding the 
> KDF as another entity?

[Joe] The EAP server is responsible for authentication and has very
limited (hopefully none) application specific knowledge.  The AAA server
contains the application specific logic to perform authorization and
other application specific tasks based on the output of the EAP server.
I think the KDF best kept as part of the EAP Server. It is an interface
to a specific function supported by an EAP server. 

> Does the AAA server (lower layer at backend EAP server) get 
> the AMSK after requesting it from the EAP layer (which holds 
> the EMSK)? 

[Joe] The application that requests the AMSK gets the AMSK (unless there
is some authorizaiton or policy that prevents it).  The AAA server can
contain one or more applications that can request AMSKs so yes the AAA
server can obtain an AMSK. There is no AMSK specific to a AAA server, an
AMSK is specific to an application supported by a AAA server. 

>Is EMSK cached at all or is it deleted right away?

[Joe] The sooner an implementation deletes the EMSK the better.
Applications that need AMSKs should determine the need for the AMSK as
soon as possible and request it.  These are basic guidelines, I'm not
sure if we have resolved the issue of caching the EMSK yet.   

> Can we assume one AMSK per applications authorized by AAA server?
[Joe] Each application can obtain one or more AMSKs.  An AMSK should not
be used for two different applications. 

> Thanks,
> 
> Madjid
> 
> 
> 
> [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] 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] 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. 
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman//listinfo/eap
Arhives: http://lists.frascone.com/pipermail/eap

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 30 Nov 2005 17:42:06 -0500

Hi Joe,

Yes, I was asking since as I recall the end of review period was end of
November, but it was not clear what the outcome of the review was
supposed to be?
I guess I agree with most of the answers you provided, except the
response to Q on deleting or caching EMSK: "The sooner an implementation
deletes the EMSK the better." This relates to when an AMSK for an
application can be requested from the EAP server (if EAP server is to
calculate AMSKs).

Thanks,

Madjid

> after requesting it from the EAP layer (which holds the EMSK)?

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap