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

1. Postmortem Opinions onLB35/TGi D2.0Carlos RiosRiosTek LLC

2. 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

3. The LB35 TGi (D2.0) Proposal • What it Did Well • 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

4. The Consequences And, unsurprisingly, LB35 was resoundingly rejected

5. 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

6. 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

7. What ARSN Provides

8. 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

9. 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 Authenticationdisenfranchises the IBSS and simple BSS from Enhanced Security • D2.0 802.1x-unique Key Management DID NOT WORKThe latest “completely different” version is also incomprehensibeThere 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.