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