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)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 WTP STA 802.11 AssocReq 802.11 Data Frame 802.11 AssocReq LWAPP (C=0) 802.11 Data Frame LWAPP (C=0) 802.11 AssocResp 802.11 AssocResp LWAPP (C=0)

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

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

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... +---------------------------------------------------------------+: Status Field Payload

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

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

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

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