The Unofficial 802.11 Security Web Page

Last update: May 29, 2005

Lots of people are interested in wireless LAN security nowadays. Given that level of interest, there's a need for accurate information on how the current standards work, what's wrong with them, and the current thinking on how to fix the problems. This page tries to gather relevant papers and standards in a single place.

Trends and overview

Ethernet Everywhere

Ethernet is on the verge of becoming the preferred technology for LAN (wired and wireless), SAN, MAN and WAN.  Increasing in speed by an order of magnitude every 3 years, "Ethernet Everywhere" could be to the next decade what "IP everywhere" was to the 1990s.

IEEE 802.1X "network Port Authentication" was designed to scale with Ethernet, adding no per-packet overhead, and bringing the management technology of dialup networks to the wired and wireless LAN worlds. Here are presentations on the current trends in Ethernet network access, both wired and wireless, and an introduction to IEEE 802.1X and its applications.

Ethernet Everywhere!
Wireless World 2001 and BAWUG Presentations on IEEE 802.1X  

Thinking about network access authentication

Here's a presentation on how we do authentication for network access and why this is most often handled at layer 2 (PPP, IEEE 802.1X) rather than at layer 1 (802.11) or at layer 3 (Mobile IP) or higher.

BURP BOF presentation at IETF 50

IEEE 802.11

Here is where you can download 802.11 standards: IEEE 802.11 specifications

WEP security issues

You've read all about the security problems with WEP.  Here are the papers and presentations that lay out the problem.

War Driving Tools
A summary presentation on WEP security issues  (from 802.11 Tgi)
Berkeley WEP Security Analysis Presentation (PDF)
Bill Arbaugh's paper on cracking WEP (PDF)
Fluhrer, Mantin and Shamir's paper on cracking WEP
Jesse Walker's "Unsafe at any key length" paper
Possible ways of improving WEP (near impossible)

Wireless LAN performance

Recently, there has been interest in wireless LAN performance. This includes work on MAC performance and capacity analysis, as well as interactions with TCP. Here are some presentations and papers on the subject:

PHY performance

Link-level Measurements from an 802.11b Mesh Network  (Slides)
Link Adaptation Strategy for IEEE 802.11 WLAN via Received Signal Strength Measurement
Measurements of a Wireless Link in an Industrial Environment
A Short Look at Power Save in 802.11
Characterizing Errors in Wireless LAN
802.11 Measurements Project

MAC  performance

802.11 Traffic Characterization
Performance in an Ad-hoc Environment
Atheros White Paper on 802.11 performance
Performance Anomaly of 802.11b (Powerpoint)
Performance Anomaly of 802.11b (PDF)
Resolving 802.11 Performance Anomaly
Capacity analysis of 802.11
802.11 performance in a multi-hop network

Transport layer performance

Presentation on Transport use of Layer 2 triggers by Sally Floyd (For IETF 55 TRIGTRAN BOF)
Performance evaluation of TCP over 802.11
Performance of Reliable Transport Protocols over 802.11

IEEE 802.11 handoff

A number of elements contribute to 802.11 handoff delay including:

As shown by a recent University of Maryland paper, in an "open" network, Probe/Beacon delay is responsible for the majority of the measured delay. However, where Layer 2 authentication is used, authentication delay can also be substantial.

Experimental Studies

802.11 security performance
Analysis of Roaming Techinques (Submission to IEEE 802.11r, work in progress)
Roaming intervals measurement (Submission to IEEE 802.11r, work in progress)
An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process  
Improving the Latency of the Probe Phase during IEEE 802.11 Handoff
Techniques to Reduce IEEE 802.11b MAC Layer Handover Time
An Experimental Study of IEEE 802.11b handover performance and its effect on voice traffic
Measurements of 802.11i 4-way handshake latency (Submission to IEEE 802.11i, work in progress)

Proposals for Improvement

Fixing AP Selection
Roaming Candidates
Thinking about the Neighbor Report (Submission to IEEE 802.11k, work in progress)
The Neighbor Report (Submission to IEEE 802.11k, work in progress)
An Inter-Access Point Handoff Mechanism for Wireless Network Management: The Sabino System
Fast Active Scan for Measurement and Handoff
SyncScan: Practical Fast Handoff for 802.11 Infrastructure Networks
SyncScan slides

Lightweight Access Points

Protocols for communication between lightweight Access Points and WLAN switches are being standardized in the IETF CAPWAP WG. Here are some pointers:

CAPWAP WG mailing list archives
CAPWAP Architecture Taxonomy
CAPWAP Objectives
LWAPP Protocol (IETF Draft, Work in Progress)
Security Analysis of LWAPP

Inter-Access Point Protocol (IAPP)

Inter-Access Point Protocol (IAPP) is being standardized by IEEE 802.11F as well as the IETF SEAMOBY WG.  IAPP  enables seamless, authenticated fast handoff between 802.11 Access Points.  Here are some pointers:

IEEE 802.11F
IEEE 802.11 context transfer
Fast Inter-AP Handoff Using Predictive Authentication Scheme in a Public Wireless LAN
Proposal for pre-emptive handoff support in IAPP (from University of Maryland)
SEAMOBY Candidate Access Router Discovery protocol (IETF Draft, work in progress)
SEAMOBY Context Transfer Protocol (IETF Draft, work in progress)
Some suggested additions to the IEEE 802.11F MIB

Wi-fi Protected Access (WPA)

The WiFi Alliance (WFA) is now certifying an interim draft of the 802.11 security specification, known as Wi-fi Protected Access (WPA).  There are also pre-WPA implementations in the market, some of which have known vulnerabilities.  Here are the details of the WPA specification and the known security vulnerabilities:

WPA

Details on WPA can be found here:

WPA Web Site (includes links to the specification)
Microsoft WPA Support
NDIS WLAN Objects

WPA Security Vulnerabilities

Details of WPA security vulnerabilities can be found here:

Issues with Pre-WPA implementations
Michael Attacks and Countermeasures
PSK-mode dictionary attack vulnerability
Weaknesses in the WPA Temporal Key Hash

    IEEE 802.11i   

The IEEE 802.11i standard was approved in July, 2004. Here are pointers to the specification and its vulnerabilities:

IEEE 802.11i specification (Approved as an IEEE 802.11 Standard)
IEEE 802.11i Overview
NIST Security Workshop

IEEE 802.11i Security Vulnerabilities

Details of IEEE 802.11i security vulnerabilities can be found here:

One Message Attack on the 4-way Handshake
Analysis of the 4-way Handshake (Paper)
Summary of Security Issues

Extensible Authentication Protocol (EAP)

EAP is the IETF standard for extensible authentication in network access. It is standardized for use within PPP (RFC 2284), wired IEEE 802 networks (IEEE 802.1X), and VPNs (L2TP/IPsec and PIC). Here are pointers to information on the EAP protocol:

EAP  (Proposed Standard, RFC 3748)
EAP Issues List
EAP state machine (IETF draft, work in progress)
EAP WG mailing list archives
How to develop an EAP method for Windows

EAP Key Management

EAP methods provide keying material.  Here are the documents describing EAP key management.

EAP  Key Management Framework (IETF draft, work in progress)
EAP Key Management Extensions (IETF draft, work in progress)
MPPE Key Derivation (Informational, RFC3079)

EAP methods

Security requirements

Since EAP is extensible there are lots of proposals for authentication methods that work with it. Only some of these methods meet the requirements for use in wireless authentication;  others have known security vulnerabilities. Here are the security requirements for EAP methods as laid out by IEEE 802.11i:

EAP method requirements (Informational, RFC 4017)

Here are some of the proposed EAP methods:

Certificate authentication

EAP-TLS (Experimental, RFC 2716)

Token card/smartcard authentication

RSA SecurID Token Card (IETF draft, work in progress)
Smartcard EAP Method (IETF draft, work in progress)

Password authentication

PEAPv2 (IETF draft, work in progress)  ; used with: EAP MS-CHAP-v2 (IETF draft, work in progress)
EAP-FAST (IETF draft, work in progress)
TLS Session Resumption for EAP-FAST (IETF draft, work in progress)
EAP-SRP (IETF draft, work in progress)
Presentation on EAP SRP

Pre-shared keys

EAP Archie (IETF draft, work in progress)
Presentation on EAP Archie
EAP-PSK (IETF draft, work in progress)
EAP-PAX (IETF draft, work in progress)

Security vulnerabilities in EAP methods

Here is a summary of the known security vulnerabilities of implemented or proposed EAP methods.

Kerberos vulnerability

Kerberos is vulnerable to dictionary attacks.  Here are the details on the vulnerability:

EAP-GSS (IETF draft, work in progress)
IAKERB (used with EAP GSS, IETF draft, work in progress)
Thomas Wu's security analysis of Kerberos (why using Kerberos for wireless authentication isn't a good idea)

LEAP vulnerability

Cisco's LEAP protocol is also vulnerable to dictionary attacks, and several LEAP cracking tools are now available. Here are the details on the vulnerability and cracking tools:

ASLEAP cracking tool
THC LEAP cracking tool
ANWRAP LEAP cracking tool
Cisco Security Advisory on default username/password vulnerability
Cisco LEAP specification
Cisco Tech Note on LEAP Dictionary Attack Vulnerabilities
Computerworld story
Defcon 11 Presentation on LEAP cracking
Light-Reading Presentation on LEAP cracking
Security analysis of MS-CHAPv1
Security analysis of MS-CHAPv2

EAP-SIM vulnerability

The security weaknesses in GSM/GPRS are well known. Recently there have been proposals for reuse of GSM (SIM) and 3G (AKA) security mechanisms in WLAN. Here are pointers to the specifications and papers describing how GSM/GPRS security can be cracked in real time. The attacks can be used against EAP-SIM where a single SIM is used for both WLAN and WWAN authentication:

EAP-SIM Specification (IETF draft, work in progress)
Security Analysis of EAP SIM
Instant Ciphertext-only Cryptanalysis of GSM Encrypted Communication
Other GSM security analyses
EAP AKA (IETF draft, work in progress) 
3GPP security (AKA)

PAP vulnerability

Authentication protocols supporting cleartext authentication using RADIUS (even within a protected tunnel) are vulnerable to known plaintext attacks.  IETF protocols vulnerable to this attack include:

IKEv2
EAP TTLS (IETF draft, work in progress)

Here are the details of the vulnerability:

PAP security vulnerability

Man-in-the-Middle Attacks on Tunneled Authentication Protocols

It has recently been discovered that a number of protocols proposed within the IETF are vulnerable to man-in-the-middle attacks.  IETF protocols vulnerable to the attack include:

HTTP digest over TLS
XAUTH within IKE
PIC
PANA over TLS
EAP TTLS (IETF draft, work in progress)
Microsoft Windows XP SP1 PEAPv0 Implemention
Cisco PEAPv1 Implementation (IETF draft, work in progress).

Details of the attacks are described in these papers:

The Compound Authentication Binding Problem (IETF draft, work in progress)
Man-in-the-Middle Attacks in Tunneled Authentication Protocols (Nokia Research Center)
What's Wrong with PIC? (Presentation to IETF 55 Credentials Workshop)

IEEE 802.1X "Network Port Authentication"

IEEE 802.1X is an IEEE standard (approved, June 2001) that enables authentication and key management for IEEE 802 Local Area Networks, including Ethernet, Token Ring, and FDDI.  Since the IEEE 802.11 Task Group I security work had only just gotten underway at the time that the IEEE 802.1X standard was approved, 802.1X does not describe how the 802.1X and 802.11 state machines are to be coupled. That task was left to IEEE 802.11 Task Group I.

Since IEEE 802.1X is not a cipher, it is not an alternative to WEP, 3DES, AES, or any other cipher.  Since IEEE 802.1X is only focused on authentication and key management, it does not specify how or when security services are to be delivered using the derived keys. However, it can be used to derive authentication and encryption keys for use with any cipher, and can also be used to periodically refresh keys and re-authenticate so as to make sure that the keying material is "fresh".

IEEE 802.1X is not a single authentication method; rather it utilizes Extensible Authentication Protocol (EAP) as its authentication framework. This means that 802.1X-enabled switches and access points can support a wide variety of authentication methods, including certificate-based authentication, smartcards, token cards, one-time passwords, etc. However, the 802.1X specification itself does not specify or mandate any authentication methods. Since switches and access points act as a "pass through" for EAP, new authentication methods can be added without the need to upgrade the switch or access point, by adding software on the host and backend authentication server.

Since IEEE 802.1X doesn't involve encapsulation (unlike PPPOE or VPN) it adds no per-packet overhead and can be implemented on existing switches and access points with no performance impact. This means that IEEE 802.1X can scale from speeds of 11 Mbps (802.11) to 10+ Gbps, and can be enabled on  existing switches with a firmware upgrade, without the need to buy new hardware. On hosts, since IEEE 802.1X can be implemented in the NIC driver, support can be enabled by obtaining updating drivers from the NIC vendor; there is no need to install a new operating system.

IEEE 802.1X integrates well with open standards for authentication, authorization and accounting (including RADIUS and LDAP) and so it fits in well with existing infrastructure for managing dialup networks and VPNs.  RADIUS servers (including Windows 2000 IAS) that support EAP can be used to manage IEEE 802.1X-based network access.

These specifications describe how IEEE 802.1X works, and how it can be managed via RADIUS and SNMP.  Through RADIUS, IEEE 802.1X permits management of authorization on a per-user basis. Per-user services include filtering (layer 2 or layer 3), tunneling, dynamic VLANs, rate limits, etc.


IEEE 802.1X-2004 (Approved as an IEEE 802.1 Standard)
IEEE 802.1X-2004 MIB
IEEE 802.1X-2001 MIB (IEEE 802 Standard)
IEEE 802.1X-2001 (IEEE 802 Standard)
Some thoughts on diagnosing problems via the 802.1X MIB
IEEE 802/802.1X Architecture Issues (Draft, work in progress)

802.1X Implementations

Open 802.1X
WIRE1X

IETF/IEEE 802 Liaison

IEEE 802 and IETF communicate regularly relating to IETF dependencies of IEEE 802 working groups. Here is some information relating to the liaison relationship:

IEEE 802/IETF Relationship History
IEEE 802 Archive Access for IETF WGs
Status of IEEE 802.11i/IETF Liaison (for the NIST 802.11 Security Workshop)
IEEE 802.11 Liaison letter No. 1
IEEE 802.11 Liaison letter No. 2
Erik Nordmark's response to Liaison letter No. 2
IEEE 802.11 Draft Liaison letter No. 3 (not sent)
IEEE 802.11/IETF Liason Status Report (March 2003)
IEEE 802.11/IETF Liaison Status Report (May 2003)
IEEE 802.11/IETF Liaison Status Report (September 2003)
IEEE 802 request for feedback on IEEE 802.21 PAR (October 2003)
IEEE 802.11/IETF Liaison Status Report (January 2004)
IEEE 802/IETF Liaison Meeting Summary (January 2004)
IEEE 802.1/IETF Liaison Meeting Summary (January 2004)
IEEE 802.11/IETF Liaison Meeting Summary (January 2004)
IEEE 802.11/IETF Liaison Status Report (May 2004)
IEEE 802.11/IETF Liaison Status Report (July 2004)
IEEE 802.11/IETF Liaison Status Report (November 2004)
IEEE 802.11/IETF Liaison Status Report (January 2005)
IEEE 802.11/IETF Liaison Status Report (March 2005)
IEEE 802.11/IETF Liaison Status Report (May 2005)
3GPP liaison request to IEEE 802.11 on RADIUS/Diameter Coexistence (September 2003)
IEEE 802.11 Response to 3GPP liaison request on RADIUS/Diameter Coexistence (September 2003)
IEEE 802.11 Liaison letter No. 4 (February 2004)
GSMA Request to IETF relating to RADIUS WLAN Support
WFA Request to IETF relating to RADIUS WLAN Support
IEEE 802.11 Liaison Letter relating to Network Discovery
Input to IETF from IEEE 802.11 WIEN (September 2004)
Input to IETF from IEEE 802.11 WIEN (November 2004)
Liaison to IETF from IEEE 802.11 and IEEE 802.21 (May 2005)
Liaison to IETF from IEEE 802.16 (April 2005)
April 2005 Liaison Report
Minutes of the April 8, 2005 Liaison Conference Call
Liaison to IETF from IEEE 802.16 (May 2005)

Remote Access Dialin User Service (RADIUS)

RADIUS is a widely deployed protocol for network access authentication, authorization and accounting (AAA). There are many problems with it, including issues with security and transport, yet it is likely that RADIUS will continue to be widely used for many years to come.  Why? RADIUS is simple, efficient and easy to implement -- making it possible for RADIUS to fit into the most inexpensive embedded devices.

The issues with transport are most relevant for accounting, in situations where services are billed according to usage.  In these situations packet loss = revenue loss! RADIUS runs on UDP, with no defined retransmission or accounting record retension policy, and does not support application-layer acknowledgments or error messages (like "I'm busy, come back later" or "No disk space left"). This makes RADIUS accounting unreliable for usage-based billing services, particularly in inter-domain usage (such as roaming) where there can be substantial packet loss.

As a result, usage-based billing is often done with SNMP today.  Although SNMP runs over UDP (a TCP transport mapping has been developed but is not deployed yet), the retry policy and polling interval can be configured on the management station, so that you are not at the mercy of the RADIUS retransmission and retension policy of a particular NAS vendor.  To enable SNMP-based accounting for 802.11, as well as RADIUS accounting, we designed the IEEE 802.1X MIB to provide all the information available in RADIUS accounting within the MIB tables.  The situation is better for RADIUS authentication and authorization, because if packet loss prevents users from being authenticated, they will typically try to get on again soon afterwards.

In terms of security, RADIUS includes its own application-layer integrity protection and authentication, as well as confidentiality for "hidden attributes".  In RFC 2865, RADIUS Access Requests need not be authenticated and integrity protected; the situation was improved somewhat in RFC 2869, which requires that all messages involved in an EAP conversation include authentication and integrity protection via the Message-Authenticator attribute. As noted in the RADIUS security analysis, RADIUS security is particularly poor when dealing with cleartext passsword authentication (PAP). RFC 2865 requires that the RADIUS Response Authenticator be globally and temporally unique, since the stream cipher that RADIUS uses to encrypt User-Password is based on the Response Authenticator, and thus if it were to repeat, the keystream would be compromised. Unfortunately, not all implementations do a good job of ensuring that the Response Authenticator is not repeated.

Since the RADIUS Response Authenticator and Message-Authenticator attributes are both vulnerable to dictionary attack, it's a good idea to make sure your RADIUS shared secret has sufficient entropy and is not the same for multiple NASen. However, in real-life simple shared secrets shared with many NASen (or even all of them!) are common, and so this is probably the most serious RADIUS security vulnerability.

In terms of solutions, the best thing to do is to turn off PAP support on the NAS; that way the User-Password attribute will never be sent. Fortunately, EAP does not support PAP, and so RADIUS usage with IEEE 802.1X is not vulnerable to this particular class of attack.  If possible, it is a good idea to use authentication methods that offer protection against an offline dictionary attack. These include EAP TLS (RFC 2716), EAP SRP and PEAP (both still under development), but not EAP GSS with Kerberos V, EAP MD5 or Cisco LEAP.

If the NAS can support IPsec, then the best thing to do is foresake RADIUS application-layer security entirely and just run RADIUS over IPsec ESP with a non-null transform. This is described in RFC 3162.  Unfortunately, many embedded systems do not have the horsepower or headroom to run IPsec, so RADIUS/IPsec is not widely  used today.

Microsoft RADIUS Attributes (Informational, RFC 2548)
RADIUS authentication (Proposed Standard, RFC 2865)
IETF RADIUS WG Archives
RADIUS accounting (Informational, RFC 2866)
RADIUS tunneling accounting attributes (Informational, RFC 2867)
RADIUS tunneling authentication attributes (Informational, RFC 2868)
RADIUS Extensions (Informational, RFC 2869)
RADIUS for IPv6 (Proposed Standard, RFC 3162)
RADIUS IANA Considerations (Proposed Standard, RFC 3575)
RADIUS Dynamic Authorization (Informational, RFC 3576)
RADIUS/EAP (Informational, RFC 3579)
Using RADIUS with IEEE 802.1X (Informational, RFC 3580)
Additional RADIUS attributes for IEEE 802.1X (IETF draft, work in progress)
RADIUS security analysis
Dictionary Attack Vulnerability
A presentation on RADIUS security (IEEE 802.11i submission, discusses potential solutions)
Introduction to Accounting Management (Informational, RFC 2975, discusses issues with RADIUS accounting)
Network access requirements (Informational, RFC 2989, What a AAA protocol really needs to do)
AAA protocol evaluation (Informational, RFC 3127, How RADIUS fares against the requirements)
AAA Transport Specification (Proposed Standard, RFC 3539)

Handoff and Roaming

According to usage within GSM and IETF, "handoff" is movement of a mobile node between Access Points.  "Roaming" is the movement of a mobile node between networks.  This section provides references to documents on handoff and roaming.

Handoff and IEEE 802.1X

Here are some papers relating to handoff in IEEE 802.1X-enabled networks:

Proactive Key Distribution using Neighbor Graphs
Context Caching using Neighor Graphs
Proactive Key Distribution to Support Secure Roaming (submission to IEEE 802.11 Tgi)
RADIUS handoff extension (IRTF draft, work in progress)
802.1X pre-authentication and 802.11 (submission to IEEE 802.11 Tgi, Word document)
802.1X pre-authentication and 802.11 (submission to IEEE 802.11 Tgi, Powerpoint)
Pre-Authenticated Fast Handoff in a Wireless LAN Based on IEEE 802.1X Model
A presentation on authenticating 802.11 management frames
Fast Handoff Issues (IEEE 802.11i draft, work in progress)
PMK Plumbing for fast roaming
PMK Caching
PMK Naming

Routing Metrics

Here are some papers relating to link-aware routing metrics:

Comparison of Routing Metrics for Static Multi-Hop Wireless Networks
SrcRR: A High Throughput Routing Protocol for 802.11 Mesh Networks
Architecture and Evaluation of the MIT Roofnet Mesh Network
Effects of Loss Rate on Adhc Wireless Routing
A Radio Aware Routing Protocol for Wireless Mesh Networks
A High Throughput Path Metric for Multi-Hop Wireless Routing

Inter-media Handoff

Here are some papers relating to handoff between media:

A Generalized Model for Link Layer Triggers (Submission to IEEE 802.21, work in progress)
Interactions of IEEE 802.21 and Upper Layers (Submission to IEEE 802.21, work in progress)
Trouble with Triggers (Presentation at IETF 56 ALIAS BOF, work in progress)
Architectural Implications of Link Indications (IETF draft, work in progress)

Detection of Network Attachment

At layer 3, support for either handoff or roaming requires that mobile nodes efficiently detect network attachment. IEEE 802.11 does not support network attachment detection very well, and so this is trickier than it might seem at first glance. Here are some links describing the problem:

Detection of Network Attachment (DNA) Mailing List
DNAv4 Issues Website
Optimistic DAD (IETF draft, work in progress)
Detection of Network Attachment for IPv6 (IETF draft BCP, work in progress)
Review of current movement detection schemes for IPv6
Detection of Network Attachment for IPv4 (IETF draft, work in progress)
Detection of Network Attachment and IEEE 802.11 (IEEE 802 Handoff ECSG Presentation, work in progress)

Inter-Provider Roaming

You've probably heard a lot about the "WHISPR" specification, which is being developed within WECA. Here are the references to open standards which describe how to do roaming and fast handoff within 802.11.

Roaming, defined as the ability to connect to multiple ISPs while maintaining an account with only one, was tackled by the IETF ROAMOPS WG starting in 1996 and solutions based on this architecture are now widely deployed.  Since IEEE 802.1X is based on EAP, it is compatible with the ROAMOPS architecture as well as with existing RADIUS servers supporting RFC 2869 encapsulation of EAP in RADIUS.

One of the keys to roaming economics within 802.11 is enabling "shared use" APs.  Shared use infrastructure has been widely deployed in dialup network access, allowing multiple ISPs to share the same points of presence. Enabling APs to be shared by multiple wireless ISPs offers to improve efficiency and improve the utilization of deployed APs. Shared use APs are particularly important for wireless because not only does it cost more to deploy multiple APs in the same location, but the limited radio channels in 802.11 makes radio interference a potential problem.

In order to keep the same IP address while roaming, there are approaches at layer 2 as well as layer 3. Mobile IP is the layer 3 approach. Of the layer 2 approaches, one is dynamic VLANs. Another is tunneling. Both are enabled by RADIUS tunneling attributes.

Roaming implementations survey (Informational, RFC 2194)
Roaming architecture and requirements (Informational, RFC 2477)
The Network Access Identifier (Proposed Standard, RFC 2486)
RADIUS Proxies, Policy and Roaming (Informational, RFC 2607)
Accounting record formats (Informational, RFC 2924)
Introduction to Accounting Management (Informational, RFC 2975)
Best Practices for WISP Roaming (WFA)
RFC 2486bis (IETF Draft, work in progress)
Network Selection Problem Statement (IETF Draft, work in progress)
Network Discovery Proposal (IETF Draft, work in progress)

Virtual Access Points

Supporting roaming on a wide scale requires an AP to support more than one SSID.  Here are some papers describing how this can be done:

Virtual APs (IEEE 802.11i draft, work in progress)
Virtual APs (Presentation to WFA)
Virtual AP Definition

Miscellaneous Topics

VPN Standards and Security Analyses

You've probably heard "experts" say that  "VPN is the answer to WEP security problems." Well, it isn't that simple -- because the next question is "whose VPN?" Almost all IPsec tunnel mode products shipping today are proprietary,  interoperability is poor and many of the proprietary extensions have security flaws. Here are the references to the security analyses of VPN protocols as well as to the IETF standards for VPN.  Ask your vendors when they plan to implement the IETF standards!

Security analysis of PPTPv2
Security analysis of PPTP
Microsoft point of view on PPTP
Security analysis of XAUTH (shipping in most IPsec tunnel mode implementations)
Man-in-the-middle attacks against IPsec VPNs (also SSH, HTTPS, etc.)
Configuration of IPsec tunnel mode with DHCPv4 (Proposed Standard, RFC 3456)
Securing L2TP with IPsec ( Proposed Standard, RFC 3193)
Legacy authentication within IPsec tunnel  mode (PIC) (IETF draft, work in progress)
IPsec-NAT compatibility requirements (Informational, RFC 3715)

Credential provisioning

Recently, there has been a lot of interest in the application of certificates to WLAN authentication. Here are some presentations and papers on the subject:

IETF 55 Enrollment Workshop
Certificate-based roaming (IETF draft, now expired)
Certificate hierarchy for the WLAN industry (presentation to IEEE 802.11 Tgi)
WLAN certificate extensions (Proposed Standard, RFC 3770)
Why Certificate OIDs are needed
PEAPOD proposal for EAP-based enrollment

Multihoming Issues

The IETF is now looking at a number of new solutions to the problems of mobility, multi-homing and security.  Here are some pointers:

Choices for multi-addressing (IETF Draft, work in progress)
Multiple Address Service for Transport (MAST) (IETF Draft, work in progress)
Multihoming using 64-bit crypto-based IDs (IETF Draft, work in progress)
Multihoming without IP identifiers (IETF Draft, work in progress)
End-host Mobility and Multi-Homing with HIP (IETF Draft, work in progress)
HIP architecture (IETF Draft, work in progress)
HIP Specification (IETF Draft, work in progress)
Homeless Mobile IPv6 (IETF Draft, work in progress)

Adhoc networking

802.11 enables "adhoc" networking, which is communication between stations without an Access Point. This mode has enormous potential, most of which is not being realized. Recent IETF work in progress enables hosts to automatically assign IPv4 addresses without a DHCP server, and resolve names without a DNS server (IPv4 or IPv6). There is also IEEE work in progress that addresses the "hidden node problem" -- not all 802.11 stations in an adhoc network can communicate with each other, because they might be out of range!

To knit the stations together into a coherent network, they can either act as bridges (layer 2 approach) or routers (layer 3 approach, MANET). The issue with bridging has been convergence times -- 802.11D spanning tree doesn't converge fast enough to be viable in an adhoc network where hosts are constantly moving, associating and disassociating with each other.  IEEE work in progress on "rapid spanning tree convergence" promises to change that.  This could enable adhoc networks with dozens or even hundreds of users that could stretch over a substantial geographic distance.  Here are some pointers:

Stealth Attacks on Adhoc Networks
IPv4 linklocal addressing (Proposed Standard, RFC 3927)
IPv6 linklocal addressing (Proposed Standard, RFC 2462)
Link Local Multicast Name Resolution (LLMNR), (IETF draft, work in progress)
LLMNR Issues List
DHCP Domain Search option (Proposed Standard, RFC 3397)

Bridging and Routing protocols

IEEE 802.1 standards