RE: sending keys to authenticator? (EMSK or man-in-the-middle not needed for fast handoff)
From: Bernard Aboba (Bernard_Abobahotmail.com)
Date: Mon, 16 Jan 2006 18:56:34 -0800 (PST)
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:kapil.sood [at] intel.com] 
Sent: Saturday, January 14, 2006 9:43 AM
To: Nakhjiri Madjid-MNAKHJI1; Renwei Li; Jari Arkko; Bernard Aboba
Cc: eap [at] frascone.com; aboba [at] internaut.com
Subject: RE: [eap] sending keys to authenticator?: 

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.

Results generated by Tiger Technologies using MHonArc.