idnits 2.17.1 draft-ietf-tsvwg-dtls-for-sctp-01.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 (July 8, 2009) is 5405 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 4347 (Obsoleted by RFC 6347) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) == Outdated reference: A later version (-07) exists of draft-ietf-tls-extractor-05 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 3 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: January 9, 2010 E. Rescorla 6 RTFM, Inc. 7 July 8, 2009 9 Datagram Transport Layer Security for Stream Control Transmission 10 Protocol 11 draft-ietf-tsvwg-dtls-for-sctp-01.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 January 9, 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 all features 54 provided by SCTP and its extensions, especially support of 56 o multi-homing to provide network level fault tolerance. 58 o multiple streams to avoid head of line blocking. 60 o unordered delivery. 62 o dynamic reconfiguration of streams. 64 o partially reliable data transfer. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . . 5 71 4. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . . 6 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 80 1. Introduction 82 1.1. Overview 84 This document describes the usage of the Datagram Transport Layer 85 Security (DTLS) protocol, as defined in [RFC4347], over the Stream 86 Control Transmission Protocol (SCTP), as defined in [RFC4960]. 88 TLS is designed to run on top of a byte-stream oriented transport 89 protocol providing a reliable, in-sequence delivery. Thus, TLS is 90 currently mainly being used on top of the Transmission Control 91 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. The user of DTLS over SCTP can use all 108 services provided by SCTP and its partial reliability extension. The 109 dynamic modification of the IP-addresses used by the SCTP end-points 110 is also supported. 112 The method described in this document requires that the SCTP 113 implementation supports the optional feature of fragmentation of SCTP 114 user messages and the SCTP authentication extension defined in 115 [RFC4895]. 117 1.2. Terminology 119 This document uses the following terms: 121 Association: An SCTP association. 123 Connection: A TLS connection. 125 Session: A TLS session. 127 Stream: A unidirectional stream of an SCTP association. It is 128 uniquely identified by a stream identifier. 130 1.3. Abbreviations 132 DTLS: Datagram Transport Layer Security. 134 MTU: Maximum Transmission Unit. 136 PPID: Payload Protocol Identifier. 138 SCTP: Stream Control Transmission Protocol. 140 TCP: Transmission Control Protocol. 142 TLS: Transport Layer Security. 144 2. Conventions 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 3. DTLS Considerations 152 3.1. Message Sizes 154 DTLS limits the DTLS user message size to the current Path MTU minus 155 the header sizes. This limit SHOULD be increased to 2^14 Bytes for 156 DTLS over SCTP. 158 3.2. Message Fragmentation 160 The DTLS layer MUST NOT perform message fragmentation. The SCTP 161 layer will perform this task. Thus the supported maximum length of 162 SCTP user messages MUST be at least 2^14 + 2048 + 5 = 18437 bytes. 163 Every DTLS message MUST be handled as one SCTP user message. 165 3.3. Replay Detection 167 Replay detection of DTLS MUST NOT be used. 169 3.4. Path MTU Discovery 171 Path MTU discovery of DTLS MUST NOT be used. 173 3.5. Retransmission of Messages 175 DTLS procedures for retransmissions MUST NOT be used. 177 4. SCTP Considerations 179 4.1. Payload Protocol Identifier Usage 181 Application protocols running over DTLS over SCTP SHOULD register and 182 use a separate payload protocol identifier (PPID) and SHOULD NOT 183 reuse the PPID which they registered for running directly over SCTP. 185 This means in particular that there is no specific PPID for DTLS. 187 4.2. Stream Usage 189 All DTLS messages of the ChangeCipherSpec, Alert, or Handshake 190 protocol MUST be transported on stream 0 with unlimited reliability 191 and with the ordered delivery feature. 193 All DTLS messages of the ApplicationData protocol MAY be transported 194 over stream 0 but users SHOULD use other streams for better 195 performance. 197 4.3. Chunk Handling 199 The DATA, SACK and FORWARD-TSN chunks of SCTP MUST be sent in an 200 authenticated way as described in [RFC4895]. Other chunks MAY be 201 sent in an authenticated way. 203 This makes sure that an attacker can not modify the stream a message 204 is sent in or affect the ordered/unordered delivery of the message. 205 It is also not possible for an attacker to drop messages and use 206 forged FORWARD-TSN and SACK chunks to hide this dropping. 208 4.4. Handshake 210 To prevent DTLS from discarding DTLS user messages while 211 renegotiating, before sending a ChangeCipherSpec message all 212 outstanding SCTP user messages MUST have been acknowledged by the 213 SCTP peer and MUST NOT be revoked anymore by the SCTP peer. 215 Prior to processing a received ChangeCipherSpec all other received 216 SCTP user messages which are buffered in the SCTP layer MUST be read 217 and processed by DTLS. 219 User messages arriving between ChangeCipherSpec and Finished using 220 the new epoch have probably passed the Finished and MUST be buffered 221 by DTLS until the Finished is read. 223 4.5. Handling of Endpoint-pair Shared Secrets 225 The endpoint-pair shared secret for Shared Key Identifier 0 is empty. 226 Whenever the master key changes, a 64 byte shared secret is derived 227 from every master secret and provided as a new end-point pair shared 228 secret by using the algorithm described in [I-D.ietf-tls-extractor]. 230 The Shared Key Identifier MUST be incremented by 1. If it is 65535, 231 the next value MUST be 1. 233 Before sending the Finished message the active SCTP-AUTH key MUST be 234 switched to the new one. 236 Once the corresponding Finished message from the peer has been 237 received the old key SHOULD be removed. 239 4.6. Shutdown 241 To prevent DTLS from discarding DTLS user messages while shutting 242 down, before sending a CloseNotify message all outstanding SCTP user 243 messages MUST have been acknowledged by the SCTP peer and MUST NOT be 244 revoked anymore by the SCTP peer. 246 Prior to processing a received CloseNotify all other received SCTP 247 user messages which are buffered in the SCTP layer MUST be read and 248 processed by DTLS. 250 5. IANA Considerations 252 IANA needs to add a value to the TLS Exporter Label registry as 253 described in [I-D.ietf-tls-extractor]. The label suggested is 254 EXTRACTOR_DTLS_OVER_SCTP. The reference should refer to this 255 document. 257 6. Security Considerations 259 This document does not add any additional security considerations in 260 addition to the ones given in [RFC4347] and [RFC4895]. 262 7. Acknowledgments 264 The authors wish to thank Carsten Hohendorf, and Alfred Hoenes for 265 their invaluable comments. 267 8. References 269 8.1. Normative References 271 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 272 Requirement Levels", BCP 14, RFC 2119, March 1997. 274 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 275 Conrad, "Stream Control Transmission Protocol (SCTP) 276 Partial Reliability Extension", RFC 3758, May 2004. 278 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 279 Security", RFC 4347, April 2006. 281 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 282 "Authenticated Chunks for the Stream Control Transmission 283 Protocol (SCTP)", RFC 4895, August 2007. 285 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 286 RFC 4960, September 2007. 288 [I-D.ietf-tls-extractor] 289 Rescorla, E., "Keying Material Exporters for Transport 290 Layer Security (TLS)", draft-ietf-tls-extractor-05 (work 291 in progress), March 2009. 293 8.2. Informative References 295 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 296 RFC 793, September 1981. 298 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 299 Layer Security over Stream Control Transmission Protocol", 300 RFC 3436, December 2002. 302 Authors' Addresses 304 Michael Tuexen 305 Muenster Univ. of Applied Sciences 306 Stegerwaldstr. 39 307 48565 Steinfurt 308 Germany 310 Email: tuexen@fh-muenster.de 312 Robin Seggelmann 313 Muenster Univ. of Applied Sciences 314 Stegerwaldstr. 39 315 48565 Steinfurt 316 Germany 318 Email: seggelmann@fh-muenster.de 320 Eric Rescorla 321 RTFM, Inc. 322 2064 Edgewood Drive 323 Palo Alto, CA 94303 324 USA 326 Email: ekr@networkresonance.com