1 / 26

The Louie Architecture

The Louie Architecture. Nancy Cam Winget, Cisco Bob Moskowitz, TruSecure Greg Chesson, Atheros Al Potter, TruSecure Niels Ferguson, MacFergus Jesse Walker, Intel Thomas Hardjono, Verisign Doug Whiting, HiFn Russ Housley, RSA Labs. Agenda. Motivation

rashs
Download Presentation

The Louie Architecture

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. The Louie Architecture Nancy Cam Winget, Cisco Bob Moskowitz, TruSecure Greg Chesson, Atheros Al Potter, TruSecure Niels Ferguson, MacFergus Jesse Walker, Intel Thomas Hardjono, Verisign Doug Whiting, HiFn Russ Housley, RSA Labs Jesse Walker et al

  2. Agenda • Motivation • Objectives • Overview • Details • Issues and Status Jesse Walker et al

  3. Motivation (1) • Reduce complexity • Enable security analysis • Eliminate redundant cases • Common approach for BSS, IBSS, initial contact, roaming • Modular architecture • Separate security from connectivity • Address gaps in current architecture • How to bind authorization onto the PSK • How to bind to the “right” man-in-the-middle designed into 802.1-based networks • Enable proper problem partitioning • Networking problems decompose differently than security • Composition of secure components does not necessarily result in secure systems Jesse Walker et al

  4. Credential Alice STA A MACA No Credential AP B MACB Credential Louie EAP Server No Address 802.1X: exchange Credential Alice. Credential Louie and distribute key K TKIP, AES: MACA and MACB identify key K Motivation (2): Architectural Gap Problem:Authenticating Louie doesn’t tell Alice MACB identifies K, and authenticating Alice doesn’t tell AP B that MACA identifies K Jesse Walker et al

  5. Motivation (3) • For the key distribution to be meaningful • key identifiers used by 802.11 (MAC addresses) must be bound to 802.1X credentials (allowed to be more general than MAC addresses) • STA and AP need some way to verify that its peer MAC satisfies the binding EAP server intends • Cryptographic community doesn’t know how to accomplish these goals except by having EAP Server Louie tell both STA A and AP B the binding Key distribution more than key transport; binding proper level ids to key is the critical function of key distribution Jesse Walker et al

  6. Objectives • Base on 802.1X architecture • Coexistence, not cooption • Evolution, not revolution • Utilize the same key-passing procedure for initial contact, roaming,and for IBSS • Utilize proven security procedures • Eliminate AP-AP transactions! • Define a complete architecture • Advertisements, Registration, Unicast key distribution, Multicast key distribution, Revocation Jesse Walker et al

  7. Details • Who is Louie? • Functions in Louie’s realm: • Unicast key distribution • Registration • Discovery • Key revocation • Multicast key distribution • Not every network implements all functions, but all are needed by some network Jesse Walker et al

  8. Who is Louie? • To make security possible, every network must have a “crypto king” • Crypto king a logical function for enforcing the security policy of the network • In an ESS, the “crypto king” = 802.1X Authentication Server • In an IBSS, the “crypto king” is the station “setting up the conference call” Jesse Walker et al

  9. Unicast key distribution Note: Needham-Schroeder  Kerberos Jesse Walker et al

  10. Registration with a Shared Secret Jesse Walker et al

  11. Registration with a Public/Private key pair Jesse Walker et al

  12. Initial Discovery Jesse Walker et al

  13. Key Revocation Jesse Walker et al

  14. Multicast/Broadcast Comments • Multicast/Broadcast encapsulation is a different animal than unicast • Infeasible to prevent forgeries by group members  it is inappropriate to protect multicast/broadcast messages that are not idempotent • Updating key not sufficient; must also update IV and key id • If someone joins group, must update IV space as well as key • Revocation only needed when someone leaves the group • Revocation can be accomplished by distributing a new key for the group • Revocation should happen from central policy decision point Jesse Walker et al

  15. Broadcast/Multicast key generation Jesse Walker et al

  16. Distributing Bcast/Mcast keys Jesse Walker et al

  17. Activating Bcast/Mcast keys Jesse Walker et al

  18. Bcast/Mcast key distribution Jesse Walker et al

  19. Example 1: Ad hoc • Members elect Louie • Members arrange to register with Louie • Louie issues shared secret for enrollment • Louie periodically transmits invitation • Members register with Louie • After registering, members execute unicast key distribution for each peer with whom they wish to communicate • Louie issues updated broadcast key as needed Jesse Walker et al

  20. Example 2: Home or SoHo • Owner deploys device hosting Louie • Owner arranges to register devices with Louie • Louie issues shared secret for enrollment • Louie periodically transmits invitation • Members register with Louie • After registering, members execute unicast key distribution for each peer with whom they wish to communicate • Louie issues updated broadcast key as needed • Owner uses revocation as needed Jesse Walker et al

  21. Example 3: Enterprise • Enterprise IT deploys Louie = 802.1X server for a new security domain • IT register new devices with Louie, including their MAC addresses • Louie periodically transmits invitation • Authorized (i.e., registered) devices execute unicast key distribution for each peer with whom they wish to communicate • Louie issues updated broadcast key as needed • Enterprise uses revocation as needed Jesse Walker et al

  22. Example 4: Hot Spot • Hot Spot provider deploys Louie = 802.1X server for a new security domain • Either • Hot spot provider register new customer devices with Louie, including their MAC addresses, or • New customers enroll themselves, using the Louie registration procedure as one step • Louie periodically transmits invitation • Authorized (i.e., registered) devices execute unicast key distribution for each peer with whom they wish to communicate • Louie issues updated broadcast key as needed • Hot spot provider uses revocation as needed Jesse Walker et al

  23. Issues • We need buy-in from TGi participants • The architecture affects • IEEE 802.11i • IEEE 802.1X • IETF AAA • IETF EAP • Revocation, Bcast/Mcast incompatible with RADIUS; requires adoption of DIAMETER or COPS for back-end Jesse Walker et al

  24. Status • IETF draft-walker-aaa-key-distribution-01.txt to appear shortly • Defines an EAP key distribution method to obsolete AAA NASREQ key distribution • IETF draft-walker-eap-registration-00.txt to appear next month • Defines EAP enrollment protocol using pre-shared secret, another using RSA • Multicast/broadcast, key revocation incompatibility with RADIUS being studied Jesse Walker et al

  25. Summary • Uniform keying model for BSS, ESS, IBSS • Uniform model enables security analysis • Works in enterprise, home, hot spot, SoHo, ad hoc • Minimizes complexity by minimizing keying models • Complete proposal for IBSS that is compatible with all other deployments discussed • Fills gaps in TGi architecture • Relies on well-studied cryptographic protocols • Evolutionary outgrowth of TGi’s current direction Jesse Walker et al

  26. Feedback? Jesse Walker et al

More Related