eap Mailing List: RE: Strawman -10/EMSK deletion requirement?

[Narayanan, Vidya (vidyan]

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 

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
> Sent: Friday, March 10, 2006 12:34 AM
> To: Avi Lior
> Cc: Salowey, Joe; Narayanan, Vidya; eap [at] frascone.com
> Subject: Re: [eap] Strawman -10/EMSK deletion requirement?
> 
> Avi Lior wrote:
> 
> >>[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).
> >>    
> >>
> >
> >[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
> 
>