Strawman -10/EMSK deletion requirement?

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.

> -----Original Message-----
> From: Rafa Marin Lopez [mailto:rafadif.um.es] 
> Sent: Monday, March 13, 2006 4:39 PM
> To: Avi Lior
> Cc: Jari Arkko; eapfrascone.com
> Subject: Re: [eap] Strawman -10/EMSK deletion
requirement?
> 
> Hi Avi,
> 
> 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: rafadif.um.es
> ------------------------------------------------------
> 
> 
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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