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

[Avi Lior (avi]

Jari,
 
See inline.

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
> Sent: Friday, March 10, 2006 3: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?

That line is tough to define in RADIUS, is defined in Diameter.  And I
think it we don't need to enter the rat hole and formally define it.

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

Okay with me.

> So the conclusion is that the EMSK is kept somewhere between 
> the EAP method and AAA transport layers.

Yes.

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

Yes.

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

Understood.

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

If RADIUS is colocated with EAP-server do we need to define a protocol
for getting the AMSK(s)?
 
> --Jari
> 
>