idnits 2.17.00 (12 Aug 2021) /tmp/idnits43009/draft-fossati-dtls-over-gsm-sms-00.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 date (June 16, 2014) is 2896 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'GSM-SMS' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Possible downref: Non-RFC (?) normative reference: ref. 'WAP-WDP' == Outdated reference: A later version (-04) exists of draft-bormann-core-cocoa-01 == Outdated reference: draft-ietf-core-coap has been published as RFC 7252 == Outdated reference: draft-ietf-dice-profile has been published as RFC 7925 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Fossati 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track June 16, 2014 5 Expires: December 18, 2014 7 Datagram Transport Layer Security (DTLS) over Global System for Mobile 8 Communications (GSM) Short Message Service (SMS) 9 draft-fossati-dtls-over-gsm-sms-00 11 Abstract 13 This document specifies the use of Datagram Transport Layer Security 14 (DTLS) over the Global System for Mobile Communications (GSM) Short 15 Message Service (SMS). 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on December 18, 2014. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Usage of DTLS and SMS in CoAP M2M Environments . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. DTLS over SMS . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Data Coding Scheme . . . . . . . . . . . . . . . . . . . 3 56 3.2. Handshake Overview . . . . . . . . . . . . . . . . . . . 3 57 3.2.1. X.509 Certificate-based Authentication Caveats . . . 4 58 3.3. Message Segmentation and Re-Assembly . . . . . . . . . . 4 59 3.4. DTLS State Machine Timers Adjustments . . . . . . . . . . 5 60 3.5. Multiplexing Security Associations . . . . . . . . . . . 5 61 4. New Versions of DTLS . . . . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 8.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 This document specifies the use of DTLS [RFC6347] over GSM SMS 73 [GSM-SMS] for securing end-to-end communication between Mobile 74 Stations (i.e. devices implementing the GSM SMS communication 75 standard). 77 DTLS provides communications privacy for applications that use 78 datagram transport protocols and allows client/server applications to 79 communicate in a way that is designed to prevent eavesdropping and 80 detect tampering or message forgery. 82 SMS is a generic transport protocol for narrow-band end-to-end 83 communication between devices, and is an integral part of the GSM 84 network technology. 86 1.1. Usage of DTLS and SMS in CoAP M2M Environments 88 One of the main reasons for defining a DTLS/SMS binding is its 89 envisaged usage in machine-to-machine (M2M) communication. 91 Specifically, M2M environments based on the CoAP protocol mandate 92 DTLS for securing transactions between endpoints -- as detailed in 93 Section 9 of [I-D.ietf-core-coap], and further articulated in 94 [I-D.ietf-dice-profile], while the [OMA-LWM2M] architecture 95 identifies SMS as an alternative transport for CoAP messages. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 This specification requires readers to be familiar with all the terms 104 and concepts that are described in [GSM-SMS], [WAP-WDP], [RFC5246], 105 and [RFC6347]. 107 3. DTLS over SMS 109 3.1. Data Coding Scheme 111 The remainder of this specification assumes Mobile Stations are 112 capable of producing and consuming 8-bit binary data encoded 113 Transport Protocol Data Units (TPDU). 115 3.2. Handshake Overview 117 DTLS adds an additional roundtrip to the TLS [RFC5246] handshake to 118 serve as a return-routability test for protection against certain 119 types of DoS attacks. Thus a full blown DTLS handshake comprises up 120 to 6 "flights" (i.e. logical message exchanges), each of which is 121 then mapped on to one or more lower layer PDUs using the segmentation 122 and reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347]. 123 The overhead for said scheme is 6 bytes per Handshake message which, 124 given a realistic 10+ messages handshake, would amount around 60 125 bytes across the whole handshake sequence. 127 (Note that the DTLS SaR scheme is defined for handshake messages 128 only. In fact, Record Layer messages are never fragmented and MUST 129 fit within a single transport layer datagram, whatever be the limit 130 imposed by the underlying transport.) 132 SMS provides an optional segmentation and reassembly scheme as well, 133 known as Concatenated short messages (see Section 9.2.3.24.1 of 134 [GSM-SMS]). However, since the SaR scheme in DTLS can't be 135 circumvented, the Concatenated short messages mechanism SHOULD NOT be 136 used during handshake to avoid redundant overhead. Before starting 137 the handshake phase (either actively or passively), the DTLS 138 implementation MUST be explicitly configured with the PMTU of the SMS 139 transport in order to correctly instrument its SaR function. The 140 PMTU SHALL be 133 bytes if WPD-based multiplexing is used (see 141 Section 3.5), 140 bytes otherwise. 143 It is RECOMMENDED to use the established security context over the 144 longest possible period (possibly until a Closure Alert message is 145 received, or after a very long inactivity timeout) to avoid the 146 expensive re-establishment of the security association. 148 3.2.1. X.509 Certificate-based Authentication Caveats 150 X.509 certificate-based authentication (used in Certificate mode 151 CoAP) exacerbates the number of TPDUs -- especially those involved in 152 flight 4 and 5 -- needed to complete the handshake phase. 154 In such case, given the typical latency of the SMS transport, the 155 time to finalise the handshake could be in the order of 10s of 156 seconds (maybe even minutes). 158 More importantly, the large number of TPDUs involved increases the 159 likelihood to incur packet loss which DTLS does not handle 160 efficiently. In fact, the DTLS timeout and retransmission logics 161 apply to whole flights, but not to message fragments individually. 162 So, loss or delay of a single fragment may disrupt the current 163 flight, which needs to be entirely retransmitted. 165 Depending on the delay and packet loss characteristics of the network 166 link, completing a DTLS handshake which involves exchanging X.509 167 data may prove to be a daunting task [[CREF1: TODO: substantiate with 168 figures]]. 170 For these reasons, it is advisable to carefully consider whether the 171 use of X.509 certificate-based authentication is compatible with the 172 characteristics of the network link between the involved parties. 174 3.3. Message Segmentation and Re-Assembly 176 [RFC6347] requires that each DTLS message fits within a single 177 transport layer datagram 179 The content of an SMS message is carried in the TP-UserData field, 180 and its size may be up to 140 bytes. As already mentioned in 181 Section 3.2, longer (i.e. up to 34170 bytes) messages can be sent 182 using a segmentation and reassembly scheme known as Concatenated SMS 183 (see Section 9.2.3.24.1 of [GSM-SMS]). 185 This scheme consumes 6-7 bytes (depending on whether the short or 186 long segmentation format is used) of the TP-UserData field, thus 187 reducing the space available for the actual content of the SMS 188 message to 133-134 bytes per TPDU. 190 Though in principle a PMTU value higher than 140 bytes could be used 191 (which may look like an appealing option given its more efficient use 192 of the transport) there is a significant number of disadvantages to 193 consider (apart from the fixed tax of 7 bytes per TPDU to be paid to 194 the SaR function): 196 1. high sensitivity to packet loss -- since there is no automatic 197 recovery mechanism in case one TPDU in the chain is lost, and 198 since the SaR function is transparent to the application layer, 199 then a PMTU worth of data may be discarded even if just 1/255th 200 of the data were lost; 202 2. some networks may support the Concatenated SMS function 203 partially, if at all; 205 3. TPDU reordering may delay data delivery to the application; 207 4. high buffering requirement on both ends of the communication 208 path. 210 For these reasons, the Concatenated short messages mechanism SHOULD 211 NOT be used, and it is RECOMMENDED to leave the same PMTU settings 212 used during the handshake phase (Section 3.2), i.e. 133 bytes if WDP- 213 based multiplexing is enabled (Section 3.5), 140 bytes otherwise. 215 3.4. DTLS State Machine Timers Adjustments 217 [RFC6347] recommends an initial timer value of 1 second with 218 exponential back off up to no less then 60 seconds. Given the 219 latency characteristics of typical SMS delivery, the 1 second value 220 can easily lead to spurious retransmissions, which in turn may lead 221 to link congestion. 223 Choosing an appropriate timer value is a difficult problem due to the 224 wide variance in latency in SMS delivery. This specification 225 RECOMMENDS an initial timer value of 10 seconds with exponential back 226 off up to no less then 60 seconds. 228 If an RTT estimator (e.g. [I-D.bormann-core-cocoa]) is already 229 available in the protocol stack of the device, it could be used to 230 dynamically update the setting of the retransmit timeout. 232 3.5. Multiplexing Security Associations 234 Unlike IPsec, DTLS records do not contain any association 235 identifiers. Applications must arrange to multiplex between 236 associations on the same endpoint which, when using UDP/IP, is 237 usually done with the host/port number. 239 If the DTLS server allows more than one client to be active at any 240 given time, then the WAP User Datagram Protocol [WAP-WDP] can be used 241 to achieve multiplexing of the different security associations. (The 242 use of WDP provides the additional benefit that upper layer protocols 243 can operate independently of the underlying wireless network, hence 244 achieving application-agnostic transport handover.) 246 The total overhead cost for encoding the WDP source and destination 247 ports is 7 bytes out of the total available for the SMS content. 249 The receiving side of the communication gets the source address from 250 the originator address (TP-OA) field of the SMS-DELIVER TPDU. This 251 way an unique 4-tuple identifying the security association can be 252 reconstructed at both ends. 254 4. New Versions of DTLS 256 As DTLS matures, revisions to and updates for [RFC6347] can be 257 expected. DTLS includes mechanisms for identifying the version in 258 use, and presumably future versions will either include backward 259 compatibility modes or at least not allow connections between 260 dissimilar versions. Since DTLS over SMS simply encapsulates the 261 DTLS records transparently, these changes should not affect this 262 document and the methods of this document should apply to future 263 versions of DTLS. 265 Therefore, in the absence of a revision to this document, this 266 document is assumed to apply to all future versions of DTLS. This 267 document will only be revised if a revision to DTLS or SMS makes a 268 revision to the encapsulation necessary. 270 5. Security Considerations 272 Security considerations for DTLS as specified in [RFC6347] apply. 274 In most networks, sending SMS messages is not a free service, 275 therefore DoS attacks tend to be a lot less common than in IP 276 networks. However, it is RECOMMENDED not to disable the cookie 277 exchange protection, unless the involved risks are fully understood, 278 and the chance of a DoS attack is deemed low enough to drop the 279 protection mechanism in order to save one round-trip per handshake. 281 DTLS lays on top of SMS, and therefore it doesn't provide any 282 security service to it. The SMS implementation must be able to 283 protect itself from any special SMS message that can be used to alter 284 the device state or configuration in an undesired way (e.g. fiddling 285 with the private key store). Any SMS client must make sure that 286 malicious use of such messages is not possible, for example, by 287 filtering out certain SMS User Data header fields. 289 The layering of DTLS on top of the SMS transport does not introduce 290 any new security issues. We believe that the recommendations 291 contained in this specification (i.e. initial RTO increase, use of 292 WDP for multiplexing security associations, avoidance of SMS SaR) 293 have no impact on the security of DTLS. 295 6. Acknowledgements 297 Thanks to Tim Carey, Zhiyuan Hu, Kathleen Moriarty, Eric Rescorla, 298 Padmakumar Subramani, for helpful comments and discussions that have 299 shaped this document. 301 7. IANA Considerations 303 This specification contains no request to IANA. 305 8. References 307 8.1. Normative References 309 [GSM-SMS] ETSI, "3GPP TS 23.040 V7.0.1 (2007-03): 3rd Generation 310 Partnership Project; Technical Specification Group Core 311 Network and Terminals; Technical realization of the Short 312 Message Service (SMS) (Release 7)", March 2007. 314 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 315 Requirement Levels", BCP 14, RFC 2119, March 1997. 317 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 318 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 320 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 321 Security Version 1.2", RFC 6347, January 2012. 323 [WAP-WDP] Wireless Application Protocol Forum, "Wireless Datagram 324 Protocol", June 2001. 326 8.2. Informative References 328 [I-D.bormann-core-cocoa] 329 Bormann, C., "CoAP Simple Congestion Control/Advanced", 330 draft-bormann-core-cocoa-01 (work in progress), February 331 2014. 333 [I-D.ietf-core-coap] 334 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 335 Application Protocol (CoAP)", draft-ietf-core-coap-18 336 (work in progress), June 2013. 338 [I-D.ietf-dice-profile] 339 Hartke, K. and H. Tschofenig, "A DTLS 1.2 Profile for the 340 Internet of Things", draft-ietf-dice-profile-01 (work in 341 progress), May 2014. 343 [OMA-LWM2M] 344 OMA, "Lightweight Machine to Machine Technical 345 Specification", 2013. 347 Author's Address 349 Thomas Fossati 350 Alcatel-Lucent 351 3 Ely Road 352 Milton, Cambridge CB24 6DD 353 UK 355 Email: thomas.fossati@alcatel-lucent.com