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

From: "Sood, Kapil" <[email-masked]>
Date: Sat, 14 Jan 2006 09:43:27 -0800

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:[email-masked]]
> Sent: Thursday, January 12, 2006 5:11 PM
> To: Renwei Li; Jari Arkko; Bernard Aboba
> Cc: [email-masked]; [email-masked]
> 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:[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
> 
> 
> >-----Original Message-----
> >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?
> >
> >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
> >
> 
> 
> _________________________________________________________________
> 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

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 16 Jan 2006 18:56:32 -0800

IEEE 802.11r D1.0 (which has just passed its first letter ballot) is
available for inspection here:
http://grouper.ieee.org/groups/802/11/private/Draft_Standards/11r/P802.11r-D
1.0.pdf

If you'd like the archive password, please contact the chairs.   

As Kapil notes, 802.11r relies only on the MSK, and is based on existing EAP
and AAA RFCs, including RFC 3579, 3580, 3748 and 4072.

The 802.11r specification addresses a number of issues that came up in
802.11i and also are discussed in the EAP Key Management Framework document,
including: 

1. Key lifetime synchronization.  802.11r includes the key lifetime in the
4-way handshake, so that all parties can be aware of when the key hierarchy
expires. 

2. Key scope definition.  802.11r includes advertisement of the
NAS-Identifier (known as the R1KH-ID). 

-----Original Message-----
From: Sood, Kapil [mailto:[email-masked]] 
Sent: Saturday, January 14, 2006 9:43 AM
To: Nakhjiri Madjid-MNAKHJI1; Renwei Li; Jari Arkko; Bernard Aboba
Cc: [email-masked]; [email-masked]
Subject: RE: [eap] sending keys to authenticator?: 

Best Regards,
 
Kapil.

---

From: Clint Chaplin <[email-masked]>
Date: Tue, 17 Jan 2006 16:19:07 -0800

All:

Please do not contact me expecting the IEEE 802.11 private area
password; I am not authorized to hand that out.

The IEEE private area is open only to voters or nearly voters of IEEE
802.11, as per IEEE 802.11 policies and procedures.  Sorry.

--
Clint (JOATMON) Chaplin
Wireless Security Technologist
Wireless Standards Manager
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap