doc/protocol/draft-badra-hajjeh-mtls-00.txt

   1
   2 Internet Engineering Task Force                                M. Badra
   3 INTERNET DRAFT                                               ENST Paris
   4                                                               I. Hajjeh
   5                                                               ESRGroups
   6 Expires: March 2006                                    October 10, 2005
   7
   8                              TLS Multiplexing
   9                      <draft-badra-hajjeh-mtls-00.txt>
  10
  11
  12 Status
  13
  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.
  18
  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.
  23
  24    Internet-Drafts are draft documents valid for a maximum of six
  25    months and may be updated, replaced, or obsoleted by other documents
  26    at any time. It is inappropriate to use Internet-Drafts as reference
  27    material or to cite them other than as "work in progress."
  28
  29    The list of current Internet-Drafts can be accessed at
  30    http://www.ietf.org/ietf/1id-abstracts.txt
  31
  32    The list of Internet-Draft Shadow Directories can be accessed at
  33    http://www.ietf.org/shadow.html
  34
  35    This Internet-Draft will expire on March 10, 2006.
  36
  37 Copyright Notice
  38
  39    Copyright (C) The Internet Society (2005).
  40
  41 Abstract
  42
  43    TLS is the famous protocol that provides authentication and data
  44    protection for communication between two entities. However, missing
  45    from the protocol is a way to multiplex application data over the
  46    same TLS session.
  47
  48    This document defines a new TLS sub-protocol called MTLS running
  49    over TLS (or DTLS) Record protocol. The MTLS design provides
  50    application multiplexing over a single TLS session. Instead of
  51    associating a TLS connection with each application, MTLS allows
  52
  53 Badra & Hajjeh               Expires March 2006                [Page 1]
  54 INTERNET-DRAFT                TLS Multiplexing             October 2005
  55
  56
  57    several applications to protect their exchanges over a single TLS
  58    session.
  59
  60 1 Introduction
  61
  62    SMTP over TLS [SMTPTLS], HTTP over TLS [HTTPTLS], POP over TLS and
  63    IMAP over TLS [POPTLS] are examples of securing, respectively, SMTP,
  64    HTTP, POP and IMAP data exchanges using the TLS protocol [TLS].
  65
  66    TLS ([TLS], [TLSv1.1]) is the most deployed security protocol for
  67    securing exchanges, authenticating entities and for generating and
  68    distributing cryptographic keys. However, what is missing from the
  69    protocol is the way to multiplex application data over the same TLS
  70    session.
  71
  72    Actually, TLS (or DTLS [DTLS]) clients and servers MUST establish a
  73    TLS (or DTLS) session for each application they want to run over TCP
  74    (or UDP). However, some applications may agree or be configured to
  75    use the same security policies or parameters (f.g. authentication
  76    method and cipher_suite) and then to share one and only one TLS
  77    session to protect their exchanges. In this way, this document
  78    extends TLS to allow an application multiplexing functionality over
  79    TLS.
  80
  81    The document motivations included:
  82
  83    o   TLS is application protocol-independent. Higher-level protocol
  84        can operate on top of the TLS protocol transparently.
  85
  86    o   TLS is a modular nature protocol. Since TLS is developed in four
  87        independent protocols, the approach defined in this document can
  88        be added by extending the TLS protocol and with a total
  89        reuse of pre-existing TLS infrastructures and implementations.
  90
  91    o   It provides a secure VPN tunnel over a transport layer.
  92
  93    o   Establishing a single session for a number of applications
  94        reduces resource consumption, latency and messages flow that are
  95        associated with executing simultaneous TLS sessions.
  96
  97    o   TLS can not forbid an intruder to analyze the traffic and cannot
  98        protect data from inference. Thus, the intruder can know the
  99        type of application data transmitted through the TLS session.
 100        However, the extension defined in this document allows, by its
 101        design, data protection against inference.
 102
 103 1.2 Requirements language
 104
 105    The key words "MUST", "SHALL", "SHOULD", and "MAY", in this document
 106    are to be interpreted as described in RFC-2119.
 107
 108 Badra & Hajjeh               Expires March 2006                [Page 2]
 109 INTERNET-DRAFT                TLS Multiplexing             October 2005
 110
 111
 112 2 TLS multiplexing overview and considerations
 113
 114    This document defines a new TLS sub-protocol called Multiplexing TLS
 115    (MTLS) to handle data multiplexing, and it specifies the content
 116    type mtls(26) for this sub-protocol.
 117
 118    MTLS communication can take place over TCP or UDP. The default port
 119    is TBC, but other ports can be used.
 120
 121 2.1 Handshake
 122
 123    Based on the TLS Extensions [TLSExt], a client and a server can, in
 124    an ordinary TLS handshake, negotiate the future use of MTLS. If the
 125    client does attempt to initiate a TLS connection using MTLS with a
 126    server that does not support it, it will be automatically alerted.
 127    For servers aware of MTLS but not wishing to use it, it will
 128    gracefully revert to an ordinary TLS handshake or stop the
 129    negotiation.
 130
 131    The negotiation starts usually with the client determining whether
 132    the server is capable of and willing to use MTLS or not. In order to
 133    allow a TLS client to negotiate the application multiplexing
 134    functionality, a new extension type SHOULD be added to the Extended
 135    Client and Extended Server Hello messages.
 136
 137    This document defines an extension of type
 138    "application_layer_protocol". The "extension_data" field of this
 139    extension contains a "data_multiplexing", where:
 140
 141        Struct {
 142               ApplicationLayerProtocol alp_list<0..2^20-1>;
 143            } data_multiplexing;
 144
 145        struct {
 146               ApplicationpProtocolName apn;
 147               select (Version)
 148                  case { 3, 1 }:// TLS Version 1.0
 149                    TCPPort tcp_port;
 150                  case { 3, 2 }:// TLS Version 1.1
 151                    TCPPort tcp_port;
 152                  case { 254, 255 }:// Datagram TLS Version 1.0
 153                    UDPPort udp_port;
 154            } ApplicationLayerProtocol;
 155
 156        opaque TCPPort[2];
 157        opaque UDPPort[2];
 158        Opaque ApplicationpProtocolName<1..16>;
 159
 160    tcp_port (respectively udp_port) is the application port number at
 161    the server side. The client MUST use as destination ports, the TCP
 162    (respectively UDP) port numbers that are assigned by IANA.
 163 Badra & Hajjeh               Expires March 2006                [Page 3]
 164 INTERNET-DRAFT                TLS Multiplexing             October 2005
 165
 166
 167    Application layer running on unreliable links MUST be negotiated in
 168    a separate session using the DTLS Handshake [DTLS].
 169
 170    Note: if the server agrees, the client SHOULD establish a single TLS
 171    (respectively DTLS) session for all applications it wishes to run
 172    over TCP (respectively UDP). In this case, the client SHOULD send a
 173    data multiplexing extension containing "ALL" as
 174    ApplicationpProtocolName value and "NULL" as TCPPort (or UDPPort)
 175    value. If the server is not able to negotiate such session, it
 176    replays with a list of applications (names and ports) it can accept
 177    to run through a single TLS session, falls back on an ordinary TLS
 178    handshake or stops the negotiation.
 179
 180   2.1.1. Multi-connections during application session
 181
 182    Once the establishment is complete, the client MAY open many
 183    connections related to an arbitrary application over the secure
 184    session. In this case, the application client MUST locally reserve a
 185    port number for each connection. Next, the client application sends
 186    its request to the MTLS client which is listening on the TBC port
 187    number. This latter will check if it has an established secure
 188    session with the requested hostname (the server). If then it checks
 189    if the application protocol name has been accepted to run over MTLS,
 190    before sends the request to the MTLS server.
 191
 192 2.2 MTLS sub-protocol
 193
 194    The structure of MTLS packet is described below. The first 8 bytes
 195    of the packet represent the source and the destination ports of the
 196    connexion, and the length contains the length of the MTLS data.
 197
 198    enum {
 199         change_cipher_spec(20), alert(21), handshake(22),
 200         application_data(23), mtls(26), (255)
 201      } ContentType;
 202
 203    struct {
 204           uint32 SourcePort
 205           uint32 DestinationPort
 206           uint16 length;
 207           opaque data[MTLSPlaintext.length];
 208        } MTLSPlaintext;
 209
 210    The TLS Record Layer receives data from MTLS, supposes it as
 211    uninterpreted data and applies the fragmentation and the
 212    cryptographic operations on it, as defined in [TLS].
 213
 214    Note: multiple MTLS fragments MAY be coalesced into a single
 215    TLSPlaintext record.
 216
 217 Badra & Hajjeh               Expires March 2006                [Page 4]
 218 INTERNET-DRAFT                TLS Multiplexing             October 2005
 219
 220
 221    Received data is decrypted, verified, decompressed, and reassembled,
 222    then delivered to MTLS sub-protocol. Next, the MTLS sends data to
 223    the appropriate application using the source and destination port
 224    numbers and the length value.
 225
 226 Security Considerations
 227
 228    Security issues are discussed throughout this document, and in
 229    [TLS], [TLSv1.1], [DTLS] and [TLSEXT] documents.
 230
 231    If a fatal error related to a connexion of an arbitrary application
 232    is occurred, the secure session MUST NOT be resumed.
 233
 234 IANA Considerations
 235
 236    This document requires IANA to allocate the TBC TCP and UDP port
 237    numbers.
 238
 239 Acknowledgment
 240
 241    This document defined TLS Multiplexing for applications running over
 242    IP. Beyond that definition, generic options may be added to future
 243    versions of the current document.
 244
 245 References
 246
 247    [TLS]      Dierks, T., et. al., "The TLS Protocol Version 1.0", RFC
 248               2246, January 1999.
 249
 250    [TLSExt]   Blake-Wilson, S., et. al., "Transport Layer Security
 251              (TLS) Extensions", RFC 3546, June 2003.
 252
 253    [DTLS]     Rescorla, E., Modadugu, N., "Datagram Transport Layer
 254               Security", draft-rescorla-dtls-05.txt, June 2004.
 255
 256    [TLSv1.1]  Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
 257               draft-ietf-tls-rfc2246-bis-13.txt, June 2005
 258
 259    [SMTPTLS]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
 260               TLS", RFC 2487, January 1999.
 261
 262    [HTTPTLS]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
 263
 264    [POPTLS]   Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
 265               2595, June 1999.
 266
 267 Author's Addresses
 268
 269    Mohamad Badra
 270    ENST Paris
 271    France                    Email: Mohamad.Badra@enst.fr
 272
 273 Badra & Hajjeh               Expires March 2006                [Page 5]
 274 INTERNET-DRAFT                TLS Multiplexing             October 2005
 275
 276
 277    Ibrahim Hajjeh
 278    ESRGroups, Security WG
 279    France                    Email: Ibrahim.Hajjeh@esrgroups.org
 280
 281    Intellectual Property Statement
 282
 283    The IETF takes no position regarding the validity or scope of any
 284    Intellectual Property Rights or other rights that might be claimed
 285    to pertain to the implementation or use of the technology described
 286    in this document or the extent to which any license under such
 287    rights might or might not be available; nor does it represent that
 288    it has made any independent effort to identify any such rights.
 289    Information on the IETF's procedures with respect to rights in IETF
 290    Documents can be found in BCP 78 and BCP 79.
 291
 292    Copies of IPR disclosures made to the IETF Secretariat and any
 293    assurances of licenses to be made available, or the result of an
 294    attempt made to obtain a general license or permission for the use
 295    of such proprietary rights by implementers or users of this
 296    specification can be obtained from the IETF on-line IPR repository
 297    at http://www.ietf.org/ipr.
 298
 299    The IETF invites any interested party to bring to its attention any
 300    copyrights, patents or patent applications, or other proprietary
 301    rights that may cover technology that may be required to implement
 302    this standard. Please address the information to the IETF at ietf-
 303    ipr@ietf.org.
 304
 305    Disclaimer of Validity
 306
 307    This document and the information contained herein are provided on
 308    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
 309    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
 310    INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
 311    IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 312    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 313    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 314
 315    Copyright Statement
 316
 317    Copyright (C) The Internet Society (2004). This document is subject
 318    to the rights, licenses and restrictions contained in BCP 78, and
 319    except as set forth therein, the authors retain all their rights.
 320
 321    Acknowledgment
 322
 323    Funding for the RFC Editor function is currently provided by the
 324    Internet Society.
 325 Badra & Hajjeh               Expires March 2006                [Page 6]