idnits 2.17.00 (12 Aug 2021) /tmp/idnits12882/draft-tuexen-dtls-for-sctp-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 301. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 307. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Replay detection of DTLS MUST not be used. -- 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 (November 17, 2007) is 5292 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) == Unused Reference: 'RFC2246' is defined on line 239, but no explicit reference was found in the text == Unused Reference: 'RFC5061' is defined on line 246, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4347 (Obsoleted by RFC 6347) == Outdated reference: A later version (-01) exists of draft-rescorla-tls-extractor-00 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 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 Muenster Univ. of Applied Sciences 4 Intended status: Standards Track E. Rescorla 5 Expires: May 20, 2008 RTFM, Inc. 6 November 17, 2007 8 Datagram Transport Layer Security for Stream Control Transmission 9 Protocol 10 draft-tuexen-dtls-for-sctp-02.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 20, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes the usage of the Datagram Transport Layer 44 Security (DTLS) protocol over the Stream Control Transmission 45 Protocol (SCTP). 47 The user of DTLS over SCTP can take advantage of all features 48 provided by SCTP and its extensions, especially support of 49 o multiple streams to avoid head of line blocking. 51 o multi-homing to provide network level fault tolerance. 53 o unordered delivery. 55 o partial reliable data transfer. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. DTLS considerations . . . . . . . . . . . . . . . . . . . . . . 4 62 4. SCTP considerations . . . . . . . . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 65 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 68 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 70 Intellectual Property and Copyright Statements . . . . . . . . . . 8 72 1. Introduction 74 1.1. Overview 76 This document describes the usage of the Datagram Transport Layer 77 Security (DTLS) protocol, as defined in [RFC4347], over the Stream 78 Control Transmission Protocol (SCTP), as defined in [RFC4960]. 80 TLS is designed to run on top of a byte-stream oriented transport 81 protocol providing a reliable, in-sequence delivery. Thus, TLS is 82 currently mainly being used on top of the Transmission Control 83 Protocol (TCP), as defined in RFC0793 [RFC0793]. 85 TLS over SCTP as described in [RFC3436] has some serious limitations: 87 o It does not support the unordered delivery of SCTP user messages. 89 o It does not support partial reliablility as defined in [RFC3758]. 91 o It only supports the usage of the same number of streams in both 92 directions. 94 o It uses a TLS connection for every bidirectional stream, which 95 requires a substantial amount of resources and message exchanges 96 if a large number of streams is used. 98 DTLS over SCTP as described in this document overcomes these 99 limitations of TLS over SCTP. The user of DTLS over SCTP can use all 100 services provided by SCTP and its paritial reliability extension. 101 The dynamic modification of the IP-addresses used by the SCTP enp- 102 points is alos supported. 104 The method described in this document requires that the SCTP 105 implementation supports the optional feature of fragmentation of SCTP 106 user messages and the SCTP authentication extension defined in 107 [RFC4895]. 109 1.2. Terminology 111 This document uses the following terms: 113 Association: An SCTP association. 115 Connection: A TLS connection. 117 Session: A TLS session. 119 Stream: A unidirectional stream of an SCTP association. It is 120 uniquely identified by a stream identifier. 122 1.3. Abbreviations 124 DTLS: Datagram Transport Layer Security 126 MTU: Maximum Transmission Unit 128 SCTP: Stream Control Transmission Protocol 130 TCP: Transmission Control Protocol 132 TLS: Transport Layer Security 134 2. Conventions 136 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD. 137 SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when 138 they appear in this document, are to be interpreted as described in 139 [RFC2119]. 141 3. DTLS considerations 143 3.1. Message fragmentation 145 The DTLS layer MUST NOT perform message fragmentation. The SCTP 146 layer will perform this task. Thus the supported maximum length of 147 SCTP user messages MUST be at least 2^14 + 2048 + 5 = 18437 bytes. 148 Every DTLS message MUST be handled as one user message for SCTP. 150 3.2. Message sizes 152 DTLS imposes an limit in the user message size. This limit applies 153 also to DTLS/SCTP. 155 3.3. Replay detection 157 Replay detection of DTLS MUST not be used. 159 3.4. Changing of Cipher Specs 161 Whenever Cipher Specs are changed a new shared secret MUST be derived 162 from the master secret and used for SCTP-AUTH. The shared key 163 identifier used by SCTP-AUTH MUST be incremented. 165 4. SCTP considerations 167 4.1. Stream usage 169 All DTLS control messages MUST be transported on stream 0 with 170 unlimited reliability and with the ordered delivery feature. 172 User data messages MAY be transported over stream 0 but users SHOULD 173 use other streams for better performance. 175 4.2. Chunk handling 177 The DATA, SACK and FORWARD-TSN chunks of SCTP MUST be sent in an 178 authenticated way as described in [RFC4895]. Other chunks MAY be 179 sent in an authenticated way. 181 This makes sure that an attacker can not modify the stream a message 182 is sent in or affect the ordered/unordered delivery of the message. 183 It is also not possible for an attacker to drop messages and use 184 forged FORWARD-TSN and SACK chunks to hide this dropping. 186 4.3. Handling of endpoint-pair shared secrets 188 The endpoint-pair shared secret for Shared Key Identifier 0 is empty. 189 After DTLS cipher specs are changed, a 64 byte shared secret is 190 derived from the master secret and used a the new end-point pair 191 shared secret by using the algorthm described in 192 [I-D.rescorla-tls-extractor]. The shared Key identifier MUST be 193 incremented by 1. If it is 65535, the next value MUST be 1. 195 5. IANA Considerations 197 This section is not complete yet. 199 6. Security Considerations 201 This section is not complete yet. 203 7. Acknowledgments 205 The authors wish to thank Carsten Hohendorf for his invaluable 206 comments. 208 8. References 210 8.1. Normative References 212 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 213 Requirement Levels", BCP 14, RFC 2119, March 1997. 215 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 216 Conrad, "Stream Control Transmission Protocol (SCTP) 217 Partial Reliability Extension", RFC 3758, May 2004. 219 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 220 Security", RFC 4347, April 2006. 222 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 223 "Authenticated Chunks for the Stream Control Transmission 224 Protocol (SCTP)", RFC 4895, August 2007. 226 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 227 RFC 4960, September 2007. 229 [I-D.rescorla-tls-extractor] 230 Rescorla, E., "Keying Material Extractors for Transport 231 Layer Security (TLS)", draft-rescorla-tls-extractor-00 232 (work in progress), January 2007. 234 8.2. Informative References 236 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 237 RFC 793, September 1981. 239 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 240 RFC 2246, January 1999. 242 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 243 Layer Security over Stream Control Transmission Protocol", 244 RFC 3436, December 2002. 246 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 247 Kozuka, "Stream Control Transmission Protocol (SCTP) 248 Dynamic Address Reconfiguration", RFC 5061, 249 September 2007. 251 Authors' Addresses 253 Michael Tuexen 254 Muenster Univ. of Applied Sciences 255 Stegerwaldstr. 39 256 48565 Steinfurt 257 Germany 259 Email: tuexen@fh-muenster.de 261 Eric Rescorla 262 RTFM, Inc. 263 2064 Edgewood Drive 264 Palo Alto, CA 94303 265 USA 267 Email: ekr@networkresonance.com 269 Full Copyright Statement 271 Copyright (C) The IETF Trust (2007). 273 This document is subject to the rights, licenses and restrictions 274 contained in BCP 78, and except as set forth therein, the authors 275 retain all their rights. 277 This document and the information contained herein are provided on an 278 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 279 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 280 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 281 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 282 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 283 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 285 Intellectual Property 287 The IETF takes no position regarding the validity or scope of any 288 Intellectual Property Rights or other rights that might be claimed to 289 pertain to the implementation or use of the technology described in 290 this document or the extent to which any license under such rights 291 might or might not be available; nor does it represent that it has 292 made any independent effort to identify any such rights. Information 293 on the procedures with respect to rights in RFC documents can be 294 found in BCP 78 and BCP 79. 296 Copies of IPR disclosures made to the IETF Secretariat and any 297 assurances of licenses to be made available, or the result of an 298 attempt made to obtain a general license or permission for the use of 299 such proprietary rights by implementers or users of this 300 specification can be obtained from the IETF on-line IPR repository at 301 http://www.ietf.org/ipr. 303 The IETF invites any interested party to bring to its attention any 304 copyrights, patents or patent applications, or other proprietary 305 rights that may cover technology that may be required to implement 306 this standard. Please address the information to the IETF at 307 ietf-ipr@ietf.org. 309 Acknowledgment 311 Funding for the RFC Editor function is provided by the IETF 312 Administrative Support Activity (IASA).