doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 1 Secure Mesh Formation Notice: This document has been prepared to assist IEEE 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 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 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at. Date: Authors:

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 2 Abstract A new security protocol for s is proposed. It addresses secure mesh formation and mesh transport.

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 3 Problems with existing scheme Two complete 802.1x exchanges –Code bloat-- have to implement all supplicant state machines in addition to the authenticator state machine that all APs already have –Requires that both APs have access to an AS –Problematic mesh formation Too orderly: can only happen from mesh portal “out” Quasi-secure: requires one node to route packets to an AS through a node it does not yet trust. They’re data frames! Requires authentication and association first

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 4 Problems with existing scheme An external authentication server may not be reachable by an MP to authenticate another MP. So make MPs support not only authenticator and supplicant roles but also an authentication server role! –Replication of a large database –Code bloat-- in addition to 802.1x and client side EAP, need server side EAP, plus some EAP methods: PEAP, EAP-MSCHAPv2, TTLS, TLS, et cetera

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 5 Problems with Existing Scheme Pre-shared key mode is broken. This is not a problem with “weak” pre-shared keys. –PSK in i can be broken by anyone within earshot of the AP –PSK in a mesh allows the mesh to grow unbounded including both unauthorized MPs and unauthorized STAs. Deployment experience shows this is a big problem –PSKs are typically shared– i.e. not bound to specific supplicant MAC address. –Phrases over 20 characters are not really possible when humans are involved. Random strings are difficult to remember and prone to mis- configuration. PSK authentication also doesn’t provide Perfect Forward Secrecy –all traffic previously sent can be decrypted –all future traffic can be decrypted –bogus frames can be injected into current traffic

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 6 Protocol Requirements For Secure Mesh Formation MUST dynamically generate ephemeral session keys MUST NOT be susceptible to passive or active attack MUST provide some level of DoS resistance MAY provide implicit authorization since this is for base capabilities that all roles share. Any other role MAY require separate authorization.

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 7 A protocol named comminus Key exchange is based on SKEME –Designed by Hugo Krawczyk –Has been analysed. Outline is in Hugo’s paper “SKEME: A versatile Secure Key Exchange Mechanism for the Internet.” Diffie-Hellman based Equivalent modes of operation for pre-shared and certificate-based authentication Uses authentication frames Mutual authentication of equals, no notion of supplicant or authenticator, no need for an external authentication server.

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 8 Features of comminus Provides Perfect Forward Secrecy –The property that “disclosure of long term secret keying material does not compromise the secrecy of exchanged keys from earlier runs”-- Diffie, van Oorshot, and Wiener in Authentication and Authenticated Key Exchanges. Resistant to passive attack and denial of service attacks After authentication with comminus it is possible to protect all subsequent management frames using the resulting ephemeral session keys. Implicit authorization-- it’s for mesh formation. No PMK exposure issues, secret is known only by the two MPs.

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 9 A protocol named comminus Notation –a is Alice, the initiator –b is Bob, the responder –g x is a Diffie-Hellman public value for x (mod p is implied) –X | Y is the concatenation of X with Y –PRF(x,y) is a pseudo-random function taking arguments x (a key) and y (data) –{X}y is the encryption of X with y When y is a symmetric key it denotes AES-Keywrap When y is an asymmetric key it denotes public key encryption

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 10 A protocol named comminus Notation (continued) –Na is a pseudo-random number chosen by Alice –Nb is a pseudo-random number chosen by Bob –K is a secret derived from g ab modp, the Diffie-Hellman shared secret –p is an authenticating key derived from K –w is a key-encrypting key derived from K –AtoB is PRF(Nb, p|g a |g b |BSSIDa|BSSIDb) –BtoA is PRF(Na, p|g b |g a |BSSIDb|BSSIDa)

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 11 comminus, pre-shared key Where k comprised of a pre-shared key encryption key and a pre-shared IV AliceBob g a, {Na}k g b, {Nb}k, BtoA AtoB, {GTKa} w {GTKb}w

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 12 comminus, public key Where pub_b is Bob’s public key and pub_a is Alice’s public key AliceBob g a, {Na}pub_b g b, {Nb}pub_a, BtoA AtoB, {GTKa} w {GTKb}w

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 13 comminus cookie request Bob wishes to have proof that Alice is live Bob creates a stateless “cookie” Bob does not accept initial messages that do not contain a valid “cookie” AliceBob g a, {Na}k cookie g a, {Na} k, cookie g b, {Nb}k, BtoA

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 14 comminus certificate discovery Alice wishes to use certificate-based authentication but does not have Bob’s certificate Alice sends her certificate to Bob and Bob sends his to Alice AliceBob “whoRU”, CERTa CERTb

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 15 Features of comminus Has already received analysis in the form of the SKEME protocol. Not susceptible to passive attack in either pre-shared or certificate mode. Exchange has perfect forward secrecy too in case a pre-shared key is obtained by an attacker. Limited active attack possible –When pre-shared key is shared by a group a member of that group can impersonate other members of the group. Built-in DoS resistance. Diffie-Hellman based, both parties contribute to the secret.

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 16 Features of comminus A new authentication protocol –Security association is created upon first contact –No need to exchange any more frames with a mesh point that is unauthenticated. –Can be used to protect subsequent association No notion of a supplicant and an authenticator –Mutual authentication between equals –No AS needed –The shared secret that results from comminus is known only by the mesh points. There are no “PMK exposure” issues.

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 17 Features of comminus Does not impose cumbersome requirements on mesh formation. Provides authenticated keys for use with CCMP (or TKIP) After comminus is finished MPs are securely part of the mesh and can establish a security association with an external authentication server. This can then be used to perform subsequent authentication and authorization to determine ability for an MP to act in another role-- e.g. routing. Simple: only four messages needed for mutual authentication and key establishment. As Jan said, “we need to get the authentication exchange down to 4 messages.” Now we have.

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 18 Comminus Reference Implementation Uses OpenSSL library for cryptographic primitives Performs both pre-shared key and certified public key authentication. Tested under freeBSD, netBSD, linux, MACOS X Quite simple to implement –Less than 1000 lines of code for both client (supplicant) and server (authenticator), counting license boilerplate and comments. –Compares to over 53,000 lines of code for wpa_supplicant alone!

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 19 Proposal Add comminus to TGs draft for secure mesh formation. Get rid of existing PSK authentication mode. –Note: we still support using a PSK for all applicable use cases! Use 802.1x/EAP authentication as a subsequent step to perform authorization of additional roles– e.g. MP is authorized to route.

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 20 Questions?

doc.: IEEE /1092r2 Submission Nov 2006 D. Harkins, Tropos Networks Slide 21 References SKEME: A Versatile Secure Key Exchange Mechanism for the Internet, H. Krawczyk, August 1995 RFC2409: D. Harkins and D. Carrel, the Internet Key Exchange (IKE), November 1998 RFC2522: P. Karn and W. Simpson, Photuris, March 1999