doc.: IEEE /1066r2 Submission July 2011 Robert Moskowitz, VerizonSlide 1 Link Setup Flow Date: Authors: NameCompanyAddressPhone Robert Moskowitz Verizon Sutherland, Oak Park, MI 48237, USA Tero KivinenAuthenTec Eerikinkatu 28, FI-00180, Helsinki, Finland

doc.: IEEE /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.

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

doc.: IEEE /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?

doc.: IEEE /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%

doc.: IEEE /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

doc.: IEEE /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'

doc.: IEEE /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

doc.: IEEE /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

doc.: IEEE /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

doc.: IEEE /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

doc.: IEEE /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

doc.: IEEE /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!