eap Mailing List: RE: sending keys to authenticator?: was: Issue: AAA Key Caching effectively prohibited?

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

Question: Does EAP keying allow sending keys to an entity other than the
initial authenticator, e.g. another AAA client or a key holder? 
Or Does the EAP keying framework that prohibits keys being sent to an
entity other than the initial authenticator?


Thanks,

Madjid

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
Sent: Saturday, November 05, 2005 6:34 PM
To: Bernard Aboba
Cc: Nakhjiri Madjid-MNAKHJI1; aboba [at] internaut.com; eap [at] frascone.com
Subject: Re: [eap] RE: Issue: AAA Key Caching effectively prohibited?

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