idnits 2.17.00 (12 Aug 2021) /tmp/idnits43217/draft-kelly-capwap-lwapp-dtls-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 514. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 527. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 24 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 344: '...owing algorithms MUST be supported whe...' RFC 2119 keyword, line 351: '...owing algorithms SHOULD be supported w...' RFC 2119 keyword, line 357: '...owing algorithms MAY be supported when...' RFC 2119 keyword, line 386: '...nce, that method MUST NOT be used. If...' RFC 2119 keyword, line 387: '...ed, then DHE_PSK MUST be supported, an...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 12, 2005) is 5997 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'DTLS' -- Possible downref: Non-RFC (?) normative reference: ref. 'LWAPP' -- Possible downref: Non-RFC (?) normative reference: ref. 'TLS-PSK' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Kelly 3 Internet-Draft Talari Networks 4 Expires: June 15, 2006 E. Rescorla 5 Network Resonance 6 December 12, 2005 8 Securing LWAPP with DTLS 9 draft-kelly-capwap-lwapp-dtls-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 15, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The LWAPP protocol defines interactions between wireless termination 43 points and wireless access controllers. Communications between these 44 components must be secured, and the current specification provides 45 for transport security using proprietary mechanisms which are 46 embedded in the protocol. This document describes an alternative 47 approach which eliminates the embedded security, and instead uses 48 DTLS as a secure, tightly-integrated wrapper. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Inserting DTLS . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Control/Data Channel Considerations . . . . . . . . . . . 7 55 2.1.1. Separate Control/Data Channel Ports . . . . . . . . . 8 56 2.1.2. Adding a Protocol Mux . . . . . . . . . . . . . . . . 8 57 3. Endpoint Authentication using DTLS . . . . . . . . . . . . . . 8 58 3.1. Authenticating with Certificates . . . . . . . . . . . . . 9 59 3.2. Authenticating with Preshared Keys . . . . . . . . . . . . 9 60 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 67 Intellectual Property and Copyright Statements . . . . . . . . . . 14 69 1. Introduction 71 The Light Weight Acess Point Protocol (LWAPP) provides for 72 centralized control and management of Wireless Termination Points 73 (WTPs) by devices referred to as Access Controllers (ACs). For more 74 detail on this protocol and/or these components, see [LWAPP]. The 75 CAPWAP working group is currently considering using LWAPP as the 76 basis for a standardized AC-WTP control protocol (recommended in 77 [CAPWAP-EVAL]). 79 LWAPP currently includes security elements which provide for the 80 following capabilities: 82 o Endpoint Authentication - AC and WTP are strongly authenticated 83 using either public key certificates or shared secrets (also known 84 as "pre-shared keys"). 86 o Data Confidentiality - (AC-WTP control channel) data is encrypted 87 using the 128-bit AES-CBC algorithm. 89 o Data Integrity/Origin Authenticity - an Integrity Check Value 90 (ICV) is computed using 128-bit AES-CBC-MAC (a keyed MAC). 92 The current LWAPP security scheme has been through at least one 93 security review [LWAPP-SEC], the results of which were favorable. 94 Still, the protocol evaluation team concluded that LWAPP would 95 benefit from replacement of its proprietary security scheme with a 96 standardized, more widely deployed facility such as DTLS [DTLS]. 98 Why replace LWAPP's security mechanism, when so far, security 99 evaluations have not found it wanting? There are at least two good 100 reasons: 102 o Industry experience/review - to the chagrin of many protocol 103 designers, it has been often demonstrated that subtle security 104 flaws may escape the most diligent reviewer. As a result, the 105 cryptographic community invests significant effort in the ongoing 106 analysis of deployed (and proposed) security mechanisms. 107 Sometimes problems are found very quickly, but in other cases 108 issues my not be discovered for years. Thus, security protocols 109 and mechanisms which have been extensively deployed and analyzed 110 are almost always preferable to those which have not. 112 o Algorithm Agility - Because most cryptographic algorithms are 113 eventually either broken outright or rendered computationally 114 insufficient by advancing technology, it is crucial to have the 115 ability to easily replace outdated or compromised algorithms. 117 Note that LWAPP, while having gone through some security review, has 118 not yet provided the opportunity for the sort of extensive public 119 review and analysis that TLS [TLS11] has enjoyed. Also, LWAPP 120 provides no facility for algorithm negotiation - changing security 121 algorithms would require a change to the protocol standard, along 122 with firmware upgrades for both WTP and AC. This is clearly 123 undesirable. 125 DTLS, on the other hand, is a standards-track effort which is based 126 upon TLS. The underlying security-related protocol mechanisms have 127 been successfully deployed for many years now. The TLS protocol is 128 well-understood from an operational perspective, and with the recent 129 specification of its datagram-based variant, is an obvious choice for 130 meeting the security requirements of LWAPP. 132 2. Inserting DTLS 134 Note that for the time being, only the UDP transport mechanism for 135 LWAPP is considered. Since the evaluation document recommends 136 eliminating layer 2 encapsulation support, it is not addressed here. 137 Should this change, the mechanism described below in section 2.1.2 138 could be used to partially address that case. 140 From a high level, simple replacement of the LWAPP security 141 mechanisms with DTLS amounts to something like this: 143 1. Replace the JOIN phase with DTLS session establishment 145 2. Replace LWAPP re-key functionality with a DTLS re-key 147 3. Remove the existing LWAPP security scheme 149 This amounts to employing DTLS as a tightly-integrated secure 150 wrapper. Here is the resulting LWAPP state machine: 152 /-------------\ 153 | v 154 | +------------+ 155 | C| Idle |<--------------------------------------+ 156 | +------------+ | 157 | ^ |a ^ | 158 | | | \----\ y | 159 | | | | +-------------+------------+ z | 160 | | | | | | DTLS-rekey |-\ | 161 | | | | | +--------->+------------+ | | 162 | | | | | | | ^ 163 | | | |t V | x | | 164 | | | +--------+--+ +------------+ | | 165 | / | C| Run |------>| DTLS-Reset |<+--|----\ 166 | / | r+-----------+ u +------------+ | | | 167 | / | ^ ^ v| | | | 168 | | v | | | | | | 169 | | +--------------+ | /----/ V V | | 170 | | C| Discovery | q| o| +-------+ | | 171 | | b+--------------+ +-------------+ | Reset |-+ w | 172 | | |d f| ^ | Configure | +-------+ | 173 | | | | | +-------------+ | 174 | |e v | | ^ | 175 | +---------+ v |i 2| | 176 | C| Sulking | +------------+ +--------------+ | 177 | +---------+ C| DTLS-Init |--->| DTLS-Complete| | 178 | g+------------+ z +--------------+ | 179 | |h m| |4 | 180 | | | v o / 181 \ | | +------------+-------/ 182 \-----------------/ \------------->| Image Data |C 183 +------------+n 185 Figure 1: LWAPP State Machine w/DTLS Support 187 Following is a description of the associated state changes. Note 188 that we only address those which are new: 190 Discovery to DTLS-Init (f): This state is used by the WTP to confirm 191 its commitment to an AC that it wishes to be provided service, and to 192 simultaneously establish a secure control channel. 194 WTP: The WTP selects the best AC based on the information it 195 gathered during the Discovery Phase. It then initiates a DTLS 196 connection with its preferred AC. The WTP starts the WaitJoin 197 Timer. 199 AC: The AC enters this state for the given WTP upon reception of a 200 DTLS initialization request. The AC processes the request and 201 responds by engaging in DTLS negotiation with the WTP. 203 DTLS-Init to Discovery (i): This state is used to return the WTP to 204 discovery mode when an unresponsive AC is encountered. 206 WTP: The WTP enters this state when the WaitJoin timer expires 207 prior to successful completion of DTLS negotiation. 209 AC: This state transition is invalid. 211 DTLS-Init to DTLS-Complete (z): This state is used to indicate DTLS 212 session establishment. 214 WTP: This state is entered when the WTP and AC complete DTLS 215 negotiation. 217 AC: This state is entered when the WTP and AC complete DTLS 218 negotiation. 220 Run to DTLS-Reset (u): This state is used to when the AC or WTP wish 221 to tear down the connection. 223 WTP: The WTP enters this state when it wishes to initiate orderly 224 termination of the DTLS connection; the WTP sends the a TLS 225 Finished message. 227 AC: The AC enters this state upon receipt of TLS Finished message 228 from the WTP. 230 Image-data to DTLS-Reset (o): This state is used to reset the 231 connection prior to restarting the WTP after an image download. 233 WTP: The WTP enters this state when image download completes 235 AC: The AC enters this state upon receipt of TLS Finished message 236 from the WTP. 238 DTLS-Reset to Reset (v): This state is used to complete DTLS session 239 tear-down 241 WTP: The WTP enters this state when it has completed DTLS session 242 cleanup, and it is ready to finish LWAPP session clean-up. 244 AC: The AC enters this state when it has completed DTLS session 245 cleanup, and it is ready to finish LWAPP session clean-up. 247 Run to DTLS-Rekey (x): This state is used to initiate a new DTLS 248 handshake. Either the WTP or AC may initiate the state transition. 249 It is important to note that this might more accurately be termed a 250 "meta-state", as the DTLS re-handshake is transparent to the LWAPP 251 protocol, and may even be interpersed with other LWAPP control 252 messages. 254 WTP: The WTP enters this state when either (1) a rekey is 255 required, or (2) the AC initiates a DTLS handshake. 257 AC: The AC enters this state when either (1) a rekey is required, 258 or (2) the WTP initiates a DTLS handshake. 260 DTLS-Rekey to Reset (z): This state is used to clean up when a DTLS 261 handshake fails. 263 WTP: The WTP enters this state when a DTLS handshake fails. 265 AC: The AC enters this state when a DTLS handshake fails. 267 2.1. Control/Data Channel Considerations 269 Note that while this scheme seems quite simple at first glance, there 270 is one complication. Currently, LWAPP only applies security to 271 control channel communications, and relies upon external facilities 272 for securing user data. In order to preserve this convention, we 273 must be able to distinguish between control and data packets, 274 forwarding only control packets to the DTLS engine. 276 This task is complicated by the fact that LWAPP currently 277 distinguishes between control and data traffic using the 'C' bit in 278 the LWAPP header. This is possible even on the encrypted control 279 channel because the LWAPP header is not encrypted - in the case of 280 the control channel, it is only authenticated: 282 +--------+---------+-----------+-------------------------+-----------+ 283 | IP Hdr | UDP Hdr | LWAPP Hdr | Data | LWAPP Tlr | 284 +--------+---------+-----------+-------------------------+-----------+ 285 \------ encrypted ------/ 286 \-------- authenticated -----------/ 288 Figure 2: Current LWAPP Packet Security 290 DTLS, on the other hand, provides for securing the entire channel. 291 If the LWAPP packets are encapsulated within DTLS, the LWAPP header 292 will be encrypted: 294 +--------+---------+---------+-----------+-------------+----------+ 295 | IP Hdr | UDP Hdr |DTLS Hdr | LWAPP Hdr | Data | DTLS Tlr | 296 +--------+---------+---------+-----------+-------------+----------+ 297 \--------- authenticated ---------/ 298 \------------ encrypted -----------/ 300 Figure 3: LWAPP+DTLS Packet Security 302 A direct consequence of this is that with DTLS encapsulation, we 303 cannot distinguish between control traffic and data without first 304 decrypting the packet - this means we must establish separate 305 channels if we do not wish to encrypt data channel traffic. Two 306 methods for accomplishing this are discussed below. 308 2.1.1. Separate Control/Data Channel Ports 310 The simplest solution entails using separate ports for LWAPP control 311 and data traffic, with DTLS securing only the control channel. The 312 control traffic could continue to utilize the current well-known 313 LWAPP port. For the data channel, a new port could be assigned by 314 IANA, or it could instead be specified by the AC after the DTLS 315 session is established, providing some additional flexibility. Note 316 that this solution will not work for layer 2 LWAPP encapsulation. 317 However, if L2 support is to be removed from LWAPP, this point is 318 moot. 320 2.1.2. Adding a Protocol Mux 322 An alternative solution entails adding a protocol multiplexer module 323 between the packet input/output and the DTLS modules, and adding an 324 additional small associated LWAPP header between the UDP header and 325 the DTLS record layer header. While this LWAPP header need only 326 contain a single bit to differentiate between control/data traffic, 327 alignment concerns suggest the header would most likely be either 32 328 or 64 bits in length. 330 3. Endpoint Authentication using DTLS 332 Currently, LWAPP supports authentication using either public key 333 certificates or shared secrets (pre-shared keys). DTLS support 334 implies no changes in this regard. Certificate-based authentication 335 is natively supported, and support for preshared keys is currently 336 progressing toward standardization (see [TLS-PSK]). Below we 337 describe supported TLS algorithm suites for each endpoint 338 authentication method. 340 3.1. Authenticating with Certificates 342 Note that only block ciphers are currently recommended for use with 343 DTLS. To understand the reasoning behind this, see [DTLS-DESIGN]. 344 The following algorithms MUST be supported when using certificates 345 for LWAPP authentication: 347 o TLS_RSA_WITH_AES_128_CBC_SHA 349 o TLS_RSA_WITH_3DES_EDE_CBC_SHA 351 The following algorithms SHOULD be supported when using certificates: 353 o TLS_DH_RSA_WITH_AES_128_CBC_SHA 355 o TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA 357 The following algorithms MAY be supported when using certificates: 359 o TLS_RSA_WITH_AES_256_CBC_SHA 361 o TLS_DH_RSA_WITH_AES_256_CBC_SHA 363 Certificates should be verified in the same manner as currently 364 specified in LWAPP. 366 3.2. Authenticating with Preshared Keys 368 Pre-shared keys present significant challenges from a security 369 perspective, and for that reason, their use is strongly discouraged. 370 However, [TLS-PSK] defines 3 different methods for authenticating 371 with preshared keys: 373 o PSK key exchange algorithm - simplest method, ciphersuites use 374 only symmetric key algorithms 376 o DHE_PSK key exchange algorithm - use a PSK to authenticate a 377 Diffie-Hellman exchange. These ciphersuites give some additional 378 protection against dictionary attacks and also provide Perfect 379 Forward Secrecy (PFS). 381 o RSA_PSK key exchange algorithm - use RSA and certificates to 382 authenticate the server, in addition to using a PSK. Not 383 susceptible to passive attacks. 385 The first approach (PSK) is susceptible to passive dictionary 386 attacks; hence, that method MUST NOT be used. If support for pre- 387 shared keys is desired, then DHE_PSK MUST be supported, and RSA_PSK 388 MAY be supported. 390 The following cryptographic algorithms MUST be supported when using 391 preshared keys: 393 o TLS_PSK_WITH_AES_128_CBC_SHA 395 o TLS_PSK_WITH_3DES_EDE_CBC_SHA 397 The following algorithms SHOULD be supported when using preshared 398 keys: 400 o TLS_PSK_WITH_AES_256_CBC_SHA 402 The following algorithms MAY be supported when using preshared keys: 404 o TLS_RSA_PSK_WITH_AES_128_CBC_SHA 406 o TLS_RSA_PSK_WITH_AES_256_CBC_SHA 408 o TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA 410 4. Conclusions 412 DTLS represents a strong replacement candidate for the existing LWAPP 413 security scheme. In addition to being a known quantity which has 414 received and will continue to receive a healthy dose of ongoing 415 analysis and review from the cryptographic community, it supports all 416 required LWAPP security functionality, and also provides for 417 algorithm agility should the need arise. Further, its negotiation 418 capability provides for a measure of implementation flexibility not 419 possible with the current LWAPP scheme. 421 While it is not a drop-in replacement, it requires a reasonably 422 bounded amount of change to the existing state machine and packet 423 formats. As noted, since DTLS does not provide for unequal 424 encryption vs authentication lengths within a packet, it requires 425 adding either a secondary data port or a short demux header. 427 5. Security Considerations 429 The security of LWAPP over DTLS is completely dependent on the 430 security of DTLS. Any flaws in DTLS compromise the security of 431 LWAPP. In particular, it is critical that the communicating parties 432 verify their peer's credentials. In the case of pre-shared keys, 433 this happens automatically via the key. In the case of certificates, 434 the parties must check the peer's certificate. The appropriate 435 checks are described in the current LWAPP document 437 The use of parallel protected and unprotected channels deserves 438 special consideration, but does not create a threat. There are two 439 potential concerns: attempting to convert protected data into un- 440 protected data and attempting to convert un-protected data into 441 protected data. The use of the MAC makes it impossible for the 442 attacker to forge protected records. The attacker can easily remove 443 protected records from the stream (this is a consequence of 444 unreliability), though not undetectably so. If a non-encrypted 445 cipher suite is in use, the attacker can turn such a record into an 446 un-protected record. However, this attack is really no different 447 from simple injection into the unprotected stream. 449 6. IANA Considerations 451 Should a separate UDP port for data channel communications be the 452 selected demultiplexing mechanism, a port must be assigned for this 453 purpose. Should a demultiplexing header be used instead, there may 454 be additional IANA requirements (we'll cross that bridge if we come 455 to it). 457 7. References 459 7.1. Normative References 461 [DTLS] Rescorla et al, E., "Datagram Transport Layer Security", 462 June 2004. 464 [LWAPP] Calhoun et al, P., "Light Weight Access Point Protocol", 465 June 2005, . 467 [TLS-PSK] Eronen et al, P., "Pre-Shared Key Ciphersuites for 468 Transport Layer Security (TLS)", June 2005. 470 7.2. Informative References 472 [CAPWAP-EVAL] 473 Lohrer et al, D., "Evaluation of Candidate CAPWAP 474 Protocols", August 2005, . 476 [DTLS-DESIGN] 477 Modadugu et al, N., "The Design and Implementation of 478 Datagram TLS", Feb 2004. 480 [LWAPP-SEC] 481 Clancy, C., "Security Review of the Light Weight Access 482 Point Protocol", May 2005. 484 [TLS11] Dierks et al, T., "The TLS Protocol Version 1.1", 485 June 2005. 487 Authors' Addresses 489 Scott G. Kelly 490 Talari Networks 491 150 W. Iowa Ave Ste 208 492 Sunnyvale, CA 94086 493 US 495 Email: scott@hyperthought.com 497 Eric Rescorla 498 Network Resonance 499 2483 El Camino Real, #212 500 Palo Alto, CA 94303 501 US 503 Email: ekr@networkresonance.com 505 Intellectual Property Statement 507 The IETF takes no position regarding the validity or scope of any 508 Intellectual Property Rights or other rights that might be claimed to 509 pertain to the implementation or use of the technology described in 510 this document or the extent to which any license under such rights 511 might or might not be available; nor does it represent that it has 512 made any independent effort to identify any such rights. Information 513 on the procedures with respect to rights in RFC documents can be 514 found in BCP 78 and BCP 79. 516 Copies of IPR disclosures made to the IETF Secretariat and any 517 assurances of licenses to be made available, or the result of an 518 attempt made to obtain a general license or permission for the use of 519 such proprietary rights by implementers or users of this 520 specification can be obtained from the IETF on-line IPR repository at 521 http://www.ietf.org/ipr. 523 The IETF invites any interested party to bring to its attention any 524 copyrights, patents or patent applications, or other proprietary 525 rights that may cover technology that may be required to implement 526 this standard. Please address the information to the IETF at 527 ietf-ipr@ietf.org. 529 Disclaimer of Validity 531 This document and the information contained herein are provided on an 532 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 533 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 534 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 535 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 536 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 537 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 539 Copyright Statement 541 Copyright (C) The Internet Society (2005). This document is subject 542 to the rights, licenses and restrictions contained in BCP 78, and 543 except as set forth therein, the authors retain all their rights. 545 Acknowledgment 547 Funding for the RFC Editor function is currently provided by the 548 Internet Society.