Network Working Group S. Kelly Internet-Draft Airespace Expires: February 19, 2004 D. Molnar Legra Systems August 21, 2003 Security Requirements for a Light Weight Access Point Protocol draft-kelly-ietf-lwapp-sec-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 19, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract LWAPP defines the interactions of wireless lan infrastructure components, including access points (APs) and access routers (ARs). The AR represents a centralized point of management control in such infrastructures, implying critical control signalling between APs and ARs. Given the open nature of WLANs, a careful analysis of security threats is required, and appropriate security countermeasures must be defined. This document provides a security analysis and makes recommendations for securing LWAPP Kelly & Molnar Expires February 19, 2004 [Page 1] Internet-Draft LWAPP Security Requirements August 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 2. LWAPP Architecture and Topology . . . . . . . . . . . . . 4 3. WLAN Security Termination . . . . . . . . . . . . . . . . 4 4. WLAN Security Architecture Naming Convention . . . . . . . 5 5. Topological Assumptions . . . . . . . . . . . . . . . . . 5 5.1 Directly Connected . . . . . . . . . . . . . . . . . . . . 6 5.2 Switched Connections . . . . . . . . . . . . . . . . . . . 7 5.3 Routed Connections . . . . . . . . . . . . . . . . . . . . 8 6. Capabilities of Adversary . . . . . . . . . . . . . . . . 10 6.1 Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 10 6.2 Packet Modification . . . . . . . . . . . . . . . . . . . 10 6.2.1 Packet Injection . . . . . . . . . . . . . . . . . . . . . 10 6.2.2 Packet Deletion . . . . . . . . . . . . . . . . . . . . . 10 6.2.3 Packet Reordering . . . . . . . . . . . . . . . . . . . . 10 6.2.4 Packet Redirection . . . . . . . . . . . . . . . . . . . . 10 6.2.5 Packet Reflection . . . . . . . . . . . . . . . . . . . . 10 6.2.6 Session Replay . . . . . . . . . . . . . . . . . . . . . . 11 6.3 Address Spoofing . . . . . . . . . . . . . . . . . . . . . 11 6.4 MiM Attack . . . . . . . . . . . . . . . . . . . . . . . . 11 6.5 Password Guessing/Dictionary Attacks . . . . . . . . . . . 11 6.6 Corruption of Auxiliary Network Services . . . . . . . . . 11 6.6.1 DCHP Takeover . . . . . . . . . . . . . . . . . . . . . . 11 6.6.2 DNS Takeover . . . . . . . . . . . . . . . . . . . . . . . 11 7. Adversary Goals . . . . . . . . . . . . . . . . . . . . . 11 7.1 Associate Unauthorized AP with Legitimate AR . . . . . . . 12 7.2 Associate Unauthorized AR with Legitimate AP . . . . . . . 12 7.3 De-associate authorized AP and AR . . . . . . . . . . . . 12 7.4 DoS attacks . . . . . . . . . . . . . . . . . . . . . . . 12 7.5 Eavesdropping on AP Control Data . . . . . . . . . . . . . 12 7.6 Modification of AP Control Data . . . . . . . . . . . . . 12 7.7 Eavesdropping on AR Control Data . . . . . . . . . . . . . 12 7.8 Modification of AR Control Data . . . . . . . . . . . . . 13 8. Adversary Scenarios . . . . . . . . . . . . . . . . . . . 13 8.1 Rogue AP . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.2 Rogue AR . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.3 AP Takeover . . . . . . . . . . . . . . . . . . . . . . . 13 8.4 AR Takeover . . . . . . . . . . . . . . . . . . . . . . . 13 8.5 Passive Adversary between AR and AP . . . . . . . . . . . 13 8.6 Active Adversary between AR and AP . . . . . . . . . . . . 14 9. Countermeasures . . . . . . . . . . . . . . . . . . . . . 14 9.1 Secure Association . . . . . . . . . . . . . . . . . . . . 14 9.2 Authentication . . . . . . . . . . . . . . . . . . . . . . 14 9.3 Secure Discovery . . . . . . . . . . . . . . . . . . . . . 15 9.4 Integrity Verification . . . . . . . . . . . . . . . . . . 15 9.4.1 Control Traffic . . . . . . . . . . . . . . . . . . . . . 16 9.4.2 Data Traffic . . . . . . . . . . . . . . . . . . . . . . . 16 Kelly & Molnar Expires February 19, 2004 [Page 2] Internet-Draft LWAPP Security Requirements August 2003 9.5 Anti-replay . . . . . . . . . . . . . . . . . . . . . . . 16 9.5.1 Control Traffic . . . . . . . . . . . . . . . . . . . . . 17 9.5.2 Data Traffic . . . . . . . . . . . . . . . . . . . . . . . 17 9.6 Confidentiality . . . . . . . . . . . . . . . . . . . . . 17 9.6.1 Control Traffic . . . . . . . . . . . . . . . . . . . . . 17 9.6.2 Data Traffic . . . . . . . . . . . . . . . . . . . . . . . 18 10. Additional Security Requirements . . . . . . . . . . . . . 18 10.1 Cryptographic Keys . . . . . . . . . . . . . . . . . . . . 18 10.1.1 Key Establishment . . . . . . . . . . . . . . . . . . . . 18 10.1.2 Key Naming . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1.3 Key Freshness . . . . . . . . . . . . . . . . . . . . . . 18 10.2 Privilege Separation . . . . . . . . . . . . . . . . . . . 18 10.3 Firewall/NAT Considerations . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . 19 12. Intellectual Property . . . . . . . . . . . . . . . . . . 19 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 19 References . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 19 Full Copyright Statement . . . . . . . . . . . . . . . . . 21 Kelly & Molnar Expires February 19, 2004 [Page 3] Internet-Draft LWAPP Security Requirements August 2003 1. Introduction LWAPP defines the interactions of wireless lan infrastructure components, including access points (APs) and access routers (ARs). For a complete description of this protocol, see [LWAPP]. The primary goal of LWAPP is to centralize much of the non-PHY WLAN processing at the AR, thereby enabling scalable, manageable deployments of lightweight APs. The AR represents a centralized point of management control in such infrastructures, implying critical control signalling between APs and ARs. All WLAN data traffic must transit between ARs and APs as well. Given the security concerns surrounding wireless access, it seems prudent to consider the associated security vulnerabilities and threats, and to define appropriate countermeasures. This document provides a security analysis and makes recommendations for securing LWAPP. 2. LWAPP Architecture and Topology For a complete definition of the LWAPP architecture, see [LWAPP]. For convenience, the following figure is copied from that document: --------------------------------------------------------------------- +-+ 802.11frames +-+ | |--------------------------------| | | | +-+ | | | |--------------| |---------------| | | | 802.11 PHY/ | | LWAPP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA AP AR Figure 1: LWAPP Architecture --------------------------------------------------------------------- LWAPP encompasses control and data traffic flowing bidirectionally between the AP and the AR. Note that some topological subtleties exist which are not called out by the above diagram. These are discussed in the following sections. 3. WLAN Security Termination The IEEE 802.11 specification family [802.11] defines multiple security mechanisms, including WEP, 802.1x, and 802.11i. In Kelly & Molnar Expires February 19, 2004 [Page 4] Internet-Draft LWAPP Security Requirements August 2003 addition, the WiFi consortium defines WPA as an interim step between WEP and 802.11i. In non-LWAPP deployments, these protocols interact with the mobile station (STA) and the AP, and also with an Authentication Server (AS) in the case of 802.1x. LWAPP entails delegation of some or all of the AP's roles in these mechanisms to the AR. For example, WEP associations are historically between STA and AP, but with LWAPP, the association may be between STA and AR if desired. 802.1x associations are historically a 3-way conversation between STA, AP, and AS, but with LWAPP, these are more typically between STA, AR and AS. Hence, the introduction of LWAPP entails modifications to security termination points which may introduce new security concerns. 4. WLAN Security Architecture Naming Convention For convenience, we now define names for some possible WLAN security architectures. This naming is not meant to be exhaustive; we only give a few possible architectures that can help illustrate the security impact of MAC-splitting decisions. These architectures are: SAAP - standalone AP terminates all L2 security ARCH1 - terminate WEP/WPA/802.11i/802.1x at the AR ARCH2 - terminate WEP/WPA/802.11i at the AP, 802.1x at the AR ARCH3 - terminate WEP/WPA/802.11i/802.1x at the AP Note that we could also define an architecture wherein WEP/WPA/ 802.11i are terminated at the AR, and 802.1x is terminated at the AP, but this seems nonsensical, and so it is not defined. Note that LWAPP is irrelevant for the SAAP architecture, but that architecture is included for completeness. 5. Topological Assumptions LWAPP assumes that the AR and AP are within the same administrative domain, i.e. they are owned/controlled by the same entity. LWAPP makes no topological assumptions beyond these, meaning there are several topologies which must be considered for our purposes. These are discussed below, along with the interactions between each topology and different WLAN security architectures Kelly & Molnar Expires February 19, 2004 [Page 5] Internet-Draft LWAPP Security Requirements August 2003 5.1 Directly Connected The first topology we consider is one in which APs are directly connected to an AR: --------------------------------------------------------------------- -------+------ LAN | +-------+-------+ | + + AR + + | +----+-----+----+ | | +---+ +---+ | | +--+--+ +--+--+ | AP | | AP | +--+--+ +--+--+ Figure 2: Directly Connected --------------------------------------------------------------------- In this case, a direct layer 2 connection exists between the AP and AR, and an adversary must penetrate the direct connection in order to access the AP-AR traffic. While such physical access is possible, the risk of such access may be low enough to be acceptable in specific situations. In the case of ARCH1, security for STA-AR data traffic is provided by the WPA/802.11i MAC functionality in addition to physical access control. Note that this effectively provides security for AP-AR data traffic. Security for AP-AR control traffic is not provided by any MAC layer functionality; additional mechanisms must be employed if assurances beyond physical security are desired In the case of ARCH2, security provided by 802.11i/WPA MAC functionality for data traffic is strictly between STA and AP; data and control traffic between AP and AR rely primarily on physical access control. If assurances beyond physical security are desired for this region, additional mechanisms must be employed for both data and control traffic. For example, IPsec may be used between STA and AR to secure AP-AR data traffic, but the issue remains for control traffic. Because 802.1x traffic terminates at the AR, security of this traffic depends on the EAP method used; if a method such as EAP- TLS is employed, then access to the AP-AR traffic is less of a concern Kelly & Molnar Expires February 19, 2004 [Page 6] Internet-Draft LWAPP Security Requirements August 2003 The case of ARCH3 is similar to the case of ARCH2, except now all 802.1x traffic terminates at the AP. This may imply that 802.1x provisioning information is pushed from the AR to the AP, or it may imply that the AP will form separate connections with back-end AAA servers. In any case, physical security provides the primary assurance for communications between AP and the rest of the network. 5.2 Switched Connections --------------------------------------------------------------------- -------+------ LAN | +-------+-------+ | + + AR + + | +----+-----+----+ | | +---+ +---+ | | +--+--+ +-----+-----+ | AP | | Switch | +--+--+ +---+-----+-+ | | +--+--+ +----+ | AP | | +--+--+ +--+---+ | host | +------+ Figure 3: Switched Connections --------------------------------------------------------------------- This case is (almost) functionally identical to the directly connected case. For all practical purposes, a direct layer 2 connection exists between the AP and AR. The primary difference is that other systems may also be "directly" connected to the AR, and intermingling traffic with the AP on that medium. In this case, there are additional security considerations because these systems potentially have access to the AP-AR traffic, and may be indistinguishable from a valid AP or AR In the case of ARCH1, security for STA-AR data traffic is provided by the 802.11i MAC functionality in addition to physical access control. Security for AP-AR control traffic is not provided by any MAC layer functionality; additional mechanisms must be employed if assurances beyond physical security are desired. Note that in this case, Kelly & Molnar Expires February 19, 2004 [Page 7] Internet-Draft LWAPP Security Requirements August 2003 security of control traffic relies on the security of all systems with access to AP-AR traffic In the case of ARCH2, security for the STA-AR data traffic relies on the security of AP-AR data traffic,and both AP-AR data and control traffic rely primarily on physical access control. If assurances beyond physical security are desired, additional mechanisms must be employed for both data and control traffic. For example, IPsec may be used between STA and AR to secure user data traffic, but this does nothing to secure AP-AR control traffic. Because 802.1x traffic terminates at the AR, security of his traffic depends on the EAP method used; if a secure method such as EAP-TLS is employed, then access to the AP-AR traffic is perhaps less of a concern The case of ARCH3 is similar to the case of ARCH2, except now all 802.1x traffic terminates at the AP. This may imply that 802.1x provisioning information is pushed from the AR to the AP, or it may imply that the AP will form separate connections with back-end AAA servers. In any case, physical security provides the primary assurance for communications between AP and the rest of the network; if switches on the subnet are considered untrustworthy, additional mechanisms will be required 5.3 Routed Connections Kelly & Molnar Expires February 19, 2004 [Page 8] Internet-Draft LWAPP Security Requirements August 2003 --------------------------------------------------------------------- +-------+-------+ | + + AR + + | +-------+-------+ | --------+------ LAN | +-------+-------+ | router | +-------+-------+ | -----+--+--+--- LAN | | +---+ +---+ | | +--+--+ +--+--+ | AP | | AP | +--+--+ +--+--+ Figure 4: Routed Connections --------------------------------------------------------------------- This case is considerably different than the direct and switched cases. Routed connections imply a layer 3 connection between the AP and AR. Additionally, there may be other systems on either LAN segment. If there are, this introduces additional security considerations, because these systems have access to AP-AR traffic, and may be indistinguishable from APs/ARs. It is also possible for a mix of links with different security properties to be employed between the AP and AR; some links may even be wireless. Under such circumstances, it may be appropriate to treat the connection between AP and AR as untrusted In the case of ARCH1, security for STA-AR data traffic is provided by the 802.11i MAC functionality. Security for AP-AR control traffic is not provided by any MAC layer functionality; additional mechanisms must be employed if security is desired In the case of ARCH2, security for the STA-AR data traffic relies on the security of AP-AR data traffic. If security is desired, additional mechanisms must be employed for both control and data traffic between the AP and AR. For example, IPsec may be used to secure user data between STA and AR. In the case of 802.1x traffic passing from STA to AR, protection depends on the EAP method used; unencrypted methods such as EAP-MD5 should not be used under these Kelly & Molnar Expires February 19, 2004 [Page 9] Internet-Draft LWAPP Security Requirements August 2003 circumstances The case of ARCH3 is similar to the case of ARCH2, except now all 802.1x traffic terminates at the AP. This may imply that 802.1x provisioning information is pushed from the AR to the AP, or it may imply that the AP will form separate connections with back-end AAA servers. Additional mechanisms beyond physical security should then provide the primary assurance for communications between AP and the rest of the network. 6. Capabilities of Adversary We now enumerate capabilities of adversaries in this setting. Different adversaries may have different mixes of capabilities. When specifying security mechanisms, it is important to state precisely which adversaries are defended against 6.1 Eavesdropping An adversary may read traffic on a link. 6.2 Packet Modification An adversary may modify packets on a link. There are several special cases of this capability 6.2.1 Packet Injection The adversary may add arbitrary packets to the link. These packets are not constrained to follow any particular standard format. 6.2.2 Packet Deletion The adversary may delete a packet from the link; the packet is dropped and never reaches its destination 6.2.3 Packet Reordering The adversary may reorder packets or delay packets indefinitely. 6.2.4 Packet Redirection The adversary may send a packet intended for one recipient to another recipien 6.2.5 Packet Reflection The adversary may re-address a packet to its original sender. Kelly & Molnar Expires February 19, 2004 [Page 10] Internet-Draft LWAPP Security Requirements August 2003 6.2.6 Session Replay The adversary may record messages on a link between two parties and then replay half the conversation later to one of the parties. 6.3 Address Spoofing The adversary may change its network address (e.g. IP or MAC address) arbitraril 6.4 MiM Attack The adversary may pose as an AP or an AR and negotiate a connection that "passes through" the adversary. This adversary may be situated between a legitimate AP-AR pair, or it may terminate one end of the AP-AR connection itself 6.5 Password Guessing/Dictionary Attacks In scenarios where passwords are used, the adversary may attempt to guess passwords and employ password dictionaries. 6.6 Corruption of Auxiliary Network Services 6.6.1 DCHP Takeover The adversary may take over a DHCP server on any subnet it likes. Alternatively, the adversary sets up its own DHCP server and responds more quickly than the "real" DHCP server 6.6.2 DNS Takeover The adversary may take over a DNS server or respond more quickly than the real DNS server 7. Adversary Goals This section contains an overview of some likely goals of an adversary. While we cannot always know with certainty all the ways in which an adversary might behave, we can anticipate certain actions based on a knowledge of higher-level objectives in conjunction with the constraints of the problem space. We should note that it is sometimes difficult to anticipate precisely how exploits might be combined to compromise a system, and so we must exercise caution when considering dismissal of some goal which, taken by itself, might seem trivial and uninteresting. With this in mind, we review the following list of likely adversarial objectives Kelly & Molnar Expires February 19, 2004 [Page 11] Internet-Draft LWAPP Security Requirements August 2003 7.1 Associate Unauthorized AP with Legitimate AR Such APs may be used in MiM attacks, or to facilitate unauthorized network access 7.2 Associate Unauthorized AR with Legitimate AP Unauthorized ARs may be used in MiM attacks on 802.1x, or may be used to associate stations with unauthorized networks 7.3 De-associate authorized AP and AR This attack could be used as part of a MiM scheme (de-associate authorized device, re-associate with unauthorized device), or as a DoS 7.4 DoS attacks For this category, we concentrate on DoS attacks which are LWAPP- specific, such as de-associating an AP-AR pair, corrupting LWAPP protocol setup packets, and other actions which disrupt AP-AR (and by extension, STA-AR) communications. This class does not include general DoS attacks such as LAN saturation, ping floods, etc. which LWAPP cannot address 7.5 Eavesdropping on AP Control Data AP control data includes AP configuration, which might contain credentials, security parameters, firmware, or RF parameters, to name a few things. Knowledge of such values could provide an attacker with facilitating information. 7.6 Modification of AP Control Data Modification of AP control data may permit an attacker to take control of the AP to varying degrees. This might be used to facilitate DoS or MiM attacks, or takeover of an AP (if control data includes AP firmware) 7.7 Eavesdropping on AR Control Data AR control data includes AR configuration, which might contain credentials, security parameters, and various other things. Knowledge of such values could provide an attacker with facilitating information Kelly & Molnar Expires February 19, 2004 [Page 12] Internet-Draft LWAPP Security Requirements August 2003 7.8 Modification of AR Control Data Modification of AR control data may permit an attacker to take control of the AR to varying degrees. This might be used to facilitate DoS or MiM attacks 8. Adversary Scenarios We now define specific adversary scenarios in which a network is attacked. Documents defining LWAPP security mechanisms should be able to "walk through" how the mechanism interacts with each of these scenarios. In particular, adversary goals that the mechanism does and does not permit in each scenario should be spelled out. 8.1 Rogue AP The adversary obtains a "clean" AP and connects to the network without being authorized by the network administrator 8.2 Rogue AR The adversary obtains a "clean" AR and connects to the network without being authorized by the network administrator. 8.3 AP Takeover In the Rogue AP scenario, the AP has no preexisting relationship with any STA or AR on the network. In the AP Takeover scenario, an adversary gains control of an AP with existing security relationships. This takeover may occur due to password leakage, buffer overflow in the AP software, compromise or injection of an AP firmware download, or other reasons 8.4 AR Takeover In the Rogue AR scenario, the AR had no preexisting relationship with any STA or AR on the network. In the AR Takeover scenario, an adversary gains control of an AP with existing security relationships. This takeover may occur due to password leakage, buffer overflow in the AR software, or other reasons 8.5 Passive Adversary between AR and AP In this scenario, an adversary has the capability of eavesdropping on any link between AR and AP, but does not have the capability to modify packets Kelly & Molnar Expires February 19, 2004 [Page 13] Internet-Draft LWAPP Security Requirements August 2003 8.6 Active Adversary between AR and AP In this scenario, an adversary may eavesdrop and/or modify packets on any link between AR and AP. Such modification may include injection, deletion, reflection, reordering, or replay. The attacker may effect a MiM attack or a DoS attack 9. Countermeasures 9.1 Secure Association Just as strong authentication is a precursor for integrity verification, a secure association mechanism is a precursor to authentication. Assuming that an AR is always situated between an AP and the wired network, prevention of Rogue AP/AR deployment comes down to a single question: how do an AR and AP determine that they should associate with each other? There must be a mechanism for forming a "secure association" between AR and AP that has these properties 1) Association between an AR and AP occurs only when intended by the network administrator 2) Once formed, the secure association can only be torn down if the administrator authorizes it, the AP fails, or the AR fails; no third party can cause disassociation of the AR and AP There are numerous ways in which a secure association might be created, and a detailed discussion of such mechanisms is beyond the scope of this document. However, such a mechanism is a prerequisite to AP-AR authentication 9.2 Authentication Strong AP-AR authentication is a precursor to per-packet integrity verification, so to fully understand its impact, we must examine its benefits alone and in conjunction with integrity verification. In this section, we review it as a stand-alone mechanism only - integrity verification is reviewed fully in section 6.4 - Associate Unauthorized AP with Legitimate AR (7.1) - Associate Unauthorized AR with Legitimate AP (7.2) - De-associate authorized AP and AR (7.3) This provides protection against the following adversary scenarios: Kelly & Molnar Expires February 19, 2004 [Page 14] Internet-Draft LWAPP Security Requirements August 2003 - Rogue AP (8.1); if an AP-AR association is strongly authenticated, the rogue AP cannot form an unauthorized association. - Rogue AR (8.2); if an AP-AR association is strongly authenticated, the rogue AR cannot form an unauthorized association. Again, we must emphasize that due to the fact that it is required for per-packet integrity verification and reliable cryptographic key exchange, strong authentication has significant consequences beyond these, and it must be considered in that context. Integrity verification is reviewed below in section 6.x. 9.3 Secure Discovery In addition to methods for creating a secure association, AP's and AR's must have some method for dynamically discovering such associations. An AP deployed in a network must discover at least one AR with which it has established a secure association. The mechanisms for this discovery should not return information concerning ARs that cannot form a secure association with the AP. An adversary should also be unable to use discovery to switch one AR with another AR that also can securely associate with the AP. 9.4 Integrity Verification At minimum, integrity verification mechanisms assure us that the data has not been modified in transit. There are simple integrity verification mechanisms which require no prior relationship between the endpoints, e.g. a CRC checksum. While such mechanisms are helpful in detecting transmission errors and the like in a non- hostile environment, they are of little use in the face of an adversary. This is because the adversary can modify the data and then simple recompute the Integrity Check Value (ICV) In order to protect against such malicious tampering, we must have a mechanism for ICV computation which is not available to the attacker. Typically, this is accomplished by adding some sort of secret which is shared only by the authorized endpoints into the ICV computation. An example of such a ICV method using a shared secret is HMAC-SHA1 HMAC [3] Regardless of whether integrity-related secrets are manually configured or dynamically created, associated integrity mechanisms have an added benefit: they provide data origin authentication. This means that when we verify the ICV associated with the data, not only are we sure that the data was not modified in transit, but we also Kelly & Molnar Expires February 19, 2004 [Page 15] Internet-Draft LWAPP Security Requirements August 2003 have some assurance regarding its origin Per-packet integrity verification may be applied to all traffic, or it may be selectively applied to control traffic or data traffic. Different attacker goals and scenarios are affected, depending on our choice in this regard. These are treated separately below. 9.4.1 Control Traffic Integrity protection for LWAPP signalling interferes with the following adversary goals - DoS attacks (7.4); some DoS attacks are prevented due to the data origination verification provided as a benefit of integrity verification - Modification of AP Control Data (7.8); the ICV prevents modification of in-transit packets, and also prevents injection of invalid packets. This provides protection against the following adversary scenarios: - Rogue AP (8.1); this is prevented due to the data origination verification provided as a benefit of integrity verification. - Rogue AR (8.2); this is prevented due to the data origination verification provided as a benefit of integrity verification. 9.4.2 Data Traffic Integrity protection for LWAPP data traffic interferes with the following adversary goals: - Modification of user Data (7.6); the ICV prevents modification of in-transit packets, and also prevents injection of invalid packets This provides protection against the following adversary scenarios: - Active Adversary Between AR and AP (8.6); this is prevented due to the data origination verification provided as a benefit of integrity verification. 9.5 Anti-replay This feature entails a mechanism for preventing the replay of valid traffic. It is typically implemented through inclusion of an Kelly & Molnar Expires February 19, 2004 [Page 16] Internet-Draft LWAPP Security Requirements August 2003 authenticated sequence number in each packet. 9.5.1 Control Traffic Integrity-protected anti-replay protection for LWAPP control traffic interferes with the following adversary goals: - Replay of AP Control Data (7.8); replayed control data could be used to cause the AP to revert to a previous (exploitable) state This provides protection against the following adversary scenarios: - Rogue AP (8.1); if an adversary can replay discovery and association packets, it may be able to impersonate a valid AP. - Active Adversary Between AR and AP (8.6) 9.5.2 Data Traffic Integrity-protected anti-replay protection for LWAPP data traffic interferes with the following adversary goals - Replay of AP Control Data (7.8); replayed control data could be used to cause the AP to revert to a previous (exploitable) state This provides protection against the following adversary scenarios: - Active Adversary Between AR and AP (8.6) 9.6 Confidentiality Data confidentiality involves rendering the data unreadable to all but the authorized parties. It should be noted that data confidentiality cannot be effectively provided without also providing a data integrity function. 9.6.1 Control Traffic Confidentiality protection for LWAPP control traffic interferes with the following adversary goals - Eavesdropping on user data (7.5); an adversary could use knowledge gained from control data to facilitate an attack on the AP/AR This provides protection against the following adversary scenarios: Kelly & Molnar Expires February 19, 2004 [Page 17] Internet-Draft LWAPP Security Requirements August 2003 - Passive Adversary Between AR and AP (8.5) - Active Adversary Between AR and AP (8.6) 9.6.2 Data Traffic Confidentiality protection for LWAPP data traffic interferes with the following adversary goals - Eavesdropping on user data (7.5); an adversary could use knowledge gained from control data to facilitate an attack on the AP/AR This provides protection against the following adversary scenarios: - Passive Adversary Between AR and AP (8.5); - Active Adversary Between AR and AP (8.6) 10. Additional Security Requirements 10.1 Cryptographic Keys 10.1.1 Key Establishment Confidentiality and integrity verification mechanisms require cryptographic keys. It is possible to establish such keys via manual configuration or dynamic key exchange. Given that some deployments may be very large, scalability issues associated with manual configuration imply the need to support dynamic key establishment mechanisms along with manual mechanisms 10.1.2 Key Naming Each key in a security mechanism must be explicitly named. This name facilitates the management and revocation of keys 10.1.3 Key Freshness Keys in a security mechanism should be refreshed. The exact details of when to refresh may depend on adminstrator policy and the specific security mechanisms used 10.2 Privilege Separation Takeover of any component of the system (STA, AP, or AR) should Kelly & Molnar Expires February 19, 2004 [Page 18] Internet-Draft LWAPP Security Requirements August 2003 compromise the minimum possible number of additional components. In particular, compromise of an AP should yield no key material or other data protecting the control or data transport of any other AP 10.3 Firewall/NAT Considerations Security mechanisms should strive to avoid bad interactions with firewall and NAT techniques. When interactions exist, they should be clearly documented 11. Security Considerations The topic of this document is LWAPP security requirements, so no separate security considerations discussion is required 12. Intellectual Property Since this is strictly an informational requirements document, there are no associated intellectual property rights 13. Acknowledgements We thank Russ Housley for useful discussions about security protocol requirements. Of course any shortcomings are our own. [DM] References [1] "Key words for use in RFCs to Indicate Requirement Levels", March 1997, . [2] "IEEE Std 802.11i/3.0: Specification for Enhanced Security", November 2003. [3] "HMAC: Keyed-Hashing for Message Authentication", February 1997, . Authors' Addresses Scott Kelly Airespace 110 Nortech Parkway San Jose, CA 95134 Phone: +1 408-635-2022 EMail: skelly@airespace.com Kelly & Molnar Expires February 19, 2004 [Page 19] Internet-Draft LWAPP Security Requirements August 2003 David Molnar Legra Systems 3 Burlington Woods Dr Burlington, MA 01803 Phone: +1 781-272-8400 EMail: dmolnar@legra.com Kelly & Molnar Expires February 19, 2004 [Page 20] Internet-Draft LWAPP Security Requirements August 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Kelly & Molnar Expires February 19, 2004 [Page 21]