1 / 13
Télécharger la présentation

July 2011

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

Playing audio...

  1. July 2011 Link Setup Flow Date: 2011-05-10 Authors: Slide 1 Robert Moskowitz, Verizon

  2. July 2011 Abstract This document presents an approach for accelerating the security setup for FILS. It will also provide facilities for supporting acceleration of IP addressing. Slide 2 Robert Moskowitz, Verizon

  3. July 2011 Agenda • Problem statement • Solution overview • Conclusions Slide 3 Robert Moskowitz, Verizon

  4. July 2011 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? Slide 4 Robert Moskowitz, Verizon

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

  6. July 2011 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 Slide 6 Robert Moskowitz, Verizon

  7. July 2011 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' Slide 7 Robert Moskowitz, Verizon

  8. July 2011 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 Slide 8 Robert Moskowitz, Verizon

  9. July 2011 Protocol Sequence to Establish a Connection to the Internet by using Authentication and Association frames STA AP [Auth server] Probe Authentication HIP or IKEv2 (4 packets), optional AS or OCSP access Slide 9 Robert Moskowitz, Verizon

  10. July 2011 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 Slide 10 Robert Moskowitz, Verizon

  11. July 2011 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 Slide 11 Robert Moskowitz, Verizon

  12. July 2011 Solution Overview • HIP specific • Anonymity explicit in design – HITs • EAP an Internet Draft • CERT RFC does not include OCSP proxy • Needs IP address parameters Slide 12 Robert Moskowitz, Verizon

  13. May 2011 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! Slide 13 Robert Moskowitz, Verizon

More Related