Strawman -10/EMSK deletion requirement?

Jari,
 
See inline.

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

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
> 
> 
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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

Avi Lior wrote:

>>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)?
>  
>

I do not think we need a protocol definition between the AAA
and EAP layers;
this is mostly an API in any case.

However, I do believe that if some device (e.g. a NAS, DHCP
server, ...)
is going
to need an AMSK, then its very unlikely that such a device
is in the
same box
as the AAA and EAP servers. This implies that we do need a
protocol
extension
from a AAA client to the AAA server to retrieve AMSKs. This
isn't a task
that we commit to taking in the EAP keying framework or EAP
WG. Go
talk to the RADEXT or DIME groups instead.

--Jari


____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap

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