idnits 2.17.1 draft-ietf-tsvwg-dtls-for-sctp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (October 23, 2009) is 5298 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) == Outdated reference: A later version (-06) exists of draft-ietf-tls-rfc4347-bis-03 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: April 26, 2010 E. Rescorla 6 RTFM, Inc. 7 October 23, 2009 9 Datagram Transport Layer Security for Stream Control Transmission 10 Protocol 11 draft-ietf-tsvwg-dtls-for-sctp-02.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and 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 April 26, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document describes the usage of the Datagram Transport Layer 50 Security (DTLS) protocol over the Stream Control Transmission 51 Protocol (SCTP). 53 The user of DTLS over SCTP can take advantage of most of the features 54 provided by SCTP and its extensions, especially support of 56 o multi-homing to provide network level fault tolerance. 58 o dynamic reconfiguration of IPv4 and IPv6 addresses. 60 o multiple streams to avoid head of line blocking. 62 o unordered delivery. 64 o dynamic reconfiguration of streams. 66 o partially reliable data transfer. 68 However, the DTLS maximum user message size limit of 2^14 bytes 69 applies also to DTLS over SCTP. Since DTLS over SCTP uses the SCTP- 70 AUTH extension, the DTLS user can not manage the keying material, 71 since this is done by the DTLS layer. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . . 5 78 4. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . . 6 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 81 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 87 1. Introduction 89 1.1. Overview 91 This document describes the usage of the Datagram Transport Layer 92 Security (DTLS) protocol, as defined in [I-D.ietf-tls-rfc4347-bis], 93 over the Stream Control Transmission Protocol (SCTP), as defined in 94 [RFC4960]. 96 TLS, from which DTLS was derived, is designed to run on top of a 97 byte-stream oriented transport protocol providing a reliable, in- 98 sequence delivery. Thus, TLS is currently mainly being used on top 99 of the Transmission Control Protocol (TCP), as defined in [RFC0793]. 101 TLS over SCTP as described in [RFC3436] has some serious limitations: 103 o It does not support the unordered delivery of SCTP user messages. 105 o It does not support partial reliability as defined in [RFC3758]. 107 o It only supports the usage of the same number of streams in both 108 directions. 110 o It uses a TLS connection for every bidirectional stream, which 111 requires a substantial amount of resources and message exchanges 112 if a large number of streams is used. 114 DTLS over SCTP as described in this document overcomes these 115 limitations of TLS over SCTP. The user of DTLS over SCTP can use 116 almost all services provided by SCTP and its partial reliability 117 extension. However, DTLS limits the user message size to 2^14 bytes. 118 The dynamic modification of the IP-addresses used by the SCTP end- 119 points is also supported. The same applies to the dynamic 120 reconfiguration of streams. The DTLS user can request SCTP chunk 121 types to be authenticated by using SCTP-AUTH as defined in [RFC4895]. 122 However, the DTLS user can not perform the SCTP-AUTH key management, 123 because this is done by the DTLS layer. 125 The method described in this document requires that the SCTP 126 implementation supports the optional feature of fragmentation of SCTP 127 user messages and the SCTP authentication extension defined in 128 [RFC4895]. 130 1.2. Terminology 132 This document uses the following terms: 134 Association: An SCTP association. 136 Stream: A unidirectional stream of an SCTP association. It is 137 uniquely identified by a stream identifier. 139 1.3. Abbreviations 141 DTLS: Datagram Transport Layer Security. 143 MTU: Maximum Transmission Unit. 145 PPID: Payload Protocol Identifier. 147 SCTP: Stream Control Transmission Protocol. 149 TCP: Transmission Control Protocol. 151 TLS: Transport Layer Security. 153 2. Conventions 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 3. DTLS Considerations 161 3.1. Message Sizes 163 DTLS limits the DTLS user message size to the current Path MTU minus 164 the header sizes. This limit SHOULD be increased to 2^14 Bytes for 165 DTLS over SCTP. 167 3.2. Replay Detection 169 Replay detection of DTLS MUST NOT be used. 171 3.3. Path MTU Discovery 173 Path MTU discovery of DTLS MUST NOT be used. 175 3.4. Retransmission of Messages 177 DTLS procedures for retransmissions MUST NOT be used. 179 4. SCTP Considerations 181 4.1. Mapping of DTLS Records 183 The supported maximum length of SCTP user messages MUST be at least 184 2^14 + 2048 + 13 = 18445 bytes (2^14 + 2048 is the maximum length of 185 the DTLSCiphertext.fragment and 13 is the size of the DTLS record 186 header). In particular, the SCTP implementation MUST support 187 fragmentation of user messages. 189 Every SCTP user message MUST consist of exactly one DTLS record. 191 4.2. Payload Protocol Identifier Usage 193 Application protocols running over DTLS over SCTP SHOULD register and 194 use a separate payload protocol identifier (PPID) and SHOULD NOT 195 reuse the PPID which they registered for running directly over SCTP. 197 This means in particular that there is no specific PPID for DTLS. 199 4.3. Stream Usage 201 All DTLS messages of the ChangeCipherSpec, Alert, or Handshake 202 protocol MUST be transported on stream 0 with unlimited reliability 203 and with the ordered delivery feature. 205 All DTLS messages of the ApplicationData protocol MAY be transported 206 over stream 0 but users SHOULD use other streams to avoid possible 207 performance problems due to head of line blocking. 209 4.4. Chunk Handling 211 The DATA, SACK, SHUTDOWN, and FORWARD-TSN chunks of SCTP MUST be sent 212 in an authenticated way as described in [RFC4895]. Other chunks MAY 213 be sent in an authenticated way. 215 This makes sure that an attacker can not modify the stream a message 216 is sent in or affect the ordered/unordered delivery of the message. 217 It is also not possible for an attacker to drop messages and use 218 forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this 219 dropping. 221 4.5. Handshake 223 A DTLS implementation discards DTLS messages from older epochs after 224 some time as described in section 4.1 of [I-D.ietf-tls-rfc4347-bis]. 225 This is not acceptable when the DTLS user performs a reliable data 226 transfer. To avoid the discarding of messages, the following 227 procedures are required. 229 Before sending a ChangeCipherSpec message all outstanding SCTP user 230 messages MUST have been acknowledged by the SCTP peer and MUST NOT be 231 revoked anymore by the SCTP peer. 233 Prior to processing a received ChangeCipherSpec all other received 234 SCTP user messages which are buffered in the SCTP layer MUST be read 235 and processed by DTLS. 237 User messages arriving between ChangeCipherSpec and Finished using 238 the new epoch have probably passed the Finished and MUST be buffered 239 by DTLS until the Finished is read. 241 4.6. Handling of Endpoint-pair Shared Secrets 243 The endpoint-pair shared secret for Shared Key Identifier 0 is empty. 244 Whenever the master key changes, a 64 byte shared secret is derived 245 from every master secret and provided as a new end-point pair shared 246 secret by using the algorithm described in [I-D.ietf-tls-extractor]. 248 The Shared Key Identifier MUST be incremented by 1. If it is 65535, 249 the next value MUST be 1. 251 Before sending the Finished message the active SCTP-AUTH key MUST be 252 switched to the new one. 254 Once the corresponding Finished message from the peer has been 255 received the old SCTP-AUTH key SHOULD be removed. 257 4.7. Shutdown 259 To prevent DTLS from discarding DTLS user messages while shutting 260 down, before sending a CloseNotify message all outstanding SCTP user 261 messages MUST have been acknowledged by the SCTP peer and MUST NOT be 262 revoked anymore by the SCTP peer. 264 Prior to processing a received CloseNotify all other received SCTP 265 user messages which are buffered in the SCTP layer MUST be read and 266 processed by DTLS. 268 5. IANA Considerations 270 IANA needs to add a value to the TLS Exporter Label registry as 271 described in [I-D.ietf-tls-extractor]. The label suggested is 272 EXTRACTOR_DTLS_OVER_SCTP. The reference should refer to this 273 document. 275 6. Security Considerations 277 The security considerations given in [I-D.ietf-tls-rfc4347-bis], 278 [RFC4895], and [RFC4960] also apply to this document. 280 It is possible to authenticate DTLS endpoints based on IP-addresses 281 in certificates. SCTP associations can use multiple addresses per 282 SCTP endpoint. Therefore it is possible that DTLS records will be 283 sent from a different IP-address than that originally authenticated. 284 This is not a problem provided that no security decisions are made 285 based on that IP-address. This is a special case of a general rule: 286 all decisions should be based on the peer's authenticated identity, 287 not on its transport layer identity. 289 The SCTP user provides for each user message also a stream 290 identifier, a flag whether the message is sent ordered or unordered 291 and a payload protocol identifier. Although DTLS can be used to 292 provide privacy for the actual user message, none of these three are 293 protected by DTLS. They are sent as clear text, because they are 294 part of the SCTP DATA chunk header. 296 If future SCTP extensions define chunk types which processing affect 297 the handling of TSNs, these chunk types MUST be sent in an 298 authenticated way as described in [RFC4895]. One example would be an 299 extension providing an alternate way of acknowledging TSNs. 301 7. Acknowledgments 303 The authors wish to thank Carsten Hohendorf, Alfred Hoenes, Daniel 304 Mentz, Ian Goldberg, Anna Brunstrom, and Stefan Lindskog for their 305 invaluable comments. 307 8. References 309 8.1. Normative References 311 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 312 Requirement Levels", BCP 14, RFC 2119, March 1997. 314 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 315 Conrad, "Stream Control Transmission Protocol (SCTP) 316 Partial Reliability Extension", RFC 3758, May 2004. 318 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 319 "Authenticated Chunks for the Stream Control Transmission 320 Protocol (SCTP)", RFC 4895, August 2007. 322 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 323 RFC 4960, September 2007. 325 [I-D.ietf-tls-extractor] 326 Rescorla, E., "Keying Material Exporters for Transport 327 Layer Security (TLS)", draft-ietf-tls-extractor-07 (work 328 in progress), September 2009. 330 [I-D.ietf-tls-rfc4347-bis] 331 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 332 Security version 1.2", draft-ietf-tls-rfc4347-bis-03 (work 333 in progress), October 2009. 335 8.2. Informative References 337 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 338 RFC 793, September 1981. 340 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 341 Layer Security over Stream Control Transmission Protocol", 342 RFC 3436, December 2002. 344 Authors' Addresses 346 Michael Tuexen 347 Muenster Univ. of Applied Sciences 348 Stegerwaldstr. 39 349 48565 Steinfurt 350 Germany 352 Email: tuexen@fh-muenster.de 354 Robin Seggelmann 355 Muenster Univ. of Applied Sciences 356 Stegerwaldstr. 39 357 48565 Steinfurt 358 Germany 360 Email: seggelmann@fh-muenster.de 361 Eric Rescorla 362 RTFM, Inc. 363 2064 Edgewood Drive 364 Palo Alto, CA 94303 365 USA 367 Email: ekr@networkresonance.com