Light Weight Access Point Protocol (LWAPP)

Pat R. CalhounBob O’HaraRohit Suri

Nancy Cam WingetScott Kelly

Michael WilliamsSue Hares

draft-ohara-capwap-lwapp-03.txt

Introduction

• LWAPP is a candidate protocol for CAPWAP that supports both Split and Local MAC approaches

• The protocol specification is mature and complete– Products have been shipping for well over 2 years– LWAPP specs have been available through individual

contributions for well over 18 months– Many comments have been received (both technical

and editorial), which have been included in the specification.

Introduction (cont.)

• LWAPP Version 03 was submitted to the IETF• This document comprises of many changes:

– Addresses all comments and issues identified in Charles Clancy’s security review: (http://www.cs.umd.edu/~clancy/docs/lwapp-review.pdf)

– Addresses all non-conforming objectives listed in LWAPP self evaluation version 00

– Complete text for Local MAC support was added• Although initially supported, normative text was missing

– Support for IPv6– Added significant amount of behavioral text to aid in

interoperability• e.g., BSSID/SSID Mapping recommendation

Why use 802.11 Frames?

• An AC can perform its task better if it has complete information– e.g., BSSID enforcement at the AC

• Signal strength allows AC to make access policy decisions based on RF information

• Also useful for Local MAC– Proxy MAC allows WTP to make access

control decisions, while providing visibility to the AC

Addressing Security Review Comments

• We worked directly with Charles in addressing identified issues, ensuring the solution was technically (and cryptographically) sound, including:– Simplified the state machine to provide key confirmation for all

security mechanisms supported– Mutual Derivation of LWAPP Session Keys and Initialization

Vector– Unified Key Exchange protocol for both X.509 (asymmetric) and

pre-shared key (symmetric) security modes– Included an X.509 certificate profile to ease interoperability (and

eliminate man-in-the-middle attacks)– Text describing the use of 802.11i, and how to handle handoffs

in conjunction with 802.11i to avoid vulnerabilities• Makes use of NIST approved cryptographic algorithms

only

Basic LWAPP Architecture

AC

WTP

STA

802.11AssocReq

802.11Data Frame

802.11AssocReq

LWAPP(C=0)

802.11Data Frame

LWAPP(C=0)

802.11AssocResp

802.11AssocResp

LWAPP(C=0)

Advantages of using 802.11 frames

• The design goal behind LWAPP was to allow for 802.11 extensions to be added with minimal (if any) protocol changes.

• Minimize lag time between IEEE 802.11 extension publication and ability to deliver CAPWAP based solutions

• LWAPP is also efficient on AP processor as it only requires tunneling– Local MAC requires additional processing on AP to

provide Proxy MAC

LWAPP Configuration Mgmt

AC

WTP

Config Request(Override Configuration)

(SSID=foobar, RSN, WMM)

Config Update(Configuration)

(e.g., External Antenna)

OverrideConfiguration

By default, WTP uses AC configuration, but can have its own override configurationfor APs that require different configuration from the norm (e.g, corner of building AP

requires only left antenna to be enabled).

GlobalConfiguration

Advantages of Configuration Mgmt

• Allows for centralized (global AC) configuration policies to be enforced

• Allows for localized configuration override for specific WTPs

• Allows for WTP to provide localized configuration to one of many ACs, without a need for a global WTP configuration database

• No complex configuration versioning problem

Modes of Operation

Split MAC Encryption at WTP Mandatory to implement for Split MAC

Split MAC Encryption in AC Optional

Local MAC Encryption at WTP Mandatory to implement

Small number of modes of operationProvides sufficient flexibility

Mandatory to implement modes guarantee interoperability

Quality of Service

• The LWAPP Spec contains complete QoS handling, including:– Marking of tunneled packets between AC and

WTP– Configuration of 802.11e EDCA Parameter in

the WTP– Enforcement of 802.11e at the WTP– Configuration of 802.11e/802.1P/DSCP table

mapping

Objectives ComparisonFeature Compliance Rating

Logical Groups SSupport for Traffic Separation SWireless Terminal Transparency SConfiguration Consistency SFirmware Trigger SMonitoring and Exchange of System-wide Resource State SResource Control Objective SCAPWAP Protocol Security SSystem-wide Security SIEEE 802.11i Considerations SInteroperability Objective SProtocol Specifications SVendor Independence SVendor Flexibility SMultiple Authentication Mechanisms SSupport for Future Wireless Technologies SSupport for New IEEE Requirements SInterconnection Objective SAccess Control SSupport for Non-CAPWAP WTPs STechnical Specifications SAP Fast Handoff S

Questions?

Backup

LWAPP Packet FormatsLWAPP Header: 0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |C|F|L| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status/WLANs | Payload... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Control Packets (C=1): 0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Type | Seq Num | Msg Element Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Element [0..N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Packets (C=0): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------------------------------------------------------+ | RSSI | SNR | 802.11 Frame... +---------------------------------------------------------------+:

Status Field Payload

Payload

Revised LWAPP State Machine /------------\

| v | +------------+ | C| Idle |<-----------------------------------\ | +------------+<-----------------------\ | | ^ |a ^ | | | | | \----\ | | | | | | w +------------+ | | | | | /----------| Key Confirm| | | | | | | +------------+ | | | | | | ^ | | | | |t v | 5 | | | | +-----------+ +------------+ | | / | C| Run | u | Key Update | | | / | r+-----------+------>+------------+ | | / | ^ |s x| | | | v | | | | | | +--------------+ | | v |y | | C| Discovery | q| \--------------->+-------+ | | b+--------------+ +-------------+ | Reset | | | |d f| ^ | Configure |------->+-------+ | | | | | +-------------+p ^ | |e v | | ^ | | +---------+ v |i 2| | | C| Sulking | +------------+ +--------------+ | | +---------+ C| Join |--->| Join-Confirm | | | g+------------+z +--------------+ | | |h m| 3| |4 | | | | | v |o |\ | | | +------------+ \\-----------------/ \--------+---->| Image Data |C \------------------------------------/ +------------+n

Key ConfirmationPhase

Unified Key ExchangeJoin-Req(SID, XNonce, WTP-Cert)

Join-Resp(SID, RSA-E(wtp-Kpub, XNonce XOR ANonce), AC-Cert)

Join-Ack(AES(RK0E, WNonce), AES-CMAC(SK1M, Join-Ack))

Join-Confirm(AES-CMAC(SK1M, Join-Confirm))

*SK1=KDF(WNonce || ANonce, string || SID || WTP-MAC || AC-MAC) SK1E (Encryption Key), SK1M (MIC’ing Key), SK1R (Rekey Key), IV

RK0=KDF(psk, string || SID || WTP-MAC || AC-MAC) RK0E (Encryption Key), RK0M(MIC’ing Key)

First frame uses IV from AC, SK1E plumbed into crypto engine

Join-Resp(SID, AES(RK0E, XNonce XOR ANonce), AES-CMAC(RK0M, Join-Resp))

PSK:

CERT:

Join-Ack(RSA-E(ac-Kpub, WNonce), AES-CMAC(SK1M, Join-Ack))*WTP generates K1

*WTP generates K1

*AC generates K1

Proposed ReKey Exchange

Rekey-Req(new-SID, XNonce)

Rekey-Ack(AES(RK0E, WNonce), AES-CMAC(SK2M, Join-Ack))

Rekey-Confirm(AES-CMAC(SK2M, Join-Confirm))

RK0=KDF(SK1R, string || SID || WTP-MAC || AC-MAC) RK0E (Encryption Key), RK0M(MIC’ing Key)

SK2E & new IV plumbed into crypto engineSK1R replaced with SK2R

Rekey-Resp(new-SID, AES(RK0E, XNonce XOR ANonce), AES-CMAC(RK0M, Join-Resp))

*WTP generates K2

*AC generates K2

*SK2=KDF(WNonce || ANonce, string || SID || WTP-MAC || AC-MAC) SK2E (Encryption Key), SK2M (MIC’ing Key), SK2R (Rekey Key), IV

X.509 Certificate Profile

• Latest LWAPP specification includes an X.509 certificate profile to facilitate interoperability

• The X.509 profile defines a field that indicates a device’s CAPWAP role (AC or WTP)

• Embedding the role eliminates the possibility for man-in-the-middle attacks