doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 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

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 2 Agenda Motivation Objectives Overview Details Issues and Status

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 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 based networks Enable proper problem partitioning –Networking problems decompose differently than security –Composition of secure components does not necessarily result in secure systems

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 4 Motivation (2): Architectural Gap Credential Alice STA A MAC A No Credential AP B MAC B Credential Louie EAP Server No Address 802.1X: exchange Credential Alice. Credential Louie and distribute key K TKIP, AES: MAC A and MAC B identify key K Problem: Authenticating Louie doesn’t tell Alice MAC B identifies K, and authenticating Alice doesn’t tell AP B that MAC A identifies K

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 5 Motivation (3) For the key distribution to be meaningful –key identifiers used by (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

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 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

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 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

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 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”

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 9 Unicast key distribution Note: Needham-Schroeder  Kerberos

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 10 Registration with a Shared Secret

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 11 Registration with a Public/Private key pair

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 12 Initial Discovery

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 13 Key Revocation

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 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

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 15 Broadcast/Multicast key generation

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 16 Distributing Bcast/Mcast keys

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 17 Activating Bcast/Mcast keys

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 18 Bcast/Mcast key distribution

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 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

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 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

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 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

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 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

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 23 Issues We need buy-in from TGi participants The architecture affects –IEEE i –IEEE 802.1X –IETF AAA –IETF EAP Revocation, Bcast/Mcast incompatible with RADIUS; requires adoption of DIAMETER or COPS for back-end

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 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

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 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

doc.: IEEE /322r0 Submission May 2002 Jesse Walker et alSlide 26 Feedback?