----------- change log from v05 to v06 ------------------ 1) re-organize the first two sections: put Conventions as a separate section at the very beginning, and put the introduction before the definitions. [Per Joel Halpern¡¯s comment.] This affects the section number of the first two sections in v05, now 3 sections in v06. 2) ¡°WTP¡± definition in old 1.3 (new 3.2): [Per Steve Bellovin¡¯s comment] [old, 1.3] Wireless Termination Point (WTP): the physical or network entity that contains RF antenna and 802.11 PHY to transmit and receive station traffics for the IEEE 802.11 WLAN access networks. Such physical entities are often called "Access Points" (AP) previously, but "AP" can also be used to refer to logical entity that implements 802.11 services. So we recommend using "WTP" instead to explicitly refer to the physical entity. [new 3.2 ] Wireless Termination Point (WTP): the physical or network entity that contains RF antenna and 802.11 PHY to transmit and receive station traffic for the IEEE 802.11 WLAN access networks. Such physical entities are often called "Access Points" (AP) previously, but "AP" can also be used to refer to the logical entity that implements 802.11 services. So we recommend "WTP" as the generic term used to explicitly refer to the physical entity with the above property (i.e. featuring an RF antenna and 802.11 PHY), applicable to network entities of both Autonomous and Centralized WLAN Architecture (see below). 3) 1.4: [Per Steve Bellovin¡¯s comment] [old 1.4] Standalone Access Point: use WTP or Standalone WTP. Fat Access Point: the same as Standalone Access Point. Use WTP or Standalone WTP. Thin Access Point: use WTP, or Controlled WTP. Light weight Access Point: the same as Thin Access Point, use WTP, or Controlled WTP. [new 3.3] Standalone Access Point: use Standalone WTP. Fat Access Point: Use Standalone WTP. Thin Access Point: use Controlled WTP. Light weight Access Point: Use Controlled WTP. 4) Old 4.8.1 [client data security, PMK sharing issue, Per Russ Housley¡¯s comment] [old 4.8.1] If the STA and AC are the parties in the 4-way handshake (defined in [4]), and the encryption/decryption happens at the WTP, then the PTK (Pairwise Transient Key) has to be securely transferred from the AC to the WTP. If the PMK (Pairwise Master Key) is reused across multiple WTPs, then requiring a 4-way handshake for each WTP that the station associates to, followed by the transfer of that PTK from the AC to the WTP, would ensure that a different PTK is used at each WTP. Since the keying material is part of the control and provisioning of the WTPs, a secure encrypted tunnel for control frames is employed to transport the keying material. [new 5.8.1] If the STA and AC are the parties in the 4-way handshake (defined in [4]), and 802.11i traffic encryption terminates at the WTP, then the PTK (Pairwise Transient Key) has to be transferred from the AC to the WTP. Since the keying material is part of the control and provisioning of the WTPs, a secure encrypted tunnel for control frames is employed to transport the keying material. The centralized model encourages AC implementations to use one PMK for many different WTPs. This practice facilitates speedy transition by a station from one WTP to another WTP that is connected to the same AC without establishing a separate PMK. However, this leaves the station in a difficult position. The station cannot distinguish between a compromised PMK and one that is intentionally being shared. This issue must be resolved, but the resolution is beyond the scope of the CAPWAP working group. The venue for this resolution is to be determined by the IEEE 802 and IETF liaisons. 5) Old 5.2 security (for distributed architecture) [Per Matt Holdrege¡¯s comments] [old 5.2] Similar security concerns for client data security as described in Section 4.8.1 also apply to the Distributed Mesh Architecture. Additionally, one important security consideration for the mesh networks is that the mesh nodes must authenticate each other within the same administrative domain, and data transmission among neighboring nodes must be secured. Each node that is part of the mesh must be fully trusted for the mesh to be secure. It is often recommended that all communication between mesh nodes be secured by some mechanism of confidentiality, integrity and replay protection, since they may carry user traffic that is not. For this reason, the operator should always encrypt and protect mesh links, in order to fully secure the network. [new 6.2] Similar security concerns for client data security as described in Section 5.8.1 also apply to the Distributed Mesh Architecture. Additionally, one important security consideration for the mesh networks is that the mesh nodes must authenticate each other within the same administrative domain. Also to protect user and management data that may not be secured at layer 3, data transmission among neighboring nodes should be secured by a layer 2 mechanism of confidentiality, integrity and replay protection. 6) References changed into ¡°normative references¡± [Scott Hollenbeck comment] Also fixed the 11i reference, and updated Problem Statement reference. ---------- end of change log ---------------