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

[Sood, Kapil (kapil.sood]

11r does not have a 'trusted' man-in-the-middle.  11r still bases its
security model on that the AAA Key (MSK) gets delivered to the
authorized Authenticator only.  This is the authenticator through which
the STA performed the full EAP authentication.  This is called R0 Key
holder (R0KH) in 11r draft.  R0KH derives the PMK-R0 from the MSK with
domain specific parameters binding.

R0KH also derives multiple PMK-R1 keys (11r key hierarchy) from the
PMK-R0, for distribution to other authenticators (called R1 key holders)
within the same administrative domain (called mobility domain in 11r).
A local trusted party (say, MDC - Mobility Domain Controller) helps
establish mutual authentication between these authenticators (key
holders in 11r) and derives mutual Key Encryption Keys (KEKs).  These
KEKs will be used for secure delivery of PMK-R1 keys from R0KH to R1KHs.
AAA server may not have any knowledge of this key hierarchy (by design),
and distribution.

Best Regards,
 
Kapil.
503.264.3759
> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri [at] motorola.com]
> Sent: Thursday, January 12, 2006 5:11 PM
> To: Renwei Li; Jari Arkko; Bernard Aboba
> Cc: eap [at] frascone.com; aboba [at] internaut.com
> Subject: RE: [eap] sending keys to authenticator?: was: Issue: AAA
KeyCaching effectively
> prohibited?
> 
> 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
> >
> 
> 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/eap
> 
> Arhives: http://lists.frascone.com/pipermail/eap