idnits 2.17.1 draft-ietf-tsvwg-dtls-for-sctp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (March 22, 2010) is 5141 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: 3 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: September 23, 2010 E. Rescorla 6 RTFM, Inc. 7 March 22, 2010 9 Datagram Transport Layer Security (DTLS) for Stream Control Transmission 10 Protocol (SCTP) 11 draft-ietf-tsvwg-dtls-for-sctp-05.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 Security features provided by DTLS over SCTP include authentication, 20 message integrity and privacy of user messages. Applications using 21 DTLS over SCTP can use almost all transport features provided by SCTP 22 and its extensions. 24 Status of this Memo 26 This Internet-Draft is submitted to IETF in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 This Internet-Draft will expire on September 23, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . . 4 66 4. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 69 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 1.1. Overview 79 This document describes the usage of the Datagram Transport Layer 80 Security (DTLS) protocol, as defined in [RFC4347], over the Stream 81 Control Transmission Protocol (SCTP), as defined in [RFC4960]. 83 Security features provided by DTLS over SCTP include authentication, 84 message integrity and privacy of user messages. Applications using 85 DTLS over SCTP can use almost all transport features provided by SCTP 86 and its extensions. 88 TLS, from which DTLS was derived, is designed to run on top of a 89 byte-stream oriented transport protocol providing a reliable, in- 90 sequence delivery. Thus, TLS is currently mainly being used on top 91 of the Transmission Control Protocol (TCP), as defined in [RFC0793]. 93 TLS over SCTP as described in [RFC3436] has some serious limitations: 95 o It does not support the unordered delivery of SCTP user messages. 97 o It does not support partial reliability as defined in [RFC3758]. 99 o It only supports the usage of the same number of streams in both 100 directions. 102 o It uses a TLS connection for every bidirectional stream, which 103 requires a substantial amount of resources and message exchanges 104 if a large number of streams is used. 106 DTLS over SCTP as described in this document overcomes these 107 limitations of TLS over SCTP. Especially DTLS/SCTP supports 109 o preservation of message boundaries. 111 o a large number of uni-directional and bi-directional streams. 113 o ordered and unordered delivery of SCTP user messages. 115 o the partial reliability extension as defined in [RFC3758]. 117 o the dynamic address reconfiguration extension as defined in 118 [RFC5061]. 120 However, the following limitations still apply: 122 o The maximum user message size is 2^14 bytes, which is the DTLS 123 limit. 125 o The DTLS user can not perform the SCTP-AUTH key management, 126 because this is done by the DTLS layer. 128 The method described in this document requires that the SCTP 129 implementation supports the optional feature of fragmentation of SCTP 130 user messages as defined in [RFC4960] and the SCTP authentication 131 extension defined in [RFC4895]. 133 1.2. Terminology 135 This document uses the following terms: 137 Association: An SCTP association. 139 Stream: A unidirectional stream of an SCTP association. It is 140 uniquely identified by a stream identifier. 142 1.3. Abbreviations 144 DTLS: Datagram Transport Layer Security. 146 MTU: Maximum Transmission Unit. 148 PPID: Payload Protocol Identifier. 150 SCTP: Stream Control Transmission Protocol. 152 TCP: Transmission Control Protocol. 154 TLS: Transport Layer Security. 156 2. Conventions 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in [RFC2119]. 162 3. DTLS Considerations 164 3.1. Future Versions of DTLS 166 This document is based on [RFC4347]. If a new RFC updates or 167 obsoletes [RFC4347], this documents also applies to the newer 168 document defining DTLS unless this document also gets updated or 169 revised. 171 3.2. Message Sizes 173 DTLS limits the DTLS user message size to the current Path MTU minus 174 the header sizes. This limit SHOULD be increased to 2^14 Bytes for 175 DTLS over SCTP. 177 3.3. Replay Detection 179 Replay detection of DTLS MUST NOT be used. 181 3.4. Path MTU Discovery 183 Path MTU discovery of DTLS MUST NOT be used. 185 3.5. Retransmission of Messages 187 DTLS procedures for retransmissions MUST NOT be used. 189 4. SCTP Considerations 191 4.1. Mapping of DTLS Records 193 The supported maximum length of SCTP user messages MUST be at least 194 2^14 + 2048 + 13 = 18445 bytes (2^14 + 2048 is the maximum length of 195 the DTLSCiphertext.fragment and 13 is the size of the DTLS record 196 header). In particular, the SCTP implementation MUST support 197 fragmentation of user messages. 199 Every SCTP user message MUST consist of exactly one DTLS record. 201 4.2. DTLS connection handling 203 Each DTLS connection MUST be established and terminated within the 204 same SCTP association. A DTLS connection MUST NOT span multiple SCTP 205 associations. 207 4.3. Payload Protocol Identifier Usage 209 Application protocols running over DTLS over SCTP SHOULD register and 210 use a separate payload protocol identifier (PPID) and SHOULD NOT 211 reuse the PPID that they registered for running directly over SCTP. 213 This means in particular that there is no specific PPID for DTLS. 215 4.4. Stream Usage 217 All DTLS messages of the ChangeCipherSpec, Alert, or Handshake 218 protocol MUST be transported on stream 0 with unlimited reliability 219 and with the ordered delivery feature. 221 All DTLS messages of the ApplicationData protocol MAY be transported 222 over stream 0, but users SHOULD use other streams to avoid possible 223 performance problems due to head of line blocking. 225 4.5. Chunk Handling 227 DATA chunks of SCTP MUST be sent in an authenticated way as described 228 in [RFC4895]. Other chunks MAY be sent in an authenticated way. 229 This makes sure that an attacker can not modify the stream in which a 230 message is sent in or affect the ordered/unordered delivery of the 231 message. 233 If PR-SCTP as defined in [RFC3758] is used, FORWARD-TSN chunks MUST 234 also be sent in an authenticated way as described in [RFC4895]. This 235 makes sure that it is not possible for an attacker to drop messages 236 and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this 237 dropping. 239 4.6. Handshake 241 A DTLS implementation discards DTLS messages from older epochs after 242 some time, as described in section 4.1 of [RFC4347]. This is not 243 acceptable when the DTLS user performs a reliable data transfer. To 244 avoid discarding messages, the following procedures are required. 246 Before sending a ChangeCipherSpec message all outstanding SCTP user 247 messages MUST have been acknowledged by the SCTP peer and MUST NOT be 248 revoked anymore by the SCTP peer. 250 Prior to processing a received ChangeCipherSpec all other received 251 SCTP user messages that are buffered in the SCTP layer MUST be read 252 and processed by DTLS. 254 User messages arriving between ChangeCipherSpec and Finished using 255 the new epoch have probably passed the Finished and MUST be buffered 256 by DTLS until the Finished is read. 258 4.7. Handling of Endpoint-pair Shared Secrets 260 The endpoint-pair shared secret for Shared Key Identifier 0 is empty 261 and MUST be used when establishing a DTLS connection. Whenever the 262 master key changes, a 64 byte shared secret is derived from every 263 master secret and provided as a new end-point pair shared secret by 264 using the exporter described in [RFC5705]. The exporter MUST use the 265 label given in Section 5 and no context. The new Shared Key 266 Identifier MUST be the old Shared Key Identifier incremented by 1. 267 If the old one is 65535, the new one MUST be 1. 269 Before sending the Finished message the active SCTP-AUTH key MUST be 270 switched to the new one. 272 Once the corresponding Finished message from the peer has been 273 received, the old SCTP-AUTH key SHOULD be removed. 275 4.8. Shutdown 277 To prevent DTLS from discarding DTLS user messages while it is 278 shutting down, a CloseNotify message MUST only be sent after all 279 outstanding SCTP user messages have been acknowledged by the SCTP 280 peer and MUST NOT still be revoked by the SCTP peer. 282 Prior to processing a received CloseNotify all other received SCTP 283 user messages that are buffered in the SCTP layer MUST be read and 284 processed by DTLS. 286 5. IANA Considerations 288 IANA needs to add a value to the TLS Exporter Label registry as 289 described in [RFC5705]. The label suggested is 290 "EXPORTER_DTLS_OVER_SCTP". The reference should refer to this 291 document. 293 6. Security Considerations 295 The security considerations given in [RFC4347], [RFC4895], and 296 [RFC4960] also apply to this document. 298 It is possible to authenticate DTLS endpoints based on IP-addresses 299 in certificates. SCTP associations can use multiple addresses per 300 SCTP endpoint. Therefore it is possible that DTLS records will be 301 sent from a different IP-address than that originally authenticated. 302 This is not a problem provided that no security decisions are made 303 based on that IP-address. This is a special case of a general rule: 304 all decisions should be based on the peer's authenticated identity, 305 not on its transport layer identity. 307 For each message, the SCTP user also provides a stream identifier, a 308 flag to indicate whether the message is sent ordered or unordered and 309 a payload protocol identifier. Although DTLS can be used to provide 310 privacy for the actual user message, none of these three are 311 protected by DTLS. They are sent as clear text, because they are 312 part of the SCTP DATA chunk header. 314 7. Acknowledgments 316 The authors wish to thank Carsten Hohendorf, Alfred Hoenes, Daniel 317 Mentz, Ian Goldberg, Anna Brunstrom, Stefan Lindskog, and Gorry 318 Fairhurst for their invaluable comments. 320 8. References 322 8.1. Normative References 324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 325 Requirement Levels", BCP 14, RFC 2119, March 1997. 327 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 328 Conrad, "Stream Control Transmission Protocol (SCTP) 329 Partial Reliability Extension", RFC 3758, May 2004. 331 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 332 "Authenticated Chunks for the Stream Control Transmission 333 Protocol (SCTP)", RFC 4895, August 2007. 335 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 336 RFC 4960, September 2007. 338 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 339 Security", RFC 4347, April 2006. 341 [RFC5705] Rescorla, E., "Keying Material Exporters for Transport 342 Layer Security (TLS)", RFC 5705, March 2010. 344 8.2. Informative References 346 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 347 RFC 793, September 1981. 349 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 350 Layer Security over Stream Control Transmission Protocol", 351 RFC 3436, December 2002. 353 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 354 Kozuka, "Stream Control Transmission Protocol (SCTP) 355 Dynamic Address Reconfiguration", RFC 5061, 356 September 2007. 358 Authors' Addresses 360 Michael Tuexen 361 Muenster Univ. of Applied Sciences 362 Stegerwaldstr. 39 363 48565 Steinfurt 364 Germany 366 Email: tuexen@fh-muenster.de 368 Robin Seggelmann 369 Muenster Univ. of Applied Sciences 370 Stegerwaldstr. 39 371 48565 Steinfurt 372 Germany 374 Email: seggelmann@fh-muenster.de 376 Eric Rescorla 377 RTFM, Inc. 378 2064 Edgewood Drive 379 Palo Alto, CA 94303 380 USA 382 Email: ekr@networkresonance.com