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

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

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:renwei [at] anqsystems.com] 
Sent: Wednesday, January 11, 2006 7:00 PM
To: Nakhjiri Madjid-MNAKHJI1; Jari Arkko; Bernard Aboba
Cc: eap [at] frascone.com; aboba [at] internaut.com
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


>-----Original Message-----
>From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri [at] motorola.com]
>Sent: Wednesday, January 11, 2006 07:13 PM
>To: 'Jari Arkko', 'Bernard Aboba'
>Cc: eap [at] frascone.com, aboba [at] internaut.com
>Subject: RE: [eap] sending keys to authenticator?: was: Issue: AAA Key
Caching effectively prohibited?
>
>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
>
>
>_________________________________________________________________
>To unsubscribe or modify your subscription options, please visit:
>http://lists.frascone.com/mailman/listinfo/eap
>
>Arhives: http://lists.frascone.com/pipermail/eap
>