Strawman -10/EMSK deletion requirement?

Hi Jari,

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

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkkopiuha.net] 
> Sent: Monday, March 06, 2006 2:05 PM
> To: Avi Lior
> Cc: eapfrascone.com
> 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

Avi Lior wrote:

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

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

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

>>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.
>  
>
Ok. Hmm... it seems that I misread your original comment.
Sorry.
But it seems that we agree on this.

--Jari

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

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