<?xml version="1.0" encoding="US-ASCII"?>
<!-- vim: set ts=2 expandtab: -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY RFC6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC7252 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7252.xml">
<!ENTITY I-D.ietf-dice-profile SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dice-profile.xml">
<!ENTITY I-D.bormann-core-cocoa SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bormann-core-cocoa.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<rfc category="std" docName="draft-fossati-dtls-over-gsm-sms-01" ipr="trust200902">
  <front>
    <title abbrev="DTLS over SMS">
      Datagram Transport Layer Security (DTLS) over Global System for Mobile Communications (GSM) Short Message Service (SMS)
    </title>

    <author fullname="Thomas Fossati" initials="T.F." surname="Fossati">
      <organization>Alcatel-Lucent</organization>
      <address>
        <postal>
          <street>3 Ely Road</street>
          <city>Milton, Cambridge</city>
          <code>CB24 6DD</code>
          <country>UK</country>
        </postal>
        <email>thomas.fossati@alcatel-lucent.com</email>
      </address>
    </author>

    <author fullname="Hannes Tschofenig" initials="H.T." surname="Tschofenig">
      <organization>ARM Ltd.</organization>
      <address>
        <postal>
          <street>110 Fulbourn Rd</street>
          <city>Cambridge</city>
          <code>CB1 9NJ</code>
          <country>UK</country>
        </postal>
        <email>hannes.tschofenig@gmx.net</email>
        <uri>http://www.tschofenig.priv.at</uri>
      </address>
    </author>

    <date year="2014" month="October" />

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>DTLS GSM SMS M2M</keyword>

    <abstract>
      <t>This document specifies the use of Datagram Transport Layer Security (DTLS) over the Global System for Mobile Communications (GSM) Short Message Service (SMS).</t>
      <t></t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document specifies the use of DTLS <xref target="RFC6347"/> over GSM SMS <xref target="GSM-SMS"/> for securing end-to-end communication between Mobile Stations (i.e. devices implementing the GSM SMS communication standard).</t>
      <t>DTLS provides communications privacy for applications that use datagram transport protocols and allows client/server applications to communicate in a way that is designed to prevent eavesdropping and detect tampering or message forgery.</t>
      <t>SMS is a generic transport protocol for narrow-band end-to-end communication between devices, and is an integral part of the GSM network technology.</t>

      <section title="Usage of DTLS and SMS in CoAP M2M Environments">
        <t>One of the main reasons for defining a DTLS/SMS binding is its envisaged usage in machine-to-machine (M2M) communication.</t>
        <t>Specifically, M2M environments based on the CoAP protocol mandate DTLS for securing transactions between endpoints -- as detailed in Section 9 of <xref target="RFC7252"/>, and further articulated in <xref target="I-D.ietf-dice-profile"/>, while the <xref target="OMA-LWM2M"/> architecture identifies SMS as an alternative transport for CoAP messages.</t>
      </section>
    </section>  <!-- Introduction -->

    <section title="Terminology">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119"/>.</t>
        <t>This specification requires readers to be familiar with all the terms and concepts that are described in <xref target="GSM-SMS"/>, <xref target="WAP-WDP"/>, <xref target="RFC5246"/>, and <xref target="RFC6347"/>.</t>
    </section>  <!-- Terminology -->

    <section title="DTLS over SMS">
      <section title="Data Coding Scheme">
        <t>The remainder of this specification assumes Mobile Stations are capable of producing and consuming 8-bit binary data encoded Transport Protocol Data Units (TPDU).</t>
      </section>  <!-- Data Coding Scheme -->

      <section title="Handshake Overview" anchor="section:handshake">
        <t>DTLS adds an additional roundtrip to the TLS <xref target="RFC5246"/> handshake to serve as a return-routability test for protection against certain types of DoS attacks.  Thus a full blown DTLS handshake comprises up to 6 "flights" (i.e. logical message exchanges), each of which is then mapped on to one or more lower layer PDUs using the segmentation and reassembly (SaR) scheme described in Section 4.2.3 of <xref target="RFC6347"/>.  The overhead for said scheme is 6 bytes per Handshake message which, given a realistic 10+ messages handshake, would amount around 60 bytes across the whole handshake sequence.</t>
        <t>(Note that the DTLS SaR scheme is defined for handshake messages only.  In fact, Record Layer messages are never fragmented and MUST fit within a single transport layer datagram, whatever be the limit imposed by the underlying transport.)</t>
        <t>SMS provides an optional segmentation and reassembly scheme as well, known as Concatenated short messages (see Section 9.2.3.24.1 of <xref target="GSM-SMS"/>).  However, since the SaR scheme in DTLS can't be circumvented, the Concatenated short messages mechanism SHOULD NOT be used during handshake to avoid redundant overhead.  Before starting the handshake phase (either actively or passively), the DTLS implementation MUST be explicitly configured with the PMTU of the SMS transport in order to correctly instrument its SaR function.  The PMTU SHALL be 133 bytes if WDP-based multiplexing is used (see <xref target="section:multiplexing"/>), 140 bytes otherwise.</t>
          <t>It is RECOMMENDED to use the established security context over the longest possible period (possibly until a Closure Alert message is received, or after a very long inactivity timeout) to avoid the expensive re-establishment of the security association.</t>
        <section title="X.509 Certificate-based Authentication Caveats">
          <t>X.509 certificate-based authentication (used in Certificate mode CoAP) exacerbates the number of TPDUs -- especially those involved in flight 4 and 5 -- needed to complete the handshake phase.</t>
          <t>In such case, given the typical latency of the SMS transport, the time to finalise the handshake could be in the order of 10s of seconds (maybe even minutes).</t>
          <t>More importantly, the large number of TPDUs involved increases the likelihood to incur packet loss which DTLS does not handle efficiently.  In fact, the DTLS timeout and retransmission logics apply to whole flights, but not to message fragments individually.  So, loss or delay of a single fragment may disrupt the current flight, which needs to be entirely retransmitted.</t>
          <t>Depending on the delay and packet loss characteristics of the network link, completing a DTLS handshake which involves exchanging X.509 data may prove to be a daunting task <cref>TODO: substantiate with figures</cref>.</t>
          <t>For these reasons, it is advisable to carefully consider whether the use of X.509 certificate-based authentication is compatible with the characteristics of the network link between the involved parties.</t>
            <!-- TODO See appendix \ref{appendix:examples} for practical examples of ciphersuites that minimise the number of round trips necessary to complete the handshake. -->
        </section>  <!-- X.509 Certificate-based Authentication Caveats -->
      </section>  <!-- Handshake Overview -->

      <section title="Message Segmentation and Re-Assembly">
        <t><xref target="RFC6347"/> requires that each DTLS message fits within a single transport layer datagram</t>
        <t>The content of an SMS message is carried in the TP-UserData field, and its size may be up to 140 bytes.  As already mentioned in <xref target="section:handshake"/>, longer (i.e. up to 34170 bytes) messages can be sent using a segmentation and reassembly scheme known as Concatenated SMS (see Section 9.2.3.24.1 of <xref target="GSM-SMS"/>).</t>
        <t>This scheme consumes 6-7 bytes (depending on whether the short or long segmentation format is used) of the TP-UserData field, thus reducing the space available for the actual content of the SMS message to 133-134 bytes per TPDU.</t>
        <t>Though in principle a PMTU value higher than 140 bytes could be used (which may look like an appealing option given its more efficient use of the transport) there is a significant number of disadvantages to consider (apart from the fixed tax of 7 bytes per TPDU to be paid to the SaR function):
          <list style="numbers">
            <t>high sensitivity to packet loss -- since there is no automatic recovery mechanism in case one TPDU in the chain is lost, and since the SaR function is transparent to the application layer, then a PMTU worth of data may be discarded even if just 1/255th of the data were lost;</t>
            <t>some networks may support the Concatenated SMS function partially, if at all;</t>
            <t>TPDU reordering may delay data delivery to the application;</t>
            <t>high buffering requirement on both ends of the communication path.</t>
          </list></t>
          <t>For these reasons, the Concatenated short messages mechanism SHOULD NOT be used, and it is RECOMMENDED to leave the same PMTU settings used during the handshake phase (<xref target="section:handshake"/>), i.e. 133 bytes if WDP-based multiplexing is enabled (<xref target="section:multiplexing"/>), 140 bytes otherwise.</t>
          <t>Note that, after DTLS handshake has completed, any fragmentation and reassembly logics that pertains the application layer - e.g. segmenting CoAP messages into DTLS records and reassembling them after the crypto operations have been successfully performed - needs to be handled by the application that uses the established DTLS tunnel.</t>
      </section>  <!-- Message Segmentation and Re-Assembly --> 

      <section title="DTLS State Machine Timers Adjustments">
        <t><xref target="RFC6347"/> recommends an initial timer value of 1 second with exponential back off up to no less then 60 seconds.  Given the latency characteristics of typical SMS delivery, the 1 second value can easily lead to spurious retransmissions, which in turn may lead to link congestion.</t>
        <t>Choosing an appropriate timer value is a difficult problem due to the wide variance in latency in SMS delivery.
          <!-- and also to the fact that in M2M environments a substantial fraction of the delay could be due to the cryptographic computation that the (constrained) device is performing. -->
        This specification RECOMMENDS an initial timer value of 10 seconds with exponential back off up to no less then 60 seconds.</t>
        <t>If SMS-STATUS-REPORT messages are enabled, their receipt is not to be interpreted as the signal that the specific handshake message has been acted upon by the receiving party.  Therefore, it MUST NOT be taken into account by the DTLS timeout and retransmission function.</t>
        <t>Handshake messages MUST carry a validity period (TP-VP parameter in a SMS-SUBMIT TPDU) that is not less than the current value of the retransmission timeout.  In order to avoid persisting messages in the network that will be discarded by the receiving party, handshake messages SHOULD carry a validity period that is the same as, or just slightly higher than, the current value of the retransmission timeout.</t>
        <t>If an RTT estimator (e.g. <xref target="I-D.bormann-core-cocoa"/>) is already available in the protocol stack of the device, it could be used to dynamically update the setting of the retransmit timeout.</t>
      </section>  <!-- DTLS State Machine Timers Adjustments -->

      <section title="Multiplexing Security Associations" anchor="section:multiplexing">
        <t>Unlike IPsec, DTLS records do not contain any association identifiers.  Applications must arrange to multiplex between associations on the same endpoint which, when using UDP/IP, is usually done with the host/port number.</t>
        <t>If the DTLS server allows more than one client to be active at any given time, then the WAP User Datagram Protocol <xref target="WAP-WDP"/> can be used to achieve multiplexing of the different security associations.  (The use of WDP provides the additional benefit that upper layer protocols can operate independently of the underlying wireless network, hence achieving application-agnostic transport handover.)</t>
        <t>The total overhead cost for encoding the WDP source and destination ports is 7 bytes out of the total available for the SMS content.</t>
        <t>The receiving side of the communication gets the source address from the originator address (TP-OA) field of the SMS-DELIVER TPDU.  This way an unique 4-tuple identifying the security association can be reconstructed at both ends. (When replying to its DTLS peer, the sender will swaps the TP-OA and TP-DA parameters and the source and destination ports in the WDP.)</t>
      </section>  <!-- Multiplexing Security Associations -->
    </section>

    <section title="New Versions of DTLS">
      <t>As DTLS matures, revisions to and updates for <xref target="RFC6347"/> can be expected.  DTLS includes mechanisms for identifying the version in use, and presumably future versions will either include backward compatibility modes or at least not allow connections between dissimilar versions.  Since DTLS over SMS simply encapsulates the DTLS records transparently, these changes should not affect this document and the methods of this document should apply to future  versions of DTLS.</t>
      <t>Therefore, in the absence of a revision to this document, this document is assumed to apply to all future versions of DTLS.  This document will only be revised if a revision to DTLS or SMS makes a revision to the encapsulation necessary.</t>
    </section>  <!-- New Versions of DTLS -->


    <section title="Security Considerations">
      <t>Security considerations for DTLS as specified in <xref target="RFC6347"/> apply.</t>
      <t>In most networks, sending SMS messages is not a free service, therefore DoS attacks tend to be a lot less common than in IP networks.  However, it is RECOMMENDED not to disable the cookie exchange protection, unless the involved risks are fully understood, and the chance of a DoS attack is deemed low enough to drop the protection mechanism in order to save one round-trip per handshake.</t>
      <t>DTLS lays on top of SMS, and therefore it doesn't provide any security service to it.  The SMS implementation must be able to protect itself from any special SMS message that can be used to alter the device state or configuration in an undesired way (e.g. fiddling with the private key store).  Any SMS client must make sure that malicious use of such messages is not possible, for example, by filtering out certain SMS User Data header fields.</t>
      <t>The layering of DTLS on top of the SMS transport does not introduce any new security issues.  We believe that the recommendations contained in this specification (i.e. initial RTO increase, use of WDP for multiplexing security associations, avoidance of SMS SaR) have no impact on the security of DTLS.</t>
    </section>  <!-- Security Considerations -->

    <section title="Acknowledgements">
      <t>Thanks to
        Tim Carey,
        Thierry Garnier,
        Zhiyuan Hu,
        Kathleen Moriarty,
        Eric Rescorla,
        Padmakumar Subramani,
      for helpful comments and discussions that have shaped this document.
      </t>
    </section>  <!-- Acknowledgements -->

    <section title="IANA Considerations">
      <t>This specification contains no request to IANA.</t>
    </section>  <!-- IANA Considerations -->

  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC5246;
      &RFC6347;
      <reference anchor="WAP-WDP">
        <front>
          <title>Wireless Datagram Protocol</title>
          <author>
            <organization>Wireless Application Protocol Forum</organization>
          </author>
          <date month="June" year="2001" />
        </front>
      </reference>
      <reference anchor="GSM-SMS">
        <front>
          <title>3GPP TS 23.040 V7.0.1 (2007-03): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Technical realization of the Short Message Service (SMS) (Release 7)</title>
          <author>
            <organization>ETSI</organization>
          </author>
          <date month="March" year="2007" />
        </front>
      </reference>
    </references> <!-- Normative Refs -->

    <references title="Informative References">
      &RFC7252;
      &I-D.ietf-dice-profile;
      &I-D.bormann-core-cocoa;
      <reference anchor="OMA-LWM2M">
        <front>
          <title>Lightweight Machine to Machine Technical Specification</title>
          <author>
            <organization>OMA</organization>
          </author>
          <date year="2013" />
        </front>
      </reference>
    </references> <!-- Informative Refs -->

    <!--
    <section title="Examples">
    </section>
    -->
  </back>
</rfc>
