Network Working Group S. Kelly Internet-Draft Talari Networks Expires: June 15, 2006 E. Rescorla Network Resonance December 12, 2005 Securing LWAPP with DTLS draft-kelly-capwap-lwapp-dtls-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 June 15, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The LWAPP protocol defines interactions between wireless termination points and wireless access controllers. Communications between these components must be secured, and the current specification provides for transport security using proprietary mechanisms which are embedded in the protocol. This document describes an alternative approach which eliminates the embedded security, and instead uses DTLS as a secure, tightly-integrated wrapper. Kelly & Rescorla Expires June 15, 2006 [Page 1] Internet-Draft Securing LWAPP with DTLS December 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Inserting DTLS . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Control/Data Channel Considerations . . . . . . . . . . . 7 2.1.1. Separate Control/Data Channel Ports . . . . . . . . . 8 2.1.2. Adding a Protocol Mux . . . . . . . . . . . . . . . . 8 3. Endpoint Authentication using DTLS . . . . . . . . . . . . . . 8 3.1. Authenticating with Certificates . . . . . . . . . . . . . 9 3.2. Authenticating with Preshared Keys . . . . . . . . . . . . 9 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Kelly & Rescorla Expires June 15, 2006 [Page 2] Internet-Draft Securing LWAPP with DTLS December 2005 1. Introduction The Light Weight Acess Point Protocol (LWAPP) provides for centralized control and management of Wireless Termination Points (WTPs) by devices referred to as Access Controllers (ACs). For more detail on this protocol and/or these components, see [LWAPP]. The CAPWAP working group is currently considering using LWAPP as the basis for a standardized AC-WTP control protocol (recommended in [CAPWAP-EVAL]). LWAPP currently includes security elements which provide for the following capabilities: o Endpoint Authentication - AC and WTP are strongly authenticated using either public key certificates or shared secrets (also known as "pre-shared keys"). o Data Confidentiality - (AC-WTP control channel) data is encrypted using the 128-bit AES-CBC algorithm. o Data Integrity/Origin Authenticity - an Integrity Check Value (ICV) is computed using 128-bit AES-CBC-MAC (a keyed MAC). The current LWAPP security scheme has been through at least one security review [LWAPP-SEC], the results of which were favorable. Still, the protocol evaluation team concluded that LWAPP would benefit from replacement of its proprietary security scheme with a standardized, more widely deployed facility such as DTLS [DTLS]. Why replace LWAPP's security mechanism, when so far, security evaluations have not found it wanting? There are at least two good reasons: o Industry experience/review - to the chagrin of many protocol designers, it has been often demonstrated that subtle security flaws may escape the most diligent reviewer. As a result, the cryptographic community invests significant effort in the ongoing analysis of deployed (and proposed) security mechanisms. Sometimes problems are found very quickly, but in other cases issues my not be discovered for years. Thus, security protocols and mechanisms which have been extensively deployed and analyzed are almost always preferable to those which have not. o Algorithm Agility - Because most cryptographic algorithms are eventually either broken outright or rendered computationally insufficient by advancing technology, it is crucial to have the ability to easily replace outdated or compromised algorithms. Kelly & Rescorla Expires June 15, 2006 [Page 3] Internet-Draft Securing LWAPP with DTLS December 2005 Note that LWAPP, while having gone through some security review, has not yet provided the opportunity for the sort of extensive public review and analysis that TLS [TLS11] has enjoyed. Also, LWAPP provides no facility for algorithm negotiation - changing security algorithms would require a change to the protocol standard, along with firmware upgrades for both WTP and AC. This is clearly undesirable. DTLS, on the other hand, is a standards-track effort which is based upon TLS. The underlying security-related protocol mechanisms have been successfully deployed for many years now. The TLS protocol is well-understood from an operational perspective, and with the recent specification of its datagram-based variant, is an obvious choice for meeting the security requirements of LWAPP. 2. Inserting DTLS Note that for the time being, only the UDP transport mechanism for LWAPP is considered. Since the evaluation document recommends eliminating layer 2 encapsulation support, it is not addressed here. Should this change, the mechanism described below in section 2.1.2 could be used to partially address that case. From a high level, simple replacement of the LWAPP security mechanisms with DTLS amounts to something like this: 1. Replace the JOIN phase with DTLS session establishment 2. Replace LWAPP re-key functionality with a DTLS re-key 3. Remove the existing LWAPP security scheme This amounts to employing DTLS as a tightly-integrated secure wrapper. Here is the resulting LWAPP state machine: Kelly & Rescorla Expires June 15, 2006 [Page 4] Internet-Draft Securing LWAPP with DTLS December 2005 /-------------\ | v | +------------+ | C| Idle |<--------------------------------------+ | +------------+ | | ^ |a ^ | | | | \----\ y | | | | | +-------------+------------+ z | | | | | | | DTLS-rekey |-\ | | | | | | +--------->+------------+ | | | | | | | | | ^ | | | |t V | x | | | | | +--------+--+ +------------+ | | | / | C| Run |------>| DTLS-Reset |<+--|----\ | / | r+-----------+ u +------------+ | | | | / | ^ ^ v| | | | | | v | | | | | | | | +--------------+ | /----/ V V | | | | C| Discovery | q| o| +-------+ | | | | b+--------------+ +-------------+ | Reset |-+ w | | | |d f| ^ | Configure | +-------+ | | | | | | +-------------+ | | |e v | | ^ | | +---------+ v |i 2| | | C| Sulking | +------------+ +--------------+ | | +---------+ C| DTLS-Init |--->| DTLS-Complete| | | g+------------+ z +--------------+ | | |h m| |4 | | | | v o / \ | | +------------+-------/ \-----------------/ \------------->| Image Data |C +------------+n Figure 1: LWAPP State Machine w/DTLS Support Following is a description of the associated state changes. Note that we only address those which are new: Discovery to DTLS-Init (f): This state is used by the WTP to confirm its commitment to an AC that it wishes to be provided service, and to simultaneously establish a secure control channel. WTP: The WTP selects the best AC based on the information it gathered during the Discovery Phase. It then initiates a DTLS connection with its preferred AC. The WTP starts the WaitJoin Timer. Kelly & Rescorla Expires June 15, 2006 [Page 5] Internet-Draft Securing LWAPP with DTLS December 2005 AC: The AC enters this state for the given WTP upon reception of a DTLS initialization request. The AC processes the request and responds by engaging in DTLS negotiation with the WTP. DTLS-Init to Discovery (i): This state is used to return the WTP to discovery mode when an unresponsive AC is encountered. WTP: The WTP enters this state when the WaitJoin timer expires prior to successful completion of DTLS negotiation. AC: This state transition is invalid. DTLS-Init to DTLS-Complete (z): This state is used to indicate DTLS session establishment. WTP: This state is entered when the WTP and AC complete DTLS negotiation. AC: This state is entered when the WTP and AC complete DTLS negotiation. Run to DTLS-Reset (u): This state is used to when the AC or WTP wish to tear down the connection. WTP: The WTP enters this state when it wishes to initiate orderly termination of the DTLS connection; the WTP sends the a TLS Finished message. AC: The AC enters this state upon receipt of TLS Finished message from the WTP. Image-data to DTLS-Reset (o): This state is used to reset the connection prior to restarting the WTP after an image download. WTP: The WTP enters this state when image download completes AC: The AC enters this state upon receipt of TLS Finished message from the WTP. DTLS-Reset to Reset (v): This state is used to complete DTLS session tear-down WTP: The WTP enters this state when it has completed DTLS session cleanup, and it is ready to finish LWAPP session clean-up. Kelly & Rescorla Expires June 15, 2006 [Page 6] Internet-Draft Securing LWAPP with DTLS December 2005 AC: The AC enters this state when it has completed DTLS session cleanup, and it is ready to finish LWAPP session clean-up. Run to DTLS-Rekey (x): This state is used to initiate a new DTLS handshake. Either the WTP or AC may initiate the state transition. It is important to note that this might more accurately be termed a "meta-state", as the DTLS re-handshake is transparent to the LWAPP protocol, and may even be interpersed with other LWAPP control messages. WTP: The WTP enters this state when either (1) a rekey is required, or (2) the AC initiates a DTLS handshake. AC: The AC enters this state when either (1) a rekey is required, or (2) the WTP initiates a DTLS handshake. DTLS-Rekey to Reset (z): This state is used to clean up when a DTLS handshake fails. WTP: The WTP enters this state when a DTLS handshake fails. AC: The AC enters this state when a DTLS handshake fails. 2.1. Control/Data Channel Considerations Note that while this scheme seems quite simple at first glance, there is one complication. Currently, LWAPP only applies security to control channel communications, and relies upon external facilities for securing user data. In order to preserve this convention, we must be able to distinguish between control and data packets, forwarding only control packets to the DTLS engine. This task is complicated by the fact that LWAPP currently distinguishes between control and data traffic using the 'C' bit in the LWAPP header. This is possible even on the encrypted control channel because the LWAPP header is not encrypted - in the case of the control channel, it is only authenticated: +--------+---------+-----------+-------------------------+-----------+ | IP Hdr | UDP Hdr | LWAPP Hdr | Data | LWAPP Tlr | +--------+---------+-----------+-------------------------+-----------+ \------ encrypted ------/ \-------- authenticated -----------/ Figure 2: Current LWAPP Packet Security DTLS, on the other hand, provides for securing the entire channel. If the LWAPP packets are encapsulated within DTLS, the LWAPP header Kelly & Rescorla Expires June 15, 2006 [Page 7] Internet-Draft Securing LWAPP with DTLS December 2005 will be encrypted: +--------+---------+---------+-----------+-------------+----------+ | IP Hdr | UDP Hdr |DTLS Hdr | LWAPP Hdr | Data | DTLS Tlr | +--------+---------+---------+-----------+-------------+----------+ \--------- authenticated ---------/ \------------ encrypted -----------/ Figure 3: LWAPP+DTLS Packet Security A direct consequence of this is that with DTLS encapsulation, we cannot distinguish between control traffic and data without first decrypting the packet - this means we must establish separate channels if we do not wish to encrypt data channel traffic. Two methods for accomplishing this are discussed below. 2.1.1. Separate Control/Data Channel Ports The simplest solution entails using separate ports for LWAPP control and data traffic, with DTLS securing only the control channel. The control traffic could continue to utilize the current well-known LWAPP port. For the data channel, a new port could be assigned by IANA, or it could instead be specified by the AC after the DTLS session is established, providing some additional flexibility. Note that this solution will not work for layer 2 LWAPP encapsulation. However, if L2 support is to be removed from LWAPP, this point is moot. 2.1.2. Adding a Protocol Mux An alternative solution entails adding a protocol multiplexer module between the packet input/output and the DTLS modules, and adding an additional small associated LWAPP header between the UDP header and the DTLS record layer header. While this LWAPP header need only contain a single bit to differentiate between control/data traffic, alignment concerns suggest the header would most likely be either 32 or 64 bits in length. 3. Endpoint Authentication using DTLS Currently, LWAPP supports authentication using either public key certificates or shared secrets (pre-shared keys). DTLS support implies no changes in this regard. Certificate-based authentication is natively supported, and support for preshared keys is currently progressing toward standardization (see [TLS-PSK]). Below we describe supported TLS algorithm suites for each endpoint Kelly & Rescorla Expires June 15, 2006 [Page 8] Internet-Draft Securing LWAPP with DTLS December 2005 authentication method. 3.1. Authenticating with Certificates Note that only block ciphers are currently recommended for use with DTLS. To understand the reasoning behind this, see [DTLS-DESIGN]. The following algorithms MUST be supported when using certificates for LWAPP authentication: o TLS_RSA_WITH_AES_128_CBC_SHA o TLS_RSA_WITH_3DES_EDE_CBC_SHA The following algorithms SHOULD be supported when using certificates: o TLS_DH_RSA_WITH_AES_128_CBC_SHA o TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA The following algorithms MAY be supported when using certificates: o TLS_RSA_WITH_AES_256_CBC_SHA o TLS_DH_RSA_WITH_AES_256_CBC_SHA Certificates should be verified in the same manner as currently specified in LWAPP. 3.2. Authenticating with Preshared Keys Pre-shared keys present significant challenges from a security perspective, and for that reason, their use is strongly discouraged. However, [TLS-PSK] defines 3 different methods for authenticating with preshared keys: o PSK key exchange algorithm - simplest method, ciphersuites use only symmetric key algorithms o DHE_PSK key exchange algorithm - use a PSK to authenticate a Diffie-Hellman exchange. These ciphersuites give some additional protection against dictionary attacks and also provide Perfect Forward Secrecy (PFS). o RSA_PSK key exchange algorithm - use RSA and certificates to authenticate the server, in addition to using a PSK. Not susceptible to passive attacks. The first approach (PSK) is susceptible to passive dictionary Kelly & Rescorla Expires June 15, 2006 [Page 9] Internet-Draft Securing LWAPP with DTLS December 2005 attacks; hence, that method MUST NOT be used. If support for pre- shared keys is desired, then DHE_PSK MUST be supported, and RSA_PSK MAY be supported. The following cryptographic algorithms MUST be supported when using preshared keys: o TLS_PSK_WITH_AES_128_CBC_SHA o TLS_PSK_WITH_3DES_EDE_CBC_SHA The following algorithms SHOULD be supported when using preshared keys: o TLS_PSK_WITH_AES_256_CBC_SHA The following algorithms MAY be supported when using preshared keys: o TLS_RSA_PSK_WITH_AES_128_CBC_SHA o TLS_RSA_PSK_WITH_AES_256_CBC_SHA o TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA 4. Conclusions DTLS represents a strong replacement candidate for the existing LWAPP security scheme. In addition to being a known quantity which has received and will continue to receive a healthy dose of ongoing analysis and review from the cryptographic community, it supports all required LWAPP security functionality, and also provides for algorithm agility should the need arise. Further, its negotiation capability provides for a measure of implementation flexibility not possible with the current LWAPP scheme. While it is not a drop-in replacement, it requires a reasonably bounded amount of change to the existing state machine and packet formats. As noted, since DTLS does not provide for unequal encryption vs authentication lengths within a packet, it requires adding either a secondary data port or a short demux header. 5. Security Considerations The security of LWAPP over DTLS is completely dependent on the security of DTLS. Any flaws in DTLS compromise the security of LWAPP. In particular, it is critical that the communicating parties Kelly & Rescorla Expires June 15, 2006 [Page 10] Internet-Draft Securing LWAPP with DTLS December 2005 verify their peer's credentials. In the case of pre-shared keys, this happens automatically via the key. In the case of certificates, the parties must check the peer's certificate. The appropriate checks are described in the current LWAPP document The use of parallel protected and unprotected channels deserves special consideration, but does not create a threat. There are two potential concerns: attempting to convert protected data into un- protected data and attempting to convert un-protected data into protected data. The use of the MAC makes it impossible for the attacker to forge protected records. The attacker can easily remove protected records from the stream (this is a consequence of unreliability), though not undetectably so. If a non-encrypted cipher suite is in use, the attacker can turn such a record into an un-protected record. However, this attack is really no different from simple injection into the unprotected stream. 6. IANA Considerations Should a separate UDP port for data channel communications be the selected demultiplexing mechanism, a port must be assigned for this purpose. Should a demultiplexing header be used instead, there may be additional IANA requirements (we'll cross that bridge if we come to it). 7. References 7.1. Normative References [DTLS] Rescorla et al, E., "Datagram Transport Layer Security", June 2004. [LWAPP] Calhoun et al, P., "Light Weight Access Point Protocol", June 2005, . [TLS-PSK] Eronen et al, P., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", June 2005. 7.2. Informative References [CAPWAP-EVAL] Lohrer et al, D., "Evaluation of Candidate CAPWAP Protocols", August 2005, . [DTLS-DESIGN] Modadugu et al, N., "The Design and Implementation of Kelly & Rescorla Expires June 15, 2006 [Page 11] Internet-Draft Securing LWAPP with DTLS December 2005 Datagram TLS", Feb 2004. [LWAPP-SEC] Clancy, C., "Security Review of the Light Weight Access Point Protocol", May 2005. [TLS11] Dierks et al, T., "The TLS Protocol Version 1.1", June 2005. Kelly & Rescorla Expires June 15, 2006 [Page 12] Internet-Draft Securing LWAPP with DTLS December 2005 Authors' Addresses Scott G. Kelly Talari Networks 150 W. Iowa Ave Ste 208 Sunnyvale, CA 94086 US Email: scott@hyperthought.com Eric Rescorla Network Resonance 2483 El Camino Real, #212 Palo Alto, CA 94303 US Email: ekr@networkresonance.com Kelly & Rescorla Expires June 15, 2006 [Page 13] Internet-Draft Securing LWAPP with DTLS December 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Kelly & Rescorla Expires June 15, 2006 [Page 14]