Postmortem Opinions on LB35/TGi D2.0 Carlos Rios RiosTek LLC

Fundamental TGi Requirements Fix broken 802.11-1999 security mechanisms Fix 1- Firmware-downloadable retrofit for existing legacy equipment Fix 2- State-of-the-art encryption implementable in new generation equipment Incorporate 802.1x/EAPOL-based authentication into 802.11 802.11-1999 authentication does not scale well to very large networks (dozens of access points, hundreds of stations, guest users, etc) Incorporate EAPOL, leverage RADIUS infrastructure already prevalent in enterprise networks

The LB35 TGi (D2.0) Proposal What it Did Well What it Did Badly Created the Robust Security Network (RSN) context, distinct and separate from legacy 802.11-1999 security Incorporated TKIP (for legacy) and AES-OCB (for new equipment) Incorporated 802.1x/EAPOL based Upper Layer Authentication (ULA) What it Did Badly Deprecated all other 802.11-1999 authentication- only 802.1x/ULA would support Enhanced Security/RSN Proposed incomprehensibly complex, unworkable 802.1x/EAPOL based Key Management (Nonce, Group Key distribution) mechanism Left some big holes (fast roaming, multicast/broadcast) What it Didn’t Do at All Address Authentication for (non-AS provisioned) IBSS and Simple BSS Address Key Management for non-802.1x/EAPOL provisioned WLANs

And, unsurprisingly, LB35 was resoundingly rejected The Consequences RSN Functionality Editorial Commentary Strong Privacy Good TKIP and AES-OCB constructs, with improvements still coming (i.e., explicit 48 bit IVs) Authentication, given AS Full 802.1x and EAPOL support Authentication, non-AS None Key Management Incomprehensibly complex and unworkable Multicast/Broadcast Messaging protocols undefined, so what to do? Roaming Requires full (500ms?) 802.1x Authentication Comprehensive Solution Nope Large BSS Deployment Great Privacy, Authentication; Poor Messaging, Roaming SOHO BSS Deployment No AS=> No Authentication=> No Enhanced Security IBSS And, unsurprisingly, LB35 was resoundingly rejected

So, What now? D2.x- The son of D2.0 Authentication, Key Management supported uniquely by 802.1x rev ? Such an incarnation does not yet exist, is being made up as we go along We’ve been provided with incomprehensible updates periodically since Sept 01 Only the authors understand it, but they built it and could not make D2.0 work Now, 02/298 is the “completely new and different” operative substance for D2.x 02/298 is also incomprehensible. Whatever it is, I can’t build to it. It’s Sept 01 again. Except now I cannot blindly accept 02/298 as the UNIQUE basis for a solution. I’m not alone, and any LB derived solely from 02/298 will also be rejected This is clearly NOT a path to a standard any time soon Louie- The culmination of WLAN Security “Compleat Security Server” strips all security functionality from 802.11 Intriguing idea, but not even minimally baked yet D2.x should probably evolve into Louie Sounds comprehensive and probably robust, but certainly not timely Might make for a good standard someday

How about another approach? “ARSN, An Adjunct RSN”, 11-02-360r1-I Starts from 802.11-1999 and D2.0 Incorporates TKIP and AES-OCB privacy mechanisms Incorporates 802.1x/ULA authentication to support AS- provisioned networks Incorporates parallel “robust shared key authentication” for IBSS and Home WLANs, works alongside 802.1x/ULA for AS-provisioned networks Minimalist 802.11-1999 authentication fix- uses TKIP/AES for challenge/response Provides needed IBSS, simple BSS authentication mechanisms missing in D2.0 An optional solution for all us 802.1x/AS-deprived folk Incorporates parallel MAC-level mechanisms to support Key Management, Unicast and Multicast/Broadcast messaging, etc., in non-802.1x contexts Minimal modifications of existing 802.11-1999 management frames provide a full key management and messaging protocol for non EAPOL provisioned WLANs Can also support ULA networks in the interim, until EAPOL based key management and messaging is well-defined, finalized, working and stable. Again, an optional solution for us 02/298-challenged folk Incorporate fast roaming using IAPP to transport key material between APs This approach is comprehensive, robust and timely

What ARSN Provides RSN Functionality Editorial Commentary Strong Privacy Good TKIP and AES-OCB constructs, with improvements still coming (i.e., explicit 48 bit IVs) Authentication, given AS Full 802.1x and EAPOL support Authentication, non-AS TKIP/AES challenge/response adequate for IBSS, Home Key Management MAC based protocols hold the fort, perhaps only until EAPOL based Key Management is ready for prime time Multicast/Broadcast MAC based protocols hold the fort, perhaps only until EAPOL based messaging protocols are ready for prime time Roaming 20 ms max fast handoff Comprehensive Solution Yes Large BSS Deployment Excellent Authentication, Privacy, Messaging, Roaming SOHO BSS Deployment Acceptable Authentication, Privacy, Messaging, Roaming IBSS Acceptable Authentication, Privacy, Messaging

Motivation for ARSN D2.0 failed to provide an Enhanced WLAN Security solution acceptable to the full 802.11 membership D2.x is more of the same, and likewise will never get to sponsor ballot Louie sounds great, but Takes complexity to a much higher level Looks like a high cost adder throughout (Need a Louie server in every station!!) Won’t be ready anytime soon ARSN will provide a timely, workable (and perhaps) interim solution for RSN security Incorporates TKIP, AES-OCB and 802.1x/ULA Makes small mods to 802.11-1999 to produce a necessary and sufficient security fix ARSN text is readable, comprehensible and eminently critique-able, and runs 14 pages ARSN is structured to allow incorporation of D2.x and/or Louie protocols as these are defined, verified, finalized and stabilized. We get something that will work acceptably now (2002), and can keep on working to improve it

And, Let’s Speak Frankly The industry, and some of our bosses, have been screaming for a “WEP Fix” for about a year now TGi has been spectacularly unsuccessful in producing one Somewhere along the line, said WEP Fix has picked up baggage that is now effectively precluding its completion and adoption: “802.1x is the unique mechanism for RSN Authentication and Key Management” 802.1x-unique Authentication disenfranchises the IBSS and simple BSS from Enhanced Security D2.0 802.1x-unique Key Management DID NOT WORK The latest “completely different” version is also incomprehensibe There is NO reason to assume this version will work either As long as the WEP Fix carries this baggage it will never pass One resolution is to ditch the 802.1x-only pony and allow alternative optional solutions that avoid these problems. ARSN is one of many possible such solutions, and I urge the Task Group to provide it, and any others, the crucially important consideration they merit.