Light Weight Access Point Protocol (LWAPP)

1. 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

2. 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.

3. 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

4. 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

5. 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

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

7. 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

8. LWAPP Configuration Mgmt Global Configuration AC Config Request (Override Configuration) (SSID=foobar, RSN, WMM) Config Update (Configuration) (e.g., External Antenna) Override Configuration WTP 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).

9. 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

10. Modes of Operation Small number of modes of operation Provides sufficient flexibility Mandatory to implement modes guarantee interoperability

11. 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

12. 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 802.11i 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

13. Questions?

14. Backup

15. LWAPP Packet Formats LWAPP 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... +---------------------------------------------------------------+: Payload Payload Status Field

16. Revised LWAPP State Machine /------------\ | v | +------------+ | C| Idle |<-----------------------------------\ | +------------+<-----------------------\ | | ^ |a ^ | | | | | \----\ | | | | | | w +------------+ | | | | | /----------| Key Confirm| | | | | | | +------------+ | | | | | | ^ | | | | |t v | 5 | | | | +-----------+ +------------+ | | / | C| Run | u | Key Update | | | / | r+-----------+------>+------------+ | | / | ^ |sx| | | | v | | | | | | +--------------+ | | v |y | | C| Discovery | q| \--------------->+-------+ | | b+--------------+ +-------------+ | Reset | | | |df| ^ | Configure |------->+-------+ | | | | | +-------------+p ^ | |e v | | ^ | | +---------+ v |i2| | | C| Sulking | +------------+ +--------------+ | | +---------+ C| Join |--->| Join-Confirm | | | g+------------+z +--------------+ | | |hm| 3| |4 | | | | | v |o |\ | | | +------------+ \\-----------------/ \--------+---->| Image Data |C \------------------------------------/ +------------+n Key Confirmation Phase

17. Unified Key Exchange Join-Req(SID, XNonce, WTP-Cert) CERT: Join-Resp(SID, RSA-E(wtp-Kpub, XNonce XOR ANonce), AC-Cert) *WTP generates K1 Join-Ack(RSA-E(ac-Kpub, WNonce), AES-CMAC(SK1M, Join-Ack)) PSK: RK0=KDF(psk, string || SID || WTP-MAC || AC-MAC) RK0E (Encryption Key), RK0M(MIC’ing Key) Join-Resp(SID, AES(RK0E, XNonce XOR ANonce), AES-CMAC(RK0M, Join-Resp)) *WTP generates K1 Join-Ack(AES(RK0E, WNonce), AES-CMAC(SK1M, Join-Ack)) *AC generates K1 Join-Confirm(AES-CMAC(SK1M, Join-Confirm)) First frame uses IV from AC, SK1E plumbed into crypto engine *SK1=KDF(WNonce || ANonce, string || SID || WTP-MAC || AC-MAC) SK1E (Encryption Key), SK1M (MIC’ing Key), SK1R (Rekey Key), IV

18. Proposed ReKey Exchange RK0=KDF(SK1R, string || SID || WTP-MAC || AC-MAC) RK0E (Encryption Key), RK0M(MIC’ing Key) Rekey-Req(new-SID, XNonce) Rekey-Resp(new-SID, AES(RK0E, XNonce XOR ANonce), AES-CMAC(RK0M, Join-Resp)) *WTP generates K2 Rekey-Ack(AES(RK0E, WNonce), AES-CMAC(SK2M, Join-Ack)) *AC generates K2 Rekey-Confirm(AES-CMAC(SK2M, Join-Confirm)) SK2E & new IV plumbed into crypto engine SK1R replaced with SK2R *SK2=KDF(WNonce || ANonce, string || SID || WTP-MAC || AC-MAC) SK2E (Encryption Key), SK2M (MIC’ing Key), SK2R (Rekey Key), IV

19. 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