idnits 2.17.1 draft-badra-hajjeh-mtls-05.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.ii 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 21, 2009) is 5455 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 226 -- Looks like a reference, but probably isn't: '4' on line 320 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-06) exists of draft-ietf-tls-rfc4347-bis-02 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Badra 3 Internet-Draft CNRS/LIMOS Laboratory 4 Intended status: Standards Track I. Hajjeh 5 Expires: October 23, 2009 INEOVATION 6 April 21, 2009 8 MTLS: (D)TLS Multiplexing 9 draft-badra-hajjeh-mtls-05.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on October 23, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 The (Datagram) Transport Layer Security ((D)TLS) standard provides 58 connection security with mutual authentication, data confidentiality 59 and integrity, key generation and distribution, and security 60 parameters negotiation. However, missing from the protocol is a way 61 to multiplex several application data over a single (D)TLS. 63 This document defines MTLS, an application-level protocol running 64 over (D)TLS Record protocol. The MTLS design provides application 65 multiplexing over a single (D)TLS session. Therefore, instead of 66 associating a (D)TLS session with each application, MTLS allows 67 several applications to protect their exchanges over a single (D)TLS 68 session. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Conventions Used in This Document . . . . . . . . . . . . 5 74 2. (D)TLS Multiplexing Overview and Considerations . . . . . . . 5 75 2.1. MTLS over TLS . . . . . . . . . . . . . . . . . . . . . . 5 76 2.1.1. Opening Channels . . . . . . . . . . . . . . . . . . . 5 77 2.1.2. Closing Channels . . . . . . . . . . . . . . . . . . . 7 78 2.2. MTLS Flow Control . . . . . . . . . . . . . . . . . . . . 7 79 2.3. MTLS over DTLS . . . . . . . . . . . . . . . . . . . . . . 9 80 2.4. MTLS Message Types . . . . . . . . . . . . . . . . . . . . 10 81 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 84 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 87 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 90 1. Introduction 92 (D)TLS ([RFC5246], ([I-D.ietf-tls-rfc4347-bis]) is the most deployed 93 security protocol for securing exchanges, for authenticating entities 94 and for generating and distributing cryptographic keys. However, 95 what is missing from the protocol is the way to multiplex application 96 data over the same (D)TLS session. 98 Actually, (D)TLS clients and servers MUST establish a (D)TLS session 99 for each application they want to run over a transport layer. The 100 client and the server MUST also duplicate the existing TLS/DTLS 101 session for each application's stream/thread/connection (channel). 102 However, some applications may agree or be configured to use the same 103 security policies or parameters (e.g. authentication method and 104 cipher_suite) and then to share a single TLS session to protect their 105 exchanges. In this way, this document describes a way to allow 106 application multiplexing over TLS/DTLS. 108 The document motivations included: 110 o TLS is application protocol-independent. Higher-level protocol 111 can operate on top of the TLS protocol transparently. 113 o (D)TLS is a protocol of a modular nature. Since TLS is developed 114 in four independent protocols, the approach defined in this 115 document can be used with a total reuse of pre-existing (D)TLS 116 infrastructures and implementations. 118 o It provides a secure VPN tunnel over a transport layer. Unlike 119 "ssh-connection" [RFC4254], MTLS can run over unreliable transport 120 protocols, such as UDP. 122 o Establishing a single (D)TLS session for a number of applications 123 -instead of establishing a (D)TLS session per one of those 124 applications- reduces resource consumption, latency and messages 125 flow that are associated with executing simultaneous (D)TLS 126 sessions. 128 o (D)TLS can not forbid an intruder to analyze the traffic and 129 cannot protect data from inference. Thus, the intruder can know 130 the type of application data transmitted through the (D)TLS 131 sessions. However, the approach defined in this document allows, 132 by its design, data protection against inference. 134 1.1. Conventions Used in This Document 136 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 137 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 138 document are to be interpreted as described in [RFC2119]. 140 2. (D)TLS Multiplexing Overview and Considerations 142 This document defines an application-level protocol called (D)TLS 143 Multiplexing (MTLS) to handle data multiplexing. 145 2.1. MTLS over TLS 147 If the client is willing to run MTLS over TLS, it MUST connect to the 148 server that passively listens for the incoming TLS connection on the 149 IANA-to-be-assigned TCP port (TBA). The client MUST therefore send 150 the TLS ClientHello to begin the TLS handshake. Once the Handshake 151 is complete, the client and the server can establish and manage many 152 applications' channels using the MTLS requests/responses defined 153 below. 155 2.1.1. Opening Channels 157 The sender MAY request the opening of many channels. For each 158 channel, the MTLS layer generates and sends the following request: 160 struct { 161 uint8 type; 162 uint16 length; 163 opaque sender_channel_id[2]; 164 uint32 sender_window_length; 165 uint32 sender_max_packet_length; 166 opaque source_address_machine<1..2^16-1>; 167 opaque source_port[2]; 168 opaque destination_address_machine<1..2^16-1>; 169 opaque destination_port[2]; 170 } ChannelEstablishmentRequest; 172 type 173 The "type" field specifies the MTLS packet type (types are 174 summarized below). 176 length 177 The "length" field indicates the length, in octets, of the current 178 MTLS packet. 180 sender_channel_id 181 The "sender_channel_id" is the first half of the channel 182 identifier. The second half is generated by the receiver of that 183 MTLS packet. 185 sender_window_length 186 The "sender_window_length" field conveys the data length (in 187 octets), specifying how many bytes the receiver of the packet can 188 maximally send on the channel before receiving a new window length 189 (available free space). Each end of the channel establishes a 190 "receive buffer" and a "send buffer". 192 sender_max_packet_length 193 The "sender_max_packet_length" field conveys the data length (in 194 octets), specifying the maximal packet's length in octets the 195 receiver of that packet can send on the channel. The 196 sender_max_packet_length is always smaller than the free space of 197 the sender_window_length (the sender's "receive buffer"). 199 source_address_machine and source_port 200 The "source_address_machine" MAY carry either the numeric IP 201 address or the domain name of the host from where the application 202 originates the data multiplexing request and the "source_port" is 203 the port on the host from where the connection originated. 205 destination_address_machine and destination_port 206 The "destination_address_machine" and "destination_port" specify 207 the TCP/IP host and port where the recipient should connect the 208 channel. The "destination_address_machine" MAY be either a domain 209 name or a numeric IP address. 211 The receiver decides whether it can open the channel, and replies 212 with one of the following messages: 214 struct { 215 uint8 type; 216 uint16 length; 217 opaque sender_channel_id[2]; 218 opaque receiver_channel_id[2]; 219 uint32 receiver_window_length; 220 uint32 receiver_max_packet_length; 221 } ChannelEstablishmentSuccess; 223 struct { 224 uint8 type; 225 uint16 length; 226 opaque sender_channel_id[2]; 227 opaque error<0..2^16-6>; 228 } ChannelRequestEchec; 230 The "sender_channel_id" and "receiver_channel_id" are the same 231 generated during the channel establishment. The length conveys the 232 data length of the current packet. 234 The field "error" conveys a description of the error. 236 Each MTLS channel has its identifier computed as: 238 channel_id = sender_channel_id + receiver_channel_id 240 Where "+" indicates concatenation. 242 Note: channel_id may be susceptible to collisions. The receiver 243 needs to take care not to choose a "receiver_channel_id" to avoid any 244 collide with any of the established channel identifiers. 246 2.1.2. Closing Channels 248 The following packet MAY be sent to notify the receiver that the 249 sender will not send any more data on this channel and that any data 250 received after a closure request will be ignored. The sender of the 251 closure request MAY close its "receive buffer" without waiting for 252 the receiver's response. However, the receiver MUST respond with a 253 confirmation of the closure and close down the channel immediately, 254 discarding any pending writes. 256 struct { 257 uint8 type; 258 uint16 length; 259 opaque channel_id[4]; 260 } ChannelCloseRequest; 262 struct { 263 uint8 type; 264 uint16 length; 265 opaque channel_id[4]; 266 } ChannelCloseConfirmation; 268 The above two packets can be sent even if no window space is 269 available. 271 2.2. MTLS Flow Control 273 The structure of the MTLS data packet is described below. 275 Each entity maintains its "max_packet_length" (that is originally 276 initialized during the channel establishment) to a value not bigger 277 than the free space of its "receive buffer". For each received 278 packet, the receiver MUST subtract the packet's length from the free 279 space of its "receive buffer". For each transmitted packet, the 280 sender MUST subtract the packet's length from the free space of its 281 "send buffer". In any case, the result is always positive. 283 If the entity is willing to notify the other side about any change in 284 the "max_packet_length", the entity MUST send a NewMaxPacketLength 285 conveying the new "max_packet_length" that MUST be smaller than the 286 free space of the entity's "receive buffer" 288 The free space of the "receive buffer" of the sender (resp. the 289 receiver) MAY increase in length. The sender SHOULD send an 290 Acknowledgment packet to inform the receiver about this increase, 291 allowing this latter to send more packets but with length smaller or 292 equal than the minimum of the "max_packet_length" and the "receive 293 buffer" of the sender. 295 If the length of the "receive buffer" does not change, the 296 Acknowledgment packet will never be sent. 298 In the case where the "receive buffer" of an entity fills up, the 299 other entity MUST wait for an Acknowledgment packet before sending 300 any more MTLSPlaintext packets. 302 struct { 303 uint8 type; 304 uint32 length; 305 opaque channel_id[4]; 306 opaque data[MTLSPlaintext.length]; 307 } MTLSPlaintext; 309 struct { 310 uint8 type; 311 uint16 length; 312 opaque channel_id[4]; 313 uint32 max_packet_length; 314 /* the max_packet_length of the sender of that packet */ 315 } NewMaxPacketLength; 317 struct { 318 uint8 type; 319 uint16 length; 320 opaque channel_id[4]; 321 uint32 free_space; 322 } Acknowledgment; 324 The Acknowledgment and NewMaxPacketLength packets can be sent even if 325 no window space is available. 327 The (D)TLS Record Layer receives data from MTLS, supposes it as 328 uninterpreted data and applies the fragmentation and the 329 cryptographic operations on it, as defined in [RFC5246]. 331 Note: multiple MTLS fragments MAY be coalesced into a single 332 TLSPlaintext record. 334 Received data is decrypted, verified, decompressed, and reassembled, 335 then delivered to MTLS layer. Next, the MTLS sends data to the 336 appropriate application using the channel identifier and the length 337 value. 339 2.3. MTLS over DTLS 341 To run MTLS over DTLS, we MUST provide reliability for all MTLS 342 messages, except the MTLSPlaintext message that will be handled by 343 DTLS record. 345 If the client is willing to run MTLS over DTLS, it MUST connect to 346 the server that passively listens for the incoming DTLS connection on 347 the IANA-to-be-assigned UDP port (TBA). The client MUST therefore 348 send the TLS ClientHello to begin the DTLS handshake. Once the 349 Handshake is complete, the client and the server cache the session ID 350 and the master_secret. 352 Next, the client and the server start a TLS-PSK handshake [RFC4279]. 353 The client only includes pre-shared key based cipher suites to the 354 ClientHello message. The psk_identity is the session ID generated 355 during the DTLS handshake and the psk is the master_secret. Using 356 the cached session ID will help the server and the client to 357 establish a local mapping between both TLS and DTLS sessions. 359 Once the TLS handshake is complete, both the client and the server 360 can start multiplexing applications' channels using the set of 361 requests/responses defined above. Excepting MTLSPlaintext, all 362 requests/responses will be conveyed using TLS record. 364 MTLSPlaintext will be conveyed using DTLS record. The same Transport 365 Layer Mapping defined by DTLS MUST be used here. In particular, the 366 maximum record size. Hence, MTLSPlaintext MUST be smaller than the 367 maximum record size - 9. 369 It is REQUIRED to support the cipher suite 370 TLS_PSK_WITH_AES_128_CBC_SHA. 372 2.4. MTLS Message Types 374 This section defines the initial set of MTLS Message Types used in 375 Request/Response exchanges. The Message Type field is one octet and 376 identifies the structure of an MTLS Request or Response message. 378 The messages defined in this document are listed below. More Message 379 Types may be defined in future documents. The list of Message Types, 380 as defined through this document, is maintained by the Internet 381 Assigned Numbers Authority (IANA). Thus, an application needs to be 382 made to the IANA in order to obtain a new Message Type value. Since 383 there are subtle (and not-so-subtle) interactions that may occur in 384 this protocol between new features and existing features that may 385 result in a significant reduction in overall security, new values 386 SHALL be defined only through the IETF Review process specified in 387 [RFC5226]. 389 ChannelEstablishmentRequest 1 390 ChannelEstablishmentSuccess 2 391 ChannelRequestEchec 3 392 ChannelCloseRequest 4 393 ChannelCloseConfirmation 5 394 MTLSPlaintext 6 395 NewMaxPacketLength 7 396 Acknowledgment 8 398 3. Security Considerations 400 Security issues are discussed throughout this document and in 401 [RFC5246]. 403 If a fatal error related to any channel of an arbitrary application 404 occurs, the secure session MUST NOT be resumed. This is logic since 405 the Record protocol does not distinguish between the MTLS channels. 406 However, if an error occurs at the MTLS layer, both parties 407 immediately close the related channel, but not the (D)TLS session (no 408 alert of any type is sent by the (D)TLS Record). 410 4. IANA Considerations 412 This section provides guidance to the IANA regarding registration of 413 values related to the TLS protocol. 415 IANA is requested to assign a TCP and UDP port numbers that will be 416 the default port for MTLS sessions as defined in this document. 417 There is one name space in MTLS that requires registration: Message 418 Types. 420 Message Types have a range from 1 to 255, of which 1-8 are to be 421 allocated for this document. Because a new Message Type has 422 considerable impact on interoperability, a new Message Type SHALL be 423 defined only through the IETF Review process specified in [RFC5226]. 425 5. Acknowledgments 427 The authors appreciate Alfred Hoenes for his detailed review. 429 6. Contributors 431 James Blaisdell (Mocana, USA) 433 7. References 435 7.1. Normative References 437 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 438 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 443 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 444 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 445 May 2008. 447 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 448 for Transport Layer Security (TLS)", RFC 4279, 449 December 2005. 451 [I-D.ietf-tls-rfc4347-bis] 452 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 453 Security version 1.2", draft-ietf-tls-rfc4347-bis-02 (work 454 in progress), March 2009. 456 7.2. Informative References 458 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 459 Connection Protocol", RFC 4254, January 2006. 461 Authors' Addresses 463 Mohamad Badra 464 CNRS/LIMOS Laboratory 465 Campus de cezeaux, Bat. ISIMA 466 Aubiere 63170 467 France 469 Email: badra@isima.fr 471 Ibrahim Hajjeh 472 INEOVATION 473 France 475 Email: ibrahim.hajjeh@ineovation.fr