Security Review of the Light-Weight Access Point Protocol draft-ohara-capwap-lwapp-02

Security Review of the Light-Weight Access Point Protocol

draft-ohara-capwap-lwapp-02

T.Charles Clancy

clancy@https://www.wendangku.net/doc/5d19118591.html,

Laboratory for Telecommunication Sciences Department of Computer Science Department of Defense?University of Maryland,College Park

May12,2005

Abstract

This document introduces the LWAPP protocol and provides an analysis of its security fea-tures.In particular,the public-key authentication,preshared-key authentication,and packet-level

encryption are examined.Also,the security rami?cations introduced by the IEEE802.11binding

are https://www.wendangku.net/doc/5d19118591.html,stly,recommendations on changes the the protocol are presented.

Overall,LWAPP is“secure”.However,given access to the wired network,there are opportunities for denial of service attacks against the public-key authentication algorithm.None of the attacks

presented in this document result in the compromise of keying material for active sessions,or the

ability to steal service.

1Introduction

The Light-Weight Access Point Protocol(LWAPP)[1]o?ers a solution to the Control and Provisioning of Wireless Access Points(CAPWAP)problem[2].Traditional access points are replaced by Wireless Termination Points(WTP)that essentially act as thin access points(APs).A collection of WTPs are governed by an Access Controller(AC).LWAPP de?nes the protocol between WTPs and ACs.

LWAPP includes three areas related to security.The?rst is its authentication protocol between a WTP and an AC.Both a public-key mode and a preshared-key mode are supported.Section2 discusses these protocols in more detail and provides a security evaluation.The next area is packet level encryption,which is accomplished using AES-CCM,described in section3.The LWAPP draft de?nes an802.11[4]binding,which is the third area.The interaction between LWAPP and802.11 security is discussed in https://www.wendangku.net/doc/5d19118591.html,stly,section5provides recommendations to increase LWAPP’s overall security.

?The opinions expressed in this document are solely those of the author,and do not represent a formal evaluation or endorsement by the Department of Defense or US Federal Government.

2Authentication

LWAPP de?nes two authentication protocols.The?rst is a public-key approach where the WTP and AC each have a certi?cate signed by a trusted certi?cate authority.These certi?cates are used to perform authentication and key distribution.The second is a preshared-key approach where a shared key is used to derive various authentication and session keys,which are subsequently validated.

In the next sections,the following notation will be used:

?CERT X:Certi?cate of party X,containing P UB/X

?E K(Z):Encryption of message Z with key K

?KDF K(Z):PRNG keyed with K using entropy Z used for key generation

?MAC X:L2MAC address of party X

?MIC K(Z):Message Integrity Code generated over message Z with key K

?N X:Nonce generated by X

?not(Z):Boolean NOT of binary value Z

?P UB/X:Public key of party X

?P RV/X:Private key of party X

?P SK:Preshared Key between the WTP and AC

?S K(Z):Digital signature of message Z with key K

?SID:Session ID,randomly generated by the WTP

Each protocol will be evaluated in the following areas:mutual authentication,replay protection, key derivation,and session independence.

2.1Public-Key Authentication

LWAPP public-key authentication can be abstracted as the following algorithm.

WTP AC

W

?CERT A,E P UB/W(K)

S P RV/A(SID,E P UB/W(K))

encryption key=K

The WTP selects a random SID and sends it along with its certi?cate to the AC.After validation, the server replies with its own certi?cate,a session key encrypted with the WTPs public key,and a signature validating the message came from the server.

The LWAPP draft claims this protocol achieves mutual authentication;however,it only achieves implicit mutual authentication.The WTP is never explicitly authenticated by the https://www.wendangku.net/doc/5d19118591.html,ck of explicit mutual authentication can lead to several types of denial of service attacks.One example of an overloading DoS is where many spoofed clients could all simultaneously authenticate,overloading an AC.Another DoS attack involves a single client authenticating using an already-authenticated WTP certi?cate.This spoofed authentication session creates new session keys that the real WTP does not know,rendering it unable to communicate with the AC.

With only one round trip,replay protection is not possible.Obviously the?rst packet of any conversation can be replayed,however it is typically validated later by a packet that cannot be replayed. This replay problem is what facilitates the DoS attacks described above.Also,the AC is only weakly authenticated.The Join-Response can be replayed if an earlier transaction used the same SID.Since the SID is only32bits long,this space is fairly small from a cryptographic standpoint.

With respect to key derivation,the protocol uses entropy from only the AC and pushs the key to the WTP.This could lead to attacks if the AC’s random number generator is compromised.

The LWAPP draft says that the WTP must validate the AC certi?cate,however the validation requirements should be more speci?c.In particular,there is nothing to prevent a second compromised WTP with a valid certi?cate from impersonating an AC.Certi?cates used by ACs should have an extended key usage?eld authorizing them for use as LWAPP ACs,or WTPs should have some other mechanism for authorizing ACs.

2.2Preshared-Key Authentication

The preshared-key mode of authentication for LWAPP works by validating the successful decryption of various nonces encrypted with keys derived from the original PSK.Upon completion,both parties have independently derived a joint session key.The algorithm is described below.

WTP AC

P SK W A

SID,E J1(N W)?

{J1,J2}=KDF P SK(SID,MAC W,MAC A)

{K,L}=KDF J2(N W,N A,MAC W,MAC A)

M=E J1(not(N W),N A)

?M,MIC L(M)

{K,L}=KDF J2(N W,N A,MAC W,MAC A)

E J1(N W),MIC L(E J1(N W))?

?SID,MIC L(SID)

encryption key=K

With respect to the evaluation criteria,the PSK authentication protocol satis?es them all.Mutual authentication is achieved by validation of the PSK-MIC?elds in the?nal acknowledgement messages. Replay attacks are only possible on the?rst Join-Request packet,however without knowledge of the PSK,an attacker cannot forge the second Join-Request.Neither of the Join-Responses are replayable. This technique derives strong keys and provides session independence.It does not provide forward secrecy,but that is not a protocol requirement.

3Packet-Level Encryption

Control packets in LWAPP are encrypted using AES-CCM with an IV seeded by the Session ID(SID) used in the initial authentication.The IV is not included in the packets,but rather each participant keeps a counter indicating the current IV.

This approach to the IV could lead to desynchronization attacks if there are any?aws in the WTP or AC state machines.Yet,this approach is good in that it doesn’t allow either party to easily select their IV.However,note that since the client has complete control over the Session ID selection,it allows the client to consequently have control over the IV space.

4IEEE802.11Binding

The LWAPP802.11binding supports both standard802.11WEP for privacy and authentication, along with the more recent amendment802.11i[5]and RSN security.

First it should be noted that any network employing WEP(in conjunction with LWAPP or not)is insecure,due to the various insecurities of WEP[3].Consequently this evaluation will only examine using LWAPP in conjunction with802.11i RSN.

The biggest area of concern the hando?process.During an authentication,either EAP or a preshared-key is used to compute the pairwise master key(PMK).This key is then used in the802.11 four-way handshake to derive session keys.In LWAPP this conversation happens between the wireless client and the AC.When a client roams from one WTP to another,LWAPP sends the link-layer encryption keys derived during the initial four-way handshake to the new WTP in the Add-Mobile request.

Without additional requirements on implementation state machines,there are two potential attacks here.The?rst is a denial of service attack where a client simply spoofs the association frames for an already authenticated client.If improperly implemented,the AC could send a Delete-Mobile request to the WTP to which the valid client is connected and Add-Mobile requests to the WTP to which the spoofed client is connected.The valid client loses connectivity.This is more serious than other L2 802.11denial of service attacks because it can be carried out against any WTP.

The second attack involves a compromised WTP.Session keys should only be live between a client and a WTP.When a client roams to a new WTP it should have new packet-level encryption keys. However,in LWAPP draft does not specify that keys must be rederived.1

5Recommendations

The public-key protocol as-is is practically secure,but not cryptographically secure.It will prevent unauthorized clients from easily gaining access to the network;however,it is susceptible to various denial of service and replay attacks.The preshared-key protocol as-is is cryptographically secure.

To follow are alterations to LWAPP to enhance security.Changes that are recommended will prevent attacks currently mountable against LWAPP.Changes that are suggested will help prevent future attacks if the cryptographic primitives employed by LWAPP are weakened.

1It should be noted that these attacks are not possible in the current Cisco LWAPP implementation,as hando?s are authenticated and rekeys occur upon roaming.These issues should,however,be addressed in the LWAPP draft.

At a minimum,it is recommended that the following changes be made to the LWAPP public-key authentication protocol:

?Add an additional round-trip to perform explicit key validation.

?Increase the size of the SID to128bits to prevent replay attacks,or add an additional nonce.

?Require AC certi?cates to contain an extended key usage authorizing them to provide AC ser-vices.

The following changes are suggested to the packet-level encryption:

?Secure derivation of the initialization vector,at least by the AC,but preferably by both the AC and WTP.

Additionally,the following suggested changes to the public-key protocol serve to mitigate future at-tacks:

?Perform key derivation based on exchanged entropy,rather than having the AC push a key to the WTP.

The following suggested changes to the802.11binding will increase overall security when LWAPP is used in conjunction with IEEE802.11:

?Normatively RECOMMEND that LWAPP not be used with802.11WEP.

?Add text stating that hando?s must be authenticated,for example by requiring a successful 802.11rekey before moving a session from one WTP to another.

In conclusion,this security evaluation was conducted from a protocol perspective,assuming the security of the underlying cryptographic primatives.If the security of any of the employed primitives are severely weakened,then the protocol security of LWAPP will need to be reevaluated. References

[1]P.Calhoun,B.O’Hara,S.Kelly,R.Suri,M.Williams,S.Hares,and N.Cam Winget,Light weight

access point protocol,Internet Draft,I-D.ohara-capwap-lwapp-02,2005.

[2]B.O’Hara,P.Calhoun,and J.Kempf,Con?guration and provisioning for wireless access points

(CAPWAP)problem statement,RFC3990,2005.

[3]N.Petroni and W.Arbaugh,The dangers of mitigating security design?aws:A wireless case

study,January2003.

[4]IEEE Computer Society,Wireless LAN medium access control and physical layer speci?cations,

IEEE Standard802.11,1999.

[5],Wireless LAN medium access control and physical layer speci?cations amendment6:

Medium access control security enhancements,IEEE Standard802.11i,2004.