| RE: sending keys to authenticator? (EMSK or man-in-the-middle not needed for fast handoff) | <– Date –> <– Thread –> |
|
From: Bernard Aboba (Bernard_Aboba |
|
| 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.
-
RE: sending keys to authenticator?: was: Issue: AAA KeyCaching effectively prohibited? Sood, Kapil, January 14 2006
- RE: sending keys to authenticator? (EMSK or man-in-the-middle not needed for fast handoff) Bernard Aboba, January 16 2006
- Re: sending keys to authenticator? (EMSK or man-in-the-middle not needed for fast handoff) Clint Chaplin, January 17 2006
-
RE: sending keys to authenticator?: was: Issue: AAA KeyCaching effectively prohibited? Nakhjiri Madjid-MNAKHJI1, January 18 2006
-
Re: sending keys to authenticator?: was: Issue: AAA KeyCaching effectively prohibited? Clint Chaplin, January 19 2006
- RE: sending keys to authenticator?: was: Issue: AAA KeyCaching effectively prohibited? Bernard Aboba, January 20 2006
-
Re: sending keys to authenticator?: was: Issue: AAA KeyCaching effectively prohibited? Clint Chaplin, January 19 2006
Results generated by Tiger Technologies using MHonArc.