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

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Thu, 2 Mar 2006 11:43:42 -0500

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)

In both cases we require deletion of EMSK after generation of AMSK, why?

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

---

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 2 Mar 2006 11:49:27 -0800

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

---

From: "Avi Lior" <[email-masked]>
Date: Thu, 2 Mar 2006 15:16:26 -0500

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.

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?

Finally I have an slight issue with the statement that a KEY should be
deleted so that it wont be used for other purposes.  I find that
statements like that are an over specification.  What makes anyone think
that making a statement that "X should/must be deleted" is going to be
taken more seriously then "X should/must only be used for purpose X and
should/must not be transported out of Y"?

I think that whether it gets deleted or not is an implementation issue.

Finally if we insist on saying that X must be deleted we should really
say that X must be securely deleted.  There is a difference.  When a key
is securely deleted the software takes extra care that the memory
location containing the key is first erased before the memory location
is freed to the heap.  Perhaps we can state that somewhere. 

> Sent: Thursday, March 02, 2006 2:49 PM
> > email from Rafa and I am to blame for causing that confusion, as I 
> > kept that part to provide context.
> > generating the first AMSK (or first set of AMSKs?)? This 
> seems to be 
> > the requirement regardless of two options:
> > 
> > AAA layer, delete EMSK Immediately (this means EAP layer must have 
> > KDFs for AMSK=KDF(EMSK, etc)
> [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).
>  
> > 
> [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
> > 
> > [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.
> >

---

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

> generating the first AMSK (or first set of AMSKs?)? This seems to be 

Madjid>>I guess the number of people who are not sure about definition
of AAA layer is more than one :)
Joking aside, what is your reason what not making EMSK available to
lower layer, while doing so for MSK is ok? What is the fundamental
difference.

Madjid>>because a priori I cannot know how many AMSKs I may need later.
An application may pop up later that needs keying or I move to a
different domain that may require a new AMSK, but I cannot anticipate
the move ahead of time...

> [Joe] Not really, strictly speaking the lower layer shouldn't expect 
> 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

---

From: "Avi Lior" <[email-masked]>
Date: Sun, 5 Mar 2006 10:08:31 -0500

Hi Madjid 

Seems that there a lot of good reasons for keeping EMSK around after it
is used to generate AMSKs.  Hopefully everyone gets that.

> Sent: Friday, March 03, 2006 6:21 PM
> To: Avi Lior; Salowey, Joe; Rafa Marin Lopez; Bernard Aboba
> Cc: [email-masked]
> Hi Avi, 
> 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]
> 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.
> 
> > something else then I don't know about (1).
> > > In both cases we require deletion of EMSK after 
> generation of AMSK, 
> > > why?
> > >

---

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 6 Mar 2006 09:45:56 -0800

> Sent: Thursday, March 02, 2006 12:16 PM
> generate an AMSK
[Joe] I understand that there may be need for caching of certain
quantities.  I think Jari explained it well in a separate message.  In
my opinion you should try to identify the applications in use and the
keys needed as early as possible.  If this is not possible then caching
of the MSK may be necessary.  Do we have examples where the caching of
the EMSK is necessary.  In the case where key caching is used the cache
needs to be managed.  If we are caching EMSKs then the document that
describes EMSK usage must describe how key cache can be managed. 

> I think that whether it gets deleted or not is an 

[Joe] The goal of the architecture is to prevent the re-use of keys for
multiple different purposes.  I agree that this is not necessarily the
same a deletion.  It is very important that keys derived from the EMSK
don't collide purposes across applications.  What happens in a
particular AMSK branch of the key hierarchy is not necessarily as
important since this branch is cryptographically separated from the rest
of the system through the AMSK derivation.  I think the current text
could probably do better in motivating why it is good practice to delete
keys.

---

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 6 Mar 2006 09:48:03 -0800

> is used to generate AMSKs.  Hopefully everyone gets that.
[Joe] No. After the AMSKs are generated what are you going to do with
the EMSK?  The purpos of the EMSK is to generate AMSKs.  
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 6 Mar 2006 10:05:50 -0800

> lower layer, while doing so for MSK is ok? What is the fundamental
[Joe] If you pass the EMSK to the lower layer it becomes effectively the
same as the MSK.  If you want use the EMSK to key an independent
application that uses a different authenticator the security of that
application becomes completely dependent upon the lower layer its
authenticator.  

> the move ahead of time...
[Joe] A different application I may understand although it seems the
system typically knows the applications that are in use.  If you don't
I'm not sure how can authorize the distribution of keys.  For the
handoff case consider deriving an Handoff AMSK from the EMSK.  This
handoff AMSK becomes the root of all keys used for handoff. When you
move you derive a key from the handoff AMSK.

---

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 6 Mar 2006 10:56:44 -0800

> Sent: Monday, March 06, 2006 10:36 AM
> I have something to say about both your replies to I included them
> together.
> 
> 
> > 
> > Hi Madjid
> > 
> > Seems that there a lot of good reasons for keeping EMSK 
> around after 
> > it is used to generate AMSKs.  Hopefully everyone gets that.
> > 
> I think it is sufficient to say that exactly what you said: 
> "The purpose
> of the EMSK is to generate AMSKs."
> 
[Joe] OK great. SO in the above you meant keeping the EMSK around to
generate AMSKs after the EAP authentication transaction has completed. 

> Why should we generate all the AMSKs at once?  A session may have
> several applications that may require AMSK.  Some applications will be
> used 100% of the time, some application will be used rarely.  
> Why should
> an implmeentation genrate an AMSK and cache it just in case 
> it will need
> the key?  That doesn't make sense.
> 
[Joe] OK so as an optimization an entity can cache the EMSK so it could
generate the AMSK "just in time". I'm not sure how much of an
optimization would be, but I suppose there could be a few applications
that use this mechanism. If we do this we need to manage the cache, how
are entries identified, so they can be retrieved and deleted. We have a
key name so the key can be identified, although there may be an issue if
there are multiple caches as to which cache contains the right keys. 

> > Sent: Monday, March 06, 2006 12:46 PM
> > To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; 
> > Bernard Aboba
> > Cc: [email-masked]
> > > To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin 
> > Lopez; Bernard 
> > > Aboba
> > > Cc: [email-masked]
> generate an 
> > > AMSK for another application associated with the current session.
> > > 
> > [Joe] I understand that there may be need for caching of 
> > certain quantities.  I think Jari explained it well in a 
> > separate message.  In my opinion you should try to identify 
> > the applications in use and the keys needed as early as 
> > possible.  
> I disagree.  I think from a resource point of view we should 
> not genrate
> keys for something that we may not be using.  At any rate 
> this needs to
> be an implmeentation choice and we should not prohibit this 
> choice in a
> standard.
> 
> > If this is not possible then caching of the MSK 
> > may be necessary.  
> 
> I think you mean EMSK not MSK. Right?
> 
> If yes, we agree then caching of EMSK may be necessary.  Great!!!
> 
> I don't think we should write a specification that MUST require an
> implmeentation to dervie all the keys that it is necessary on 
> the chance
> that the keys may be needed.  
> 
> I do agree that EMSK MUST ONLY BE USED for key derivation (AMSKs) and
> MUST NOT be transported out of the EAP Authentication Server layer.
> 
> > Do we have examples where the caching of 
> > the EMSK is necessary.  
> 
> What if I don't have an example today?  Does that mean that in the
> future I won't? or that somewhere in the world someone does 
> have such a
> need?
> 
> > In the case where key caching is used 
> > the cache needs to be managed.  If we are caching EMSKs then 
> > the document that describes EMSK usage must describe how key 
> > cache can be managed. 
> 
> I agree.
>  
> > 
> > > statements like that are an over specification.  What 
> makes anyone 
> > > think that making a statement that "X should/must be 
> > deleted" is going 
> > > to be taken more seriously then "X should/must only be used for 
> > > purpose X and should/must not be transported out of Y"?
> > > 
> > [Joe] The goal of the architecture is to prevent the re-use 
> > of keys for multiple different purposes.  I agree that this 
> > is not necessarily the same a deletion.  It is very important 
> > that keys derived from the EMSK don't collide purposes across 
> > applications.  
> 
> I agree and therefore lets stick to the important issue and drop the
> deletion argument.  The important issue being that EMSK shall be used
> for AMSK derivation and for no other purpose.
> 
> > What happens in a particular AMSK branch of 
> > the key hierarchy is not necessarily as important since this 
> > branch is cryptographically separated from the rest of the 
> > system through the AMSK derivation.  I think the current text 
> > could probably do better in motivating why it is good 
> > practice to delete keys.  
> 
> I don't think we need to talk about key deletion at all, 
> except when it
> comes to the key's end-of-life or end of session.  I think we need to
> stress exactly what you said.
> 
>  
> > > > > 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).
> > > > [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
> > > > >

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 6 Mar 2006 14:04:47 -0500

Hi Jari,

I am not saying you have to have multiple AMSKs for multiple
technologies, but I was providing an example as a case where people may
want to. I don't happen to be one of them, at least not for a single AAA
domain.

Anyhow, as far as  "<x> MUST be deleted after <y>" and "<x> MUST be only
used for <y>", I agree there are no differences IF and ONLY IF <y> needs
to happen only once. I.e. if you use EMSK for generation of multiple
AMSKs at various times, then EMSK should not be deleted. You can still
require that EMSK is only used for authorized AMSK generation, under
whatever conditions that are set. But you cannot create AMSK later after
EMSK is deleted.

Madjid 

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Sunday, March 05, 2006 1:30 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Avi Lior; Salowey, Joe; Rafa Marin Lopez; Bernard Aboba;
[email-masked]
Subject: Re: [eap] Strawman -10/EMSK deletion requirement?

Madjid, Avi,

>Madjid>> Thank you for clarification. Another example may be roaming to
>Madjid>>i.e. keep EMSK for future AMSK generation. The first option 
>Madjid>>will
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

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 6 Mar 2006 14:05:15 -0500

Exactly my point. Thank you. 

-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Sunday, March 05, 2006 9:09 AM
To: Nakhjiri Madjid-MNAKHJI1; Salowey, Joe; Rafa Marin Lopez; Bernard
Aboba
Cc: [email-masked]

Hi Madjid 

> To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard 
> Aboba
> Cc: [email-masked]
> The only reason for caching the EMSK is if you have to generate an 

> server then the

---

From: "Salowey, Joe" <[email-masked]>
Date: Mon, 6 Mar 2006 14:03:58 -0800

Hi Avi,  

> 
> Perhaps you missed my poorly stated point :-)
> 
> What if the user is requesting access to a new application? 
> which could
> also involve the modification of the user's profile. 
> If EMSK is not there, then what do I do? Restart the session? No.
> 
> At anyrate I belive that there could be other use cases... I gave two
> reason why:
> 
> Just-in-time;
> Dynamic-Application provisioning.

[Joe] Would you agree with the following:

"For any specific application once the AMSK is generated for that
application there is no requirement to cache the EMSK for that
application, however there may be a need to cache the EMSK if the system
requires other Masks to be generated. "  

This makes the caching more of a system issue than an issue for one
particular application.

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 6 Mar 2006 18:31:30 -0500

Madjid>>I like to consider myself as an EAP keying consumer. I don't
really know what the cryptographic requirements for MSK or EMSK are? All
I know is that EMSK is recommended for creation of AMSK. Hence the need
for caching EMSK for future AMSK generation instances. I don't really
care about MSK at this point, because it is not used for AMSKs.

> statements like that are an over specification.  What makes anyone 
> think that making a statement that "X should/must be deleted" is going

Madjid>>Are you saying EAP keying architecture is incapable of
supportring various keying needs? I like to have a tree with EMSK as a
root and one per application AMSK as each branch and hopefully
independent of other AMSKs, is that wrong?
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 6 Mar 2006 18:32:26 -0500

Madjid>> Keep EMSK in case I need to create AMSKs later (as long as EAP
session is still valid). 

-----Original Message-----
From: Salowey, Joe [mailto:[email-masked]] 
Sent: Monday, March 06, 2006 11:48 AM
To: Avi Lior; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard Aboba
Cc: [email-masked]
Subject: RE: [eap] Strawman -10/EMSK deletion requirement?

 > 
> Hi Madjid
> 
> Seems that there a lot of good reasons for keeping EMSK around after

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Mon, 6 Mar 2006 18:38:35 -0500

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

Madjid>>I am not transporting the EMSK anywhere. I thought that was a
main distinction.
Well, the role of authenticator may be not as relevant as the role of
the AAA server in keying for an application. Authenticator is just a
pass-through for EAP, the applications don't have to get their keys from
the authenticator.

Madjid>>Well today, you run one EAP every time you need keys for a
protocol (MIPv6 or something else, SIP, I don't know). Do you know
exactly at the start how many protocols you want to key for? Do you want
to run a new EAP every time you find out?
For handover, yes HO-AMSK is a good solution, if you own the whole
network, I don't know what sort of requirements people will have moving
to another operator network??

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Tue, 7 Mar 2006 13:06:33 -0500

I agree with Avi's statements. Limit the purpose of EMSK and its usage
(to AMSK generation) and prohibit its transport outside server, without
requiring its deletion. That will cover future AMSK generations as well.

Madjid

-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Monday, March 06, 2006 12:36 PM
To: Salowey, Joe; Nakhjiri Madjid-MNAKHJI1; Rafa Marin Lopez; Bernard
Aboba
Cc: [email-masked]

Hi Joe,

I think it is sufficient to say that exactly what you said: "The purpose
of the EMSK is to generate AMSKs."

Why should we generate all the AMSKs at once?  A session may have
several applications that may require AMSK.  Some applications will be
used 100% of the time, some application will be used rarely.  Why should
an implmeentation genrate an AMSK and cache it just in case it will need
the key?  That doesn't make sense.

> keys needed as early as possible.
I disagree.  I think from a resource point of view we should not genrate
keys for something that we may not be using.  At any rate this needs to
be an implmeentation choice and we should not prohibit this choice in a
standard.

> If this is not possible then caching of the MSK may be necessary.

I don't think we should write a specification that MUST require an
implmeentation to dervie all the keys that it is necessary on the chance
that the keys may be needed.  

> Do we have examples where the caching of the EMSK is necessary.

What if I don't have an example today?  Does that mean that in the
future I won't? or that somewhere in the world someone does have such a
need?

> In the case where key caching is used the cache needs to be managed.  
> If we are caching EMSKs then the document that describes EMSK usage 
> must describe how key cache can be managed.

I agree.
 
> [Joe] The goal of the architecture is to prevent the re-use of keys 
> for multiple different purposes.  I agree that this is not necessarily

> the same a deletion.  It is very important that keys derived from the 
> EMSK don't collide purposes across applications.

> What happens in a particular AMSK branch of the key hierarchy is not 
> necessarily as important since this branch is cryptographically 
> separated from the rest of the system through the AMSK derivation.  I 
> think the current text could probably do better in motivating why it 
> is good practice to delete keys.

I don't think we need to talk about key deletion at all, except when it
comes to the key's end-of-life or end of session.  I think we need to
stress exactly what you said.

> > > the EMSK should not be available to this layer, if the AAA layer 
> > > [Joe] To minimize the chance of exposure of the EMSK.  Why do you

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 7 Mar 2006 12:39:51 -0800

Joe, 
I can see the problem with transporting the EMSK to other entities -
however, what really is the concern with caching the EMSK as long as it
is never exported? Is it just the concern of having to maintain state or
is there a security concern here? 

Vidya 

> Sent: Monday, March 06, 2006 2:04 PM
> To: Avi Lior; Jari Arkko
> Cc: [email-masked]
> "For any specific application once the AMSK is generated for 
> that application there is no requirement to cache the EMSK 
> for that application, however there may be a need to cache 
> the EMSK if the system requires other Masks to be generated. "  
>

---

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 8 Mar 2006 10:23:12 -0800

The EMSK is the root of all AMSKs, so a compromise of the EMSK
compromises all AMSKs.  Therefore I would like to see the EMSK protected
as much as possible.  Once the EMSK is securely deleted it cannot be
compromised. I would like to see applications be as independent from one
another as possible and not have one application require the EMSK be
cached once its AMSK is generated. This implies a deeper key hierarchy
than if an application derives all of its keys directly from the EMSK.  

Caching itself is new functionality in the system, but seems to be
required whether you cache AMSK or EMSK.  I don't really have a problem
with caching the EMSK if it is required at the system level because all
applications are not known at the right time.  It think it may be OK for
an implementation to cache the EMSK for its own optimizations, but I
would prefer that the caching of the EMSK not be required for any
particular AMSK usage.  Since an AMSK is exportable you have more
options on where it can be cached.  

Hope this helps,

Joe

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Tuesday, March 07, 2006 12:40 PM
> To: Salowey, Joe; Avi Lior; Jari Arkko
> Cc: [email-masked]

---

From: "Avi Lior" <[email-masked]>
Date: Wed, 8 Mar 2006 13:24:16 -0500

So there might be reason for caching the EMSKs.  So language like the
following:

EMSK is used strictly for generating AMSKs.

EMSK is not transported out of the EAP Authentication Server Layer.

EMSK MUST be deleted when the session for which it was created is
deleted.

EMSK SHOULD be deleted sooner, when it is no longer required.  

> Sent: Wednesday, March 08, 2006 1:23 PM
> To: Narayanan, Vidya; Avi Lior; Jari Arkko
> Cc: [email-masked]
> The EMSK is the root of all AMSKs, so a compromise of the 
> EMSK compromises all AMSKs.  Therefore I would like to see 
> the EMSK protected as much as possible.  Once the EMSK is 
> securely deleted it cannot be compromised. I would like to 
> see applications be as independent from one another as 
> possible and not have one application require the EMSK be 
> cached once its AMSK is generated. This implies a deeper key 
> hierarchy than if an application derives all of its keys 
> directly from the EMSK.  
> 
> Caching itself is new functionality in the system, but seems 
> to be required whether you cache AMSK or EMSK.  I don't 
> really have a problem with caching the EMSK if it is required 
> at the system level because all applications are not known at 
> the right time.  It think it may be OK for an implementation 
> to cache the EMSK for its own optimizations, but I would 
> prefer that the caching of the EMSK not be required for any 
> particular AMSK usage.  Since an AMSK is exportable you have 
> more options on where it can be cached.  
> 
> Hope this helps,
> 
> Joe
> 
> > however, what really is the concern with caching the EMSK 
> as long as 
> > it is never exported? Is it just the concern of having to maintain 
> > state or is there a security concern here?
> > 
> > Vidya
> > 
> > > application, however there may be a need to cache the EMSK if the 
> > > system requires other Masks to be generated. "
> > >

---

From: Pascal Urien <[email-masked]>
Date: Wed, 08 Mar 2006 19:32:54 +0100

Hi everybody

>options on where it can be cached.

In the last version of 
http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-10.txt
it is suggested to securely compute AMSK keys in EAP smartcards, without 
exporting EMSK

see

 >>7.16 Get-AMSK
 >>
 >>   According to [RFC 4017] EMSK is an "additional keying material
 >>   derived between the EAP client and server that is exported by the
 >>   EAP method. The EMSK is at least 64 octets in length. The EMSK is
 >>   not shared with the authenticator or any other third party. The EMSK
  >>  is reserved for future uses that are not yet defined".
 >>
 >>   It has been suggested in [EAP-EXT] to derive Application-specific
 >>   Master Session Keys (AMSKs)from EMSK. As an illustration AMSK MAY be
 >>   obtained by a Key Derivation Function (KDF), such as
 >>
 >>                        AMSK = KDF(EMSK, label, length)
 >>
 >>   The Get-AMSK(index,label) command is used to compute AMSK key,
 >>   identified by an index and optionally associated to a label, needed
 >>   to its calculation.

I believe that this functionality should be useful when a high security level
  is required, specially if EMSK controls a critical process like handover

Pascal

---

From: "Salowey, Joe" <[email-masked]>
Date: Wed, 8 Mar 2006 17:28:51 -0800

I would add that the AMSK for a particular application should be derived
such that once the AMSK is derived for that application there is no need
to continue to use the EMSK for derivation of additional keys for that
application.  

> Sent: Wednesday, March 08, 2006 10:24 AM
> To: Salowey, Joe; Narayanan, Vidya; Jari Arkko
> Cc: [email-masked]

---

From: "Avi Lior" <[email-masked]>
Date: Thu, 9 Mar 2006 09:20:47 -0500

Hi Joe

> Sent: Wednesday, March 08, 2006 8:29 PM
> To: Avi Lior; Narayanan, Vidya; Jari Arkko
> Cc: [email-masked]
> I would add that the AMSK for a particular application should 
> be derived such that once the AMSK is derived for that 
> application there is no need to continue to use the EMSK for 
> derivation of additional keys for that application.  

Yes I totally agree.  AMSK derivation happens within the EAP Auth
Server.  Derived keys from AMSK happen within KeyHolder/KeyGenerator
function which is external to the EAP Auth Server.

> > > compromises all AMSKs.  Therefore I would like to see the EMSK 
> > > protected as much as possible.  Once the EMSK is securely 
> deleted it 
> > > cannot be compromised. I would like to see applications be as 
> > > independent from one another as possible and not have one 
> > > application require the EMSK be cached once its AMSK is 
> generated. 
> > > This implies a deeper key hierarchy than if an 
> application derives 
> > > all of its keys directly from the EMSK.
> > > 
> > > required whether you cache AMSK or EMSK.  I don't really have a 
> > > problem with caching the EMSK if it is required at the 
> system level 
> > > because all applications are not known at the right time. 
>  It think 
> > > it may be OK for an implementation to cache the EMSK for its own 
> > > optimizations, but I would prefer that the caching of the 
> EMSK not 
> > > be required for any particular AMSK usage.  Since an AMSK is 
> > > exportable you have more options on where it can be cached.
> > > 
> > > Hope this helps,
> > > 
> > > Joe
> > >

---

From: "Avi Lior" <[email-masked]>
Date: Thu, 9 Mar 2006 10:05:07 -0500

Hi,
I would like to modify what you wrote as follows:

> "The EMSK MUST NOT be used to generate any keys other than 
> AMSKs needed for the same EAP peer that owns the EMSK. 

The EMSK MUST NOT be used to generate any keys other than AMSKs needed
for the same session for which the EMSK was generated.

> The 
> EMSK MUST NOT be transported out of the EAP (AAA?) Layer and 
> MUST be deleted when the corresponding EAP session expires.

Replace EAP (AAA?) with EAP Authentication Server; and "corresponding
EAP session expires" with 'corresponding session has ended'.

Motivation for above: Not sure if EAP session is defined; and you delete
the EMSK when the session is terminated either because it expired or
because it was explicitly terminated.
 
> Further, an EMSK MUST NOT be used to generate more than one 
> AMSK for a given application. 

I am not sure that the above does not pose a threat.  Normally we would
think that one Application would require one AMSK.  But since we are not
defining what an application is -- and we shouldn't IMO enter that rat
hole.  Then what if there was some application that requires an two
AMSKs.?  Is there harm?

> If more keys are needed for an 
> application, those may be derived from the AMSK subsequently 
> by the entities sharing the AMSK. 

I don't think you need the 'subsequently by entities sharing the AMSK'.
I can give one example of one application where  there there is only one
entity that receives the AMSK.  That entity generates the keys needed by
the applications and transports those keys to elements that need the
key.  The AMSK is not transported at all.

> It is RECOMMENDED that all 
> necessary AMSKs corresponding to various applications be 
> generated immediately upon EMSK generation and that the EMSK 
> be deleted right away thereafter."  

I prefer:

Once all AMSKs have been derived and the EMSK is not needed it shall be
deleted.

> Sent: Wednesday, March 08, 2006 8:38 PM
> Putting all this together, is it fair to say this then? 
> 
> "The EMSK MUST NOT be used to generate any keys other than 
> AMSKs needed for the same EAP peer that owns the EMSK. The 
> EMSK MUST NOT be transported out of the EAP (AAA?) Layer and 
> MUST be deleted when the corresponding EAP session expires. 
> Further, an EMSK MUST NOT be used to generate more than one 
> AMSK for a given application. If more keys are needed for an 
> application, those may be derived from the AMSK subsequently 
> by the entities sharing the AMSK. It is RECOMMENDED that all 
> necessary AMSKs corresponding to various applications be 
> generated immediately upon EMSK generation and that the EMSK 
> be deleted right away thereafter." 
> 
> > Sent: Wednesday, March 08, 2006 5:29 PM
> > I would add that the AMSK for a particular application should be 
> > derived such that once the AMSK is derived for that 
> application there 
> > is no need to continue to use the EMSK for derivation of additional 
> > keys for that application.
> > 
> > > > > > > At anyrate I belive that there could be other use 
> cases... 
> > > > > > I gave two
> > > > > > > reason why:
> > > > > > > 
> > > > > > > Just-in-time;

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 9 Mar 2006 07:25:19 -0800

> AMSKs needed 
> >for the same EAP peer that owns the EMSK. The EMSK MUST NOT be 
> >transported out of the EAP (AAA?) Layer and MUST be deleted when the 
> >corresponding EAP session expires. Further, an EMSK MUST NOT 
> be used to 
> >generate more than one AMSK for a given application. If more 
> keys are 
> >needed for an application, those may be derived from the AMSK 
> >subsequently by the entities sharing the AMSK. It is 
> RECOMMENDED that 
> >all necessary AMSKs corresponding to various applications be 
> generated 
> >immediately upon EMSK generation and that the EMSK be deleted right 
> >away thereafter."
> >  
> >
> I think I can live with this text. As I said in a previous 
> e-mail, I have been convinced that we need to support some 
> form of dynamic generation of AMSKs.
> 
> We also seem to be coming to a consensus on keeping the EMSK 
> at the server side.
> 
> But I still have a few nagging thoughts:
> 
> 1. In order to avoid a situation that suddenly all AAA 
> servers need to start
>     keeping state, do we need  to require an authorization profile
>     flag, configuration knob, or attribute to signal the need for
>     keeping state?
> 

I wonder if this could be handled by policy alone. A flag or signal
would be better and more explicit - did you think this would be signaled
by the peer? The authenticator will not have sufficient knowledge about
the applications that the peer is interested in and hence this should
probably come from the peer - now, we are talking about introducing this
into EAP messaging - right? 

> 2. The text does not tell us how to determine when all necessary
>     AMSKs have been generated.
> 

Maybe the text should also say "The server may have policies to indicate
the number of AMSKs a peer is authorized for - once those are derived,
the EMSK is deleted" - ? 

-Vidya

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 9 Mar 2006 07:42:36 -0800

Hi Avi,
 
> > "The EMSK MUST NOT be used to generate any keys other than AMSKs 
> > needed for the same EAP peer that owns the EMSK.
> 
> The EMSK MUST NOT be used to generate any keys other than 
> AMSKs needed for the same session for which the EMSK was generated.
> 

Sounds good. 

> > The
> > EMSK MUST NOT be transported out of the EAP (AAA?) Layer 
> and MUST be 
> > deleted when the corresponding EAP session expires.
> 
> Replace EAP (AAA?) with EAP Authentication Server; and 
> "corresponding EAP session expires" with 'corresponding 
> session has ended'.
> 

I guess when you say EAP Authentication Server, it is a bit vague about
whether that is the EAP layer or AAA layer. I'm not sure if there is
value in clarifying this or if it makes more sense to leave it to
implementation.  

> Motivation for above: Not sure if EAP session is defined; and 
> you delete the EMSK when the session is terminated either 
> because it expired or because it was explicitly terminated.
>  

Could we say "corresponding session has either expired or been
terminated"? 

> I am not sure that the above does not pose a threat.  
> Normally we would think that one Application would require 
> one AMSK.  But since we are not defining what an application 
> is -- and we shouldn't IMO enter that rat hole.  Then what if 
> there was some application that requires an two AMSKs.?  Is 
> there harm?
> 

Hmmm. If an application requires more than one key, would there really
be a case where creation of a root AMSK and subsequent keys from that
root AMSK not work? I'm wondering why you need to create multiple AMSKs
for the same application directly from the EMSK. I'd personally like to
have no more than one key coming out of the EMSK for the same key label
(unique per application) in AMSK derivation. 

> > application, those may be derived from the AMSK subsequently by the 
> > entities sharing the AMSK.
> 
> I can give one example of one application where  there there 
> is only one entity that receives the AMSK.  That entity 
> generates the keys needed by the applications and transports 
> those keys to elements that need the key.  The AMSK is not 
> transported at all.
> 

Fair enough. I was trying to get at the fact that subsequent keys should
not be derived for entities other than the ones the AMSK was meant for -
maybe that restriction itself isn't really needed. 

> > necessary AMSKs corresponding to various applications be generated 
> Once all AMSKs have been derived and the EMSK is not needed 
> it shall be deleted.
> 

To Joe's earlier points (about trying to keep the EMSK as secure as
possible and delete it as quickly as possible), I would like to see this
recommendation. Maybe appending the former text with "When this is not
feasible, the EMSK MUST be deleted once all the AMSKs have been derived"
makes sense? 

-Vidya

> > "The EMSK MUST NOT be used to generate any keys other than AMSKs 
> > needed for the same EAP peer that owns the EMSK. The EMSK 
> MUST NOT be 
> > corresponding EAP session expires.
> AMSK for a 
> > given application. If more keys are needed for an 
> application, those 
> > may be derived from the AMSK subsequently by the entities 
> sharing the 
> > AMSK. It is RECOMMENDED that all necessary AMSKs corresponding to 
> > various applications be generated immediately upon EMSK 
> generation and 
> > that the EMSK be deleted right away thereafter."
> >

---

From: "Avi Lior" <[email-masked]>
Date: Thu, 9 Mar 2006 11:45:18 -0500

Hi 

Please see inline... 

> Sent: Thursday, March 09, 2006 10:43 AM
> To: Avi Lior; Salowey, Joe; Jari Arkko
> Cc: [email-masked]
> "corresponding 
> I guess when you say EAP Authentication Server, it is a bit 
> vague about whether that is the EAP layer or AAA layer. I'm 
> not sure if there is value in clarifying this or if it makes 
> more sense to leave it to implementation.  

Well it is not happening in the AAA layer.  My understanding is that the
EAP Method executes within the EAP Auth Server.  EAP Auth Server may or
may not be colocated with the AAA server.

> > Motivation for above: Not sure if EAP session is defined; and you 
> > delete the EMSK when the session is terminated either because it 
> > expired or because it was explicitly terminated.
> >  
> 
> Could we say "corresponding session has either expired or 
> been terminated"? 

Sounds good.
> > > given application.
> one AMSK.  
> > But since we are not defining what an application is -- and we 
> > shouldn't IMO enter that rat hole.  Then what if there was some 
> > application that requires an two AMSKs.?  Is there harm?
> > 
> 
> Hmmm. If an application requires more than one key, would 
> there really be a case where creation of a root AMSK and 
> subsequent keys from that root AMSK not work? I'm wondering 
> why you need to create multiple AMSKs for the same 
> application directly from the EMSK. I'd personally like to 
> have no more than one key coming out of the EMSK for the same 
> key label (unique per application) in AMSK derivation. 

Lets get to right down to the label(s).  If I have an application called
foo, can I generate two AMSKs as follows:

AMSK-FOO-A = KGF(EMSK,"FOO-A" | ......)
AMSK-FOO-B = KGF(EMSK,"FOO-B" | ......)

I don't know why an application FOO would like to do this.  Maybe FOO
application is really two applications.    

But the point is, from a security perspective why does it matter?

> > I can give one example of one application where  there 
> there is only 
> > one entity that receives the AMSK.  That entity generates the keys 
> > needed by the applications and transports those keys to 
> elements that 
> > need the key.  The AMSK is not transported at all.
> > 
> 
> Fair enough. I was trying to get at the fact that subsequent 
> keys should not be derived for entities other than the ones 
> the AMSK was meant for - maybe that restriction itself isn't 
> really needed. 
> 
> it shall 
> > be deleted.
> To Joe's earlier points (about trying to keep the EMSK as 
> secure as possible and delete it as quickly as possible), I 
> would like to see this recommendation. Maybe appending the 
> former text with "When this is not feasible, the EMSK MUST be 
> deleted once all the AMSKs have been derived"
> makes sense? 

I think my statement addresses Joe's concern.  But I find the whole
concept of immediacy silly especially when EAP does not concern itself
with key lifetimes etc....

Why are we all of a sudden concerned about timelyness?

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Thu, 9 Mar 2006 10:18:31 -0800

Jari Arkko <mailto:[email-masked]> supposedly scribbled:

> Glen Zorn (gwz) wrote:
> 
>> 
>>>> 
>>>> 
>>> The problem is that since EMSK is the root, its compromise will lead
>>> to the compromise of all derived keys. This also holds locally for
>>> the AMSK_root_0 approach. That is, if AMSK_root_0 is compromised
>>> then any keys derived from that root are compromised (but not keys
>>> in 
>>> other apps).
>>> 
>>> 
>> 
>> I guess I'm just confused, then (not a first!).  I thought that the
>> major problem was that it is basically impossible to no which (if
>> any) _applications_ a person would choose to use during a session. 
>> If that is accurate, I can't really see how the AMSK_root_0 approach
>> solves the problem.  If that's not the problem, what is?    
>> 
>> 
> Oh. Maybe I was confused. AMSK_root_0 does not solve that problem. It
> solves the problem that if your application requires multiple keys
> (as in fast handoff to AP2, AP3, etc) then you still only need one
> AMSK from the EMSK for the application. That AMSK_root_0 can then be
> used to generate all the keys that the application in question needs.

OK, I guess I just assumed that the "M" in "AMSK" implied that usage.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: "Avi Lior" <[email-masked]>
Date: Thu, 9 Mar 2006 14:40:44 -0500

Glen and Jari,

That is what I thought the 'M' was about as well. 

> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Thursday, March 09, 2006 1:19 PM
> To: Jari Arkko
> Cc: [email-masked]
> >>> in other apps).
> > solves the problem that if your application requires 
> multiple keys (as 
> > in fast handoff to AP2, AP3, etc) then you still only need one AMSK 
> > from the EMSK for the application. That AMSK_root_0 can 
> then be used 
> > to generate all the keys that the application in question needs.
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 9 Mar 2006 15:53:04 -0800

> > I guess when you say EAP Authentication Server, it is a bit vague 
> > about whether that is the EAP layer or AAA layer. I'm not sure if 
> > there is value in clarifying this or if it makes more sense 
> to leave 
> > it to implementation.
> 
> Well it is not happening in the AAA layer.  My understanding 
> is that the EAP Method executes within the EAP Auth Server.  
> EAP Auth Server may or may not be colocated with the AAA server.
> 

I wonder if this is a problem - if we want the EAP AS to generate the
EMSK/AMSK and cache it for an entity (such as a MIP HA) to fetch the
AMSK later upon receiving a BU or something, the HA will only contact
the AAA server. Or, do you envision the AMSK in such cases to be sent to
the AAA server for caching? 

<snip>

> there really 
> > root AMSK not work? I'm wondering why you need to create multiple 
> > AMSKs for the same application directly from the EMSK. I'd 
> personally 
> > like to have no more than one key coming out of the EMSK 
> for the same 
> Lets get to right down to the label(s).  If I have an 
> application called foo, can I generate two AMSKs as follows:
> 

As far as the EAP server is concerned, I'd argue that FOO-A and FOO-B
are different applications. So, we could just say that no more than one
EMSK for a given key label is allowed. 

> application is really two applications.    

<snip>

> > possible and delete it as quickly as possible), I would like to see 
> > this recommendation. Maybe appending the former text with 
> "When this 
> > is not feasible, the EMSK MUST be deleted once all the 
> AMSKs have been 
> > derived"
> > makes sense? 
> 
> I think my statement addresses Joe's concern.  But I find the 
> whole concept of immediacy silly especially when EAP does not 
> concern itself with key lifetimes etc....
> 

I'd personally be okay with leaving this out - even if it is recommended
to be deleted, implementations are likely to cache it for practical
reasons anyway. 

Vidya

---

From: "Avi Lior" <[email-masked]>
Date: Thu, 9 Mar 2006 21:25:47 -0500

Hi, 

> Sent: Thursday, March 09, 2006 6:53 PM

<snip>

> > Well it is not happening in the AAA layer.  My 
> understanding is that 
> > the EAP Method executes within the EAP Auth Server.
> I wonder if this is a problem - if we want the EAP AS to 
> generate the EMSK/AMSK and cache it for an entity (such as a 
> MIP HA) to fetch the AMSK later upon receiving a BU or 
> something, the HA will only contact the AAA server. Or, do 
> you envision the AMSK in such cases to be sent to the AAA 
> server for caching? 

We don't want the EAP AS to cache the AMSK.

The AAA isnt responsible for caching either.  If we consider RADIUS,
RADIUS is stateless, it has no caching capabilites at all.  Diameter
does (however).

So AMSK is cached outside the EAP AS and outside AAA - I belive the AMSK
is cached in another functional entity called a KeyHolder/KeyGenerator.
That solves the problem for RADIUS.

> > Lets get to right down to the label(s).  If I have an application 
> > called foo, can I generate two AMSKs as follows:
> > 
> > AMSK-FOO-A = KGF(EMSK,"FOO-A" | ......) AMSK-FOO-B = 
> KGF(EMSK,"FOO-B" 
> > | ......)
> > 
> 
> As far as the EAP server is concerned, I'd argue that FOO-A 
> and FOO-B are different applications. So, we could just say 
> that no more than one EMSK for a given key label is allowed. 

Fine with me.  Its not about defining an application but rather the
important piece is defining the concept of a label. 

Because you have this possiblity as well and sounds like a lable needs
to be precisely defined.

FOO-A = KGF(EMSK,"FOO" | "A" | ....);
FOO-B = KGF(EMSK,"FOO" | "B" | ....); 

So the first part "FOO" is the lable and it is the key name and
therefore must be unique within each session.  Therefore, although FOO-A
<> FOO-B, the above is illegal.

> secure as 
> I'd personally be okay with leaving this out - even if it is 
> recommended to be deleted, implementations are likely to 
> cache it for practical reasons anyway. 

I agree.....but I am easy going about this either way.

---

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 9 Mar 2006 20:58:41 -0800

> vague about
[Joe] I'm pretty convinced it is in EAP.  In the pictures the AAA layer
appears to carry communication between AAA client and AAA server, I do
not think this is where the EMSK belongs.

---

From: "Avi Lior" <[email-masked]>
Date: Fri, 10 Mar 2006 00:02:50 -0500

Joe and All,

I totally agree with Joe.

AAA is a protocol that transports and cant realy cache anything in the
case of RADIUS which is stateless.

So any caching has to be outside AAA or with AAA (but Diameter only). 

> Sent: Thursday, March 09, 2006 11:59 PM
> [Joe] I'm pretty convinced it is in EAP.  In the pictures the 
> AAA layer appears to carry communication between AAA client 
> and AAA server, I do not think this is where the EMSK belongs. 
> 
>  
>

---

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 9 Mar 2006 21:08:58 -0800

<snip>
> application called
[Joe] As long as there is not caching required between AMSK-FOO-A and
AMSK-FOO-B, I'm not sure it really matters. The argument against it is
that it may encourage caching and there really isn't a reason why you
couldn't derive the two keys lower in the hierachy (except perhaps for
efficiency).  For what its worth in the original EMSK usage draft
(http://bgp.potaroo.net/ietf/all-ids/draft-salowey-eap-key-deriv-02.txt)
we had the following prototype for the KDF:

AMSK = KDF(EMSK, key label, optional application data, length

---

From: "Avi Lior" <[email-masked]>
Date: Fri, 10 Mar 2006 00:11:11 -0500

Joe,

See inline.... 

> Sent: Thursday, March 09, 2006 11:51 PM
> [Joe] I think we will probably need mopre definition around this. 

[Avi] Okay.

> > Normally we would
> [Joe] If they are generated at the same time I don't think there is a
> problem.  If there is a delay in generation where the application
> requires the EMSK to be cached it is less than optimal.  
> 
[Avi] In another email thread we explored this further and the way I
understand it is that an Application can have one AMSK key because:

FOO-AMSK = KGF(EMSK,"FOO" | ... | ...)

"FOO" is a the Key Lable and it must be unique.

FOO-A-AMSK = KGF(EMSK,"FOO-A" |  ... | ...)
FOO-B-AMSK = KGF(EMSK,"FOO-B" |  ... | ...)

Are really two differnet AMSKs and this is legal because these are
viewed as two separate applications.

And 
FOO-A-AMSK = KGF(EMSK,"FOO" | "A" | ...)
FOO-B-AMSK = KGF(EMSK,"FOO" | "B" | ...)

Generates two distinct keys but SHOULD not be legal. 

I am not sure if this is defined correctly.

Finally,  I am not sure how this has to do with EMSK caching or not.

---

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 9 Mar 2006 21:16:29 -0800

> Sent: Thursday, March 09, 2006 9:03 PM

[Joe] I think a AAA server is typically composed of several components.
One of these can be a key holder.  I don't see why you couldn't define
new functionality in RADIUS to interact with the key holder (other than
the fact that it seems to be difficult to define anything new in
RADIUS).

---

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 9 Mar 2006 21:42:35 -0800

> I am not sure if this is defined correctly.

[Joe] I'm not sure the last has to be illegal but it calls into question
the "M" in AMSK.  It would be better to derive these two keys off an
AMSK for FOO.  

> Finally,  I am not sure how this has to do with EMSK caching or not.

[Joe] Any one application should not introduce a requirement to cache
the EMSK. If you are going to derive keys at different times for an
application this should be done off an AMSK not the EMSK.  
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

---

From: "Avi Lior" <[email-masked]>
Date: Fri, 10 Mar 2006 00:55:27 -0500

See inline....

> Sent: Friday, March 10, 2006 12:43 AM
> > > > > Further, an EMSK MUST NOT be used to generate more 
> than one AMSK 
> > > > > for a given application.
> > > > 
> > > > think that one Application would require one AMSK.  But 
> since we 
> > > > are not defining what an application is -- and we shouldn't IMO
> > > enter that rat
> > FOO-A-AMSK = KGF(EMSK,"FOO-A" |  ... | ...) FOO-B-AMSK = 
> > KGF(EMSK,"FOO-B" |  ... | ...)
> > 
> > FOO-A-AMSK = KGF(EMSK,"FOO" | "A" | ...) FOO-B-AMSK = 
> KGF(EMSK,"FOO" | 
> > "B" | ...)
> > 
> [Joe] I'm not sure the last has to be illegal but it calls 
> into question the "M" in AMSK.  It would be better to derive 
> these two keys off an AMSK for FOO.  

FOO-A-AMSK and FOO-B-AMSK are not intended to be subkeys for FOO -- they
are two AMSKs for FOO.  The original context was whether or not an
Application can have two or more AMSKs.
 
> [Joe] Any one application should not introduce a requirement 
> to cache the EMSK. If you are going to derive keys at 
> different times for an application this should be done off an 
> AMSK not the EMSK.  
>

---

From: "Avi Lior" <[email-masked]>
Date: Fri, 10 Mar 2006 10:41:14 -0500

Jari,

> Sent: Friday, March 10, 2006 2:47 AM
> To: Salowey, Joe; Avi Lior; Narayanan, Vidya
> Cc: [email-masked]
> >>>Further, an EMSK MUST NOT be used to generate more than 
> one AMSK for 
> >>>a given application.
> >>>      
> >>>
> since we are 
> >>not defining what an application is -- and we shouldn't IMO 
> enter that 
> >>rat hole.  Then what if there was some application that requires an 
> >>two AMSKs.?  Is there harm?
> >>    
> >>
> 
> This related originally to the EMSK deletion requirement. 
> There was an argument that the EMSK need to stay around so 
> that application X can keep on asking the 127th key that it needs.
> 
> Now that we seem to be saying that there is no strict EMSK 
> deletion requirement, this may be less urgent.
> 
> However, I still think it is a good idea that applications 
> get just one AMSK, and if they need multiple keys they 
> generate those themselves.  And the definition of an 
> application can be "an IANA registered label for an AMSK 
> needed for a specific purpose". Since the IANA registrations 
> won't have "handoff 1st key", "handoff 2nd key" etc but 
> rather "handoff key", then we satisfy this model. But this is 
> still mostly to keep the hierarchy structurally clean and 
> simple, not for any specific technical reason. (Other than 
> that it still allows early deletion of the EMSK better than 
> if we would base all keys on the EMSK.)

I agree.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 10 Mar 2006 09:19:54 -0800

I completely agree with Jari's comments below. I also meant EAP/AAA
server as a "box" and was not so much referring to the AAA protocol
itself. While AAA protocols could remain stateless, it would be fine to
say that the EMSK resides in the EAP server without getting into key
holders, etc. 

Thanks,
Vidya 

> Sent: Friday, March 10, 2006 12:34 AM
> To: Avi Lior
> Cc: Salowey, Joe; Narayanan, Vidya; [email-masked]
> Avi Lior wrote:
> >>new functionality in RADIUS to interact with the key holder (other 
> >>than the fact that it seems to be difficult to define 
> anything new in 
> >>RADIUS).
> >>    
> >>
> >
> >[Avi]  Aboslutely correct on all fronts ;-).  A AAA server can have 
> >EAP-AS (authetncation server) and a key holder/key generator.  So I 
> >guess ia m being very formal in the sense that AAA is a protocol and 
> >not a server.
> >
> >And BTW I don't think we need to have an RFC to define a Key Holder 
> >function in RADIUS servers.
> >  
> >
> First of all, I think this part of the discussion is largely 
> just a matter of vague definitions making it hard to make 
> exact statements. E.g. where is the line between AAA as a 
> "transport" and as an "application" that has intelligence to 
> make decisions and grant resources such as keys?
> 
> Just to repeat what we have already established, I think we 
> have consensus that (a) EMSK is generated by EAP methods and 
> that (b) its not going to be shipped away to the access 
> devices. In addition, it seems obvious that the document we 
> are discussing will not define how AMSKs are used or transported.
> 
> So the conclusion is that the EMSK is kept somewhere between 
> the EAP method and AAA transport layers.
> I would note that this means that it is, in an IETF sense, 
> within a box and not transported via protocols. I don't think 
> it makes a lot of sense to debate too long about what the 
> internal structure of the box is. I'd be happy saying that it 
> resides in the EAP server. I would in addition only say the 
> following about the internal module structures: The EMSK is 
> not communicated either to the lower layer or the AAA transport layer.
> But AMSKs derived from it can be,
> and that any such derivation would have to be defined in 
> future documents.
> 
> Finally, I dislike the idea that we would be adding major 
> functionality (such as key server) to IETF protocols and 
> mechanisms without properly documenting how they will be used 
> and what the protocols will exactly carry. The role of the 
> EAP keying framework is to leave some key material in the EAP 
> server to enable such functionality, but if we are going to 
> use it, we will need, among other things, protocol 
> descriptions on how RADIUS can retrieve pieces of this key 
> information and how particular applications employ these keys.
> 
> --Jari
> 
>

---

From: "Avi Lior" <[email-masked]>
Date: Fri, 10 Mar 2006 14:55:31 -0500

Vidya,

See inline... 

> Sent: Friday, March 10, 2006 12:23 PM
> To: Avi Lior; Jari Arkko
> Cc: Salowey, Joe; [email-masked]
> > > The role of the
> > > EAP keying framework is to leave some key material in the
> > EAP server
> > > to enable such functionality, but if we are going to use
> > it, we will
> > > need, among other things, protocol descriptions on how RADIUS can 
> > > retrieve pieces of this key information and how particular 
> > > applications employ these keys.
> > 
> > If RADIUS is colocated with EAP-server do we need to define 
> a protocol 
> > for getting the AMSK(s)?
> >  
> 
> I would imagine that each application will define some RADIUS 
> attributes or Diameter AVPs to retrive the AMSK using the AAA 
> protocol. No? 

Yes. To get the AMSK or derivative keys from the AAA server. But not
between the AAA server and the EAP-Authentication Server.

Note, if I can remember correctly someone wanted to specify a protocol
to get the AMSK from the EMSK.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 10 Mar 2006 13:13:36 -0800

Avi,

> Yes. To get the AMSK or derivative keys from the AAA server. 
> But not between the AAA server and the EAP-Authentication Server.
> 
> Note, if I can remember correctly someone wanted to specify a 
> protocol to get the AMSK from the EMSK.
> 

How often do we have an EAP server not co-located with the AAA server?
When they are co-located, a protocol isn't really required. When they
are not, I can see a need - but, from a practical use case perspective,
I feel that such a protocol would find very limited use. 

Vidya

---

From: "Avi Lior" <[email-masked]>
Date: Fri, 10 Mar 2006 16:24:59 -0500

See inline please.... 

> How often do we have an EAP server not co-located with the AAA server?

Well in one SDO activitiy that I am working on there is a case where the
EAP-Server is not deployed with the AAA-server for some fo the cases.
It is however co-located with the NAS.

> When they are co-located, a protocol isn't really required. 

I agree.

> When they are not, I can see a need - but, from a practical 
> use case perspective, I feel that such a protocol would find 
> very limited use. 

I agree with you. But I wouldn't discount it either.  My approach is to
allow for that -- and certainly it is allowed and then solve the problem
when someone can actually demonstrate a need. Or let them solve the
problem ;-)

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 10 Mar 2006 14:17:06 -0800

> Well in one SDO activitiy that I am working on there is a 
> case where the EAP-Server is not deployed with the AAA-server 
> for some fo the cases.

Is a AAA-server separately deployed in this case and does the EAP server
contact the AAA server to authenticate the peer? 

I guess we can say that a protocol may be needed when the NAS is not in
pass through mode? 

> use case 
> > perspective, I feel that such a protocol would find very 
> limited use.
> 
> I agree with you. But I wouldn't discount it either.  My 
> approach is to allow for that -- and certainly it is allowed 
> and then solve the problem when someone can actually 
> demonstrate a need. Or let them solve the problem ;-)
> 

I like the latter :)

---

From: "Avi Lior" <[email-masked]>
Date: Mon, 13 Mar 2006 09:04:28 -0500

Hi  Jari,

You know what?  I read: " I do not think we need a protocol
definition...." as
" I do think we need...."  -- big difference ;-)

So therefore listed all the other APIs.

So I agree with you.  There is an API or there isnt? Its not IETF's
domain.

Sorry for the confusion it was very early in the morning.

Avi 

> Sent: Monday, March 13, 2006 3:30 AM
> To: Avi Lior
> Cc: [email-masked]
> >>I do not think we need a protocol definition between the 
> AAA and EAP 
> >>layers; this is mostly an API in any case.
> >>    
> >>
> >
> >What about the API to fetch the MSK? Or to Push the MSK?
> >What about the API to send the EAP message from the AAA to 
> the EAP AS?
> >What about the API to retrieve the EAP message from the EAP-AS?
> >Etc....why are we forgetting these as well?
> >  
> >
> I am not saying that they are not needed. The question is 
> whether the IETF wants to get into the business of 
> standardizing such APIs. We mostly deal with what happens on 
> the wire, in protocols.
> 
> --Jari
> 
>

---

From: "Avi Lior" <[email-masked]>
Date: Tue, 14 Mar 2006 14:31:17 -0500

Hi Rafa,

In the example below neither elements E1 E2 E3 had to be an EAP Peer. 

One real case for this is Proxy Mobile IP. The AMSK or the keys derived
from the AMSK go to the Proxy Mobile IP client which is not the EAP
Peer.

If you need more explanation on PMIP let me know.

> From: Rafa Marin Lopez [mailto:[email-masked]] 
> Sent: Monday, March 13, 2006 4:39 PM
> To: Avi Lior
> Cc: Jari Arkko; [email-masked]
> please see my comments inline
> 
> Avi Lior wrote:
> 
> >Hi Rafa,
> >
> >You raise a good point in the following: 
> >
> >  
> >
> >>I have seen during discussions and also under my understanding of 
> >>draft-aboba-eap-keying-extns-00.txt that either 1) AMSK would be 
> >>tranported from AAA server to some entity or 2) AMSK could 
> be used as 
> >>a root and cached by the AAA server to derive new keys 
> which would be 
> >>eventually transported to different entities.
> >>
> >>will that decision between both cases be specified for 
> application? or 
> >>would it be better to select one approach (it seems people 
> like second 
> >>one)?
> >>    
> >>
> >
> >I have recently seen the need for both models.  IMO keeping 
> the AMSK at 
> >the AAA and EAP Peer and only transporting derived keys to external 
> >entities makes a lot of sense but consider the following:
> >
> >Supposing I have an two entities E1 and E2 that received DE-KEY(s) 
> >derived from E-AMSK.  DE-KEY(s) are used to secure the communication 
> >between E1 and E2.
> >  
> >
> What entity is the EAP peer? At least one of the entities 
> should be the EAP peer no?.
> 
> or are you calling "entity" to EAP lower layer in the EAP peer??
> 
> >Now E2 wants to delegate responsibility of communicate with E1 to E3 
> >which it trusts.  E2 can pass the DE-KEY(s) to E3 but it would be 
> >better to derive another set of keys for that communication.
> >  
> >
> Yes, I would prefer to see E2 derives keys for the 
> communication between
> E1 and E3
> 
> >As I understand it, E2 and E1 cannot derive DE-KEY'(s) from 
> DE-KEY(s) 
> >-- since DE-KEY(s) are used for one purpose already and 
> using them for 
> >another purpose (key derivation) will make them weak.
> >
> I am not sure about this. Why will it make them weak? I mean 
> it looks like the definition of key hierarchy. It the key 
> hierarchy and role of participating entities are well 
> defined...  why is it weaker?
> 
> > So in this case
> >the only way to achieve this tranasaction is to involve AAA again.  
> >This could be very expensive.
> >
> >Another approach is to send E1 and E2 E-AMSK so that they 
> can generate 
> >subsequent keys to deal with this scenario.  Of course you 
> could also 
> >send E1 and E2 DE-KEY(S) to secure their communication and 
> also another 
> >key derived from E-AMSK for the purpose of generating new 
> keys.  But is 
> >that necessary?
> >
> 
> >Why couldn't we just distribute E-AMSK.
> >
> between E1 and E2...?I am not really sure if i get your example :(. 
> Could you provide a real scenario where this is happening?
> 
> 
> P.D: I think distributing AMSK is a possible alternative. 
> However if in a future access, another AMSK is needed, AAA 
> server should "request" 
> another AMSK (derived from EMSK) to the EAP server. On the 
> other hand, if AAA server already has a cached AMSK to 
> generate more keys, use of EMSK is not needed (which might be 
> an advantage if eventually it is decided EMSK needs to be 
> removed). In the end, I think application should define its 
> own key hierarchy from AMSK. In this way, an application 
> could want to tranport AMSK derived from EMSK to 
> authenticator and another ones may want to use that AMSK to 
> create another keys to be sent to authenticators.
> 
> --
> ------------------------------------------------------
> Rafael Marin Lopez
> Faculty of Computer Science-University of Murcia
> 30071 Murcia - Spain
> Telf: +34968367645    e-mail: [email-masked]
> ------------------------------------------------------
> 
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 14 Mar 2006 17:39:18 -0800

I would agree with Joe here that the actual text (to the extent we have
been discussing this) belongs in an EMSK specific document. However,
there are places in the EAP keying document that state "MUST NOT cache
keying materials..." - I wonder if those can be changed in accordance
with the consensus we have on the topic. 

Also, what would be the home going forward for the EAP keying extensions
work? 

Thanks,
Vidya 

> Sent: Tuesday, March 14, 2006 2:36 PM
> To: Jari Arkko; [email-masked]
> I can work on some specific proposed text for this, however 
> it is not clear to me if this belongs in the current EAP 
> keying document or an EMSK specific document.  I'm not sure 
> we resolved this.  I think it probably belongs in its own 
> document discussing EMSK guidelines and usage.
> 
> Joe  
> 
> > Sent: Tuesday, March 14, 2006 3:12 AM
> > To: [email-masked]
> > It seems that we have converged on this issue. Is there anyone who 
> > would like to suggest specific text changes?
> > 
> >