Light Weight Access Point Protocol (LWAPP) Pat R. Calhoun Bob O’Hara Rohit Suri Nancy Cam Winget Scott Kelly Michael Williams Sue 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: ( –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 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 i, and how to handle handoffs in conjunction with i to avoid vulnerabilities Makes use of NIST approved cryptographic algorithms only

Basic LWAPP Architecture AC WTP STA AssocReq Data Frame AssocReq LWAPP (C=0) Data Frame LWAPP (C=0) AssocResp AssocResp LWAPP (C=0)

Advantages of using frames The design goal behind LWAPP was to allow for extensions to be added with minimal (if any) protocol changes. Minimize lag time between IEEE 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) Override Configuration By default, WTP uses AC configuration, but can have its own override configuration for APs that require different configuration from the norm (e.g, corner of building AP requires only left antenna to be enabled). Global Configuration

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 MACEncryption at WTPMandatory to implement for Split MAC Split MACEncryption in ACOptional Local MACEncryption at WTPMandatory to implement Small number of modes of operation Provides 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 e EDCA Parameter in the WTP –Enforcement of e at the WTP –Configuration of e/802.1P/DSCP table mapping

Objectives Comparison Feature Compliance Rating Logical Groups S Support for Traffic Separation S Wireless Terminal Transparency S Configuration Consistency S Firmware Trigger S Monitoring and Exchange of System-wide Resource State S Resource Control Objective S CAPWAP Protocol Security S System-wide Security S IEEE i Considerations S Interoperability Objective S Protocol Specifications S Vendor Independence S Vendor Flexibility S Multiple Authentication Mechanisms S Support for Future Wireless Technologies S Support for New IEEE Requirements S Interconnection Objective S Access Control S Support for Non-CAPWAP WTPs S Technical Specifications S AP Fast Handoff S

Questions?

Backup

LWAPP Packet Formats LWAPP Header: |VER| RID |C|F|L| Frag ID | Length | | Status/WLANs | Payload... | Control Packets (C=1): | Message Type | Seq Num | Msg Element Length | | Session ID | | Msg Element [0..N] | Data Packets (C=0): | RSSI | SNR | Frame : Status Field Payload

Revised LWAPP State Machine / \ | v | | C| Idle | | | / | ^ |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 Confirmation Phase

Unified Key Exchange Join-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 *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 engine SK1R 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