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

From: "Avi Lior" <[email-masked]>
Date: Mon, 6 Mar 2006 15:01:31 -0500

Hi Jari,

These are similar to Joe's questions to I will just answer here.  Please
see inline. 

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, March 06, 2006 2:05 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: [eap] Strawman -10/EMSK deletion requirement?
> 
> Avi,
> 
> I understand that you feel strongly about the need to use the 
> EMSK on a per-need basis. But I have some questions for you :-)
> 
> 1. Ccan you explain what specific technical problem do you 
> encounter with the proposal that I outlined in my e-mail, 
> namely that you generate the AMSKs that you need, and that 
> those AMSKs can be kept around and used for further 
> generation of keys when the application in question needs 
> more than one?

The AMSKs we be application specific right? For example, one application
key for MIP keys, another for access to some other application like
single sign-on to our corporate server etc...

I don't have an issue with the AMSK's.

> 
> Is it just the need to do unnecessary work for keys that may 
> not be needed for this session? Or is there some functional 
> difference?

It is basically this, how do I know which ones to generate during
network access authentication?  I could have lots of them.  Also perhaps
during this session the user requested access to a new application.  I
need a key now.  Should I tear down the session just so I can get a new
EMSK?

> 2. Do you have a plan how to manage the cache at the AAA 
> server side, if there is no agreement a priori that EMSKs and 
> specific AMSKs are going to be needed?

EMSK should be bound to a user session. When the user session goes away
so should the EMSK.  If the user session is reauthenticated so should
the EMSK.

> 3. Also, you wrote:
> 
> >I do agree that EMSK MUST ONLY BE USED for key derivation (AMSKs) and
> >  
> >
> What specific purpose did you have in mind for the EMSK? Do 
> you plan to use the entire EMSK for some specific application 
> you had in mind? What if other applications want to use it too?

EMSK MUST only be used for generating AMSKs.  I would think that using
EMSK for other purpsoses will weakent the EMSK and hence weaken the
AMSKs etc... So this is a very bad thing to do.

> 
> 4. And you wrote
> 
> >MUST NOT be transported out of the EAP Authentication Server layer.
> >
> Ok. This is the issue that I wrote another e-mail about (the 
> one with choices 1a, 1b, 2a, and 2b) -- can you comment on 
> that e-mail what you want along with the rationale for your choice?

I will go back to that email and comment.

> Thanks,
> --Jari
_________________________________________________________________
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: Mon, 06 Mar 2006 22:45:29 +0200

>I don't have an issue with the AMSK's.
Right. Ok.

>need a key now.  Should I tear down the session just so I can get a new
The latter should never happen. If we do the calculation of AMSKs a priori,
then it needs to be something enabled by the user's profile. If he is
authorized to day (say) access handoff, mobile IP, and some QoS exchange,
then we'd generate three AMSKs for that user.

>so should the EMSK.  If the user session is reauthenticated so should
Ok. This sounds reasonable. There may be still tradeoffs
between keeping one EMSK for all sessions vs. keeping bunch of
AMSKs for those sessions that have been authorized to do
more than pure access. But its hard for me to quantify this
tradeoff, given that we don't know how many applications we could
in practice be talking about, and in particular we don't know what
fraction of users would be authorized to use those applications. Just
some, or would this be something that is by default turned on for
everyone?

>AMSKs etc... So this is a very bad thing to do.
Ok. Hmm... it seems that I misread your original comment. Sorry.
But it seems that we agree on this.

--Jari