Light Weight Access Point Protocol (LWAPP)
description
Transcript of Light Weight Access Point Protocol (LWAPP)
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