Re: Strawman -10/EMSK deletion requirement?
From: Yoshihiro Ohba (yohbatari.toshiba.com)
Date: Tue, 14 Mar 2006 06:58:57 -0800 (PST)
Hi Avi,

On Fri, Mar 10, 2006 at 11:50:41AM -0500, Avi Lior wrote:

(snip)
> 
> 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.

Actually this scenario is covered by Section 4.2. (Transferring CBMK)
of draft-ohba-eap-channel-binding-00.txt.

Yoshihiro Ohba

> 
> 
> > -----Original Message-----
> > From: Rafa Marin Lopez [mailto:rafa [at] dif.um.es] 
> > Sent: Friday, March 10, 2006 11:15 AM
> > To: Jari Arkko
> > Cc: Avi Lior; eap [at] frascone.com
> > Subject: Re: [eap] Strawman -10/EMSK deletion requirement?
> > 
> > Hi Jari
> > 
> > >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?
> > >  
> > >
> > I agree on you this. In my mind the AAA server (where EAP 
> > server might be co-located) is (or should be) intelligent 
> > enough to manage keys from users.
> > 
> > >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.
> > >  
> > >
> > So far, between EAP methods and AAA transpor layers (AAA 
> > server?? ) we have EAP authenticator layer and EAP layer. An 
> > as specified draft-ietf-eap-keying-10.txt both layers cannot 
> > cache anything. I think it does not preclude the use of EMSK 
> > but it establishes limits to the creation of AMSK. That is, 
> > the AMSK should be created just in the moment the EMSK is 
> > exported. If EMSK wants to be cached, that part of text 
> > should be relaxed, no?
> > 
> > >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.
> > >  
> > >
> > 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)?
> > 
> > Regards.
> > 
> > --
> > ------------------------------------------------------
> > Rafael Marin Lopez
> > Faculty of Computer Science-University of Murcia
> > 30071 Murcia - Spain
> > Telf: +34968367645    e-mail: rafa [at] dif.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
> 
> 

Results generated by Tiger Technologies using MHonArc.