idnits 2.17.1 draft-ietf-tsvwg-dtls-for-sctp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (September 1, 2010) is 4979 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) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Tuexen 3 Internet-Draft R. Seggelmann 4 Intended status: Standards Track Muenster Univ. of Applied Sciences 5 Expires: March 5, 2011 E. Rescorla 6 RTFM, Inc. 7 September 1, 2010 9 Datagram Transport Layer Security (DTLS) for Stream Control Transmission 10 Protocol (SCTP) 11 draft-ietf-tsvwg-dtls-for-sctp-06.txt 13 Abstract 15 This document describes the usage of the Datagram Transport Layer 16 Security (DTLS) protocol over the Stream Control Transmission 17 Protocol (SCTP). 19 DTLS over SCTP provides communications privacy for applications that 20 use SCTP as its transport protocol and allows client/server 21 applications to communicate in a way that is designed to prevent 22 eavesdropping and detect tampering or message forgery. 24 Applications using DTLS over SCTP can use almost all transport 25 features provided by SCTP and its extensions. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 5, 2011. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . . 4 64 4. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . . 5 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 1. Introduction 75 1.1. Overview 77 This document describes the usage of the Datagram Transport Layer 78 Security (DTLS) protocol, as defined in [RFC4347], over the Stream 79 Control Transmission Protocol (SCTP), as defined in [RFC4960]. 81 DTLS over SCTP provides communications privacy for applications that 82 use SCTP as its transport protocol and allows client/server 83 applications to communicate in a way that is designed to prevent 84 eavesdropping and detect tampering or message forgery. 86 Applications using DTLS over SCTP can use almost all transport 87 features provided by SCTP and its extensions. 89 TLS, from which DTLS was derived, is designed to run on top of a 90 byte-stream oriented transport protocol providing a reliable, in- 91 sequence delivery. Thus, TLS is currently mainly being used on top 92 of the Transmission Control Protocol (TCP), as defined in [RFC0793]. 94 TLS over SCTP as described in [RFC3436] has some serious limitations: 96 o It does not support the unordered delivery of SCTP user messages. 98 o It does not support partial reliability as defined in [RFC3758]. 100 o It only supports the usage of the same number of streams in both 101 directions. 103 o It uses a TLS connection for every bidirectional stream, which 104 requires a substantial amount of resources and message exchanges 105 if a large number of streams is used. 107 DTLS over SCTP as described in this document overcomes these 108 limitations of TLS over SCTP. Especially DTLS/SCTP supports 110 o preservation of message boundaries. 112 o a large number of uni-directional and bi-directional streams. 114 o ordered and unordered delivery of SCTP user messages. 116 o the partial reliability extension as defined in [RFC3758]. 118 o the dynamic address reconfiguration extension as defined in 119 [RFC5061]. 121 However, the following limitations still apply: 123 o The maximum user message size is 2^14 bytes, which is the DTLS 124 limit. 126 o The DTLS user cannot perform the SCTP-AUTH key management, because 127 this is done by the DTLS layer. 129 The method described in this document requires that the SCTP 130 implementation supports the optional feature of fragmentation of SCTP 131 user messages as defined in [RFC4960] and the SCTP authentication 132 extension defined in [RFC4895]. 134 1.2. Terminology 136 This document uses the following terms: 138 Association: An SCTP association. 140 Stream: A unidirectional stream of an SCTP association. It is 141 uniquely identified by a stream identifier. 143 1.3. Abbreviations 145 DTLS: Datagram Transport Layer Security. 147 MTU: Maximum Transmission Unit. 149 PPID: Payload Protocol Identifier. 151 SCTP: Stream Control Transmission Protocol. 153 TCP: Transmission Control Protocol. 155 TLS: Transport Layer Security. 157 2. Conventions 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 3. DTLS Considerations 164 3.1. Version of DTLS 166 This document is based on [RFC4347] and it is expected that DTLS/SCTP 167 as described in this document will work with future versions of DTLS. 169 3.2. Message Sizes 171 DTLS limits the DTLS user message size to the current Path MTU minus 172 the header sizes. For the purposes of running over SCTP, the DTLS 173 path MTU MUST be considered to be 2^14. 175 3.3. Replay Detection 177 The replay detection of DTLS may result in the DTLS layer dropping 178 messages. Since DTLS/SCTP provides a reliable service if requested 179 by the application, replay detection cannot be used. Therefore, 180 replay detection of DTLS MUST NOT be used. 182 3.4. Path MTU Discovery 184 SCTP provides Path MTU discovery and fragmentation / reassembly for 185 user-messages. According to Section 3.2 DTLS can send maximum sized 186 messages. Therefore, Path MTU discovery of DTLS MUST NOT be used. 188 3.5. Retransmission of Messages 190 SCTP provides a reliable and in-sequence transport service for DTLS 191 messages which require it. See Section 4.4. Therefore, DTLS 192 procedures for retransmissions MUST NOT be used. 194 4. SCTP Considerations 196 4.1. Mapping of DTLS Records 198 The supported maximum length of SCTP user messages MUST be at least 199 2^14 + 2048 + 13 = 18445 bytes (2^14 + 2048 is the maximum length of 200 the DTLSCiphertext.fragment and 13 is the size of the DTLS record 201 header). In particular, the SCTP implementation MUST support 202 fragmentation of user messages. 204 Every SCTP user message MUST consist of exactly one DTLS record. 206 4.2. DTLS connection handling 208 Each DTLS connection MUST be established and terminated within the 209 same SCTP association. A DTLS connection MUST NOT span multiple SCTP 210 associations. 212 4.3. Payload Protocol Identifier Usage 214 Application protocols running over DTLS over SCTP SHOULD register and 215 use a separate payload protocol identifier (PPID) and SHOULD NOT 216 reuse the PPID that they registered for running directly over SCTP. 218 Using the same PPID does not harm as long as the application can 219 determine whether DTLS is used or not. However, for protocol 220 analyzers, for example, it is much easier if a separate PPID is used. 222 This means in particular that there is no specific PPID for DTLS. 224 4.4. Stream Usage 226 All DTLS messages of the ChangeCipherSpec, Alert, or Handshake 227 protocol MUST be transported on stream 0 with unlimited reliability 228 and with the ordered delivery feature. 230 DTLS messages of the ApplicationData protocol SHOULD use multiple 231 streams other than stream 0; they MAY use stream 0 for everything if 232 they do note care about minimizing head of line blocking. 234 4.5. Chunk Handling 236 DATA chunks of SCTP MUST be sent in an authenticated way as described 237 in [RFC4895]. Other chunks MAY be sent in an authenticated way. 238 This makes sure that an attacker cannot modify the stream in which a 239 message is sent in or affect the ordered/unordered delivery of the 240 message. 242 If PR-SCTP as defined in [RFC3758] is used, FORWARD-TSN chunks MUST 243 also be sent in an authenticated way as described in [RFC4895]. This 244 makes sure that it is not possible for an attacker to drop messages 245 and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this 246 dropping. 248 4.6. Renegotiation 250 DTLS supports renegotiation and therefore this feature is also 251 available by DTLS/SCTP. It is up to the upper layer to use/allow it 252 or not. Application writers should be aware that allowing 253 renegotiations may result in changes of security parameters. 255 4.7. Handshake 257 A DTLS implementation discards DTLS messages from older epochs after 258 some time, as described in section 4.1 of [RFC4347]. This is not 259 acceptable when the DTLS user performs a reliable data transfer. To 260 avoid discarding messages, the following procedures are required. 262 Before sending a ChangeCipherSpec message all outstanding SCTP user 263 messages MUST have been acknowledged by the SCTP peer and MUST NOT be 264 revoked by the SCTP peer. 266 Prior to processing a received ChangeCipherSpec all other received 267 SCTP user messages that are buffered in the SCTP layer MUST be read 268 and processed by DTLS. 270 User messages arriving between ChangeCipherSpec and Finished using 271 the new epoch have probably passed the Finished and MUST be buffered 272 by DTLS until the Finished is read. 274 4.8. Handling of Endpoint-pair Shared Secrets 276 The endpoint-pair shared secret for Shared Key Identifier 0 is empty 277 and MUST be used when establishing a DTLS connection. Whenever the 278 master key changes, a 64 byte shared secret is derived from every 279 master secret and provided as a new end-point pair shared secret by 280 using the exporter described in [RFC5705]. The exporter MUST use the 281 label given in Section 5 and no context. The new Shared Key 282 Identifier MUST be the old Shared Key Identifier incremented by 1. 283 If the old one is 65535, the new one MUST be 1. 285 Before sending the Finished message the active SCTP-AUTH key MUST be 286 switched to the new one. 288 Once the corresponding Finished message from the peer has been 289 received, the old SCTP-AUTH key SHOULD be removed. 291 4.9. Shutdown 293 To prevent DTLS from discarding DTLS user messages while it is 294 shutting down, a CloseNotify message MUST only be sent after all 295 outstanding SCTP user messages have been acknowledged by the SCTP 296 peer and MUST NOT still be revoked by the SCTP peer. 298 Prior to processing a received CloseNotify all other received SCTP 299 user messages that are buffered in the SCTP layer MUST be read and 300 processed by DTLS. 302 5. IANA Considerations 304 IANA needs to add a value to the TLS Exporter Label registry as 305 described in [RFC5705]. The label suggested is 306 "EXPORTER_DTLS_OVER_SCTP". The reference should refer to this 307 document. 309 6. Security Considerations 311 The security considerations given in [RFC4347], [RFC4895], and 312 [RFC4960] also apply to this document. 314 It is possible to authenticate DTLS endpoints based on IP-addresses 315 in certificates. SCTP associations can use multiple addresses per 316 SCTP endpoint. Therefore it is possible that DTLS records will be 317 sent from a different IP-address than that originally authenticated. 318 This is not a problem provided that no security decisions are made 319 based on that IP-address. This is a special case of a general rule: 320 all decisions should be based on the peer's authenticated identity, 321 not on its transport layer identity. 323 For each message, the SCTP user also provides a stream identifier, a 324 flag to indicate whether the message is sent ordered or unordered and 325 a payload protocol identifier. Although DTLS can be used to provide 326 privacy for the actual user message, none of these three are 327 protected by DTLS. They are sent as clear text, because they are 328 part of the SCTP DATA chunk header. 330 DTLS supports cipher suites that contain a NULL cipher algorithm. 331 Negotiating a NULL cipher algorithm will not provide communications 332 privacy for applications and will not provide privacy for user 333 messages. 335 7. Acknowledgments 337 The authors wish to thank Anna Brunstrom, Lars Eggert, Gorry 338 Fairhurst, Ian Goldberg, Alfred Hoenes, Carsten Hohendorf, Stefan 339 Lindskog, Daniel Mentz, and Sean Turner for their invaluable 340 comments. 342 8. References 344 8.1. Normative References 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 350 Conrad, "Stream Control Transmission Protocol (SCTP) 351 Partial Reliability Extension", RFC 3758, May 2004. 353 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 354 "Authenticated Chunks for the Stream Control Transmission 355 Protocol (SCTP)", RFC 4895, August 2007. 357 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 358 RFC 4960, September 2007. 360 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 361 Security", RFC 4347, April 2006. 363 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 364 Layer Security (TLS)", RFC 5705, March 2010. 366 8.2. Informative References 368 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 369 RFC 793, September 1981. 371 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 372 Layer Security over Stream Control Transmission Protocol", 373 RFC 3436, December 2002. 375 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 376 Kozuka, "Stream Control Transmission Protocol (SCTP) 377 Dynamic Address Reconfiguration", RFC 5061, 378 September 2007. 380 Authors' Addresses 382 Michael Tuexen 383 Muenster University of Applied Sciences 384 Stegerwaldstr. 39 385 48565 Steinfurt 386 Germany 388 Email: tuexen@fh-muenster.de 390 Robin Seggelmann 391 Muenster University of Applied Sciences 392 Stegerwaldstr. 39 393 48565 Steinfurt 394 Germany 396 Email: seggelmann@fh-muenster.de 397 Eric Rescorla 398 RTFM, Inc. 399 2064 Edgewood Drive 400 Palo Alto, CA 94303 401 USA 403 Email: ekr@networkresonance.com