eap Mailing List: Re: Issue: AAA Key Caching effectively prohibited?

[Jari Arkko (jari.arkko]

Bernard Aboba wrote:

> My own reservations with AAA server caching derive from the issues 
> surrounding "on demand" key creation:
>
> a. Presumably keys are created "on demand" only when requested by either 
> the EAP peer or authenticator.  This implies that the EAP peer or 
> authenticator keep track of which AAA server is caching which keys, so 
> that they can direct subsequent requests to a server capable of answering 
> them. 
>
> b. However, all EAP methods do not provide the Server-ID, which uniquely 
> identifies the EAP server which has produced a given key.  Also, an EAP 
> authenticator/AAA client may not necessarily control which AAA server it 
> is talking to; it just sends an Access-Request with an NAI in the 
> User-Name attribute and it is routed to a destination.  The Access-Accept 
> may not identify the originating AAA server well enough to allow the AAA 
> client to go back to that same AAA server again to request an "on demand" 
> key from it.  Given this, it is not clear to me how a "Key Request" mode 
> could be made to work with all EAP methods or AAA configurations. 
>  
These issues seem largely orthogonal to the question of
whether the caching applies to the EMSK, AMSK, or f(AMSK).

Having said that, I'm not sure its our task (in the keying
framework) to design key-req architecture. All we need
to do is to describe the current key usage (msk etc) and
provide a "handle" such as the emsk/amsk for potential
new designs, along with some basic rules for their usage.
The question in this thread has been whether preventing
emsk delivery to AAA or requiring deletion of keys sent
over AAA prohibits some useful designs. From what I can
see, the answer is "no" -- as has been demonstrated,
appropriate design of the key hierarchy appears to
make such designs possible even under these assumptions.
However, there might be additional issues not brought
up in the keying framework requirements that such designs
need to take into account - such as ability to locate the
right AAA server. That is no fault of the keying framework,
and hence does not need to be discussed in it. Very
important for extensions, though.

--Jari