Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7925

Transport Layer Security (TLS) / Datagram Transport Layer Security (DTLS) Profiles for the Internet of Things

Pages: 61
Proposed Standard
Part 3 of 3 – Pages 42 to 61
First   Prev   None

Top   ToC   RFC7925 - Page 42   prevText

17. Renegotiation Attacks

TLS/DTLS allows a client and a server that already have a TLS/DTLS connection to negotiate new parameters, generate new keys, etc., by using the renegotiation feature. Renegotiation happens in the existing connection, with the new handshake packets being encrypted along with application data. Upon completion of the renegotiation procedure, the new channel replaces the old channel. As described in RFC 5746 [RFC5746], there is no cryptographic binding between the two handshakes, although the new handshake is carried out using the cryptographic parameters established by the original handshake. To prevent the renegotiation attack [RFC5746], this specification REQUIRES the TLS renegotiation feature to be disabled. Clients MUST respond to server-initiated renegotiation attempts with an alert message (no_renegotiation), and clients MUST NOT initiate them.

18. Downgrading Attacks

When a client sends a ClientHello with a version higher than the highest version known to the server, the server is supposed to reply with ServerHello.version equal to the highest version known to the server, and then the handshake can proceed. This behavior is known as version tolerance. Version intolerance is when the server (or a middlebox) breaks the handshake when it sees a ClientHello.version higher than what it knows about. This is the behavior that leads some clients to rerun the handshake with a lower version. As a result, a potential security vulnerability is introduced when a system is running an old TLS/SSL version (e.g., because of the need to integrate with legacy systems). In the worst case, this allows an attacker to downgrade the protocol handshake to SSL 3.0. SSL 3.0 is so broken that there is no secure cipher available for it (see [RFC7568]). The above-described downgrade vulnerability is solved by the TLS Fallback Signaling Cipher Suite Value (SCSV) [RFC7507] extension. However, the solution is not applicable to implementations conforming to this profile since the version negotiation MUST use TLS/DTLS version 1.2 (or higher). More specifically, this implies: o Clients MUST NOT send a TLS/DTLS version lower than version 1.2 in the ClientHello. o Clients MUST NOT retry a failed negotiation offering a TLS/DTLS version lower than 1.2.
Top   ToC   RFC7925 - Page 43
   o  Servers MUST fail the handshake by sending a protocol_version
      fatal alert if a TLS/DTLS version >= 1.2 cannot be negotiated.
      Note that the aborted connection is non-resumable.

19. Crypto Agility

This document recommends that software and chip manufacturers implement AES and the CCM mode of operation. This document references the CoAP-recommended ciphersuite choices, which have been selected based on implementation and deployment experience from the IoT community. Over time, the preference for algorithms will, however, change. Not all components of a ciphersuite are likely to change at the same speed. Changes are more likely expected for ciphers, the mode of operation, and the hash algorithms. The recommended key lengths have to be adjusted over time as well. Some deployment environments will also be impacted by local regulation, which might dictate a certain algorithm and key size combination. Ongoing discussions regarding the choice of specific ECC curves will also likely impact implementations. Note that this document does not recommend or mandate a specific ECC curve. The following recommendations can be made to chip manufacturers: o Make any AES hardware-based crypto implementation accessible to developers working on security implementations at higher layers in the protocol stack. Sometimes hardware implementations are added to microcontrollers to offer support for functionality needed at the link layer and are only available to the on-chip link-layer protocol implementation. Such a setup does not allow application developers to reuse the hardware-based AES implementation. o Provide flexibility for the use of the crypto function with future extensibility in mind. For example, making an AES-CCM implementation available to developers is a first step but such an implementation may not be usable due to parameter differences between an AES-CCM implementation. AES-CCM in IEEE 802.15.4 and Bluetooth Smart use a nonce length of 13 octets while DTLS uses a nonce length of 12 octets. Hardware implementations of AES-CCM for IEEE 802.15.4 and Bluetooth Smart are therefore not reusable by a DTLS stack. o Offer access to building blocks in addition (or as an alternative) to the complete functionality. For example, a chip manufacturer who gives developers access to the AES crypto function can use it to build an efficient AES-GCM implementation. Another example is to make a special instruction available that increases the speed of speed-up carryless multiplications.
Top   ToC   RFC7925 - Page 44
   As a recommendation for developers and product architects, we suggest
   that sufficient headroom is provided to allow an upgrade to a newer
   cryptographic algorithm over the lifetime of the product.  As an
   example, while AES-CCM is recommended throughout this specification,
   future products might use the ChaCha20 cipher in combination with the
   Poly1305 authenticator [RFC7539].  The assumption is made that a
   robust software update mechanism is offered.

20. Key Length Recommendations

RFC 4492 [RFC4492] gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems based on the best-known algorithms for attacking them. While other publications suggest slightly different numbers, such as [Keylength], the approximate relationship still holds true. Figure 12 illustrates the comparable key sizes in bits. Symmetric | ECC | DH/DSA/RSA ------------+---------+------------- 80 | 163 | 1024 112 | 233 | 2048 128 | 283 | 3072 192 | 409 | 7680 256 | 571 | 15360 Figure 12: Comparable Key Sizes (in Bits) Based on RFC 4492 At the time of writing, the key size recommendations for use with TLS-based ciphers found in [RFC7525] recommend DH key lengths of at least 2048 bits, which corresponds to a 112-bit symmetric key and a 233-bit ECC key. These recommendations are roughly in line with those from other organizations, such as the National Institute of Standards and Technology (NIST) or the European Network and Information Security Agency (ENISA). The authors of [ENISA-Report2013] add that a 80-bit symmetric key is sufficient for legacy applications for the coming years, but a 128-bit symmetric key is the minimum requirement for new systems being deployed. The authors further note that one needs to also take into account the length of time data needs to be kept secure for. The use of 80-bit symmetric keys for transactional data may be acceptable for the near future while one has to insist on 128-bit symmetric keys for long- lived data. Note that the recommendations for 112-bit symmetric keys are chosen conservatively under the assumption that IoT devices have a long expected lifetime (such as 10+ years) and that this key length recommendation refers to the long-term keys used for device authentication. Keys, which are provisioned dynamically, for the
Top   ToC   RFC7925 - Page 45
   protection of transactional data (such as ephemeral DH keys used in
   various TLS/DTLS ciphersuites) may be shorter considering the
   sensitivity of the exchanged data.

21. False Start

A full TLS handshake as specified in [RFC5246] requires two full protocol rounds (four flights) before the handshake is complete and the protocol parties may begin to send application data. An abbreviated handshake (resuming an earlier TLS session) is complete after three flights, thus adding just one round-trip time if the client sends application data first. If the conditions outlined in [TLS-FALSESTART] are met, application data can be transmitted when the sender has sent its own "ChangeCipherSpec" and "Finished" messages. This achieves an improvement of one round-trip time for full handshakes if the client sends application data first and for abbreviated handshakes if the server sends application data first. The conditions for using the TLS False Start mechanism are met by the public-key-based ciphersuites in this document. In summary, the conditions are: o Modern symmetric ciphers with an effective key length of 128 bits, such as AES-128-CCM o Client certificate types, such as ecdsa_sign o Key exchange methods, such as ECDHE_ECDSA Based on the improvement over a full round-trip for the full TLS/DTLS exchange, this specification RECOMMENDS the use of the False Start mechanism when clients send application data first.

22. Privacy Considerations

The DTLS handshake exchange conveys various identifiers, which can be observed by an on-path eavesdropper. For example, the DTLS PSK exchange reveals the PSK identity, the supported extensions, the session ID, algorithm parameters, etc. When session resumption is used, then individual TLS sessions can be correlated by an on-path adversary. With many IoT deployments, it is likely that keying material and their identifiers are persistent over a longer period of time due to the cost of updating software on these devices.
Top   ToC   RFC7925 - Page 46
   User participation poses a challenge in many IoT deployments since
   many of the IoT devices operate unattended, even though they are
   initially provisioned by a human.  The ability to control data
   sharing and to configure preferences will have to be provided at a
   system level rather than at the level of the DTLS exchange itself,
   which is the scope of this document.  Quite naturally, the use of
   DTLS with mutual authentication will allow a TLS server to collect
   authentication information about the IoT device (likely over a long
   period of time).  While this strong form of authentication will
   prevent misattribution, it also allows strong identification.
   Device-related data collection (e.g., sensor recordings) associated
   with other data types will prove to be truly useful, but this extra
   data might include personal information about the owner of the device
   or data about the environment it senses.  Consequently, the data
   stored on the server side will be vulnerable to stored data
   compromise.  For the communication between the client and the server,
   this specification prevents eavesdroppers from gaining access to the
   communication content.  While the PSK-based ciphersuite does not
   provide PFS, the asymmetric versions do.  This prevents an adversary
   from obtaining past communication content when access to a long-term
   secret has been gained.  Note that no extra effort to make traffic
   analysis more difficult is provided by the recommendations made in
   this document.

   Note that the absence or presence of communication itself might
   reveal information to an adversary.  For example, a presence sensor
   may initiate messaging when a person enters a building.  While TLS/
   DTLS would offer confidentiality protection of the transmitted
   information, it does not help to conceal all communication patterns.
   Furthermore, the IP header, which is not protected by TLS/DTLS,
   additionally reveals information about the other communication
   endpoint.  For applications where such privacy concerns exist,
   additional safeguards are required, such as injecting dummy traffic
   and onion routing.  A detailed treatment of such solutions is outside
   the scope of this document and requires a system-level view.

23. Security Considerations

This entire document is about security. We would also like to point out that designing a software update mechanism into an IoT system is crucial to ensure that both functionality can be enhanced and that potential vulnerabilities can be fixed. This software update mechanism is important for changing configuration information, for example, trust anchors and other keying-related information. Such a suitable software update mechanism is available with the LWM2M protocol published by the OMA [LWM2M].
Top   ToC   RFC7925 - Page 47

24. References

24.1. Normative References

[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)", Registration Authority, <https://standards.ieee.org/regauth/ oui/tutorials/EUI64.html>. [GSM-SMS] ETSI, "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Technical realization of the Short Message Service (SMS) (Release 13)", 3GPP TS 23.040 V13.1.0, March 2016. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)", RFC 4279, DOI 10.17487/RFC4279, December 2005, <http://www.rfc-editor.org/info/rfc4279>. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>. [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, "Transport Layer Security (TLS) Renegotiation Indication Extension", RFC 5746, DOI 10.17487/RFC5746, February 2010, <http://www.rfc-editor.org/info/rfc5746>. [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <http://www.rfc-editor.org/info/rfc6066>. [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>.
Top   ToC   RFC7925 - Page 48
   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
              January 2012, <http://www.rfc-editor.org/info/rfc6347>.

   [RFC6520]  Seggelmann, R., Tuexen, M., and M. Williams, "Transport
              Layer Security (TLS) and Datagram Transport Layer Security
              (DTLS) Heartbeat Extension", RFC 6520,
              DOI 10.17487/RFC6520, February 2012,
              <http://www.rfc-editor.org/info/rfc6520>.

   [RFC7250]  Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
              Weiler, S., and T. Kivinen, "Using Raw Public Keys in
              Transport Layer Security (TLS) and Datagram Transport
              Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
              June 2014, <http://www.rfc-editor.org/info/rfc7250>.

   [RFC7251]  McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
              CCM Elliptic Curve Cryptography (ECC) Cipher Suites for
              TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014,
              <http://www.rfc-editor.org/info/rfc7251>.

   [RFC7627]  Bhargavan, K., Ed., Delignat-Lavaud, A., Pironti, A.,
              Langley, A., and M. Ray, "Transport Layer Security (TLS)
              Session Hash and Extended Master Secret Extension",
              RFC 7627, DOI 10.17487/RFC7627, September 2015,
              <http://www.rfc-editor.org/info/rfc7627>.

   [RFC7924]  Santesson, S. and H. Tschofenig, "Transport Layer Security
              (TLS) Cached Information Extension", RFC 7924,
              DOI 10.17487/RFC7924, July 2016,
              <http://www.rfc-editor.org/info/rfc7924>.

   [WAP-WDP]  Open Mobile Alliance, "Wireless Datagram Protocol",
              Wireless Application Protocol, WAP-259-WDP, June 2001.

24.2. Informative References

[ACE-WG] IETF, "Authentication and Authorization for Constrained Environments (ACE) Working Group", <https://datatracker.ietf.org/wg/ace/charter>. [AES] National Institute of Standards and Technology, "Advanced Encryption Standard (AES)", NIST FIPS PUB 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf>.
Top   ToC   RFC7925 - Page 49
   [CCM]      National Institute of Standards and Technology,
              "Recommendation for Block Cipher Modes of Operation: The
              CCM Mode for Authentication and Confidentiality", NIST
              Special Publication 800-38C, May 2004,
              <http://csrc.nist.gov/publications/nistpubs/800-38C/
              SP800-38C_updated-July20_2007.pdf>.

   [COAP-TCP-TLS]
              Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
              Silverajan, B., and B. Raymor, "CoAP (Constrained
              Application Protocol) over TCP, TLS, and WebSockets", Work
              in Progress, draft-ietf-core-coap-tcp-tls-03, July 2016.

   [CoRE-RD]  Shelby, Z., Koster, M., Bormann, C., and P. Stok, "CoRE
              Resource Directory", Work in Progress, draft-ietf-core-
              resource-directory-08, July 2016.

   [CRIME]    Wikipedia, "CRIME", May 2016, <https://en.wikipedia.org/w/
              index.php?title=CRIME&oldid=721665716>.

   [ENISA-Report2013]
              ENISA, "Algorithms, Key Sizes and Parameters Report -
              2013", October 2013, <https://www.enisa.europa.eu/
              activities/identity-and-trust/library/deliverables/
              algorithms-key-sizes-and-parameters-report>.

   [FFDHE-TLS]
              Gillmor, D., "Negotiated Finite Field Diffie-Hellman
              Ephemeral Parameters for TLS", Work in Progress,
              draft-ietf-tls-negotiated-ff-dhe-10, June 2015.

   [HomeGateway]
              Eggert, L., Hatoen, S., Kojo, M., Nyrhinen, A., Sarolahti,
              P., and S. Strowes, "An Experimental Study of Home Gateway
              Characteristics", In Proceedings of the 10th ACM SIGCOMM
              conference on Internet measurement,
              DOI 10.1145/1879141.1879174, 2010,
              <http://conferences.sigcomm.org/imc/2010/papers/p260.pdf>.

   [IANA-TLS] IANA, "Transport Layer Security (TLS) Parameters",
              <https://www.iana.org/assignments/tls-parameters>.
Top   ToC   RFC7925 - Page 50
   [ImprintingSurvey]
              Chilton, E., "A Brief Survey of Imprinting Options for
              Constrained Devices", March 2012,
              <http://www.lix.polytechnique.fr/hipercom/
              SmartObjectSecurity/papers/EricRescorla.pdf>.

   [Keylength]
              Giry, D., "Cryptographic Key Length Recommendations",
              September 2015, <http://www.keylength.com>.

   [LWM2M]    Open Mobile Alliance, "Lightweight Machine-to-Machine
              Requirements", Candidate Version 1.0, OMA-RD-
              LightweightM2M-V1_0-20131210-C, December 2013,
              <http://openmobilealliance.org/about-oma/work-program/
              m2m-enablers>.

   [PSK-AES-CCM-TLS]
              Schmertmann, L. and C. Bormann, "ECDHE-PSK AES-CCM Cipher
              Suites with Forward Secrecy for Transport Layer Security
              (TLS)", Work in Progress, draft-schmertmann-dice-ccm-
              psk-pfs-01, August 2014.

   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
              for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
              1996, <http://www.rfc-editor.org/info/rfc1981>.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <http://www.rfc-editor.org/info/rfc2104>.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, DOI 10.17487/RFC2865, June 2000,
              <http://www.rfc-editor.org/info/rfc2865>.

   [RFC3610]  Whiting, D., Housley, R., and N. Ferguson, "Counter with
              CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
              2003, <http://www.rfc-editor.org/info/rfc3610>.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, Ed., "Extensible Authentication Protocol
              (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
              <http://www.rfc-editor.org/info/rfc3748>.
Top   ToC   RFC7925 - Page 51
   [RFC4086]  Eastlake 3rd, D., Schiller, J., and S. Crocker,
              "Randomness Requirements for Security", BCP 106, RFC 4086,
              DOI 10.17487/RFC4086, June 2005,
              <http://www.rfc-editor.org/info/rfc4086>.

   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
              for Transport Layer Security (TLS)", RFC 4492,
              DOI 10.17487/RFC4492, May 2006,
              <http://www.rfc-editor.org/info/rfc4492>.

   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
              Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
              <http://www.rfc-editor.org/info/rfc4821>.

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals",
              RFC 4919, DOI 10.17487/RFC4919, August 2007,
              <http://www.rfc-editor.org/info/rfc4919>.

   [RFC5077]  Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
              "Transport Layer Security (TLS) Session Resumption without
              Server-Side State", RFC 5077, DOI 10.17487/RFC5077,
              January 2008, <http://www.rfc-editor.org/info/rfc5077>.

   [RFC5116]  McGrew, D., "An Interface and Algorithms for Authenticated
              Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
              <http://www.rfc-editor.org/info/rfc5116>.

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
              March 2008, <http://www.rfc-editor.org/info/rfc5216>.

   [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              RFC 5247, DOI 10.17487/RFC5247, August 2008,
              <http://www.rfc-editor.org/info/rfc5247>.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <http://www.rfc-editor.org/info/rfc5280>.
Top   ToC   RFC7925 - Page 52
   [RFC5288]  Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
              Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
              DOI 10.17487/RFC5288, August 2008,
              <http://www.rfc-editor.org/info/rfc5288>.

   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
              <http://www.rfc-editor.org/info/rfc5480>.

   [RFC5758]  Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
              Polk, "Internet X.509 Public Key Infrastructure:
              Additional Algorithms and Identifiers for DSA and ECDSA",
              RFC 5758, DOI 10.17487/RFC5758, January 2010,
              <http://www.rfc-editor.org/info/rfc5758>.

   [RFC5934]  Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor
              Management Protocol (TAMP)", RFC 5934,
              DOI 10.17487/RFC5934, August 2010,
              <http://www.rfc-editor.org/info/rfc5934>.

   [RFC6024]  Reddy, R. and C. Wallace, "Trust Anchor Management
              Requirements", RFC 6024, DOI 10.17487/RFC6024, October
              2010, <http://www.rfc-editor.org/info/rfc6024>.

   [RFC6090]  McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
              Curve Cryptography Algorithms", RFC 6090,
              DOI 10.17487/RFC6090, February 2011,
              <http://www.rfc-editor.org/info/rfc6090>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <http://www.rfc-editor.org/info/rfc6234>.

   [RFC6655]  McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for
              Transport Layer Security (TLS)", RFC 6655,
              DOI 10.17487/RFC6655, July 2012,
              <http://www.rfc-editor.org/info/rfc6655>.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
              <http://www.rfc-editor.org/info/rfc6690>.

   [RFC6733]  Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
              Ed., "Diameter Base Protocol", RFC 6733,
              DOI 10.17487/RFC6733, October 2012,
              <http://www.rfc-editor.org/info/rfc6733>.
Top   ToC   RFC7925 - Page 53
   [RFC6943]  Thaler, D., Ed., "Issues in Identifier Comparison for
              Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May
              2013, <http://www.rfc-editor.org/info/rfc6943>.

   [RFC6961]  Pettersen, Y., "The Transport Layer Security (TLS)
              Multiple Certificate Status Request Extension", RFC 6961,
              DOI 10.17487/RFC6961, June 2013,
              <http://www.rfc-editor.org/info/rfc6961>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,
              <http://www.rfc-editor.org/info/rfc7228>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <http://www.rfc-editor.org/info/rfc7252>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <http://www.rfc-editor.org/info/rfc7258>.

   [RFC7366]  Gutmann, P., "Encrypt-then-MAC for Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", RFC 7366, DOI 10.17487/RFC7366, September 2014,
              <http://www.rfc-editor.org/info/rfc7366>.

   [RFC7390]  Rahman, A., Ed. and E. Dijk, Ed., "Group Communication for
              the Constrained Application Protocol (CoAP)", RFC 7390,
              DOI 10.17487/RFC7390, October 2014,
              <http://www.rfc-editor.org/info/rfc7390>.

   [RFC7397]  Gilger, J. and H. Tschofenig, "Report from the Smart
              Object Security Workshop", RFC 7397, DOI 10.17487/RFC7397,
              December 2014, <http://www.rfc-editor.org/info/rfc7397>.

   [RFC7400]  Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
              IPv6 over Low-Power Wireless Personal Area Networks
              (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
              2014, <http://www.rfc-editor.org/info/rfc7400>.

   [RFC7452]  Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
              "Architectural Considerations in Smart Object Networking",
              RFC 7452, DOI 10.17487/RFC7452, March 2015,
              <http://www.rfc-editor.org/info/rfc7452>.
Top   ToC   RFC7925 - Page 54
   [RFC7465]  Popov, A., "Prohibiting RC4 Cipher Suites", RFC 7465,
              DOI 10.17487/RFC7465, February 2015,
              <http://www.rfc-editor.org/info/rfc7465>.

   [RFC7507]  Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
              Suite Value (SCSV) for Preventing Protocol Downgrade
              Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,
              <http://www.rfc-editor.org/info/rfc7507>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <http://www.rfc-editor.org/info/rfc7525>.

   [RFC7539]  Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
              Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
              <http://www.rfc-editor.org/info/rfc7539>.

   [RFC7568]  Barnes, R., Thomson, M., Pironti, A., and A. Langley,
              "Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
              DOI 10.17487/RFC7568, June 2015,
              <http://www.rfc-editor.org/info/rfc7568>.

   [RFC7748]  Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
              for Security", RFC 7748, DOI 10.17487/RFC7748, January
              2016, <http://www.rfc-editor.org/info/rfc7748>.

   [SP800-107-rev1]
              National Institute of Standards and Technology,
              "Recommendation for Applications Using Approved Hash
              Algorithms", NIST Special Publication 800-107, Revision 1,
              DOI 10.6028/NIST.SP.800-107r1, August 2012,
              <http://csrc.nist.gov/publications/nistpubs/800-107-rev1/
              sp800-107-rev1.pdf>.

   [SP800-22b]
              National Institute of Standards and Technology, "A
              Statistical Test Suite for Random and Pseudorandom Number
              Generators for Cryptographic Applications", NIST Special
              Publication 800-22, Revision 1a, April 2010,
              <http://csrc.nist.gov/publications/nistpubs/800-22-rev1a/
              SP800-22rev1a.pdf>.
Top   ToC   RFC7925 - Page 55
   [SP800-90A]
              National Institute of Standards and Technology,
              "Recommendation for Random Number Generation Using
              Deterministic Random Bit Generators", NIST Special
              Publication 800-90A Revision 1,
              DOI 10.6028/NIST.SP.800-90Ar1, June 2015,
              <http://csrc.nist.gov/publications/drafts/800-90/
              sp800-90a_r1_draft_november2014_ver.pdf>.

   [TLS-FALSESTART]
              Langley, A., Modadugu, N., and B. Moeller, "Transport
              Layer Security (TLS) False Start", Work in Progress,
              draft-ietf-tls-falsestart-02, May 2016.

   [Triple-HS]
              Bhargavan, K., Delignat-Lavaud, C., Pironti, A., and P.
              Yves Strub, "Triple Handshakes and Cookie Cutters:
              Breaking and Fixing Authentication over TLS", In
              Proceedings of the IEEE Symposium on Security and Privacy,
              Pages 98-113, DOI 10.1109/SP.2014.14, 2014.
Top   ToC   RFC7925 - Page 56

Appendix A. Conveying DTLS over SMS

This section is normative for the use of DTLS over SMS. Timer recommendations are already outlined in Section 11 and also applicable to the transport of DTLS over SMS. This section requires readers to be familiar with the terminology and concepts described in [GSM-SMS] and [WAP-WDP]. The remainder of this section assumes Mobile Stations are capable of producing and consuming Transport Protocol Data Units (TPDUs) encoded as 8-bit binary data.

A.1. Overview

DTLS adds an additional round-trip to the TLS [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 DTLS records using the segmentation and reassembly (SaR) scheme described in Section 4.2.3 of [RFC6347]. The overhead for said scheme is 6 bytes per handshake message which, given a realistic 10+ messages handshake, would amount to around 60 bytes across the whole handshake sequence. Note that the DTLS SaR scheme is defined for handshake messages only. In fact, DTLS records are never fragmented and MUST fit within a single transport layer datagram. SMS provides an optional segmentation and reassembly scheme as well, known as Concatenated short messages (see Section 9.2.3.24.1 of [GSM-SMS]). However, since the SaR scheme in DTLS cannot 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 Path MTU (PMTU) of the SMS transport in order to correctly instrument its SaR function. The PMTU SHALL be 133 bytes if multiplexing based on the Wireless Datagram Protocol (WDP) is used (see Appendix A.3); 140 bytes otherwise. It is RECOMMENDED that the established security context over the longest possible period be used (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.
Top   ToC   RFC7925 - Page 57

A.2. Message Segmentation and Reassembly

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 Appendix A.1, longer (i.e., up to 34170 bytes) messages can be sent using Concatenated SMS. 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. 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 are disadvantages to consider. First, there is an additional overhead of 7 bytes per TPDU to be paid to the SaR function (which is in addition to the overhead introduced by the DTLS SaR mechanism. Second, some networks only partially support the Concatenated SMS function, and others do not support it at all. 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, i.e., 133 bytes if WDP-based multiplexing is enabled; 140 bytes otherwise. Note that, after the DTLS handshake has completed, any fragmentation and reassembly logic 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.

A.3. Multiplexing Security Associations

Unlike IPsec Encapsulating Security Payload (ESP) / Authentication Header (AH), 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. If the DTLS server allows more than one client to be active at any given time, then the Wireless Application Protocol (WAP) User Datagram Protocol [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.)
Top   ToC   RFC7925 - Page 58
   The total overhead cost for encoding the WDP source and destination
   ports is either 5 or 7 bytes out of the total available for the SMS
   content depending on if 1-byte or 2-byte port identifiers are used,
   as shown in Figures 13 and 14.

   0        1        2        3        4
   +--------+--------+--------+--------+--------+
   | ...    | 0x04   | 2      | ...    | ...    |
   +--------+--------+--------+--------+--------+
     UDH      IEI      IE       Dest     Source
     Length            Length   Port     Port

   Legend:
   UDH = user data header
   IEI = information element identifier

       Figure 13: Application Port Addressing Scheme (8-Bit Address)

   0        1        2        3        4        5        6
   +--------+--------+--------+--------+--------+--------+--------+
   | ...    | 0x05   | 4      |       ...       |       ...       |
   +--------+--------+--------+--------+--------+--------+--------+
     UDH      IEI      IE       Dest              Source
     Length            Length   Port              Port

      Figure 14: Application Port Addressing Scheme (16-Bit Address)

   The receiving side of the communication gets the source address from
   the originator address (TP-OA) field of the SMS-DELIVER TPDU.  This
   way, a unique 4-tuple identifying the security association can be
   reconstructed at both ends.  (When replying to its DTLS peer, the
   sender will swap the TP-OA and destination address (TP-DA) parameters
   and the source and destination ports in the WDP.)

A.4. Timeout

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. 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.
Top   ToC   RFC7925 - Page 59

Appendix B. DTLS Record Layer Per-Packet Overhead

Figure 15 shows the overhead for the DTLS record layer for protecting data traffic when AES-128-CCM with an 8-octet Integrity Check Value (ICV) is used. DTLS Record Layer Header................13 bytes Nonce (Explicit).........................8 bytes ICV..................................... 8 bytes ------------------------------------------------ Overhead................................29 bytes ------------------------------------------------ Figure 15: AES-128-CCM-8 DTLS Record Layer Per-Packet Overhead The DTLS record layer header has 13 octets and consists of: o 1-octet content type field, o 2-octet version field, o 2-octet epoch field, o 6-octet sequence number, and o 2-octet length field. The "nonce" input to the AEAD algorithm is exactly that of [RFC5288], i.e., 12 bytes long. It consists of two values, namely a 4-octet salt and an 8-octet nonce_explicit: The salt is the "implicit" part and is not sent in the packet. Instead, the salt is generated as part of the handshake process. The nonce_explicit value is 8 octets long and it is chosen by the sender and carried in each TLS record. RFC 6655 [RFC6655] allows the nonce_explicit to be a sequence number or something else. This document makes this use more restrictive for use with DTLS: the 64-bit none_explicit value MUST be the 16-bit epoch concatenated with the 48-bit seq_num. The sequence number component of the nonce_explicit field at the AES-CCM layer is an exact copy of the sequence number in the record layer header field. This leads to a duplication of 8-bytes per record. To avoid this 8-byte duplication, RFC 7400 [RFC7400] provides help with the use of the generic header compression technique for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs). Note that this header compression technique is not available when DTLS
Top   ToC   RFC7925 - Page 60
      is exchanged over transports that do not use IPv6 or 6LoWPAN, such
      as the SMS transport described in Appendix A of this document.

Appendix C. DTLS Fragmentation

Section 4.2.3 of [RFC6347] advises DTLS implementations to not produce overlapping fragments. However, it requires receivers to be able to cope with them. The need for the latter requisite is explained in Section 4.1.1.1 of [RFC6347]: accurate PMTU estimation may be traded for shorter handshake completion time. In many cases, the cost of handling fragment overlaps has proved to be unaffordable for constrained implementations, particularly because of the increased complexity in buffer management. In order to reduce the likelihood of producing different fragment sizes and consequent overlaps within the same handshake, this document RECOMMENDs: o clients (handshake initiators) to use reliable PMTU information for the intended destination; and o servers to mirror the fragment size selected by their clients. The PMTU information comes from either a "fresh enough" discovery performed by the client [RFC1981] [RFC4821] or some other reliable out-of-band channel.

Acknowledgments

Thanks to Derek Atkins, Paul Bakker, Olaf Bergmann, Carsten Bormann, Ben Campbell, Brian Carpenter, Robert Cragie, Spencer Dawkins, Russ Housley, Rene Hummen, Jayaraghavendran K, Sye Loong Keoh, Matthias Kovatsch, Sandeep Kumar, Barry Leiba, Simon Lemay, Alexey Melnikov, Gabriel Montenegro, Manuel Pegourie-Gonnard, Akbar Rahman, Eric Rescorla, Michael Richardson, Ludwig Seitz, Zach Shelby, Michael StJohns, Rene Struik, Tina Tsou, and Sean Turner for their helpful comments and discussions that have shaped the document. A big thanks also to Klaus Hartke, who wrote the initial draft version of this document. Finally, we would like to thank our area director (Stephen Farrell) and our working group chairs (Zach Shelby and Dorothy Gellert) for their support.
Top   ToC   RFC7925 - Page 61

Authors' Addresses

Hannes Tschofenig (editor) ARM Ltd. 110 Fulbourn Rd Cambridge CB1 9NJ United Kingdom Email: Hannes.tschofenig@gmx.net URI: http://www.tschofenig.priv.at Thomas Fossati Nokia 3 Ely Road Milton, Cambridge CB24 6DD United Kingdom Email: thomas.fossati@nokia.com