doc.: IEEE /303 Submission May 2001 Simon Blake-Wilson, CerticomSlide 1 EAP-TLS Alternative for Security Simon Blake-Wilson Certicom

doc.: IEEE /303 Submission May 2001 Simon Blake-Wilson, CerticomSlide 2 Motivation Concerns over passive dictionary attacks on Kerberos Investigate TLS as alternative to Kerberos or in addition to Kerberos Please forgive me and AAA ignorance … I’m a cryptographer!

doc.: IEEE /303 Submission May 2001 Simon Blake-Wilson, CerticomSlide 3 Outline Requirements View from 10,000 Feet Operational Scenarios A Peek at the Details Dependencies Pros and Cons Summary

doc.: IEEE /303 Submission May 2001 Simon Blake-Wilson, CerticomSlide 4 Requirements Efficiency Small code size (<X kB where x=?) Efficient initial authentication (<Y secs where Y=?) Efficient roaming (<Z secs where Z=200ms?) Clients cannot be assumed to have “high entropy” secrets Security As much or better than existing wired LANs Mutual entity authentication of client and network Secure session key establishment Secure negotiation of encryption algorithms and key sizes Minimize use of new techniques

doc.: IEEE /303 Submission May 2001 Simon Blake-Wilson, CerticomSlide 5 View from 10,000 Feet Re-uses 802.1X and Enhanced Data Encryption “Realms” consisting of APs and optionally RADIUS server(s)

doc.: IEEE /303 Submission May 2001 Simon Blake-Wilson, CerticomSlide 6 View from 10,000 Feet 2 Solution steps: Server-authenticated or anonymous TLS-EAP performed between client and serving realm RADIUS server (if present) or AP Encryption keys derived from master secret and MAC addresses Encryption turned on after TLS handshake Traditional client authentication performed using EAP over encrypted channel 802.1X controlled ports opened after successful client authentication Optional enhancement - client TLS certificates - can be terminated at serving realm RADIUS server

doc.: IEEE /303 Submission May 2001 Simon Blake-Wilson, CerticomSlide 7 Scenarios - Enterprise & Public Access Serving system has RADIUS server with certificate Serving system authenticated using certificate during TLS handshake Serving system readable name confirmed with user Client authenticated based on e.g. existing username and password using EAP after TLS over encrypted channel - serving system authenticates client by contacting home system RADIUS server Effectively reduces problem to known client authentication problem

doc.: IEEE /303 Submission May 2001 Simon Blake-Wilson, CerticomSlide 8 Scenarios - Enterprise & Public Access 2 Achieving efficient roaming - option A: Client “TMSI” derived from master key along with encryption keys Serving RADIUS server passes TMSI and encryption keys to adjacent APs - can be done in advance Client passes TMSI to new AP as initial EAP identity If AP recognizes TMSI, controlled port opened immediately - otherwise TLS handshake and client authentication performed Achieving efficient roaming - option B - via TLS session resume Achieving efficient roaming - option C - DIAMETER Achieving efficient roaming - option D - context transfer

doc.: IEEE /303 Submission May 2001 Simon Blake-Wilson, CerticomSlide 9 Scenarios - SOHO AP and client establish shared password in advance Anonymous TLS handshake performed Client and AP mutually authenticate based on password using password after TLS handshake over encrypted channel (This prevents only passive dictionary attacks.)

doc.: IEEE /303 Submission May 2001 Simon Blake-Wilson, CerticomSlide 10 A Peek at the Details EAP identity response may be empty, may identify desire to perform TLS or negotiate another option, may identify home system, or may contain TMSI Derivation of encryption keys from master secret ensures encryption keys unique to particular client-AP session Clients must support one server-authenticated TLS cipher suite and one anonymous cipher suite APs must support EAP-passthrough to RADIUS server or one anonymous cipher suite TLS already supports encryption algorithm and key size negotiation Advanced cipher suites may be supported - ECC (efficient), Kerberos (existing password-based option within TLS), or SRP (improved password-based option being standardized) May alternatively add password exchange option to EAP-TLS

doc.: IEEE /303 Submission May 2001 Simon Blake-Wilson, CerticomSlide 11 Dependencies Fundamental dependencies are all complete or near complete: 802.1X EAP EAP over TLS TLS Options still in draft or need to be written: ECC, SRP in TLS DIAMETER EAP-TLS extension TLS extensions What else?

doc.: IEEE /303 Submission May 2001 Simon Blake-Wilson, CerticomSlide 12 Pros Not susceptible to passive and optionally active dictionary attacks by RF eavesdropper Improved security for efficient roaming TLS over EAP more direct approach - therefore easier to analyze and code TLS over EAP more flexible approach - built in secure cipher suite negotiation TLS already widely implemented on clients and included in some RADIUS servers More direct re-use of established RADIUS usernames and passwords Supports possible addition of anonymity option Roaming solution offers improved security Under consideration within Bluetooth SIG SEG

doc.: IEEE /303 Submission May 2001 Simon Blake-Wilson, CerticomSlide 13 Cons Public-key cryptography required in clients and SOHO APs Certificates required in RADIUS servers providing public access Clients need root keys Sensible decisions about certificate issuing and processing required - do service providers need to run a CA? Revocation? Feasability of roaming?

doc.: IEEE /303 Submission May 2001 Simon Blake-Wilson, CerticomSlide 14 Summary Dictionary attacks on Kerberos (even v5) worry me Efficient roaming with Kerberos also has some undesirable security features EAP-TLS appears attractive as the mandatory improved authentication mechanism EAP-TLS could alternatively be described as optional alternative to Kerberos What am I missing?