idnits 2.17.1 draft-tuexen-tsvwg-dtls-for-sctp-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 295. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 306. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 313. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 319. 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 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 7, 2008) is 5771 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) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 8 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 8, 2009 E. Rescorla 6 RTFM, Inc. 7 July 7, 2008 9 Datagram Transport Layer Security for Stream Control Transmission 10 Protocol 11 draft-tuexen-tsvwg-dtls-for-sctp-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 8, 2009. 38 Abstract 40 This document describes the usage of the Datagram Transport Layer 41 Security (DTLS) protocol over the Stream Control Transmission 42 Protocol (SCTP). 44 The user of DTLS over SCTP can take advantage of all features 45 provided by SCTP and its extensions, especially support of 47 o multiple streams to avoid head of line blocking. 49 o multi-homing to provide network level fault tolerance. 51 o unordered delivery. 53 o partial reliable data transfer. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. DTLS considerations . . . . . . . . . . . . . . . . . . . . . . 4 60 4. SCTP considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 68 Intellectual Property and Copyright Statements . . . . . . . . . . 8 70 1. Introduction 72 1.1. Overview 74 This document describes the usage of the Datagram Transport Layer 75 Security (DTLS) protocol, as defined in [RFC4347], over the Stream 76 Control Transmission Protocol (SCTP), as defined in [RFC4960]. 78 TLS is designed to run on top of a byte-stream oriented transport 79 protocol providing a reliable, in-sequence delivery. Thus, TLS is 80 currently mainly being used on top of the Transmission Control 81 Protocol (TCP), as defined in RFC0793 [RFC0793]. 83 TLS over SCTP as described in [RFC3436] has some serious limitations: 85 o It does not support the unordered delivery of SCTP user messages. 87 o It does not support partial reliability as defined in [RFC3758]. 89 o It only supports the usage of the same number of streams in both 90 directions. 92 o It uses a TLS connection for every bidirectional stream, which 93 requires a substantial amount of resources and message exchanges 94 if a large number of streams is used. 96 DTLS over SCTP as described in this document overcomes these 97 limitations of TLS over SCTP. The user of DTLS over SCTP can use all 98 services provided by SCTP and its partial reliability extension. The 99 dynamic modification of the IP-addresses used by the SCTP end-points 100 is also supported. 102 The method described in this document requires that the SCTP 103 implementation supports the optional feature of fragmentation of SCTP 104 user messages and the SCTP authentication extension defined in 105 [RFC4895]. 107 1.2. Terminology 109 This document uses the following terms: 111 Association: An SCTP association. 113 Connection: A TLS connection. 115 Session: A TLS session. 117 Stream: A unidirectional stream of an SCTP association. It is 118 uniquely identified by a stream identifier. 120 1.3. Abbreviations 122 DTLS: Datagram Transport Layer Security 124 MTU: Maximum Transmission Unit 126 SCTP: Stream Control Transmission Protocol 128 TCP: Transmission Control Protocol 130 TLS: Transport Layer Security 132 2. Conventions 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 3. DTLS considerations 140 3.1. Message fragmentation 142 The DTLS layer MUST NOT perform message fragmentation. The SCTP 143 layer will perform this task. Thus the supported maximum length of 144 SCTP user messages MUST be at least 2^14 + 2048 + 5 = 18437 bytes. 145 Every DTLS message MUST be handled as one user message for SCTP. 147 3.2. Message sizes 149 DTLS imposes a limit in the user message size. This limit applies 150 also to DTLS/SCTP. 152 3.3. Replay detection 154 Replay detection of DTLS MUST NOT be used. 156 3.4. Path MTU Discovery 158 Path MTU discovery of DTLS MUST NOT be used. 160 3.5. Retransmission of Messages 162 DTLS procedures for retransmissions MUST NOT be used. 164 4. SCTP considerations 166 4.1. Stream usage 168 All DTLS control messages MUST be transported on stream 0 with 169 unlimited reliability and with the ordered delivery feature. 171 User data messages MAY be transported over stream 0 but users SHOULD 172 use other streams for better performance. 174 4.2. Chunk handling 176 The DATA, SACK and FORWARD-TSN chunks of SCTP MUST be sent in an 177 authenticated way as described in [RFC4895]. Other chunks MAY be 178 sent in an authenticated way. 180 This makes sure that an attacker can not modify the stream a message 181 is sent in or affect the ordered/unordered delivery of the message. 182 It is also not possible for an attacker to drop messages and use 183 forged FORWARD-TSN and SACK chunks to hide this dropping. 185 4.3. Handling of endpoint-pair shared secrets 187 The endpoint-pair shared secret for Shared Key Identifier 0 is empty. 188 Whenever the master key changes, a 64 byte shared secret is derived 189 from the master secret and provided as a new end-point pair shared 190 secret by using the algorithm described in 191 [I-D.rescorla-tls-extractor]. 193 The Shared Key Identifier MUST be incremented by 1. If it is 65535, 194 the next value MUST be 1. 196 Before sending the Finished message the active SCTP-AUTH key MUST be 197 switched to the new one. The Finished message MUST NOT be sent 198 before all messages except the ones from this handshake have been 199 acknowledged and can not be revoked anymore by the peer. 201 Once the corresponding Finished message from the peer has been 202 received the old key SHOULD be removed. 204 5. IANA Considerations 206 IANA needs to add a value to the TLS Extractor Label registry as 207 described in [I-D.rescorla-tls-extractor]. The label suggested is 208 EXTRACTOR_DTLS_OVER_SCTP. The reference should refer to this 209 document. 211 6. Security Considerations 213 This section is not complete yet. 215 7. Acknowledgments 217 The authors wish to thank Carsten Hohendorf for his invaluable 218 comments. 220 8. References 222 8.1. Normative References 224 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 225 Requirement Levels", BCP 14, RFC 2119, March 1997. 227 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 228 Conrad, "Stream Control Transmission Protocol (SCTP) 229 Partial Reliability Extension", RFC 3758, May 2004. 231 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 232 Security", RFC 4347, April 2006. 234 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 235 "Authenticated Chunks for the Stream Control Transmission 236 Protocol (SCTP)", RFC 4895, August 2007. 238 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 239 RFC 4960, September 2007. 241 [I-D.rescorla-tls-extractor] 242 Rescorla, E., "Keying Material Extractors for Transport 243 Layer Security (TLS)", draft-rescorla-tls-extractor-01 244 (work in progress), November 2007. 246 8.2. Informative References 248 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 249 RFC 793, September 1981. 251 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 252 Layer Security over Stream Control Transmission Protocol", 253 RFC 3436, December 2002. 255 Authors' Addresses 257 Michael Tuexen 258 Muenster Univ. of Applied Sciences 259 Stegerwaldstr. 39 260 48565 Steinfurt 261 Germany 263 Email: tuexen@fh-muenster.de 265 Robin Seggelmann 266 Muenster Univ. of Applied Sciences 267 Stegerwaldstr. 39 268 48565 Steinfurt 269 Germany 271 Email: seggelmann@fh-muenster.de 273 Eric Rescorla 274 RTFM, Inc. 275 2064 Edgewood Drive 276 Palo Alto, CA 94303 277 USA 279 Email: ekr@networkresonance.com 281 Full Copyright Statement 283 Copyright (C) The IETF Trust (2008). 285 This document is subject to the rights, licenses and restrictions 286 contained in BCP 78, and except as set forth therein, the authors 287 retain all their rights. 289 This document and the information contained herein are provided on an 290 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 291 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 292 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 293 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 294 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 295 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 297 Intellectual Property 299 The IETF takes no position regarding the validity or scope of any 300 Intellectual Property Rights or other rights that might be claimed to 301 pertain to the implementation or use of the technology described in 302 this document or the extent to which any license under such rights 303 might or might not be available; nor does it represent that it has 304 made any independent effort to identify any such rights. Information 305 on the procedures with respect to rights in RFC documents can be 306 found in BCP 78 and BCP 79. 308 Copies of IPR disclosures made to the IETF Secretariat and any 309 assurances of licenses to be made available, or the result of an 310 attempt made to obtain a general license or permission for the use of 311 such proprietary rights by implementers or users of this 312 specification can be obtained from the IETF on-line IPR repository at 313 http://www.ietf.org/ipr. 315 The IETF invites any interested party to bring to its attention any 316 copyrights, patents or patent applications, or other proprietary 317 rights that may cover technology that may be required to implement 318 this standard. Please address the information to the IETF at 319 ietf-ipr@ietf.org.