Subject: RE: [eap] Strawman -10/EMSK deletion requirement?

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Fri, 3 Mar 2006 18:21:09 -0500

Hi Avi, 

-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Thursday, March 02, 2006 2:16 PM
To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard
Aboba
Cc: [email-masked]
Subject: RE: [eap] Strawman -10/EMSK deletion requirement?

Hi Joe and Madjid,

The only reason for caching the EMSK is if you have to generate an AMSK
for another application associated with the current session.

Madjid>> Thank you for clarification. Another example may be roaming to
another access technology!!

So the question is do you have to generate all possible AMSKs and then
delete the EMSK or can you generate the AMSKs as needed?

Madjid>>i.e. keep EMSK for future AMSK generation. The first option will
create the need for running EAP again.

> -----Original Message-----
> From: Salowey, Joe [mailto:[email-masked]]
> Sent: Thursday, March 02, 2006 2:49 PM
> To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba
> Cc: [email-masked]
> Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> 
>  
> 
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> > Sent: Thursday, March 02, 2006 8:44 AM
> > To: Salowey, Joe; Rafa Marin Lopez; Bernard Aboba
> > Cc: [email-masked]
> > Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> > 
> > Hi Joe,
> > 
> > Thanks for the email. I think you responded to the old piece of the 
> > email from Rafa and I am to blame for causing that confusion, as I 
> > kept that part to provide context.
> > Again, my question was why an entity needs to delete EMSK after 
> > generating the first AMSK (or first set of AMSKs?)? This
> seems to be
> > the requirement regardless of two options:
> > 
> > 1) keep EMSK at EAP layer, create AMSK at EAP layer based
> request from
> > AAA layer, delete EMSK Immediately (this means EAP layer must have 
> > KDFs for AMSK=KDF(EMSK, etc)
> > 2) push EMSK down to AAA layer at backend server, create
> AMSK at AAA
> > layer and delete EMSK immediately (this means AAA layer must have
> > KDFs)
> >
> [Joe] If the AAA layer contains the AAA client and AAA server then the

> EMSK should not be available to this layer, if the AAA layer means 
> something else then I don't know about (1).
> The AMSK should be generated in the EAP and exported, option (2).
>  
> > 
> > In both cases we require deletion of EMSK after generation of AMSK, 
> > why?
> > 
> [Joe] To minimize the chance of exposure of the EMSK.  Why do you need

> to cache it? Could you generate and cache an AMSK instead?
> 
> 
> > Thanks,
> > 
> > Madjid
> > 
> > -----Original Message-----
> > From: Salowey, Joe [mailto:[email-masked]]
> > Sent: Wednesday, March 01, 2006 5:17 PM
> > To: Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba
> > Cc: [email-masked]
> > Subject: RE: [eap] Strawman -10
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: Nakhjiri Madjid-MNAKHJI1
> [mailto:[email-masked]]
> > > Sent: Wednesday, March 01, 2006 2:38 PM
> > > To: Rafa Marin Lopez; Bernard Aboba
> > > Cc: [email-masked]
> > > Subject: RE: [eap] Strawman -10
> > > 
> > > Madjid>>Again, why is deletion of EMSK after generation of
> > > one AMSK is a
> > > requirements. What if we need to create multiple AMSKs
> and that at
> > > multiple occassions?
> > > 
> > > 
> > > 
> > > Well, actually, lower layer authenticator implementation
> > should expect
> > > (MSK,EMSK) in the case EAP method is executed by the standalone 
> > > authenticator or (MSK,AMSK) in the case EAP method is executed by 
> > > backend authentication server. If it receives (MSK,EMSK)
> > should create
> > 
> > > AMSK and delete EMSK. If it receives (MSK,AMSK) , that's
> > all, correct?
> > 
> > [Joe] Not really, strictly speaking the lower layer
> shouldn't expect
> > to receive the EMSK as that would break mode independence.  An 
> > architectural description should not have the lower layer receiving 
> > the keys. From a supplicant perspective it must appear the same 
> > whether an external EAP-Server or a collocated EAP server is used.
> > Now I don't know what is going on inside your box, it could all be 
> > monolithic when a internal EAP server is used but that shouldn't be 
> > visible to the external world.  If I was interested in
> cryptographic
> > module separation I might not be too happy if you shared
> the EMSK with
> > the lower layer.
> > 
> > > _________________________________________________________________
> > > To unsubscribe or modify your subscription options, please visit:
> > > http://lists.frascone.com/mailman/listinfo/eap
> > > 
> > > Arhives: http://lists.frascone.com/pipermail/eap
> > > 
> > 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap
> 
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Jari Arkko <[email-masked]>
Date: Sun, 05 Mar 2006 21:30:15 +0200

Madjid, Avi,

>create the need for running EAP again.
We have discussed this before... I do not see an issue for handoffs
to another access. If your AAA server supports this then it derives
AMSK_ho_root from EMSK, deletes EMSK but keeps the derived
key. Once a need to do a handoff arrives, you derive AMSK_ho_key1
from AMSK_ho_root, next time you will derive AMSK_ho_key2, etc.

Having said that, I do agree with Avi that there's really no substantial
difference between "<x> MUST be deleted after <y>" and "<x> MUST
be only used for <y>", except maybe some implementation note describing
that it would be a good idea to securely delete the value once you
know that <y> is done.

But part of this debate is really not about whether the key should
be deleted, but rather about whether we know the applications
a priori. I think there are practical and security reasons why it
is a good idea to set a requirement that the applications are known
a priori. First of all, there are no surprises to the AAA server; it
needs have specific authorization to serve a particular
application. (Possibly even specific code.) Secondly, as we
are currently in a world where the AAA servers cache no
keys at all, we need to avoid a situation where AAA servers
end up storing a lot of key state and have no way of knowing
when it is needed. Finally, security-wise I want to know what
my EAP authentication somewhere means. I, as the end user,
do not want surprises. It is better to limit the set of applications
of the keys at the beginning. Note that if you want, you can
set up state for handoff/SIP/MIP even if you do not know they
will actually be used; you set the state and keys based on
the user's authorization profile.

Based on the above, I still like the design where we know
the possible applications (and AMSKs) at the first authentication.
But we could write the text slightly differently, based on what
you Avi suggested.

--Jari