idnits 2.17.1 draft-badra-hajjeh-mtls-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (April 28, 2011) is 4746 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 221 -- Looks like a reference, but probably isn't: '4' on line 315 ** 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: 2 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 30, 2011 INEOVATION 6 April 28, 2011 8 MTLS: (D)TLS Multiplexing 9 draft-badra-hajjeh-mtls-06.txt 11 Abstract 13 The (Datagram) Transport Layer Security ((D)TLS) standard provides 14 connection security with mutual authentication, data confidentiality 15 and integrity, key generation and distribution, and security 16 parameters negotiation. However, missing from the protocol is a way 17 to multiplex several application data over a single (D)TLS. 19 This document defines MTLS, an application-level protocol running 20 over (D)TLS Record protocol. The MTLS design provides application 21 multiplexing over a single (D)TLS session. Therefore, instead of 22 associating a (D)TLS session with each application, MTLS allows 23 several applications to protect their exchanges over a single (D)TLS 24 session. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 30, 2011. 43 Copyright Notice 45 Copyright (c) 2011 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 62 2. (D)TLS Multiplexing Overview and Considerations . . . . . . . 5 63 2.1. MTLS over TLS . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1.1. Opening Channels . . . . . . . . . . . . . . . . . . . 5 65 2.1.2. Closing Channels . . . . . . . . . . . . . . . . . . . 7 66 2.2. MTLS Flow Control . . . . . . . . . . . . . . . . . . . . 7 67 2.3. MTLS over DTLS . . . . . . . . . . . . . . . . . . . . . . 9 68 2.4. MTLS Message Types . . . . . . . . . . . . . . . . . . . . 10 69 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 72 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 75 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 78 1. Introduction 80 (D)TLS ([RFC5246], ([I-D.ietf-tls-rfc4347-bis]) is the most deployed 81 security protocol for securing exchanges, for authenticating entities 82 and for generating and distributing cryptographic keys. However, 83 what is missing from the protocol is the way to multiplex application 84 data over the same (D)TLS session. 86 Actually, (D)TLS clients and servers MUST establish a (D)TLS session 87 for each application they want to run over a transport layer. The 88 client and the server MUST also duplicate the existing TLS/DTLS 89 session for each application's stream/thread/connection (channel). 90 However, some applications may agree or be configured to use the same 91 security policies or parameters (e.g. authentication method and 92 cipher_suite) and then to share a single TLS session to protect their 93 exchanges. In this way, this document describes a way to allow 94 application multiplexing over TLS/DTLS. 96 The document motivations included: 98 o TLS is application protocol-independent. Higher-level protocol 99 can operate on top of the TLS protocol transparently. 101 o (D)TLS is a protocol of a modular nature. Since TLS is developed 102 in four independent protocols, the approach defined in this 103 document can be used with a total reuse of pre-existing (D)TLS 104 infrastructures and implementations. 106 o It provides a secure VPN tunnel over a transport layer. Unlike 107 "ssh-connection" [RFC4254], MTLS can run over unreliable transport 108 protocols, such as UDP. 110 o Establishing a single (D)TLS session for a number of applications 111 -instead of establishing a (D)TLS session per one of those 112 applications- reduces resource consumption, latency and messages 113 flow that are associated with executing simultaneous (D)TLS 114 sessions. 116 o (D)TLS can not forbid an intruder to analyze the traffic and 117 cannot protect data from inference. Thus, the intruder can know 118 the type of application data transmitted through the (D)TLS 119 sessions. However, the approach defined in this document allows, 120 by its design, data protection against inference. 122 1.1. Conventions Used in This Document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in [RFC2119]. 128 2. (D)TLS Multiplexing Overview and Considerations 130 This document defines an application-level protocol called (D)TLS 131 Multiplexing (MTLS) to handle data multiplexing. 133 2.1. MTLS over TLS 135 If the client is willing to run MTLS over TLS, it MUST connect to the 136 server that passively listens for the incoming TLS connection on the 137 IANA-to-be-assigned TCP port (TBA). The client MUST therefore send 138 the TLS ClientHello to begin the TLS handshake. Once the Handshake 139 is complete, the client and the server can establish and manage many 140 applications' channels using the MTLS requests/responses defined 141 below. 143 2.1.1. Opening Channels 145 The sender MAY request the opening of many channels. For each 146 channel, the MTLS layer generates and sends the following request: 148 struct { 149 uint8 type; 150 uint16 length; 151 opaque sender_channel_id[2]; 152 uint32 sender_window_length; 153 uint32 sender_max_packet_length; 154 opaque source_address_machine<1..2^16-1>; 155 opaque source_port[2]; 156 opaque destination_address_machine<1..2^16-1>; 157 opaque destination_port[2]; 158 } ChannelEstablishmentRequest; 160 type 162 The "type" field specifies the MTLS packet type (types are 163 summarized below). 165 length 167 The "length" field indicates the length, in octets, of the current 168 MTLS packet. 170 sender_channel_id 172 The "sender_channel_id" is the first half of the channel 173 identifier. The second half is generated by the receiver of that 174 MTLS packet. 176 sender_window_length 178 The "sender_window_length" field conveys the data length (in 179 octets), specifying how many bytes the receiver of the packet can 180 maximally send on the channel before receiving a new window length 181 (available free space). Each end of the channel establishes a 182 "receive buffer" and a "send buffer". 184 sender_max_packet_length 186 The "sender_max_packet_length" field conveys the data length (in 187 octets), specifying the maximal packet's length in octets the 188 receiver of that packet can send on the channel. The 189 sender_max_packet_length is always smaller than the free space of 190 the sender_window_length (the sender's "receive buffer"). 192 source_address_machine and source_port 194 The "source_address_machine" MAY carry either the numeric IP 195 address or the domain name of the host from where the application 196 originates the data multiplexing request and the "source_port" is 197 the port on the host from where the connection originated. 199 destination_address_machine and destination_port 201 The "destination_address_machine" and "destination_port" specify 202 the TCP/IP host and port where the recipient should connect the 203 channel. The "destination_address_machine" MAY be either a domain 204 name or a numeric IP address. 206 The receiver decides whether it can open the channel, and replies 207 with one of the following messages: 209 struct { 210 uint8 type; 211 uint16 length; 212 opaque sender_channel_id[2]; 213 opaque receiver_channel_id[2]; 214 uint32 receiver_window_length; 215 uint32 receiver_max_packet_length; 216 } ChannelEstablishmentSuccess; 218 struct { 219 uint8 type; 220 uint16 length; 221 opaque sender_channel_id[2]; 222 opaque error<0..2^16-6>; 223 } ChannelRequestEchec; 225 The "sender_channel_id" and "receiver_channel_id" are the same 226 generated during the channel establishment. The length conveys the 227 data length of the current packet. 229 The field "error" conveys a description of the error. 231 Each MTLS channel has its identifier computed as: 233 channel_id = sender_channel_id + receiver_channel_id 235 Where "+" indicates concatenation. 237 Note: channel_id may be susceptible to collisions. The receiver 238 needs to take care not to choose a "receiver_channel_id" to avoid any 239 collide with any of the established channel identifiers. 241 2.1.2. Closing Channels 243 The following packet MAY be sent to notify the receiver that the 244 sender will not send any more data on this channel and that any data 245 received after a closure request will be ignored. The sender of the 246 closure request MAY close its "receive buffer" without waiting for 247 the receiver's response. However, the receiver MUST respond with a 248 confirmation of the closure and close down the channel immediately, 249 discarding any pending writes. 251 struct { 252 uint8 type; 253 uint16 length; 254 opaque channel_id[4]; 255 } ChannelCloseRequest; 257 struct { 258 uint8 type; 259 uint16 length; 260 opaque channel_id[4]; 261 } ChannelCloseConfirmation; 263 The above two packets can be sent even if no window space is 264 available. 266 2.2. MTLS Flow Control 268 The structure of the MTLS data packet is described below. 270 Each entity maintains its "max_packet_length" (that is originally 271 initialized during the channel establishment) to a value not bigger 272 than the free space of its "receive buffer". For each received 273 packet, the receiver MUST subtract the packet's length from the free 274 space of its "receive buffer". For each transmitted packet, the 275 sender MUST subtract the packet's length from the free space of its 276 "send buffer". In any case, the result is always positive. 278 If the entity is willing to notify the other side about any change in 279 the "max_packet_length", the entity MUST send a NewMaxPacketLength 280 conveying the new "max_packet_length" that MUST be smaller than the 281 free space of the entity's "receive buffer" 283 The free space of the "receive buffer" of the sender (resp. the 284 receiver) MAY increase in length. The sender SHOULD send an 285 Acknowledgment packet to inform the receiver about this increase, 286 allowing this latter to send more packets but with length smaller or 287 equal than the minimum of the "max_packet_length" and the "receive 288 buffer" of the sender. 290 If the length of the "receive buffer" does not change, the 291 Acknowledgment packet will never be sent. 293 In the case where the "receive buffer" of an entity fills up, the 294 other entity MUST wait for an Acknowledgment packet before sending 295 any more MTLSPlaintext packets. 297 struct { 298 uint8 type; 299 uint32 length; 300 opaque channel_id[4]; 301 opaque data[MTLSPlaintext.length]; 302 } MTLSPlaintext; 304 struct { 305 uint8 type; 306 uint16 length; 307 opaque channel_id[4]; 308 uint32 max_packet_length; 309 /* the max_packet_length of the sender of that packet */ 310 } NewMaxPacketLength; 312 struct { 313 uint8 type; 314 uint16 length; 315 opaque channel_id[4]; 316 uint32 free_space; 317 } Acknowledgment; 319 The Acknowledgment and NewMaxPacketLength packets can be sent even if 320 no window space is available. 322 The (D)TLS Record Layer receives data from MTLS, supposes it as 323 uninterpreted data and applies the fragmentation and the 324 cryptographic operations on it, as defined in [RFC5246]. 326 Note: multiple MTLS fragments MAY be coalesced into a single 327 TLSPlaintext record. 329 Received data is decrypted, verified, decompressed, and reassembled, 330 then delivered to MTLS layer. Next, the MTLS sends data to the 331 appropriate application using the channel identifier and the length 332 value. 334 2.3. MTLS over DTLS 336 To run MTLS over DTLS, we MUST provide reliability for all MTLS 337 messages, except the MTLSPlaintext message that will be handled by 338 DTLS record. 340 If the client is willing to run MTLS over DTLS, it MUST connect to 341 the server that passively listens for the incoming DTLS connection on 342 the IANA-to-be-assigned UDP port (TBA). The client MUST therefore 343 send the TLS ClientHello to begin the DTLS handshake. Once the 344 Handshake is complete, the client and the server cache the session ID 345 and the master_secret. 347 Next, the client and the server start a TLS-PSK handshake [RFC4279]. 348 The client only includes pre-shared key based cipher suites to the 349 ClientHello message. The psk_identity is the session ID generated 350 during the DTLS handshake and the psk is the master_secret. Using 351 the cached session ID will help the server and the client to 352 establish a local mapping between both TLS and DTLS sessions. 354 Once the TLS handshake is complete, both the client and the server 355 can start multiplexing applications' channels using the set of 356 requests/responses defined above. Excepting MTLSPlaintext, all 357 requests/responses will be conveyed using TLS record. 359 MTLSPlaintext will be conveyed using DTLS record. The same Transport 360 Layer Mapping defined by DTLS MUST be used here. In particular, the 361 maximum record size. Hence, MTLSPlaintext MUST be smaller than the 362 maximum record size - 9. 364 It is REQUIRED to support the cipher suite 365 TLS_PSK_WITH_AES_128_CBC_SHA. 367 2.4. MTLS Message Types 369 This section defines the initial set of MTLS Message Types used in 370 Request/Response exchanges. The Message Type field is one octet and 371 identifies the structure of an MTLS Request or Response message. 373 The messages defined in this document are listed below. More Message 374 Types may be defined in future documents. The list of Message Types, 375 as defined through this document, is maintained by the Internet 376 Assigned Numbers Authority (IANA). Thus, an application needs to be 377 made to the IANA in order to obtain a new Message Type value. Since 378 there are subtle (and not-so-subtle) interactions that may occur in 379 this protocol between new features and existing features that may 380 result in a significant reduction in overall security, new values 381 SHALL be defined only through the IETF Review process specified in 382 [RFC5226]. 384 ChannelEstablishmentRequest 1 385 ChannelEstablishmentSuccess 2 386 ChannelRequestEchec 3 387 ChannelCloseRequest 4 388 ChannelCloseConfirmation 5 389 MTLSPlaintext 6 390 NewMaxPacketLength 7 391 Acknowledgment 8 393 3. Security Considerations 395 Security issues are discussed throughout this document and in 396 [RFC5246]. 398 If a fatal error related to any channel of an arbitrary application 399 occurs, the secure session MUST NOT be resumed. This is logic since 400 the Record protocol does not distinguish between the MTLS channels. 401 However, if an error occurs at the MTLS layer, both parties 402 immediately close the related channel, but not the (D)TLS session (no 403 alert of any type is sent by the (D)TLS Record). 405 4. IANA Considerations 407 This section provides guidance to the IANA regarding registration of 408 values related to the TLS protocol. 410 IANA is requested to assign a TCP and UDP port numbers that will be 411 the default port for MTLS sessions as defined in this document. 412 There is one name space in MTLS that requires registration: Message 413 Types. 415 Message Types have a range from 1 to 255, of which 1-8 are to be 416 allocated for this document. Because a new Message Type has 417 considerable impact on interoperability, a new Message Type SHALL be 418 defined only through the IETF Review process specified in [RFC5226]. 420 5. Acknowledgments 422 The authors appreciate Alfred Hoenes for his detailed review. 424 6. Contributors 426 James Blaisdell (Mocana, USA) 428 7. References 430 7.1. Normative References 432 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 433 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 439 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 440 May 2008. 442 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 443 for Transport Layer Security (TLS)", RFC 4279, 444 December 2005. 446 [I-D.ietf-tls-rfc4347-bis] 447 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 448 Security version 1.2", draft-ietf-tls-rfc4347-bis-02 (work 449 in progress), March 2009. 451 7.2. Informative References 453 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 454 Connection Protocol", RFC 4254, January 2006. 456 Authors' Addresses 458 Mohamad Badra 459 CNRS/LIMOS Laboratory 460 Campus de cezeaux, Bat. ISIMA 461 Aubiere 63170 462 France 464 Email: badra@isima.fr 466 Ibrahim Hajjeh 467 INEOVATION 468 Paris 469 France 471 Email: ibrahim.hajjeh@ineovation.fr