Subject: RE: [eap] sending keys to authenticator?: was: Issue: AAA Key Caching effectively prohibited?

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 11 Jan 2006 19:13:20 -0500

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:[email-masked]] 
Sent: Saturday, November 05, 2005 6:34 PM
To: Bernard Aboba
Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]; [email-masked]
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

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

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

---

From: "Renwei Li" <[email-masked]>
Date: Thu, 12 Jan 2006 00:59:45 +0000

If we do so, we are effectively creating a scenario (Authenticated-)Man-in-the-Middle? Sounds familiar? 

Regards,

Renwei

>From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
>Sent: Wednesday, January 11, 2006 07:13 PM
>To: 'Jari Arkko', 'Bernard Aboba'
>Cc: [email-masked], [email-masked]
>Subject: RE: [eap] sending keys to authenticator?: was: Issue: AAA Key Caching	effectively prohibited?
>

---

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Thu, 12 Jan 2006 20:11:23 -0500

Not really sure what you mean by creating a scenario.  This is a real
life deployment. 11r has defined key holders. 
And what is wrong with trusted man in the middles?

-----Original Message-----
From: Renwei Li [mailto:[email-masked]] 
Sent: Wednesday, January 11, 2006 7:00 PM
To: Nakhjiri Madjid-MNAKHJI1; Jari Arkko; Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: Re: [eap] sending keys to authenticator?: was: Issue: AAA Key
Caching effectively prohibited?

If we do so, we are effectively creating a scenario
(Authenticated-)Man-in-the-Middle? Sounds familiar? 

Regards,

Renwei

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