1. doc.: IEEE 802.11-11/1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 1 Link Setup Flow Date: 2011-05-10 Authors: NameCompanyAddressPhoneemail Robert Moskowitz Verizon 15210 Sutherland, Oak Park, MI 48237, USA +1-248-928-6233 rgm@labs.htt-consult.com Tero KivinenAuthenTec Eerikinkatu 28, FI-00180, Helsinki, Finland +358 20 500 7800kivinen@iki.fi

2. doc.: IEEE 802.11-11/1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 2 Abstract This document presents an approach for accelerating the security setup for FILS. It will also provide facilities for supporting acceleration of IP addressing.

3. doc.: IEEE 802.11-11/1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 3 Agenda Problem statement Solution overview Conclusions

4. doc.: IEEE 802.11-11/1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 4 Problem Statement The majority of the packets needed for link setup are security related. –Are there alternatives? Security is only provided for 'known' (authenticatable) clients –Can we increase security deployment by supporting a 'TLS' anonymous client model? A number of use cases fit this model `Setup time MAY be further extended if Authentication Server is separate from the AP –Can we authenticate the AP without an AS?

5. doc.: IEEE 802.11-11/1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 5 EAPOL-Start EAP-Success PEAP EAP-MSCHAPv2 (4 round trip) Establishing TLS tunnel for PEAP (3 round trip) EAP-Identity (1 round trip) Association (1 round trip) Authentication (1 round trip) EAPOL-Key (2 round trip) Probe (1 round trip) EAPOL-Start (0.5round trip) EAPOL-Success (0.5round trip) 1/16 = 6.25% 2/16 = 12.5% Most of message exchanges are consumed for Authentication and Association. 11/16 = 68.75% 2/16=12.5%

6. doc.: IEEE 802.11-11/1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 6 Solution Overview Providing a 'TLS' anonymous client model –AP does not know 'who' the client is, but knows that it is always communicating with a given client AP does not authenticate client; relies on client to protect from MITM attack No AS needed by AP. Client validates AP via X.509 or raw Public Key 'white list'. No AS needed by client. –AP and client only parties in a Key Management Protocol

7. doc.: IEEE 802.11-11/1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 7 Solution Overview Providing an authenticated client model –AP does need to know 'who' the client is Client presents credentials to AP –X.509 cert validated by AP or via OCSP »No AS needed by AP (well maybe OCSP) –Limited choices that are 'fast' Client validates AP via X.509 or raw Public Key 'white list'. No AS needed by client. –Full cert validation after connection –May be hard to provide 'fast' solution or 'not so fast'

8. doc.: IEEE 802.11-11/1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 8 Solution Overview Use AUTHENTICATE frames to support Key Management –Use a well-architected 2-party KMP between the AP and client Must have security integrity proofs Provide AP authentication to client –Eg with X.509 cert Provide nonce exchange and generate both a PMK and PTK and transmit GTK –No 4-Way-Handshake needed HIP or IKEv2

9. doc.: IEEE 802.11-11/1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 9 Protocol Sequence to Establish a Connection to the Internet by using Authentication and Association frames AP Authentication Probe [Auth server] STA HIP or IKEv2 (4 packets), optional AS or OCSP access

10. doc.: IEEE 802.11-11/1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 10 Solution Overview HIP or IKEv2 –Cryptographic and liveliness proofs of Identities Supports anonymous Identities –Ephemeral 'raw' Public Key –Authenticated delivery of X.509 certs uni or bi- directional –Support for additional client authentication EAP, SAE, other –Full nonce exchange for generation of PMK and PTK –Secure transport of GTK

11. doc.: IEEE 802.11-11/1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 11 Solution Overview IKEv2 specific –Supports EAP tunneling –OCSP proxy by AP for client –IP address assignment –Limited 'raw' key support RSA supported, ECDSA not Anonymous client thus needs just a little work

12. doc.: IEEE 802.11-11/1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 12 Solution Overview HIP specific –Anonymity explicit in design – HITs –EAP an Internet Draft –CERT RFC does not include OCSP proxy –Needs IP address parameters

13. doc.: IEEE 802.11-11/1066r2 Submission May 2011 Robert Moskowitz, VerizonSlide 13 Conclusions Current KMP designs can replace 12 round trip current method with 2 round trips –TLS anonymous model has no backend cost –Significant reduction in cryptographic operations Thank you!