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

[Jari Arkko (jari.arkko]

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