1. Secure Mesh Formation Date: 2006-07-19 Authors: July 2006
doc.: IEEE /1092r1
July 2006
Secure Mesh Formation
Date:
Authors:
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 < ieee802.org/guides/bylaws/sb-bylaws.pdf>, 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
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

2. July 2006
doc.: IEEE /1092r1
July 2006
Abstract
A new security protocol for s is proposed. It addresses secure mesh formation and mesh transport.
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

3. Problem with existing scheme
July 2006
doc.: IEEE /1092r1
July 2006
Problem 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
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

4. Problems with fixing existing scheme
July 2006
doc.: IEEE /1092r1
July 2006
Problems with fixing 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
Not possible to trust authorization
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
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

5. TGs Use Cases A way NOT to look at them A better way to look at them
July 2006
doc.: IEEE /1092r1
July 2006
TGs Use Cases
A way NOT to look at them
They represent different levels of security, from weak to strong
A better way to look at them
They represent levels of user sophistication and tolerance for complexity in configuration
Ad-hoc and home networks are cases of limited sophistication and limited tolerance for complexity
Enterprise and emergency/first responder are cases of considerable sophistication and a reasonable tolerance for complexity.
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

6. July 2006
doc.: IEEE /1092r1
July 2006
TGs Use Cases
We cannot assume that certain types of attacks are acceptable for certain use cases
The protocol we come up with MUST, as a baseline, provide the same level of security and resistance to attack regardless of the use case
But it can provide varying degrees of complexity and some features may require a more sophisticated user to take advantage of
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

7. July 2006
doc.: IEEE /1092r1
July 2006
TGs Use Cases
Looking at TGs’ use cases as the spectrum of sophistication and tolerance for complexity, and thinking about how this spectrum applies to mesh formation and transport implies
A pre-shared key type of authentication
A certificate-based type of authentication
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

8. Protocol Requirements
July 2006
doc.: IEEE /1092r1
July 2006
Protocol Requirements
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.
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

9. A word about identities
July 2006
doc.: IEEE /1092r1
July 2006
A word about identities
What is the identity of a mesh node?
BSSID?
Vendor appended with serial number?
Configurable by administrator?
What is going to go in the Distinguished Name of the certificate of a mesh node?
Do we want to define minimal components for interoperability or leave it all configurable?
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

10. A protocol named comminus
July 2006
doc.: IEEE /1092r1
July 2006
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.
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

11. Features of comminus Provides Perfect Forward Secrecy
July 2006
doc.: IEEE /1092r1
July 2006
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.
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

12. A protocol named comminus
July 2006
doc.: IEEE /1092r1
July 2006
A protocol named comminus
Notation
a is Alice, the initiator
b is Bob, the responder
gx 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
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

13. A protocol named comminus
July 2006
doc.: IEEE /1092r1
July 2006
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 gab 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|ga|gb|BSSIDa|BSSIDb)
BtoA is PRF(Na, p|gb|ga|BSSIDb|BSSIDa)
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

14. comminus, pre-shared key
July 2006
doc.: IEEE /1092r1
July 2006
comminus, pre-shared key
Alice
Bob
ga, {Na}k
gb, {Nb}k, BtoA
AtoB, {GTKa} w
{GTKb}w
Where k is the pre-shared key
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

15. comminus, public key Alice Bob ga, {Na}pub_b gb, {Nb}pub_a, BtoA
July 2006
doc.: IEEE /1092r1
July 2006
comminus, public key
Alice
Bob
ga, {Na}pub_b
gb, {Nb}pub_a, BtoA
AtoB, {GTKa} w
{GTKb}w
Where pub_b is Bob’s public key and pub_a is Alice’s public key
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

16. comminus cookie request
July 2006
doc.: IEEE /1092r1
July 2006
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”
Alice
Bob
ga, {Na}k
cookie
ga, {Na} k, cookie
gb, {Nb}k, BtoA
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

17. comminus certificate discovery
July 2006
doc.: IEEE /1092r1
July 2006
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
Alice
Bob
“whoRU”, CERTa
CERTb
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

18. July 2006
doc.: IEEE /1092r1
July 2006
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.
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.
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

19. Features of comminus A new 802.11 authentication protocol
July 2006
doc.: IEEE /1092r1
July 2006
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 management frames
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.
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

20. July 2006
doc.: IEEE /1092r1
July 2006
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.
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

21. Isn’t Diffie-Hellman prohibitive?
July 2006
doc.: IEEE /1092r1
July 2006
Isn’t Diffie-Hellman prohibitive?
Not really, there are things we can do
Once a good random number is chosen and gx mod p is calculated additional public values can be calculated by merely multiplying by g mod p
y1=g(x+1) mod p, y2=g (x+2) mod p, etc.
Not any more
10 years ago this was a valid concern
Moore’s law has addressed this
Limited number of exchanges needed to form a mesh and be part of a mesh.
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

22. Questions? July 2006 doc.: IEEE 802.11-06/1092r1 July 2006
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

23. July 2006
doc.: IEEE /1092r1
July 2006
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
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink

24. July 2006
Motion
Instruct the editor to incorporate the text from document 06/0883r0 into the TGs draft
D. Harkins, Tropos Networks, C. Kuhtz, EarthLink