1 / 13

July 2011

July 2011. Security Discussions. Date: 2011-09-22. Authors:. Slide 1. Robert Moskowitz, Verizon. July 2011. Abstract. This document covers a number of security thoughts that 802.11ai may leverage to meet their performance and security goals. One size does NOT fit all

diana-cobb
Download Presentation

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

  1. July 2011 Security Discussions Date: 2011-09-22 Authors: Slide 1 Robert Moskowitz, Verizon

  2. July 2011 Abstract This document covers a number of security thoughts that 802.11ai may leverage to meet their performance and security goals. • One size does NOT fit all • “Trust then Verify” • Cryptographically bound MAC addresses Slide 2 Robert Moskowitz, Verizon

  3. July 2011 Agenda • How to offer choices • Trust then Verify of X.509 identities • Raw public keys as identities • Cryptographically bound MAC addresses • Conclusions Slide 3 Robert Moskowitz, Verizon

  4. July 2011 Problem Statement • How can 11ai make speed assertions if parts of the timings are deployment dependent • AAA and DHCP servers • Some use cases can allow for 'fast enough'? • How to affectively offer security choices? • What is the cost in identities • Code and CPU to process • Network activity to trade and trust Slide 4 Robert Moskowitz, Verizon

  5. July 2011 Approaches to offering Security choices • Use of the EAP model places authentication and keying choices within the EAP wrappings • Is this really simpler? • What are the costs? • Consider Beacon or Auth based offers • AP lists what it can provide • STA lists what it wants to provide • Who is on first? STA or AP? • Either works Slide 5 Robert Moskowitz, Verizon

  6. July 2011 Approaches to offering Security choices • AP Beacons Authentication methods • In Beacons • STA Probes for desired Authentication method • In Beacon Probe • Or STA Requests a method from a offered list • In Auth Request Slide 6 Robert Moskowitz, Verizon

  7. July 2011 X.509 based “Trust then Verify” • X.509 certificate verification MAY take network resources • OCSP and online CRL lookup • STA accepts AP cert until it can verify • Local policy decision • May occur after IP connectivity or be delayed after 'time critical' E2E secured activity • AP accepts STA cert until it can verify • STA immediately has IP connectivity • Small time window for STA activity until verified Slide 7 Robert Moskowitz, Verizon

  8. July 2011 X.509 based “Trust then Verify” • Risk is 'window of opportunity' • STA may only want the station/area map while verifying AP • AP may restrict STA services until verified to local resources (maps!) • Built on STA-AP KMP model supporting certs • e.g. IKEv2 or HIP-BEX • Some cert providers are gearing up for easy, affordable large scale cert deployment Slide 8 Robert Moskowitz, Verizon

  9. 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. • May be hard to provide 'fast' solution or 'not so fast' Slide 9 Robert Moskowitz, Verizon

  10. July 2011 Self Assertion of Identity • A Public/Private key operation is an assertion of identity • Self-signed certs as an identity claim • '“I am”, I said' – Neil Diamond, 1971 • What is gained by self-signed certs over raw keys? • Binding protection from MITM? Really? • If STA really needs to trust AP then 3rd party certs a must. Otherwise go with raw public keys • Raw public keys CAN make other identity assertions • Cryptographically Bound Addresses • e.g. HIP HITs Slide 10 Robert Moskowitz, Verizon

  11. July 2011 Self Assertion of Identity • Consider Cryptographically generated MAC addresses • Manufacturer hashes a public key with its 24 bit MAC header to produce 24 bit lower part of MAC • If a collision with prior assigned MAC, generate a new key pair, and repeat • If manufacture produces 500K devices, attacker has 3% chance to spoof SOME valid MAC for each key pair generation • 500K/16M • But 1/16M for a specific MAC • Hardness of spoofing proportional to devices manufactured Slide 11 Robert Moskowitz, Verizon

  12. July 2011 Self Assertion of Identity • Consider Cryptographically generated MAC addresses • More natural trust in MAC without PKI overhead • Manufacturer MAY publish assigned MACs for actual validation • What mechanism? • Many applications of CGA MACs Slide 12 Robert Moskowitz, Verizon

  13. May 2011 Conclusions • There is a role for “Trust then Verify” for fast access • In many scenarios use of raw keys will result in MORE security being used • “Any one can do it” Thank you! Slide 13 Robert Moskowitz, Verizon

More Related