Category: Education

Presentation Description

No description available.


Presentation Transcript

Wireless LANs: The 802.1X Revolution: 

Wireless LANs: The 802.1X Revolution Dr. Bernard Aboba Network Architect, Windows Microsoft

What We’ll Talk About: 

What We’ll Talk About Standards and resources Networking – the next decade Ethernet everywhere! Introduction to IEEE 802.1X Deploying IEEE 802.1X with 802.11 IEEE 802.1X Applications What we won’t talk about Details of WEP attacks and proposed fixes Which 802.11, 802.1X or RADIUS vendors are the best.

Standards Groups: 

Standards Groups IEEE 802.1X “Network Port Authentication” 802.1w “Spanning tree rapid convergence” 802.11e – Quality of Service 802.11f – Inter-Access Point Protocol 802.11i – Extended security IETF RADIUS & AAA – authentication, authorization, accounting PPPEXT – Extensible Authentication Protocol (EAP) IPsec and IPSRA – IPsec and VPNs

How to Learn More: 

How to Learn More The “Unofficial 802.11 Security” Web Site: IEEE IEEE 802 web page: Get IEEE 802 program provides free access to standards older than 6 months Anyone can participate, don’t have to be an IEEE member Don’t have to attend meetings to comment on drafts Meeting attendance is required for voting rights IETF IETF web page: Relevant WGs: MANET, PPPEXT, AAA, MIP, IPsec, IPSRA IETF draft archive:,

Networking – The Next Decade: 

Networking – The Next Decade

The Internet Revolution Continues…: 

The Internet Revolution Continues… Name a business that won’t be affected by the Internet Name an aspect of your life that won’t change because of the Internet Chances are that that business or aspect of life hasn’t changed much since 2000 BC either!

By 2009…: 

By 2009… Almost everything will be connected to the Internet Appliances, automobiles, personal communicators, screens (large and small), even your watch. 3 billion Internet-capable wireless devices The Internet will be: Telephone, answering machine, television, radio, movie theatre, clock, store, cell phone, pager, post office, mailbox, library, security system, gaming platform, musical instrument, learning center, storage medium, and much, much more!

Some relationships…: 

Some relationships… 1 Mbps of wired bandwidth requires approximately 1 MIP of CPU power to process it 1 Gbps ~ 1000 MIPS ~ 1 Ghz CPU Wireless LAN bandwidth is approximately 2 orders of magnitude behind wired LANs But rate of growth is the same! 1 bit of bandwidth requires approximately 10 KB of storage per client 300 bps (early modem) ~ 3 MB storage (PC XT) 1 Mbps (ADSL) ~ 10 GB storage (typical PC storage) As bandwidth increases, so does file size; today we have CD-quality Internet audio; tomorrow, broadcast quality video

Gilder’s Law vs. Moore’s Law: The Last Twenty Years: 

0.01 0.1 1 10 100 1000 10000 1986 1988 1990 1992 1994 1996 Performance in Mflop/s 8087 80287 6881 80387 R2000 i860 RS6000/540 Alpha RS6000/590 Alpha Cray 1S Cray X-MP Cray 2 Cray Y-MP Cray C90 Cray T90 1998 Gilder’s Law vs. Moore’s Law: The Last Twenty Years 1982 1984 Speed in Mbps Ethernet Ethernet Storage Storage in MB 802.11 Source: Gordon Bell, Microsoft Research

Local-Area Wireless: 

Local-Area Wireless Materials from Andrew Seybold-Microsoft Exchange Conference 1999


SAN/WAN/LAN Convergence POTS WAN LAN SAN/backpanels 1 Mb 1 Gb 1 Kb POTS @ 17%/year ISDN ADSL Source: Gordon Bell, Microsoft Research

The Next Twenty Years: 

0.1 1 10 100 1000 10000 100000 2004 2006 2008 2010 2012 2014 Performance in Gflop/s 2016 The Next Twenty Years 2000 2002 Speed in Gbps Wired Ethernet Storage Storage in GB 802.11

In a decade we will have:: 

In a decade we will have: Huge storage 1 TB disks will be mass market (<$200) Very fast wired networking 100 Gb Ethernet will be mass market (< $100) Ubiquitous wireless networking 3 billion units worldwide! 1 Gb wireless LANs: a viable replacement for wired NICs 10 Mbps wireless WANs More powerful personal computers 10+ Ghz processors 4x resolution (2K x 2K) displays competitive w/paper Large, wall-sized and watch-sized displays A new generation of personal communicators PDAs, PIMs, cell phones, watches, etc. Invisible computing Networked appliances (washing machines, microswave, etc.) Inevitable, continued cyberization… the challenge… interfacing platforms and people. Source: Gordon Bell, Microsoft Research

By the End of the Decade, 802.11 will be…. : 

By the End of the Decade, 802.11 will be…. A viable desktop NIC replacement Ubiquitous In 1994, there were less than 3K PPP dialup ports in the US… today there are millions Wireless ISPs will happen Community nets will happen Adhoc networking will extend coverage dramatically Dual 802.11/WAN NICs will be commonplace But you already know that!

2009: The Dicotomy: 

2009: The Dicotomy Bigger, Faster 200 Million units/year: Laptop, Desktop, Server 10 Ghz processor 100 GbE 1+ TB magnetic disk Smaller, Cheaper 500 million units/year: PDA/Cell phone/sub-laptop 1 Ghz processor 1 Gbps Wireless LAN 10 Mbps wireless WAN 1 GB flash disk


Implications IP and Ethernet will be the mainstream technology for SAN, MAN, WAN and LAN Fiber the primary PHY for 10 GbE Goodbye Fibre Channel and SONET! Goodbye Home RF and Bluetooth! PC architecture will have to change dramatically to keep up with bandwidth increases Hardware acceleration is required, even on desktops! PC Bus replaced by cross-bar switch Optical the ultimate interconnect? Managing vast storage will be challenging Storage area networks take off Remote backup and restore

Implications (cont’d): 

Implications (cont’d) Latency as the scarcest commodity Speed of light becomes the major limitation Distribution of applications to the edge: Akamai/Digital Island BW-Delay product will increase Applications need to be tolerant of high latency characteristic of wireless WAN Need to minimize round-trips! Efficient protocols and caching is critical Everything on IP All PC components have an IP(v6) address (Infiniband) SCSI over IP… what’s next?

Life In the 1 Gbps Lane: 

Life In the 1 Gbps Lane Clock cycles are scarce Example: 1 Gbps wire speed Packet length of 64 bytes ~ 600 bit times ~ 600ns 512 bits + 96 bits inter-frame gap For clock rate of 1 Ghz (1 ns), clocks per packet: 600 @ 1 Gbps 60 @ 10 Gbps 6 @ 100 Gbps Problem only gets worse with time! Need to carry out within clock budget: Layer 2: Ethernet, 802.1p, encapsulation/decapsulation Layer 3: IP, DiffServ, IPsec Layer 4: TCP, NAT Layer 5: SSL/TLS, iSCSI Layer 7: XML

Ethernet Everywhere!: 

Ethernet Everywhere!

Ethernet Everywhere: 

Ethernet Everywhere Ethernet is becoming the dominant LAN, SAN, MAN, WAN and WLAN medium Ethernet for metropolitan area and longhaul networks Ethernet in the First Mile Ethernet in the Home Ethernet in System Area Networks (SANs) Authenticated LANs Auto-provisioned LANs Fault-tolerant Ethernet Wireless Ethernet Ethernet ISPs Ethernet-based NASes and CPE

The Benefits of Ubiquitous Ethernet: 

The Benefits of Ubiquitous Ethernet What would it mean if you could offer twice the bandwidth at half the cost? What would it mean if customers could get more bandwidth for their Internet connection in seconds, instead of months? What would it mean if you never needed to upgrade a customer’s premise equipment or WAN links? What would it mean if you could offer wireless connectivity in any hotel, airport, or public space? What would it mean if home users could get Internet access hundreds of times faster than is available today with DSL and Cable Internet? What would it mean if customers could backup mission critical data in multiple simultaneous locations in seconds at night, while only paying for the connectivity they need during the day? This is what Gigabit Ethernet, Wireless LANs (802.11) and Network Port Authentication (IEEE 802.1X) Delivers.

10 Gb Ethernet: 

10 Gb Ethernet Standardized in IEEE 802.3az Goal is to maintain existing 802.3 frame format and size while supporting 10 Gbps full duplex operation No support for CSMA/CD! Design point is LAN, MAN and WAN LAN: 1310 nm band MAN and WAN: 1550 nm band Completion likely 2Q 2002 Dramatic cost advantages over SONET likely: $50K/port for OC-192 SONET vs. $200/port for 10 Gb Ethernet by 2004

Ethernet ISPs: 

Ethernet ISPs Wayport OnFibre Telseon,4538,2532509,00.html,4164,2523589,00.html Yipes

The Ethernet Network Access Server (NAS): 

The Ethernet Network Access Server (NAS) To offer economical Ethernet-based access we need a new class of network access server – the EtherNAS. The EtherNAS is managed like a dialup NAS but offers thousands of times the bandwidth. IEEE 802.11 APs supporting 802.1X and RADIUS are the first (but not the last) EtherNASes Key standards include: IEEE 802 RFC 2865 - 2869: RADIUS IEEE 802.1X: Network Port Authentication

The Ethernet CPE: 

The Ethernet CPE To offer economical Ethernet-based access on customer premises need a new class of Ethernet CPE device The EtherCPE is as easy to set up as a SOHO router, but offers many times the bandwidth PHY: 802.11 or 1-10 Gbps Ethernet over Fiber interface Low cost Today: $500 for 1 GbE 2002: $250 Built in mini-DHCP/DNS server Support for bridging, routing IEEE 802.1X authentication and auto-provisioning

Introduction to IEEE 802.1X: 

Introduction to IEEE 802.1X

What is Network Access Authentication?: 

What is Network Access Authentication? A mechanism by which access to the network is restricted to authorized entities Identities used are typically userIDs NB: each user on a multi-user machine does not need to authenticate once the link is up, so this doesn’t guarantee that only the authenticated user is accessing the network Once authenticated, the session needs to be authorized Authorization can include things like VLANID, rate limits, filters, tunneling, etc. To prevent hijacking, you need per-packet authentication as well Encryption orthogonal to authentication Per-packed MIC based on key derived during the authentication process, linking each packet to the identity claimed in the authentication No MIC support in PPP and WEP!

Network Access Alternatives: 

Network Access Alternatives Network access authentication has already been implemented at every layer. PHY Example: 802.11b Pros: no MAC or TCP/IP changes required (all support in firmware) Cons: requires firmware changes in NICs and NASes to support new auth methods, requires NAS to understand new auth types, slows delivery of bug fixes (e.g. WEP v1.0), hard to integrate into AAA MAC Examples: PPP , 802.1X Pros: no firmware changes required for new auth methods, easier to fix bugs, easy to integrate into AAA, no network access needed prior to authentication, extensible (RFC 2284) Cons: requires MAC layer changes unless implemented in driver

Network Access Alternatives (cont’d): 

Network Access Alternatives (cont’d) IP Examples: hotel access (based on ICMP re-direct to access web server) Pros: no client MAC or TCP/IP changes required (for ICMP re-direct method) Cons: Doesn’t work for all apps, no mutual authentication, partial network access required prior to auth, need to find access control server if not at first hop, typically not extensible, may not derive encryption keys, no accounting (no logoff) UDP/TCP Examples: Proprietary token card protocols Pros: No client MAC or TCP/IP changes required – can be implemented purely at the application layer Cons: requires client software, partial network access required prior to auth, need to find access control server if not at first hop, typically not extensible, no accounting (no logoff)

Why Do Auth at the Link Layer?: 

Why Do Auth at the Link Layer? It’s fast, simple, and inexpensive Most popular link layers support it: PPP, IEEE 802 Cost matters if you’re planning on deploying 1 million ports! Client doesn’t need network access to authenticate No need to resolve names, obtain an IP address prior to auth NAS devices need minimal layer 3 functionality 802.11 access points, 1 Gbps switch ports go for $300, support 802.1D, 802.1X, SNMP & RADIUS, may have no layer 3 filtering support Authentication, AAA support typically a firmware upgrade In a multi-protocol world, doing auth at link layer enables authorizing all protocols at the same time Doing it at the network layer would mean adding authentication within IPv4, IPv6, AppleTalk, IPX, SNA, NetBEUI Would also mean authorizing within multiple layers Result: more delay

What is IEEE 802.1X?: 

What is IEEE 802.1X? The IEEE standard for authenticated and auto-provisioned LANs. Ratified June 2001 Based on EAP, IETF RFC 2284 A framework for authentication and key management IEEE 802.1X derives keys which can be used to provide per-packet authentication, integrity and confidentiality Typically used along with well-known key derivation algorithms (e.g. TLS, SRP, etc.) IEEE 802.1X does not mandate security services – can do authentication, or authentication & encryption Encryption alone not recommended (but that’s what WEP does) What 802.1X is not Purely a wireless standard – it applies to all IEEE 802 technologies (e.g. Ethernet First Mile applications) PPP over Ethernet (PPPOE) – only supports EAP authentication methods (no PAP or CHAP), packets are not encapsulated A cipher – not a substitute for WEP, RC4, DES, 3DES, AES, etc. But 802.1X can be used to derive keys for any cipher A single authentication method But 802.1X can support many authentication methods without changes to the AP or NIC firmware

A History of IEEE 802.1X: 

A History of IEEE 802.1X The idea started with customers who wanted to control access to a public network Universities, government agencies Existing approaches were inadequate Customers wanted something that could be implemented inexpensively – on existing switches Customers wanted to utilize existing network access infrastructure (RADIUS, LDAP, etc.) PPPOE – too much overhead VPN – too many interoperability issues DHCP – designed for addressing and configuration, not access control Concept developed by 3Com, HP, and Microsoft We examined alternatives, and settled on a Layer 2 approach A small group wrote the spec and built prototypes Consensus and running code! Not designed by committee! IEEE 802.1X PAR approved in January 1999 Approved as an IEEE standard June 2001 Specification available at:

802.1X Topologies: 

802.1X Topologies Authenticator/EtherNAS (e.g. Access Point or Bridge) Supplicant Enterprise or ISP Network Semi-Public Network / Enterprise Edge AuthenticationServer RADIUS EAP Over Wireless (EAPOW) EAP over LAN (EAPOL) EAP Over RADIUS PAE PAE EtherCPE Supplicant Non-802.1X

802.1X Security Philosophy: 

802.1X Security Philosophy Approach: a flexible security framework Implement security framework in upper layers Enable plug-in of new authentication, key management methods without changing NIC or Access Point Leverage main CPU resources for cryptographic calculations How it works Security conversation carried out between supplicant and authentication server NIC, Access Point acts as a pass through device Advantages Decreases hardware cost and complexity Enables customers to choose their own security solution Can implement the latest, most sophisticated authentication and key management techniques with modest hardware Enables rapid response to security issues

What is EAP?: 

What is EAP? The Extensible Authentication Protocol (RFC 2284) Provides a flexible link layer security framework Simple encapsulation protocol No dependency on IP ACK/NAK, no windowing No fragmentation support Few link layer assumptions Can run over any link layer (PPP, 802, etc.) Does not assume physically secure link Methods provide security services Assumes no re-ordering Can run over lossy or lossless media Retransmission responsibility of authenticator (not needed for 802.1X or 802.11) EAP methods based on IETF standards Transport Level Security (TLS) (supported in Windows 2000) Secure Remote Password (SRP) GSS_API (including Kerberos)

EAP Architecture: 

EAP Architecture EAP Layer Method Layer Media Layer NDIS APIs EAP APIs PPP 802.3 802.5 802.11

What is RADIUS?: 

What is RADIUS? Remote Access Dial In User Service Supports authentication, authorization, and accounting for network access Physical ports (analog, ISDN, IEEE 802) Virtual ports (tunnels, wireless) Allows centralized administration and accounting IETF status Proposed standard RFC 2865, RADIUS authentication/authorization RFC 2618-2621, RADIUS MIBs Informational RFC 2866, RADIUS accounting RFC 2867-8, RADIUS Tunneling support RFC 2869, RADIUS extensions RFC 3162, RADIUS for IPv6

IEEE 802.1X Conversation: 

Ethernet Laptop computer Switch Radius Server IEEE 802.1X Conversation RADIUS EAPOL

802.1X On 802.11: 

Ethernet Access Point Radius Server 802.1X On 802.11 RADIUS EAPOW Laptop computer Wireless 802.11 802.11 Associate-Response

802.1X authentication in 802.11: 

802.1X authentication in 802.11 IEEE 802.1X authentication occurs after 802.11 association or reassociation Association/Reassociation serves as “port up” within 802.1X state machine Prior to authentication, access point filters all non-802.1X traffic from client If 802.1X authentication succeeds, access point removes the filter 802.1X messages sent to destination MAC address Client, Access Point MAC addresses known after 802.11 association No need to use 802.1X multicast MAC address in EAP-Start, EAP-Request/Identity messages Prior to 802.1X authentication, access point only accepts packets with source = Client and Ethertype = EAPOL

802.1X and Per-STA Session Keys: 

802.1X and Per-STA Session Keys How does 802.1X derive per-Station unicast session keys? Can use any EAP method supporting secure dynamic key derivation EAP-TLS (RFC 2716) EAP-SRP EAP-AKA, EAP-SIM (for compatibility with cellular) Security Dynamics Keys derived on client and the RADIUS server RADIUS server transmits key to access point RADIUS attribute encrypted on a hop-by-hop basis using shared secret shared by RADIUS client and server Unicast keys can be used to encrypt subsequent traffic, including EAPOW-key packet (for carrying multicast/global keys) Per-Station unicast session keys not required If only multicast/global keys are supported, then session key is only used to encrypt the multicast/global key

802.1X and Multicast/Global Keys: 

802.1X and Multicast/Global Keys How can 802.1X transfer multicast/global keys? An EAPOL packet type is defined for use in transporting multicast/global keys: EAPOW-Key EAPOW-Key packet type used to transmit one or more keys from access point to client (or vice versa) EAPOW-Key packets only sent after EAPOW authentication succeeds EAPOW-Key packets are encrypted using derived per-STA encryption key

802.1X and Ad-Hoc Networking: 

802.1X and Ad-Hoc Networking What is ad-hoc networking? Station communicating directly with other stations How does ad-hoc networking work with 802.lX? Both Stations initiate EAPOL conversation All stations authenticate with each other Otherwise mutual authentication required and algorithm to select authenticator RADIUS not used in ad-hoc mode Typically implies that user credentials are stored on Stations

Key Management for Ad-Hoc Networking: 

Key Management for Ad-Hoc Networking Requirements Password-based mutual authentication Secure key generation Evaluation of existing EAP methods EAP-TLS: supports mutual authentication, keying, but assumes both participants have a certificate EAP-SRP: supports mutual authentication, but not assumes “client” and “server” 802.1X will work in adhoc mode if required Shared key is easiest mechanism in most cases

Other issues with Adhoc: 

Other issues with Adhoc Interconnections not organized Multiple interconnections to destinations “Hidden” stations Loops in the network L2 Spanning tree required Removes loops, organizes STAs to form a coherent LAN Problem: convergence time of 802.1D too slow Not easy to connect both via adhoc and AP Two interfaces need to be exposed Requires STAs to act as a bridge Creates potential security issues

Adhoc Networking Advances: 

Adhoc Networking Advances Goal: allow devices to talk to each other without a network administrator Focus of IETF ZEROCONF WG Fast spanning tree convergence IEEE 802.1w IPv4 linklocal addressing Draft-ietf-zeroconf-ipv4-linklocal-0x.txt IPv4 automatic multicast addressing Draft-thaler-zeroconf-multicast-0x.txt Mini-DHCP server Draft-aboba-dhc-mini-0x.txt Multicast DNS Draft-ietf-dnsext-mdns-0x.txt uPnP Draft-cai-ssdp-v1-0x.txt

Extending Coverage with Adhoc: 

Extending Coverage with Adhoc Authenticator/EtherNAS (e.g. Access Point or Bridge) Supplicant Enterprise or ISP Network Semi-Public Network / Enterprise Edge AuthenticationServer RADIUS EAP Over Wireless (EAPOW) EAP over LAN (EAPOL) EAP Over RADIUS Adhoc Peer Adhoc Peer Adhoc Peer Adhoc Peer

Deploying IEEE 802.1X With 802.11: 

Deploying IEEE 802.1X With 802.11

Deployment Issues with 802.11: 

Deployment Issues with 802.11 User-based authentication and accounting 802.11-1997 only allows users to be identified by MAC address How do I know who is on my network? How can I do user-based access control, accounting and auditing? What happens if a machine is stolen? Proprietary key management solutions require separate user databases Secure roaming Why can’t you just “plug in and connect” anywhere in the world? Key management 802.11-1997 supports per-user keys, but most implementations only support global keys What if the global key(s) are compromised? Static keys difficult to manage on clients, access points

WEP Summary of Attacks: 

WEP Summary of Attacks Downloadable procedures To crack the Key: To brute force enter into WLAN, select THC-RUT from Attacks based on [Walker], [Arbaugh], [Berkeley team], [Fluhrer/Shamir] Lack of IV replay protection Short IV sequence space RC4 vulnerabilities due to WEP’s implementation Linear properties of CRC32 (allows bit flipping)) Lack of keyed MIC Use of shared keys

Quest to Improve WEP: 

Quest to Improve WEP How can we improve WEP security and Retain (most) performance Enhance without greatly reducing line rates Easily upgrade deployed systems Avoid hardware upgrades Retain interoperability Allow most deployed systems to upgrade Allow for incremental deployment Allow legacy systems to continue to work without improvements Provide better protection until AES is available

Improving WEP’s Security: 

Improving WEP’s Security Recommended Practice includes Per-link keys Unique key per STA IV Sequencing Check for monotonically increasing IVs Weak IV avoidance 104-bit keys IV + Key = 128-bits Rapid Rekey Derive WEP keys from master key Change encryption key frequently

802.1X Authentication: 

802.1X Authentication 802.1X users identified by usernames, not MAC addresses Enables user-based authentication, authorization, accounting For use with 802.1X, EAP methods supporting mutual authentication are recommended Need to mutually authenticate to guarantee key is transferred to the right entity Prevents man-in-the-middle and rogue server attacks Common EAP methods support mutual authentication TLS: server and client must supply a certificate, prove possession of private key SRP: permits mutual authentication via weak shared secret without risk of dictionary attack on the wire Tunneled TLS: enables any EAP method to run, protected by TLS

Advantages of IEEE 802.1X: 

Advantages of IEEE 802.1X Open standards based Leverages existing standards: EAP (RFC 2284), RADIUS (RFC 2865, 2866, 2867, 2868, 2869) Enables interoperable user identification, centralized authentication, key management Enables automated provisioning of LAN connectivity User-based identification Identification based on Network Access Identifier (RFC 2486) enables support for roaming access in public spaces (RFC 2607). Enables a new class of wireless Internet Access Dynamic key management Improved security for wireless (802.11) installations

WEPv1.0 w/802.1X: 

WEPv1.0 w/802.1X Improved key derivation Per-user unicast keys instead of global unicast key Unicast key may be changed periodically to avoid staleness Support for standards-based key derivation techniques Examples: TLS, SRP Kerberos V without PKINIT not recommended for use with 802.11 Additional fixes still under discussion Authentication for reassociate, disassociate WEP deficiencies still present No keyed MIC Improper usage of RC4 stream cipher No IV replay protection Long term solution: Need a “real” cipher! AES proposals under discussion AES-OCB versus AES-CTR mode and CBC-MAC with XCBC extensions

802.1X Implementations: 

802.1X Implementations Implementations available now IEEE 802.1X support included in Windows XP Firmware upgrades available from AP and NIC vendors Interoperability testing underway 802.1X OS support Microsoft: Windows XP Cisco: Windows 9x, NT4, 2000, Mac OS, Linux RADIUS servers supporting EAP Microsoft Windows 2000 Server Cisco ACS Funk RADIUS Interlink Networks (formerly MERIT) RADIUS server

Vendors Supporting 802.1X: 

Vendors Supporting 802.1X Microsoft, AirWave, Compaq, Dell, IBM, Intel, HP, Symbol, Toshiba, Telson, Wayport 3Com Agere Enterasys Intersil Cisco Catalyst switches 802.11 access points

Windows Wireless Architecture: 

Windows Wireless Architecture NDIS 5.1 Networking APIs NDIS WAN PPTP Async Bluetooth Ethernet TR 802.11 TCP/IP Protocol stacks WinSock 2.0 RSVP Packet scheduler Packet classifier TAPI 3.0 Dial-up Networking APIs IP packet filtering IP forwarder Routing APIs Network streaming (DirectX) RNDIS DHCP IGMP 802.1X DNS IRDP Networking Services Affected by Wireless Route table Network Location 802.1D NetBT UPnP

Windows XP Wireless Features: 

Windows XP Wireless Features Extensible security with 802.1X Wireless Roaming Support for 802.1X built-in (EAP-TLS, MD-5) Automated configuration via SSID detection

Windows XP Wireless (cont’d): 

Windows XP Wireless (cont’d) Improved driver support Internet Connection Firewall (ICF)

Microsoft’s 802.1X Deployment: 

Microsoft’s 802.1X Deployment Largest known 802.11b deployment Now running IEEE 802.1X exclusively Clients running Windows XP Authentication based on certificates (EAP TLS) Centralized management via Windows 2000 RADIUS server (IAS) and Active Directory Deployment based on Cisco Access Points Multiple 802.11 NIC vendors supported

Deployment Issues: 

Deployment Issues Shared use APs Driver should be prepared for multiple SSIDs included in Beacons and Probe Responses Drivers and laptops Spurious media sense events on some NICs Defective PCMCIA controllers on some laptops Poor antenna design on some laptops with built-in wireless NICs Rogue APs Problem is not just connecting to them (solved by SSID preference), but radio interference User versus machine certificates Machine certs imply authentication at boot; user certs imply authentication on user login Management (SMS, group policy, etc.) are easier if machine is always on the network Certificate management Need to get clients set up with proper machine and user certificates Solution: deployment of enrollment scripts

Diagnosing 802.1X: 

Diagnosing 802.1X RADIUS accounting Termination-Cause attribute provides information on reasons why a session ended Connection-Info attribute provides information on link performance 802.1X MIB Provides information on failures at each stage of the authentication process “Failure fractions” derived from MIB variables ideally suited for reporting and quality control charts Provides same accounting information as RADIUS accounting SNMP supports “pull model” accounting

Evaluating Access Points: 

Evaluating Access Points “MUST Haves” 802.11 Support for multiple SSIDs in Beacon, Probe Response 802.11 MIB 802.1X 802.1X MIB SNMPv3 RADIUS Authentication and accounting Termination-Cause & Connect-Info Full support for draft-congdon-radius-8021x-16.txt “SHOULD haves” IEEE 802.11f IAPP VPN support (IETF Standards!) Dynamic VLAN support

802.1X Applications: 

802.1X Applications Shared use APs Multiple ISPs sharing the same access point Wholesale wireless access Wireless outsourcing for enterprise customers Global roaming Public Ethernet taps Roaming access to 802.11 in airports, malls, hotels, etc. Seamless mobility Dynamic VLANs Compulsory wireless or wired tunneling Management of LAN-LAN tunnels VPN management outsourcing Automated provisioning Instant bandwidth upgrades


Summary The IEEE 802.1X standard enables a new class of Ethernet-based Internet Access IEEE 802.1X also enables a new generation of applications, including ubiquitious wireless roaming, automated provisioning and fibre to the home Support for IEEE 802.1X is built into Windows XP client. Windows 2000 RADIUS server already supports IEEE 802.1X applications

For More Information: 

For More Information Unofficial 802.11 security web page AES IEEE 802.1X Kerberos/GSS-API (Kerberos V) (GSS-API) RADIUS EAP



802.1X Applications: 

802.1X Applications

The Role of RADIUS: 

The Role of RADIUS RADIUS is the key to enabling 802.1X applications RADIUS enables per-user compulsory tunneling assignment More flexible than static or realm-based tunneling What if is to be given Internet access, but should be tunneled to the marketing tunnel server? RADIUS enables per-user VLAN assignment More flexible than static per-port or MAC-based VLAN assignment RADIUS enables accounting and auditing Both switch/AP and tunnel server can use RADIUS Allows enterprise to audit usage, do alarming BIGCO can match accounting records from tunnel server with accounting records from ISP for auditing purposes RADIUS enables use of a single userID/password pair Both bridge/access point and tunnel server can authenticate against the same database RADIUS server backend LDAP backend

Why Are Shared Use APs Important?: 

Why Are Shared Use APs Important? Multiple providers are becoming the norm within airports Airlines are installing 802.11 networks for use in baggage reconciliation and roving ticket counters Multiple wireless ISPs often also want to server airport customers Radio interference is an issue In the US and Europe 802.11b networks can support only 3 non-overlapping channels In France and Japan only one channel is available Once the channels are utilized by existing APs, additional APs will interfere and reduce performance 802.11 deployment in public spaces is expensive In this economic environment, raising capital is difficult The cost of providing wireless access is inversely proportional to infrastructure utilization More economical to build infrastructure and share it among multiple providers, than to build overlapping infrastructure

What Features Are Needed for Shared Use APs?: 

What Features Are Needed for Shared Use APs? Support for multiple SSIDs in a single AP Multiple SSIDs in Beacon, Probe Response not prohibited by 802.11-1997 Only single SSID needed in Association and Reassociation Request IEEE 802.1X Users identified by userid rather than MAC address Network Access Identifier (NAI) support Described in RFC 2486 Format is user@domain, where domain identifies the home server SNMPv3 support Contexts used to support multiple virtual MIB instances RADIUS authentication and accounting SSID included in Called-Station-Id attribute RADIUS proxies RADIUS-based roaming described in RFC 2607 RADIUS authentication and accounting packets routed between AP and Home Server by RADIUS proxies

Shared Use APs: 

Shared Use APs Internet BIGCO IP Shared Use 802.11 AP Remote user Customer RADIUS Server SSIDA AP RADIUS RADIUS Active Directory AP advertises multiple SSIDs in Beacon, Probe Response Multiple ISPs shared the same AP STA associates with a single AP, SSID User authentication request routed to home server SSIDB SSIDC RADIUS Proxy RADIUS ISPA Proxy

What Is Wireless Roaming?: 

What Is Wireless Roaming? Definition The ability to use many wireless Internet Service Providers while maintaining a business relationship with only one Requirements 802.1X-enabled client with 802.11 wireless card Roaming-capable authentication proxy and server Roaming standards developed in IETF ROAMOPS WG RFC 2194, Roaming Implementations Review RFC 2477, Roaming Evaluation Criteria RFC 2486, Network Access Identifier RFC 2607, Proxies and Policy Implementation

Wireless Global Roaming via IEEE 802.11 and 802.1X: 

802.11 and 802.1X Enabled airports Wireless Global Roaming via IEEE 802.11 and 802.1X Simple, Automatic Detection of 802.11 Connectivity Global login with corporate or ISP userIDs 802.11 and 802.1X Enabled Hotels and Malls Global Access to 802.11 Wireless Connectivity

Wireless Roaming : 

Wireless Roaming In Windows 2000 Built-in IEEE 802.11 support Built-in “media sense” capabilities Built-in EAP support Internet Authentication Service Roaming-enabled RADIUS server Coming in XP 802.1X support A complete solution to the global wireless roaming problem

Bilateral Roaming support: 

Bilateral Roaming support

Roaming Consortia: 

Roaming Consortia

Certificate-Based Roaming: 

Certificate-Based Roaming ISP A RADIUS server can authenticate from the client certificate No need to proxy authentication ISP A needs to check Bigco’s certificate revocation list

Wholesale Wireless Access: 

Wholesale Wireless Access AP C AP B Public 802.11 Wireless Networks Internet BIGCO IP 802.11 Wireless Access Points Remote user Carrier networks Customer RADIUS Server ISP A RADIUS Proxy AP A RADIUS RADIUS Active Directory User sends authentication request to ISP ISP Delegates authentication to Corporation Single point of administration

Benefits of Wholesale accounts The ISP: 

Benefits of Wholesale accounts The ISP Increased sales Attach rate of consumer services Partner relations with enterprise Reduction in costs Simple administration, server mgmt. tools Improved collection and billing Reduced size of client store Compensation for client support burden Simplified account management Improved collections and cash flow Corporate clientele, automated pmt

Benefits of Wholesale accounts: The Enterprise: 

Benefits of Wholesale accounts: The Enterprise Ubiquitous 802.11 wireless support Enables rapid deployment of IEEE 802.11 technology in hotels, airports, malls Users can obtain wireless access using their existing corpnet accounts Simplicity Automatic detection of wireless connectivity via “media sense” Auto-detection of 802.11 SSID Pre-configure userID/password pairs if desired Easier to provide “backup” provider RADIUS accounting data for auditing and chargeback Reduced carrying costs Leverage ISP capacity and aggregation Shared support burden and ISP expertise Improved flexibility ISP capacity Validation off RADIUS, LDAP, or ODBC back ends

Security Issues in Wholesale Wireless Access: 

Security Issues in Wholesale Wireless Access RADIUS does not provide for inter-domain security No support for end-to-end message integrity or attribute hiding Proxy can add, delete, modify attributes in transit between client and server Proxy will have access to Tunnel passwords, and WEP keys in clear text Recommendation Use strong mutual authentication when untrusted proxies are present Check logs to detect unusual proxy activity

Seamless Mobility: 

Seamless Mobility Many applications can live with changing IP address as we move Example: HTTP But others cannot TCP-based protocols with long sessions: Telnet, FTP VPNs: IKE, SSH Mobile IPv6 will eventually provide the solution MIPv4 difficult to deploy But what can we do right now? Dynamic VLANs Tunneling

RADIUS Tunnel Attributes: 

RADIUS Tunnel Attributes Used in authorization only: Tunnel-Private-Group-Id Tunnel-Assignment-Id Tunnel-Preference Tunnel-Password Not for use with proxies! Used in authorization and accounting: Tunnel-Type (PPTP, L2TP,VLAN, etc.) Tunnel-Medium-Type (X.25, ATM, Frame Relay, IEEE 802, IP, etc.) Tunnel-Client-Endpoint Tunnel-Server-Endpoint Used for accounting only: Acct-Tunnel-Connection Documents RFC 2867 RFC 2868

Understanding Dynamic VLANs: 

Understanding Dynamic VLANs Alternative to Mobile IP: Allow mobile node to maintain same address as they move Prior to VLANs, only way to do this was via host routes For a large enterprise or ISP, large number of host routes is infeasible Issue is rate of change, not number of host routes, per se With VLANs, changes in topology are handled at layer 2, not layer 3 To a “one armed router” all mobile nodes within a VLAN appear on a single interface No need for host routes

Caveats with Dynamic VLANs: 

Caveats with Dynamic VLANs Applicable only at enterprise scale Not an Internet scale solution Goal is to tag packets of mobile nodes with a pre-existing VLANID No need to create new VLANs on the fly! Requires VLAN-enabled switches or APs, VLAN-enabled core “One-armed router” configuration Single interface, multiple VLANs per interface May require substantial change to network architecture Single spanning tree used for all VLANs Single spanning tree is most stable, because spanning tree recalculation not required due to VLAN topology changes Use of multiple spanning tree (802.1s) discouraged

Example: ISP Provisioning: 

Example: ISP Provisioning Ethernet WAN Connection Customer A Branch Office 1 Corporate Office RADIUS 802.1Q VLANID can be authorized via RADIUS tunnel attributes Enables customer virtual LANs to span branch offices Enables isolation of customer traffic by assigning separate VLANIDs to them Filters installed at ISP backend separating VLANs 1 & 2 Assigned VLAN ID 1 Customer A Branch Office 2 Assigned VLAN ID 1 Provisioning Server Customer B Assigned VLAN ID 2 EtherNAS Filter separating VLAN 1 & 2

Example: Seamless 802.11 Mobility: 

Example: Seamless 802.11 Mobility “One armed router” 802.1X Supplicant RADIUS Authentication Server VLAN-aware Switch or AP VLAN 2 VLAN 1 VLAN 1 VLAN enabled core


Tunneling Ethernet WAN Connection Customer Branch Office 1 Corporate Office RADIUS Compulsory tunnels can be authorized via RADIUS Enables isolation of customer traffic Can tunnel Ethernet via L2TP & BCP Can tunnel IP via IP-IP Traffic tunneled to ISP VPN server Customer Branch Office 2 Traffic tunneled to ISP VPN server Provisioning Server EtherNAS

VPNs and 802.11: 

VPNs and 802.11 Next generation APs will have powerful crypto acceleration capabilities built-in If a general AES engine is used, can support IPsec with AES transform as easily as 802.11 with AES Can be used to develop combined 802.11/VPN devices VPNs also useful as a layer of protection above IEEE 802 Want end-to-end security, not just link layer

VPNs for Access Control?: 

VPNs for Access Control? Some 802.11 deployments implemented as DMZ(s) Clients have to connect to VPN gateway to get access to Intranet Issues Gateway discovery Multiple DMZs required for global enterprise Clients need to discover VPN gateways before gaining access Implies need for services within the DMZ: DHCP, DNS Without DNSSEC, easy to bring up rogue VPN servers Security DES still “mandatory to implement” within IPsec IKE MM requires group pre-shared key when used with dynamically addressed clients – susceptible to man-in-the middle attack Rogue VPN servers can setup in DMZ, negotiate “CHAP” authentication, crack many user passwords

VPNs for Access Control (cont’d): 

VPNs for Access Control (cont’d) Mobility Need MIP support for IPsec SAs to withstand COA changes VPN clients susceptible to dropped connections Interoperability: Addressing IKE MM pre-shared key issues requires proprietary extensions (e.g. CRACK, Hybrid) Few vendors support IETF VPN standards (IPsec/DHCP, PIC, L2TP/IPsec) Conclusions VPN-based wireless access not ready for prime time Want at least authentication (and possibly not more) in 802.11

Automated Provisioning: 

Automated Provisioning The old way ISP or customer installs 56 Kbps CSU/DSU, router as customer CPE ISP orders 56 kbps link for customer from LEC Customer waits and waits and waits… Customer outgrows 56 Kbps link ISP or customer installs T-1 CSU/DSU, router as customer CPE… and the cycle starts again. The new way ISP provides fibre or cat-5 Ethernet connectivity to customer ISP or customer installs Ethernet switch or AP as customer CPE Customer provisions themselves via a web page “Pay per packet” bandwidth authorized on demand

802.1X-based Provisioning: 

802.1X-based Provisioning Ethernet WAN Connection Customer LAN Ethernet ISP 802.1p or DiffServ rate limiting Ethernet connectivity provided to customer Web server allows customers to self-provision Rate limiting enforced at ISP backend Contract can include specifications for limits on different classes of traffic Limits can be expressed in terms of 802.1p or DiffServ markings Provisioning Web server Customer sets provisioning via web browser Instant upgrade from 1.0 Mbps to 10 Mbps! RADIUS Server

Step by Step: 

Step by Step Customer provisions themselves on ISP Web server Customer indicates how much bandwidth is desired Average usage, peak utilization, burst levels, etc. Can specify utilization within various classes of traffic if desired Provisioning server translates web form into RADIUS attributes Rate limiting filters Virtual LAN or Virtual Private Network provisioning Per-connection IP filters or static routes New settings take effect after 802.1X re-authentication/re-authorization Re-authentication/re-authorization initiated after provisioning changes Instant provisioning!

Per-User Static Routes: 

Ethernet WAN Connection Per-User Static Routes Home Network or Branch Office subnet(s) Ethernet ISP RADIUS (per-user static routes) Data extension to user object Home addresses routable to ISP net Static addresses valid during connection 802.1X enabled Bridge 802.1X enabled Bridge

Per-Connection IP Filters: 

Per-Connection IP Filters Ethernet WAN Connection Customer LAN Ethernet ISP RADIUS (per-call IP filters) Filters associated with authenticated LAN policy Policy selected at connection time

Windows RADIUS Support: 

Windows RADIUS Support

Evolution of AAA Thinking: 

Evolution of AAA Thinking Early AAA efforts (non-standard) TACACS SNMP-based, syslog-based accounting Standardization phase RADIUS authentication RADIUS accounting (informational, not advanced) RADIUS proxy extensions Shared used networks Roaming Directory integration Unified user information store Security infrastructure Widespread deployment of AAA technologies in authenticated LANs, firewalls, VPNs, IP Telephony, etc. Increased interest in auditing and intrusion detection Enhanced AAA security (RADIUS over IPSEC) Futures Certificate based authentication and roaming Standard accounting session format Standards-track accounting protocol

Authenticated LANs and IAS: 

Authenticated LANs and IAS Internet Authentication Service (IAS) is a RADIUS server Originally shipped with NT 4.0 Option Pack Integrated with Windows 2000 Active Directory Integrated with User Object UI Support for IEEE 802.1X built-in EAP over Wireless (EAPOW) EAP over LAN (EAPOL) Support for sophisticated policies based on group, access medium, time of day, etc.

IAS Standards Support: 

IAS Standards Support Standards supported RFC 2619, 2621: RADIUS server MIBs RFC 2865: RADIUS authentication RFC 2865: RADIUS accounting RFC 2867-8: RADIUS tunneling RFC 2869: RADIUS extensions Interoperability Bakeoffs completed Tested with other NAS RADIUS clients APIs Advanced Authentication through EAP Extensible via “drop-in” third party EAP DLLs Enables Third party support for Token Cards, Smart Cards, Certificates

Network Port Authentication : 

Network Port Authentication

Network Port Authentication: 

Network Port Authentication

RADIUS Authorization: 

Access Point or Bridge IEEE 802.1X) Client Components RADIUS RADIUS Authorization

RADIUS Accounting: 


Accounting, Auditing, and Alarming: 

Accounting, Auditing, and Alarming Issues Accounting for port usage by user Billback of port usage to departments Auditing of ISP bills Alarming on unusual conditions Windows 2000 accounting support NT accounting (Eventlog) RADIUS accounting Accounting protocol choice independent of authentication choice Can use RADIUS accounting with NT authentication Accounting, auditing, and alarming tools TRU RADIUS Accountant from Telco Research, included in Windows 2000 Resource Kit

Active Directory Integration: 

Active Directory Integration Per-user information in User Object in DS Policies and Profiles Local policy stored on RAS/IAS server Stand-alone Server Per-user information in Local User Object Policies and Profiles stored in local server DB RAS & IAS share RADIUS Schema in Active Directory. RAS & IAS support new features of Active Directory Universal Groups Nested Groups Universal Names, and other user naming conventions

RFCs Supported: 

RFCs Supported RFC 1334, 1994 (PAP, CHAP) RFC 1717, 2125 (MP, BACP) RFC 1777, 1960, 2251 (LDAP) RFC 2865 (RADIUS authentication) RFC 2286 (RADIUS accounting) RFC 2284 (EAP) RFC 1035 (DNS) RFC 2205, 2208 (RSVP) RFC 2619,2621 (RADIUS server MIBs) RFC 2194, 2477, 2486, 2607 (Roaming) RFC 2401-2409 (IPSEC) RFC 2637 (PPTP) RFC 2661 (L2TP) RFC 2716 (EAP-TLS) RFC 2809 (L2TP tunneling with RADIUS) RFC 2867, 2868 (RADIUS tunneling extensions) RFC 2869 (RADIUS extensions) Draft-congdon-radius-8021x-16.txt

LAN Access Policies: 

LAN Access Policies Rules-based administration for LANs Examples: access by group membership unique rules for LAN access versus dial-in access Rules for wireless vs. wired LAN access time of day access restrictions 802.1p/Q policy implementation Complementary to ZAW/GPE ZAW deals with user attributes or client settings LAN Policies and Profiles are for server treatment of clients

LAN Access Policies (cont’d): 

LAN Access Policies (cont’d) Policy = {match rule, access control, profile} match rule: matches on set of connection properties (eg user group, media, time of day..) access control: allow or deny access profile: set of attributes assigned to the connection access constraints (macAddress, session length, time of day..) network controls (address policy, IP filters)

Extended per-user Info: 

Extended per-user Info MAC address verification LAN access control Static IP address assignment Static routes assignment

User Manager Snapin: 

User Manager Snapin

LAN Access Policies : 

LAN Access Policies

Work in Progress: 

Work in Progress Warning: The work described in the rest of this deck represents work in progress. It may or may not be reflected in final standards documents.

Improving WEP: 

Improving WEP

Classes of Attacks Against WEP v1.0: 

Classes of Attacks Against WEP v1.0 IV (key) reuse [Walker, Berkeley team, Arbaugh] Made possible by small IV space in WEPv1.0, lack of IV replay protection Enables statistical attack against ciphertexts w/replayed IVs Known plaintext attack [Walker, Berkeley team, Arbaugh] Lots of known plaintext in IP traffic: ICMP, ARP, TCP ACK, etc. Can send pings from Internet through AP to snooping attacker Enables recovery of key stream of length N for a given IV Can forge packets of size N by reusing IV in absence of a keyed MIC Partial known plaintext [Berkeley team, Arbaugh] May only know a portion of the plaintext (e.g. IP header) Possible to recover M octets of the keystream, M < N Via repeated probing, can extend keystream from M to N [Arbaugh] Possible to flip bits in realtime, adjust CRC32, divert traffic to attacker Enabled by linearity of CRC32, absence of keyed MIC

Classes of Attacks (cont’d): 

Classes of Attacks (cont’d) Authentication forging [Berkeley team] WEP v1.0 encrypts challenge using IV chosen by client Recovery of key stream for a given IV enables re-use of that IV for forging WEP v1.0 authentication Does not provide key, so can’t join LAN Denial of service Disassociate, reassociate messages not authenticated Dictionary attack Possible where WEP keys derived from passwords Realtime decryption [Berkeley team, Arbaugh] Repeated IV reuse, probing enables building of a dictionary of IVs, key streams Enables decryption of traffic in realtime Possible to store dictionary due to small IV space Need 1500 octets of key stream for each IV 2^24 * 1500 octets = 24 GB

Kerberos V Dictionary Attack Vulnerabilities: 

Kerberos V Dictionary Attack Vulnerabilities References Bellovin & Meritt “Limitations of the Kerberos authentication system”, USENIX 1991 Wu, T. “A Real-World Analysis of Kerberos Password Security”, 1998 Scenario Attacker snoops AS_REQ/AS_REP exchange, recovers passwords offline In popular 802.11 networks (“hot spots”), may be possible to collect many such exchanges in a single attempt Vulnerabilities PADATA or TGT encrypted with client Key derived from password via STRING-TO-KEY(P) Results [Wu, 1998] Password checkers not successful in significantly increasing password entropy Structure of TGT (service name = krbtgt) enables verification of key guess by decrypting only 14 octets; similar issues with PADATA Use of DES to encrypt TGT enables use of parallel DES cracking techniques Of 25,000 sample TGTs, 2045 could be decrypted in two weeks using a cluster of 3 UltraSPARC-2 (200 Mhz) and 5 UltraSPARC-1 (167 Mhz) machines Today, 15 off-the-shelf PCs could accomplish the same thing in 1 day at a cost of < $15K

Rapid Rekey Explained: 

Rapid Rekey Explained MAC-Layer Authenticated Key Refresh 3-way handshake between AP and STA Authenticates the refresh operation Ensures master keys are synchronized Key material is exchanged Increases master key entropy (lifetime) Uses HMAC-MD5 to authorize the exchange

Rekey every 10K frames (as recommended by Shamir): 

Rekey every 10K frames (as recommended by Shamir)

Rekey impact: 

Rekey impact *Based on 450byte packet size

MAC-Layer Authenticated Key Refresh: 

MAC-Layer Authenticated Key Refresh 1 Time required to transfer exchange packets over the air 2 Time required to perform Authenticated Key Refresh on 333MHz Pentium Pro, using HMAC-MD5 for authentication and AES-CBC-MAC for key derivation

Recommended Practice Improves WEP Security: 

Recommended Practice Improves WEP Security IV Sequence check protects from both intentional and unintentional IV reuse Protection from IV reuse makes it harder to mount attacks [Arbaugh], [Berkeley team] and [Shamir] Longer Key requires adversary to acquire more packets for key recovery (derived key, not master key) Authenticated Key Refresh provides a secure and synchronized mechanism for rekeying

Improvements to WEP Security (cont’d): 

Improvements to WEP Security (cont’d) Frequent rekeying makes it harder to recover (derived) encryption key. Even if key is cracked, it’s only the temporal encryption key vs. master MAC-Layer Rekeying allows for faster refresh Implementation is backward compatible. All improvements are additions on top of current WEP implementations.

On the Flip side…..: 

On the Flip side….. Recommended Practice does not address Bit-flipping attacks: a keyed MIC is required Active attacks But IV sequencing protects from Shared keys Provide more data for passive attacks Rekeying could be adapted for shared keys

Alternatives Considered: 

Alternatives Considered Removing first 256 bytes of RC4 key stream Not backward compatible Still requires IV Sequencing and Keyed MIC Must be treated as separate encryption to old RC4 Prepending N pseudorandom bytes to plaintext data Not backward compatible Unclear what a sufficient N should be Increases per packet overhead Still requires IV Sequencing and Keyed MIC Must be treated as separate encryption to old RC4

Alternatives Discussed (cont’d): 

Alternatives Discussed (cont’d) Using Beacon as a means to synchronize new key Only addresses shared key Rekeying is not authenticated (i.e. insecure) Constrained to rekey only on Beacon intervals Using a Longer IV Worsens security  it reduces the number of frames required to recover key!

Security Analysis: 

Security Analysis

Secure Remote Password Authentication for 802.11: 

Secure Remote Password Authentication for 802.11

What is Secure Remote Password?: 

What is Secure Remote Password? An abstract protocol specification Creator: Thomas Wu, Stanford University RFC 2945 (Proposed Standard) An EAP method Draft-ietf-pppext-eap-srp-03.txt Standardized within PPPEXT Author: James Carlson (Sun Microsystems), Henry Haverinen, Bernard Aboba A GSS-API method Draft-ietf-cat-srpgm-02.txt (expired) A key derivation mechanism for TLS Draft-ietf-tls-srp-01.txt Standardized within TLS WG Author: D. Taylor (Forge Research) A set of SASL mechanisms Draft-burdis-cat-srp-sasl-04.txt Individual submission Authors: K.R. Burdis (Rhodes University), R. Naffah (Forge Research) A submission to IEEE P1363 See

Pros and Cons of SRP: 

Pros and Cons of SRP Pros Support for mutual authentication and key derivation No changes required to IEEE 802.1X, EAP (RFC 2284) Uses password-only credentials (no client or server certificates) Thought to be invulnerable to dictionary attack on the on-the-wire protocol Does not require password to be stored either in cleartext or reversibly encrypted Intellectual property statement filed by Stanford University Cons Computationally intensive 2 MODEXP calculations on each side (assuming verifier is cached) Only 1 exponentiation required for EKE Limited flexibility No support for ECC groups, only DH groups Requires storage of new per-user credentials Username, Salt, Password verifier, prime modulus/generator group Vulnerable to offline dictionary attack against credential store

How can SRP be used by 802.11?: 

How can SRP be used by 802.11? As an EAP method EAP SRP (draft-ietf-pppext-eap-srp-03.txt) Simplest way to obtain SRP functionality As a Kerberos Extension or GSS-API mechanism EAP GSS (draft-aboba-pppext-eapgss-04.txt) Wu proposal for SRP integration within Kerberos: SRP GSS-API mechanism:Draft-ietf-cat-srpgm-02.txt SRP negotiated via SPNEGO within EAP-GSS As a TLS mechanism SRP negotiated within TLS (draft-ietf-tls-srp-01.txt) Compatible with future upgrade to EAP-TLS with certificates (RFC 2716) Requires major change to TLS implementations Differences Overhead More overhead for layered negotiations Protected authentication negotiation Supported within GSS-API (SPNEGO), TLS Not supported within pure EAP approach (handled via policy)

How Does it Work? (From RFC 2945): 

How Does it Work? (From RFC 2945) The server stores user credentials as 5-tuples of the form: {<username>, <password verifier>, <salt>, g, N} <salt> = random() x = SHA(<salt> | SHA(<username> | ":" | <raw password>)) <password verifier> = v = g^x % N N = prime modulus; g = generator Prime modulus/generator/salt are constant each time a given user authenticates If they could vary, server would need to pre-calculate multiple verifiers, one for each salt/prime modulus/generator combination Client and server calculate and exchange public keys Server public key derived from the password verifier DH exchange used to derive a key Client and server exchange hashes based on the DH key, verifier, group, salt, username, etc. Authenticates the DH exchange

Protocol Exchange: 

Protocol Exchange Client Server -------- ------ U = <username> -> <- salt a = random() A = g^a % N -> v = <stored verifier> b = random() <- B = (v + g^b) % N p = <raw password> x = SHA(s | SHA(U | ":" | p)) S = (B - g^x) ^ (a + u * x) % N S = (A * v^u) ^ b % N K = SHA_Interleave(S) K = SHA_Interleave(S) M = H(H(N) XOR H(g) | H(U) | s | A | B | K)-> (CLIENT AUTH) <- H(A | M | K) (SERVER AUTH)

“Short Form” Exchange: 

“Short Form” Exchange Client Server -------- ------ U, A -> <-s, B H(H(N) XOR H(g) | H(U) | s | A | B | K)-> <-H(A | M | K) Usable where client initiates (e.g. GSS_API, TLS) Not usable where server initiates (EAP)

What Does SRP Not Provide?: 

What Does SRP Not Provide? Specification of bits on the wire RFC 2945 is an abstract protocol specification – need to adapt it for a particular use Specification for how additional keys are derived from SRP key (K) Bad idea to use K on the wire (master key would become stale) Need to describe how to derive IVs, authentication, encryption keys of appropriate lengths in each direction from SRP master key (K) Protected ciphersuite negotiation Needed to guard against “down negotiation” attacks

How does EAP SRP Work?: 

How does EAP SRP Work? EAP SRP is a reasonably faithful implementation of RFC 2945 as an EAP method Additional features Server can provide its identity Derived key can be used in ECP or not Support for lightweight, periodic reauthentications Support for hidden pseudonyms for identity protection Bugs/gripes Prime modulus/generator should be specified as groups, not numbers Current spec analogous to IKE “new group mode” Difficult for client to verify validity of the offered group, will probably just compare the offered group against a “known good” list Best to just assign group numbers to “known good” groups Example: groups listed in SRP-SASL draft with prime modulus >= 1024 bits

SRP References: 

SRP References T. Wu, "The SRP Authentication and Key Exchange System,“ RFC 2945, 09/2000 T. Wu, "The Secure Remote Password Protocol", in Proceedings of the 1998 Internet Society Symposium on Network and Distributed Systems Security, San Diego, CA, pp. 97-111 EAP SRP

SRP Summary: 

SRP Summary SRP attractive for password-based authentication Thought to be invulnerable to dictionary attack Does not require storing password in clear or reversibly encrypted Intellectual property filings available for inspection IETF standardization process underway RFC 2945 at Proposed Standard SRP-TLS, EAP SRP drafts on Standards Track Several ways to use SRP Can be negotiated within TLS, EAP, GSS-API Recommendation SRP worthy of consideration as mandatory-to-implement method for 802.11 Tgi Simplest to use SRP as a straight EAP mechanism Other secure password-schemes may also be worth examining (EKE, etc.) if intellectual property issues can be resolved

Fast Handoff: 

Fast Handoff

802.11: Implications for Fast Handoff: 

802.11: Implications for Fast Handoff Classic 802.11 authentication occurs before reassociation Enables a STA to pre-authenticate with the new AP prior to reassociation Management frames are not authenticated Association-Request/Response, Reassociation-Request/Response, Disassociation notification are unauthenticated Enables an attacker to forge these and other management frames, take over sessions Inter-Access Point communication typically not necessary If all APs use the same key, new AP can validate the STA authentication without contacting the old AP. Ability for STAs to quickly reassociate between access points STA sends Disassociate to old AP after it receives Reassociation-Response from new AP New AP install STA state in DS after receiving an ACK of the Reassociation-Response from STA No cryptographic operations in the critical path


State 1 Unauthenticated, Unassociated State 2 Authenticated, Unassociated State 3 Authenticated, and Associated Successful MAC layer Authentication Successful Association or Reassociation Disassociation Notification DeAuthentication Notification Deauthentication notification Class 1 Frames Class 1 & 2 Frames Class 1, 2 & 3 Frames Classic 802.11 State Machine

802.11 Fast Handoff: 

802.11 Fast Handoff STA APold APnew Associate-Request Associate-Response ACK DS Notified Reassociate-Request Reassociate-Response ACK DS Notified Disassociate Note: Authentication not on critical path, so not included Transition Period ~ OTTSTA-AP


State 1 Unauthenticated, Unassociated State 2 Authenticated, Unassociated State 3 Authenticated, and Associated Successful MAC layer Authentication Successful Association or Reassociation Disassociation Notification DeAuthentication Notification Deauthentication notification Class 1 Frames + ESN Class 2 frames Class 1 & 2 Frames Class 1, 2 & 3 Frames 802.11i State Machine State 4 ESN Associated ESN Association or Reassociation ESN Disassociation Notification Successful upper layer Authentication Class 1, 2 & 3 Frames except Authentication & Deauthentication

802.11i: Implications for Fast Handoff: 

802.11i: Implications for Fast Handoff With 802.1X, upper layer authentication occurs after ESN association/reassociation 802.1X state machine is driven by association/reassociation events AP can only be associated with a single STA; since 802.1X authentication occurs after reassociation, an ESN STA can only authenticate to a single ESN AP Full reauthentication to each AP a significant cost 802.1X authentication may involve multiple round-trips, public key operations Environments with many mobile stations can heavily load the backend authentication server Desirable to avoid a full reauthentication at every AP Need to lock all doors left open by classic 802.11 802.11i adds dynamic keying (802.1X), credible ciphersuite (AES), but… Need to address other 802.11 security holes such as unauthenticated management frames Cryptographic operations now in the critical path for Fast Handoff ESN reassociated STA cannot access the controlled port of the ESN AP until upper layer authentication completes Authentication of Reassociation-Request/Response, Disassociation required to prevent hijacking


Questions Should authentication occur before or after reassociation? How do we authenticate management frames? This presentation addresses Reassociation-Request/Response, and Disassociation Notification frames Future work will address authentication of other Management Frames Association-Request/Response, Beacon, Probe-Request/Response, Deauthentication, ATIM


Alternatives Authentication before reassociation Pros Enables pre-authentication Authentication no longer in the critical path for reassociation Cons If you authenticate management frames, cryptographic operations remain in the critical path (since you need to authenticate the Reassociation Request/Response) If you’re already authenticating reassociation request/response, why do more than “canned” authentication in addition? Reassociation before Authentication Pros Simplicity: authenticate Reassociation-Request/Response, Disassociation, AP issues “canned success” in upper layer authentication if authentication is successful at MAC layer Minimizes cryptographic operations in the critical path for reassociation Cons No pre-authentication

Proposed Approach: 

Proposed Approach Authentication of Reassociate, Disassociate frames Authenticator Information Element added to Reassociation-Request/Response, Disassociation notification frames Authenticator Information Element enables STA and new AP to provide possession of the unicast authentication session key negotiated with the old access point. Support within the Inter-Access Point Protocol (IAPP) New AP passes the Authenticator IE to the with old AP in the Inter-Access Point Protocol (IAPP) Move-Request Old AP validates the Authenticator If successfully validated, old AP sends IAPP Move-Response to new AP Otherwise, old AP silently discards IAPP Move-Request New AP will not send Reassociation-Response STA Reassociation-Request will time out STA, AP will re-authenticate Appropriate 802.11f MIB variable is incremented 802.1X “canned success” sent from AP to STA if Authenticator IE included within the Reassociation-Request is valid.

802.11i Fast Handoff: 

802.11i Fast Handoff STA APold APnew Associate-Request Associate-Response ACK DS Notified Reassociate-Request (Authenticated) Reassociate-Response (Authenticated) ACK DS Notified Disassociate (Authenticated) Transition Period ~ RTTSTA-AP 802.1X/Identity Request EAP-Success 802.1X/Identity Response EAP-Request EAP-Response Transition Period ~ nRTTSTA-AP n =3.5 (TLS), 2.5 (TLS continuation)

authorStream Live Help