Strawman -10/EMSK deletion requirement?

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.arkkopiuha.net] 
> Sent: Friday, March 10, 2006 12:34 AM
> To: Avi Lior
> Cc: Salowey, Joe; Narayanan, Vidya; eapfrascone.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
> 
> 
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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