Network Working Group S. Kelly Internet-Draft Talari Networks Expires: April 24, 2006 E. Rescorla RTFM October 21, 2005 Securing LWAPP with DTLS draft-kelly-capwap-lwapp-dtls-00 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 April 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The LWAPP protocol defines the interactions of various wireless LAN infrastructure components, including 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 Kelly & Rescorla Expires April 24, 2006 [Page 1] Internet-Draft Securing LWAPP with DTLS October 2005 wrapper. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Inserting DTLS . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Control/Data Channel Considerations . . . . . . . . . . . 5 2.1.1. Separate Control/Data Channel Ports . . . . . . . . . 5 2.1.2. Adding a Protocol Mux . . . . . . . . . . . . . . . . 5 3. Endpoint Authentication using DTLS . . . . . . . . . . . . . . 5 3.1. Authenticating with Certificates . . . . . . . . . . . . . 6 3.2. Authenticating with Preshared Keys . . . . . . . . . . . . 6 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Kelly & Rescorla Expires April 24, 2006 [Page 2] Internet-Draft Securing LWAPP with DTLS October 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 [1]. The CAPWAP working group is currently considering using LWAPP as the basis for a standardized AC-WTP control protocol (recommended in [4]). The current embodiment of LWAPP includes security elements which provide the following functionalities: o Endpoint Authentication - AC and WTP are strongly authenticated using either public key certificates or shared secrets. 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. The security scheme used by LWAPP has been through at least one security review [5], 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 [2]. 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 - it is well understood in the IETF (and broader security communities) that security by obscurity is usually insufficient, and because of this, a great deal of effort has been invested in reviewing and analysing proposed (and deployed) security mechanisms. Sometimes problems are found almost immediately, given the right group of reviewers. But vulnerabilities and attacks on cryptographic and security protocols are often quite subtle, and sometimes not discovered for years. For these reasons, security protocols and mechanisms which have been extensively deployed and analyzed should be preferred above those which have not. o Algorithm Agility - Because history shows that most cryptogaphic algorithms are eventually either broken outright or rendered computationally insufficient by advancing technology, it is crucial to have the ability to quickly replace outdated or compromised algorithms. Kelly & Rescorla Expires April 24, 2006 [Page 3] Internet-Draft Securing LWAPP with DTLS October 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 (upon which DTLS is based) has enjoyed. For more information on TLS, see [6]. Also, LWAPP provides no facility for algorithm negotiation - changing security algorithms would require a change to the protocol standard and a firmware upgrade, at minimum. This is undesirable. DTLS, while a relatively recent proposal, 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 definition 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 draft recommends eliminating layer 2 encapsulation support, it is not addressed here. From a high level, simple replacement of the LWAPP security mechanisms with DTLS amounts to something like this: 1. Insert DTLS session establishment between the DISCOVER and JOIN phases 2. Remove the existing LWAPP security scheme This amounts to employing DTLS as a "secure wrapper", with LWAPP treating the resultant channel as a connectionless transport. This works as follows: o WTP sends DISCOVER message(s) o AC(s) respond o Upon selecting an AC to bind with, WTP sends DTLS ClientHello to AC o AC responds with DTLS ServerHello o (AC and WTP negotiate algorithms) o Once DTLS session is established, WTP sends JOIN request, and LWAPP state machine proceeds as before, sans internal security mechanisms Kelly & Rescorla Expires April 24, 2006 [Page 4] Internet-Draft Securing LWAPP with DTLS October 2005 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, relying upon other 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. Unfortunately, this is not so simple as it sounds. 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 only because the LWAPP header is not encrypted - in the case of the control channel, it is only authenticated. And therein lies the rub. DTLS provides us the ability to secure the channel - all of it. If the LWAPP packets are encapsulated within DTLS, the LWAPP header will be encrypted. This means we must establish separate channels for control and data 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 within the (now secure) JOIN response, providing some additional flexibity. Note that this solution will not work for layer 2 LWAPP encapsulation. However, if L2 support is removed from LWAPP, this point becomes moot. 2.1.2. Adding a Protocol Mux A more complex solution entails adding a protocol multiplexer module between the packet input/output and the DTLS modules, and adding an additional small associated header to the packet. While this header need only contain a single bit to differentiate between control/data traffic, alignment concerns suggest the header would more likely be at least 32-bits in length. 3. Endpoint Authentication using DTLS Currently, LWAPP supports authentication using either public key certificates or shared secrets (preshared keys). DTLS requires no changes in this regard. Certificate-based authentication is natively Kelly & Rescorla Expires April 24, 2006 [Page 5] Internet-Draft Securing LWAPP with DTLS October 2005 supported, and support for preshared keys is currently progressing toward standardization (see [3]). Below we describe supported TLS algorithm suites for each endpoint authentication method. 3.1. Authenticating with Certificates Note that only block ciphers are currently recommended for use with DTLS. For a description of the reasoning behind this, see [7]. The following algorithms MUST be supported when using certificates: 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 Preshared keys present significant challenges from a security perspective, and for that reason, their use is discouraged. However, [3] defines 3 different methods for authenticating with preshared keys, only one of which is susceptible to passive dictionary attacks. This particular method MUST NOT be used. The following algorithms MUST be supported when using preshared keys: o TLS_DHE_PSK_WITH_AES_128_CBC_SHA The following algorithms SHOULD be supported when using preshared keys: o TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA The following algorithms MAY be supported when using preshared keys: Kelly & Rescorla Expires April 24, 2006 [Page 6] Internet-Draft Securing LWAPP with DTLS October 2005 o TLS_RSA_PSK_WITH_AES_128_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 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 minimal amount of changes 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 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 will be described in Section 3.1. 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 Kelly & Rescorla Expires April 24, 2006 [Page 7] Internet-Draft Securing LWAPP with DTLS October 2005 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 [1] Calhoun et al, P., "Light Weight Access Point Protocol", June 2005, . [2] Rescorla et al, E., "Datagram Transport Layer Security", June 2004. [3] Eronen et al, P., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", June 2005. 7.2. Informative References [4] Lohrer et al, D., "Evaluation of Candidate CAPWAP Protocols", August 2005, . [5] Clancy, C., "Security Review of the Light Weight Access Point Protocol", May 2005. [6] Dierks et al, T., "The TLS Protocol Version 1.1", June 2005. [7] Modadugu et al, N., "The Design and Implementation of Datagram TLS", Feb 2004. Kelly & Rescorla Expires April 24, 2006 [Page 8] Internet-Draft Securing LWAPP with DTLS October 2005 Authors' Addresses Scott G. Kelly Talari Networks 150 W. Iowa Ave Ste 208 Sunnyvale, CA 94086 US Email: scott@hyperthought.com Eric Rescorla RTFM 2064 Edgewood Drive Palo Alto, CA 94303 US Email: ekr@rtfm.com Kelly & Rescorla Expires April 24, 2006 [Page 9] Internet-Draft Securing LWAPP with DTLS October 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 April 24, 2006 [Page 10]