January 2006 doc IEEE 802 11 -06 0042

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Key Holder Protocol Options Date: 2006 -01 -17 Authors: Notice: This document has been prepared to assist IEEE 802. 11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802. 11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures , including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard. " Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802. 11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at . Submission 1 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Abstract This presentation summarizes several alternatives for a key holder protocol to be used by TGr-capable WLANs. The key holder protocol enables a secure mechanism to transfer a PMK-R 1 key from the R 0 KH to the R 1 KH for which the PMK-R 1 key was derived. Submission 2 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Design Team Members Bernard Aboba Microsoft Redmond, WA Nancy Cam Winget Cisco Systems 3625 Cisco Way, San Jose CA 95134 Clint Chaplin Symbol Technologies 6480 Via Del Oro, San Jose, CA 95119 408 -528 -2766 Frank Ciotti Motorola Corporation Austin, TX 512 -996 -5753 Frank. Ciotti@motorola. com Michael Montemurro Chantry Networks 1900 Minnesota Cr, Suite 125. Mississauga, ON 905 -363 -6413 michael. montemurro@siemens. com Russ Housley Vigil. Sec 918 Spring Knoll Drive Herndon, VA 20170 703 -435 -1775 housley@vigilsec. com Mani Mahalingam Avaya 1033 Mc. Carthy. M/S 1 -1 C Milpitas CA 95035 408 -321 -4840 mani@avaya. com Henry Ptasinski Broadcom Corporation 190 Mathilda Place Sunnyvale, CA 94086 Kapil Sood Intel Corporation 2111 NE 25 th Ave, Hillsboro OR 97124 503 -264 -3759 Kapil. Sood@intel. com Dorothy Stanley Aruba Networks Warrenville, Il 630 -363 -1389 dstanley@arubanetworks. com Jesse Walker Intel Corporation 2111 NE 25 th Ave, Hillsboro OR 97124 503 -712 -1849 Jesse. Walker@intel. com Meiyuan Zhao Intel Corporation 2111 NE 25 th Ave, Hillsboro OR 97124 503 -712 -4990 Meiyuan. Zhao@intel. com Submission aboba@internaut. com 3 408 -853 -0532 408 -543 -3316 ncamwing@cisco. com Clint. Chaplin@gmail. com henryp@broadcom. com All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Protocol Options Considered for Registration and KEK Distribution → Kerberos Protocol – With PKINIT for certificate credentials; shared secret and certificate auth supported – Can provide PMK-R 1 transport – Need extensions for SHA-256, AES-CCM • EAP – R 0 KH and R 1 KH as Authenticator and Supplicant – Need custom/re-used protocol for EAP over IP transport – Need protocol for PMK-R 1 delivery • IKEv 2 for Registration, Custom Protocol for KEK Distribution – IKEv 2 can support non-IPSec client protocol: There are 3 protocols that IKEv 2 can support – IKE, AH, ESP, with ability to define additional non-IPSEC client protocols – No advantage over Kerberos, since Kerberos PKINIT has a DH forward secrecy option, with no custom protocol needed • IKEv 2 for Registration, Kerberos for KEK Distribution – No advantage over just using Kerberos, since Kerberos PKINIT has a DH forward secrecy option • Custom protocol for registration and KEK Distribution – No advantage over the first three options Submission 4 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Protocol Selection Criteria • Meets Market needs – Enterprise, Service Provider; Home and SOHO PSK • • Meets security goals Deployable with low cost of ownership Re-use existing protocols No/minimal IPR claims No new protocol development Meets performance goals Meets Federal market needs (FIPS-140 -2 compliant) Usable for future applications Submission 5 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Custom IKEv 2/Kerberos IKEv 2/Custom EAP Kerberos Pugh Matrix for MDC Protocol Selection weight Meets Market Needs 5 ? ? Meets security goals 5 1 1 Deployable with low cost of ownership 4 1 1 Re-use existing protocols 3 1 1 No New Protocol Development 3 1 0 No/minimal IPR Claims 3 1 1 Meets performance goals 3 ? ? Meets Federal Market needs/FIPS 140 -2 5 1 Usable for additional application 2 ? ? ? 1 0 TOTAL Submission 6 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Keys that are used MDC AAA Server KDC R 0 KH – MDC/AAA Server/KDC – Long lived authentication credential R 0 KH – MDC/AAA Server/KDC – Session Master Key EAP Registration KEK Distribution R 0 KHj – R 1 KHk KEKjk R 0 KH-ID R 1 KH-ID Submission R 1 Key 7 R 1 KH-ID R 1 Key distribution All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Kerberos Based Solution – Recommend Continuing work on this option MDC KDC TGS Identity and Shared Secret Database AS_REQ TGS_REQ AS_RESP TGS_RESP AP_REQ KH 1 Submission KH 2 AP_RESP 8 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Kerberos Option Messages sk_X_Y is shared secret between parties X and Y Ticket_TGS = Encrypt(sk_TGS_KDC, sk_KH 1_TGS || Id_KH 1 || TTL) Authenticator_KH 1 = Encrypt (sk_KH 1_TGS, Id_KH 1 || TSClock_KH 1) Ticket_KH 2 = Encrypt(sk_KH 2_KDC, KEK || Id_KH 1 || TTL) Authenticator_KH 1 -2 = Encrypt (KEK, Id_KH 1 || TSClock_KH 1 -2 || sub-KEK-KH 2) AS_REQ: M 1 = Id_KH 1 || Id_TGS || TTL || Nonce-KH 1 AS_RESP: M 2 = Id_KH 1 || Ticket_TGS || Encrypt(sk_KH 1_KDC, sk_KH 1_TGS || TTL || Nonce-KH 1 || Id_TGS) TGS_REQ: M 3 = Id_KH 2 || TTL || Nonce-KH 1 -2 || Ticket_TGS || Authenticator_KH 1 TGS_RESP: M 4 = Id_KH 1 || Ticket_KH 2 || Encrypt(sk_KH 1_TGS, KEK || TTL || Nonce-KH 1 -2 || Id_KH 2) AP_REQ: M 5 = Ticket_KH 2, Authenticator_KH 1 -2 AP_RESP: M 6 = Encrypt (KEK, TSClock_KH 2 || Sub-KEK-KH 2) Encrypt() is an authentication + encryption algorithm Submission 9 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Kerberos Scheme as Applies to MDC • “Realm” options can allow authorizing keys across administrative domains (within same MD) • Security Considerations: – Authenticating Identities of KH 1 and KH 2 – Shared secret key mechanism • Can be extended for Public key – Open to Do. S attacks – Brute force/Dictionary attacks by adversary to get ciphertext, and break password/shared secret – All clocks must be loosely synchronized Submission 10 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Kerberos Option • Good existing protocol match to the application • Need Extensions to RFC 3962 to support SHA-256 and AES-CCM • PKINIT provides a Diffie-Hellman option forward secrecy • NIST allows Kerberos Submission 11 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Ongoing Work • More detail on provisioning and configuration data – Mobility domain, List of authorized keyholders and their addresses, indication for each R 0, R 1 keyholder of which role it can assume • How do key holders find each others addresses? – Info delivered from AAA or KDC • Develop Kerberos based protocol – Individual submission in IETF – Target July 06 Solid draft, Dec 06/early 07 approved RFC Submission 12 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 EAP - R 0 KH and R 1 KH as Authenticator and Supplicant • Configure Authenticators with RADIUS credentials • Configure AAA Server with Authenticator credentials • Push model: R 0 KH send EAP Identity Request to R 1 KH • Pull model: R 1 KH sends EAP Identity Request to R 0 KH Re-uses existing AAA infrastructure • Re-use RADIUS interface from Authenticator to AAA server AAA Server • Potential New Authorization attributes needed; Define new Authorization parameters – e. g. is the R 1 KH authorized to receive keys for this R 0? For this mobility domain? • Need to identify the layer 3 transport – UDP or TCP Supplicant Authenticator EAP Method R 0 KH-ID R 1 KH-ID KEK TSTA Submission 13 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 EAP Option • Re-uses existing AAA server • Definition of new attributes needed • Use existing RADIUS key delivery mechanism and its evolution • Specify transport of EAP – over TCP- Radius, Diameter, custom? • Broad selection of auth credentials Submission 14 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Custom Protocol Description Submission 15 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Terminology and Usage Models • MDC = Mobility Domain Controller • KH = Key Holder • Each KH uses one of the Registration Protocols to establish a session with between itself and MDC – Two registration protocols are defined • A KH uses the Key Distribution Protocol to obtain a Key Encryption Key between itself and a second KH • The two KH’s use the Key Encryption Key to securely move an R 1 -PMK from one to the other Submission 16 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Registration Security Goals 1. 2. 3. 4. 5. Unique Session Identity – The MDC and KH can distinguish this instance of the protocol from all other instance of the protocol and from all instances of any other protocol. Mutual Authentication – The MDC and KH are authenticated to each other in this protocol instance. Key Exclusivity -- The session key is known only to the MDC and KH. Key Integrity -- the session key is computed only from inputs contributed by the MDC and KH Key Confirmation – The MDC and KH both have assurance that the peer for this protocol instance knows the session key and is willing to use it for communication with the local entity. Submission 17 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Registration with a Shared Secret M 1 MDC M 2 KH M 3 M 1 = Nonce_KH || Id_KH || Cipher. Suite. List Hash_MDC PRF(secret, 0 || Nonce_KH || Id_KH || Nonce_MDC || Id_MDC || Cipher. Suite. List || Cipher. Suite || TTL || Key. Dist. Counter) M 2 = Nonce_KH || ID_KH || Nonce_MDC || Id_MDC || Cipher. Suite. List || Cipher. Suite || TTL || Key. Dist. Counter || Hash_MDC M 3 = Nonce_KH || ID_KH || Nonce_MDC || Id_MDC || TTL || Hash_KH PRF(secret, 1 || Nonce_KH || Id_KH || Nonce_MDC || Id_MDC || Cipher. Suite || TTL) SK PRF(secret, 2 || Nonce_KH || Id_KH || Nonce_MDC || Id_MDC || Cipher. Suite. List || Cipher. Suite || TTL) Sid hash(Nonce_KH || Id_KH || Nonce_MDC || Id_MDC || Cipher. Suite. List || Cipher. Suite || TTL) Submission 18 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Registration with a shared secret • • If Nonce_KH and Nonce_MDC are selected randomly from a sufficiently large space, then the session id Sid construction provides a (statistically) unique identifier for this instance (Security Goal 1) Message 2 authenticates MDC to KH, and Message 3 authenticates KH to MDC (Security Goal 2) – The binding of parameters into Hash_MDC and Hash_KH defends against MITM attacks if secret is known only to MDC and KH – The unique message format of each message protects against reflection attacks – Hash_MDC and Hash_KH defend messages 2 and 3 against forgery if secret is known only to MDC and KH • • • If secret is known only to MDC and KH, then the key derivation and mutual authentication mean the session key SK is known only to these two parties (Security Goal 3) If secret is known only to MDC and KH, then, since all of the parameters are authenticated and created by MDC and KH, the session key SK is derived using inputs only from MDC and KH (Security Goal 4) If Nonce_KH is unpredictable and secret known only to MDC and KH, then message 2 shows that MDC is live; if Nonce_MCD is unpredicatable as well, then message 3 shows KH is live (Security Goal 5) Submission 19 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Registration with a shared secret • Message 1 is unprotected, but this is the nature of things • Including the nonces in the derivation of the Session Key SK results in a fresh key but increases the complexity of the protocol – KH must insert Nonce_KH into message 3 to permit MDC to recover from flooding attacks • This protocol assumes that the KH initiates all its instances – The Key Distribution protocol between KH and KH fails unless KH realizes when MDC reboots Submission 20 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Registration with a Public/Private Key Pair M 1 KH M 2 MDC M 3 M 1 = Nonce_KH || Cipher. Suite. List || gx M 2 = Nonce_KH || Cipher. Suite. List || Cipher. Suite || Nonce_MDC || gy || gx || TTL || Hash_MDC || Sig_MDC || Cert_MDC Hash_MDC PRF(hash(gxy), 0 || Nonce_KH || Cipher. Suite. List || Cipher. Suite || Nonce_MDC || gy || gx || TTL) Sign_MDC Sign(sk_MDC, Hash_MDC) M 3 = Nonce_KH || Cipher. Suite. List || Cipher. Suite || Nonce_MDC || gx || gy || TTL || Hash_KH || Sig_KH || Cert_KH Hash_KH PRF(hash(gxy), 1 || Nonce_KH || Cipher. Suite. List || Cipher. Suite || Nonce_MDC || gx || gy || TTL) Sign_KH Sign(sk_KH, Hash_KH) SK PRF(hash(gxy), 2 || Nonce_KH || Id_KH || Nonce_MDC || Id_MDC || Cipher. Suite. List || Cipher. Suite || TTL) Sid hash(Nonce_KH || Id_KH || Nonce_MDC || Id_MDC || Cipher. Suite. List || Cipher. Suite || TTL) Submission 21 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Registration with a public/private key pair • • If Nonce_KH and Nonce_MDC are selected randomly from a sufficiently large space, then the session id Sid construction provides a (statistically) unique identifier for this instance (Security Goal 1) Message 4 authenticates MDC to KH, and Message 3 authenticates KH to MDC (Security Goal 2) – – • • • The binding of parameters into Sig_KH defends against MITM attacks if KH’s signing key sk_KH is known only to KH The binding of parameters into Hash_MDC defends against MITM attacks if secret is known only to MDC and KH The unique message format of each message protects against reflection attacks Sig_KH and Hash_MDC defend messages 3 and 4 against forgery If MDC’s encryption key is known only to MDC and KH’s random number generator is unpredictable, then the key derivation and mutual authentication imply the session key SK is known only to MDC and KH (Security Goal 3) If Nonce_KH and Nonce_MDC are selected randomly from a sufficiently large space, , then, since all of the parameters are authenticated and created by MDC and KH, the session key SK is derived using inputs only from MDC and KH (Security Goal 4) If Nonce_KH is unpredictable, then message 3 shows that MDC is live; if Nonce_MCD is unpredicatable as well, then message 4 shows KH is live (Security Goal 5) Submission 22 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Registration with a public/private key pair • Message 1 is unprotected, but this is the nature of things • Message 2 reduces the threat of denial-of-service attacks based on flooding • This protocol assumes that the KH initiates all its instances – The Key Distribution protocol between KH and KH fails unless KH realizes when MDC reboots Submission 23 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Key Distribution Security Goals 1. 2. 3. 4. 5. 6. 7. Session Key Existence – A fresh (i. e. , a never-before-used) session key between KH 1 and KH 2 should result Session Key Uniqueness – KH 1 and KH 2 should derive the same session key Session Identity Uniqueness – KH 1 and KH 2 can distinguish this instance of the protocol from all other instance of the protocol and from all instances of any other protocol. Mutual Authentication – The KH 1 and KH 2 are authenticated to each other in this protocol instance. Key Exclusivity -- The session key is known only to the KH 1 and KH 2 (and perhaps MDC). Key Integrity -- the session key is computed only from inputs contributed by the KH 1, KH 2, and MDC Key Confirmation – KH 1 and KH 2 both have assurance that the peer for this protocol instance knows the session key and is willing to use it for communication with the local entity. Submission 24 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Key Distribution MDC M 1 M 2 KH 1 M 3 KH 2 M 4 M 5 Submission 25 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Key Distribution M 1 = Id_KH 1 || Sid_KH 1 || Nonce 1 || Id_KH 2 M 2 = Sid_KH 1 || Ticket_KH 1 Encrypt(sk_KH 1, K || Sid_KH 2 || Ticket_KH 2 || Id_KH 1 || Id_KH 2 || Nonce 1 || Cipher. Suite || TTL || Id_MDC) M 3 = Sid_KH 2 || Ticket_KH 2 || Auth_A Ticket_KH 2 Encrypt(sk_KHs, K || Id_KH 1 || Id_KH 2 || Counter || Cipher. Suite || TTL || Id_MDC || Key. Dist. Counter) Auth_A Encrypt(KCK, Nonce_A || Id_KH 1 || Id_KH 2 M 4 = Auth_B Encrypt(KCK, Nonce_A+1 || Nonce_B || Id_KH 1 || Id_KH 2) M 5 = Auth_C Encrypt(KCK, Nonce_B+1 || Id_KH 2) KCK PRF(K, 0 || Id_KH 1 || Id_KH 2 || Nonce 1 || Nonce 2 || Cipher. Suite || TTL) KEK PRF(K, 1 || Id_KH 2 || Nonce_A || Nonce_B || Cipher. Suite || TTL) KTKid hash(Id_KH 1 || Id_KH 2 || Nonce_A || Nonce_B || Cipher. Suite || TTL) Submission 26 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Key Distribution • • If KH 1 generates Nonce_A randomly, then KH 1 knows KEK is fresh; if KH 2 enforces monotonicity of Key. Dist. Counter, then it knows KEK is fresh (Security Goal 1) If KH 1 commits to its identity Id_KH 1, then, because sk_KH 1 is known only to KH 1, it is the only party (besides MDC) that can unwrap Ticket 1. Similarly KH 2 is the only party that can unwrap Ticket 2. Both include the same key K, which is used to derive the common KEK (Security Goal 2) Nonce 1 allow KH 1 to distinguish this instance from all others. Key. Dist. Counter allows KH 2 to distinguish this instance from all others. Nonce_A and Nonce_B allows this instance of messages 4 -5 to be distinguished from all others (Security Goal 3) Message 4 authenticates KH 2 to KH 1, and message 5 authenticates KH 1 to KH 2 (Security Goal 4) If MDC does not reveal K, sk_KH 1, sk_KH 2 to any other parties, and if MDC “forgets” K after sending message 2, then the session key KTK is known only to KH 1 and KH 2 (Security Goal 5) KEK is computed only from inputs from KH 1, KH 2, and MDC (Security Goal 6) If authenticated encryption is used, – – inclusion of Nonce 1 in Ticket_KH 1 demonstrates to KH 1 that MDC is live, inclusion of Key. Dist. Counter in Ticket_KH 2 demonstrates to KH 2 that MDC is live, Inclusion of Nonce_A+1 in Auth_B demonstrates to KH 1 that KH 2 is live Inclusion of Nonce_B+1 in Auth_C demonstrates to KH 2 that KH 1 is live (Security Goal 7) Submission 27 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 Key Distribution • The opening round trip is not standard, but it allows KH 2 to verify the freshness of Ticket_KH 2 without resorting to fancy tricks • The opening round trip allows for allows easy authenticated recovery from error conditions – This assumes that KH 1 does not initiate unless it has registered first – But this does not address a reboot of the MDC • KH 2 can construct Nonce_2 so that it does not have to maintain state – E. g. , it can encrypt a local monotonic counter using a session • MDC must maintain state for each “active” KH – State could be avoided by adding a “cookie” consisting of the encrypted session key to the registration protocols, and inserting the cookies into messages M 2 and M 3 – The MDC could decrypt the cookies if it had crashed – E. g. , each cookie could have the structure Encrypt(K_MDC, SK || Sid || ID_KH || TTL || Timestamp), where K is known only to MDC Submission 28 All

January, 2006 doc. : IEEE 802. 11 -06/0042 r 0 References • 05/1216 Submission 29 All