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

[Jari Arkko (jari.arkko]

Bernard Aboba wrote:

> Under Joe's proposal, an AMSK created during the original exchange can 
> be cached in the AAA server.  One way that "Key Request" could work 
> would be for the EAP peer to request that a key be sent to the new 
> authenticator.  It would make this request by contacting the new 
> authenticator, which would generate a AAA request. The EAP peer would 
> mutually authenticate to the AAA server, demonstrate possession of the 
> cached AMSK, and then request that a key derived from that AMSK be 
> sent to the new EAP authenticator.   Via the AAA request the new EAP 
> authenticator would mutually authenticate to the AAA Server.
>
> So we have:
>
> a. Authentication of parties:  EAP peer- AAA server;  EAP 
> authenticator - EAP server;  EAP peer-authenticator (through a 
> subsequent SAP exchange)
>
> b. Freshness.  Presumably the EAP peer - AAA server exchange includes 
> nonces exchanged by both parties to ensure freshness of the derived 
> keys.  Also the SAP exchange would include a nonce exchange.
>
> c. "Channel binding":  The EAP peer requests that a key be sent via 
> the entity that it wants the key sent to.  The new authenticator 
> identifies itself to the AAA server, allowing the EAP peer and AAA 
> server to verify that it is telling the same information to both the 
> AAA server and EAP peer.

I like this. What do we need to make this possible in the keying
framework?

- Say EMSK is kept in method layer

- Possibly say that EMSK can be deleted after AAA has made
 its declaration of what application keys its going to need
 (assuming we always know what applications are authorized
 a priori - but I think that's a good assumption).

- Clarify the caching and parent death rules for AMSks.

--Jari