idnits 2.17.1 draft-dt-tls-external-psk-guidance-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 (6 April 2020) is 1481 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 335 -- Looks like a reference, but probably isn't: '256' on line 328 -- Looks like a reference, but probably isn't: '16' on line 335 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-37 == Outdated reference: A later version (-08) exists of draft-ietf-tls-external-psk-importer-03 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 tls R. Housley 3 Internet-Draft Vigil Security 4 Intended status: Informational J. Hoyland 5 Expires: 8 October 2020 Cloudflare Ltd. 6 M. Sethi 7 Ericsson 8 C.A. Wood 9 6 April 2020 11 Guidance for External PSK Usage in TLS 12 draft-dt-tls-external-psk-guidance-01 14 Abstract 16 This document provides usage guidance for external Pre-Shared Keys 17 (PSKs) in TLS. It lists TLS security properties provided by PSKs 18 under certain assumptions and demonstrates how violations of these 19 assumptions lead to attacks. This document also discusses PSK use 20 cases, provisioning processes, and TLS stack implementation support 21 in the context of these assumptions. It provides advice for 22 applications in various use cases to help meet these assumptions. 24 Note to Readers 26 Source for this draft and an issue tracker can be found at 27 https://github.com/tlswg/external-psk-design-team 28 (https://github.com/tlswg/external-psk-design-team). 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 8 October 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 65 3. PSK Security Properties . . . . . . . . . . . . . . . . . . . 3 66 4. Privacy Properties . . . . . . . . . . . . . . . . . . . . . 4 67 5. External PSK Use Cases and Provisioning Processes . . . . . . 5 68 5.1. Provisioning Examples . . . . . . . . . . . . . . . . . . 6 69 5.2. Provisioning Constraints . . . . . . . . . . . . . . . . 6 70 6. Recommendations for External PSK Usage . . . . . . . . . . . 7 71 6.1. Stack Interfaces . . . . . . . . . . . . . . . . . . . . 7 72 6.1.1. PSK Identity Encoding and Comparison . . . . . . . . 8 73 6.1.2. PSK Identity Collisions . . . . . . . . . . . . . . . 8 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 9.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 This document provides usage guidance for external Pre-Shared Keys 85 (PSKs) in TLS. It lists TLS security properties provided by PSKs 86 under certain assumptions and demonstrates how violations of these 87 assumptions lead to attacks. This document also discusses PSK use 88 cases, provisioning processes, and TLS stack implementation support 89 in the context of these assumptions. It provides advice for 90 applications in various use cases to help meet these assumptions. 92 The guidance provided in this document is applicable across TLS 93 [RFC8446], DTLS [I-D.ietf-tls-dtls13], and Constrained TLS 94 [I-D.rescorla-tls-ctls]. 96 2. Conventions and Definitions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14 [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 3. PSK Security Properties 106 The external PSK authentication mechanism in TLS implicitly assumes 107 one fundamental property: each PSK is known to exactly one client and 108 one server, and that these never switch roles. If this assumption is 109 violated, then the security properties of TLS are severely weakened. 111 As discussed in Section 5, there are use cases where it is desirable 112 for multiple clients or multiple servers to share a PSK. If this is 113 done naively by having all members share a common key, then TLS only 114 authenticates the entire group, and the security of the overall 115 system is inherently rather brittle. There are a number of obvious 116 weaknesses here: 118 1. Any group member can impersonate any other group member. 120 2. If a group member is compromised, then the attacker can 121 impersonate any group member (this follows from property (1)). 123 3. If PSK without DH is used, then compromise of any group member 124 allows the attacker to passively read all traffic. 126 In addition to these, a malicious non-member can reroute handshakes 127 between honest group members to connect them in unintended ways, as 128 detailed below. 130 Let the group of peers who know the key be "A", "B", and "C". The 131 attack proceeds as follows: 133 1. "A" sends a "ClientHello" to "B". 135 2. The attacker intercepts the message and redirects it to "C". 137 3. "C" responds with a "ServerHello" to "A". 139 4. "A" sends a "Finished" message to "B". "A" has completed the 140 handshake, ostensibly with "B". 142 5. The attacker redirects the "Finished" message to "C". "C" has 143 completed the handshake, ostensibly with "A". 145 This attack violates the peer authentication property, and if "C" 146 supports a weaker set of cipher suites than "B", this attack also 147 violates the downgrade protection property. This rerouting is a type 148 of identity misbinding attack [Krawczyk][Sethi]. Selfie attack 149 [Selfie] is a special case of the rerouting attack against a group 150 member that can act both as TLS server and client. In the Selfie 151 attack, a malicious non-member reroutes a connection from the client 152 to the server on the same endpoint. 154 Entropy properties of external PSKs may also affect TLS security 155 properties. In particular, if a high entropy PSK is used, then PSK- 156 only key establishment modes are secure against both active and 157 passive attack. However, they lack forward security. Forward 158 security may be achieved by using a PSK-DH mode. 160 In contrast, if a low entropy PSK is used, then PSK-only key 161 establishment modes are subject to passive exhaustive search passive 162 attacks which will reveal the traffic keys. PSK-DH modes are subject 163 to active attacks in which the attacker impersonates one side. The 164 exhaustive search phase of these attacks can be mounted offline if 165 the attacker captures a single handshake using the PSK, but those 166 attacks will not lead to compromise of the traffic keys for that 167 connection because those also depend on the Diffie-Hellman (DH) 168 exchange. Low entropy keys are only secure against active attack if 169 a PAKE is used with TLS. 171 4. Privacy Properties 173 PSK privacy properties are orthogonal to security properties 174 described in Section 3. Traditionally, TLS does little to keep PSK 175 identity information private. For example, an adversary learns 176 information about the external PSK or its identifier by virtue of it 177 appearing in cleartext in a ClientHello. As a result, a passive 178 adversary can link two or more connections together that use the same 179 external PSK on the wire. Applications should take precautions when 180 using external PSKs to mitigate these risks. 182 In addition to linkability in the network, external PSKs are 183 intrinsically linkable by PSK receivers. Specifically, servers can 184 link successive connections that use the same external PSK together. 185 Preventing this type of linkability is out of scope, as PSKs are 186 explicitly designed to support mutual authentication. 188 5. External PSK Use Cases and Provisioning Processes 190 Pre-shared Key (PSK) ciphersuites were first specified for TLS in 191 2005. Now, PSK is an integral part of the TLS version 1.3 192 specification [RFC8446]. TLS 1.3 also uses PSKs for session 193 resumption. It distinguishes these resumption PSKs from external 194 PSKs which have been provisioned out-of-band (OOB). Below, we list 195 some example use-cases where pair-wise external PSKs with TLS have 196 been used for authentication. 198 * Device-to-device communication with out-of-band synchronized keys. 199 PSKs provisioned out-of-band for communicating with known 200 identities, wherein the identity to use is discovered via a 201 different online protocol. 203 * Intra-data-center communication. Machine-to-machine communication 204 within a single data center or PoP may use externally provisioned 205 PSKs, primarily for the purposes of supporting TLS connections 206 with fast open (0-RTT data). 208 * Certificateless server-to-server communication. Machine-to- 209 machine communication may use externally provisioned PSKs, 210 primarily for the purposes of establishing TLS connections without 211 requiring the overhead of provisioning and managing PKI 212 certificates. 214 * Internet of Things (IoT) and devices with limited computational 215 capabilities. [RFC7925] defines TLS and DTLS profiles for 216 resource-constrained devices and suggests the use of PSK 217 ciphersuites for compliant devices. The Open Mobile Alliance 218 Lightweight Machine to Machine Technical Specification [LwM2M] 219 states that LwM2M servers MUST support the PSK mode of DTLS. 221 * Use of PSK ciphersuites are optional when securing RADIUS 222 [RFC2865] with TLS as specified in [RFC6614]. 224 * The Generic Authentication Architecture (GAA) defined by 3GGP 225 mentions that TLS-PSK can be used between a server and user 226 equipment for authentication [GAA]. 228 * Smart Cards. The electronic German ID (eID) card supports 229 authentication of a card holder to online services with TLS-PSK 230 [SmartCard]. 232 There are also use cases where PSKs are shared between more than two 233 entities. Some examples below (as noted by Akhmetzyanova et 234 al.[Akhmetzyanova]): 236 * Group chats. In this use-case, the membership of a group is 237 confirmed by the possession of a PSK distributed out-of-band to 238 the group participants. Members can then establish peer-to-peer 239 connections with each other using the external PSK. It is 240 important to note that any node of the group can behave as a TLS 241 client or server. 243 * Internet of Things (IoT). In this use-case, resource-constrained 244 IoT devices act as TLS clients and share the same PSK. The 245 devices use this PSK for quickly establishing connections with a 246 central server. Such a scheme ensures that the client IoT devices 247 are legitimate members of the system. To perform rare system 248 specific operations that require a higher security level, the 249 central server can request resource-intensive client 250 authentication with the usage of a certificate after successfully 251 establishing the connection with a PSK. 253 5.1. Provisioning Examples 255 * Many industrial protocols assume that PSKs are distributed and 256 assigned manually via one of the following approaches: typing the 257 PSK into the devices, or via web server masks (using a Trust On 258 First Use (TOFU) approach with a device completely unprotected 259 before the first login did take place). Many devices have very 260 limited UI. For example, they may only have a numeric keypad or 261 even less number of buttons. When the TOFU approach is not 262 suitable, entering the key would require typing it on a 263 constrained UI. Moreover, PSK production lacks guidance unlike 264 user passwords. 266 * Some devices provision PSKs via an out-of-band, cloud-based 267 syncing protocol. 269 * Some secrets may be baked into or hardware or software device 270 components. Moreover, when this is done at manufacturing time, 271 secrets may be printed on labels or included in a Bill of 272 Materials for ease of scanning or import. 274 5.2. Provisioning Constraints 276 PSK provisioning systems are often constrained in application- 277 specific ways. For example, although one goal of provisioning is to 278 ensure that each pair of nodes has a unique key pair, some systems do 279 not want to distribute pair-wise shared keys to achieve this. As 280 another example, some systems require the provisioning process to 281 embed application-specific information in either PSKs or their 282 identities. Identities may sometimes need to be routable, as is 283 currently under discussion for EAP-TLS-PSK. 285 6. Recommendations for External PSK Usage 287 Applications MUST use external PSKs that adhere to the following 288 requirements: 290 1. Each PSK SHOULD be derived from at least 128 bits of entropy, 291 MUST be at least 128 bits long, and SHOULD be combined with a DH 292 exchange for forward secrecy. As discussed in Section 3, low 293 entropy PSKs, i.e., those derived from less than 128 bits of 294 entropy, are subject to attack and SHOULD be avoided. Low 295 entropy keys are only secure against active attack if a Password 296 Authenticated Key Exchange (PAKE) is used with TLS. 298 2. Each PSK MUST NOT be shared between with more than two logical 299 nodes. As a result, an agent that acts as both a client and a 300 server MUST use distinct PSKs when acting as the client from when 301 it is acting as the server. 303 3. Nodes SHOULD use external PSK importers 304 [I-D.ietf-tls-external-psk-importer] when configuring PSKs for a 305 pair of TLS client and server. 307 4. Where possible the master PSK (that which is fed into the 308 importer) SHOULD be deleted after the imported keys have been 309 generated. This protects an attacker from bootstrapping a 310 compromise of one node into the ability to attack connections 311 between any node; otherwise the attacker can recover the master 312 key and then re-run the importer itself. 314 6.1. Stack Interfaces 316 Most major TLS implementations support external PSKs. Stacks 317 supporting external PSKs provide interfaces that applications may use 318 when supplying them for individual connections. Details about 319 existing stacks at the time of writing are below. 321 * OpenSSL and BoringSSL: Applications specify support for external 322 PSKs via distinct ciphersuites. They also then configure 323 callbacks that are invoked for PSK selection during the handshake. 324 These callbacks must provide a PSK identity and key. The exact 325 format of the callback depends on the negotiated TLS protocol 326 version with new callback functions added specifically to OpenSSL 327 for TLS 1.3 [RFC8446] PSK support. The PSK length is validated to 328 be between [1, 256] bytes. The PSK identity may be up to 128 329 bytes long. 331 * mbedTLS: Client applications configure PSKs before creating a 332 connection by providing the PSK identity and value inline. 334 Servers must implement callbacks similar to that of OpenSSL. Both 335 PSK identity and key lengths may be between [1, 16] bytes long. 337 * gnuTLS: Applications configure PSK values, either as raw byte 338 strings or hexadecimal strings. The PSK identity and key size are 339 not validated. 341 * wolfSSL: Applications configure PSKs with callbacks similar to 342 OpenSSL. 344 6.1.1. PSK Identity Encoding and Comparison 346 Section 5.1 of [RFC4279] mandates that the PSK identity should be 347 first converted to a character string and then encoded to octets 348 using UTF-8. This was done to avoid interoperability problems 349 (especially when the identity is configured by human users). On the 350 other hand, [RFC7925] advises implementations against assuming any 351 structured format for PSK identities and recommends byte-by-byte 352 comparison for any operation. TLS version 1.3 [RFC8446] follows the 353 same practice of specifying the PSK identity as a sequence of opaque 354 bytes (shown as opaque identity<1..2^16-1> in the specification). 355 [RFC8446] also requires that the PSK identities are at least 1 byte 356 and at the most 65535 bytes in length. Although [RFC8446] does not 357 place strict requirements on the format of PSK identities, we do 358 however note that the format of PSK identities can vary depending on 359 the deployment: 361 * The PSK identity MAY be a user configured string when used in 362 protocols like Extensible Authentication Protocol (EAP) [RFC3748]. 363 gnuTLS for example treats PSK identities as usernames. 365 * PSK identities MAY have a domain name suffix for roaming and 366 federation. 368 * Deployments should take care that the length of the PSK identity 369 is sufficient to avoid obvious collisions. 371 6.1.2. PSK Identity Collisions 373 It is possible, though unlikely, that an external PSK identity may 374 clash with a resumption PSK identity. The TLS stack implementation 375 and sequencing of PSK callbacks influences the application's 376 behaviour when identity collisions occur. When a server receives a 377 PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the 378 application's registered callback function before checking the 379 stack's internal session resumption cache. This means that if a PSK 380 identity collision occurs, the application will be given precedence 381 over how to handle the PSK. 383 7. Security Considerations 385 It is NOT RECOMMENDED to share the same PSK between more than one 386 client and server. However, as discussed in Section 5, there are 387 application scenarios that may rely on sharing the same PSK among 388 multiple nodes. [I-D.ietf-tls-external-psk-importer] helps in 389 mitigating rerouting and Selfie style reflection attacks when the PSK 390 is shared among multiple nodes. This is achieved by correctly using 391 the node identifiers in the ImportedIdentity.context construct 392 specified in [I-D.ietf-tls-external-psk-importer]. It is RECOMMENDED 393 that each endpoint selects one globally unique identifier and uses it 394 in all PSK handshakes. The unique identifier can, for example, be 395 one of its MAC addresses, a 32-byte random number, or its Universally 396 Unique IDentifier (UUID) [RFC4122]. Each endpoint SHOULD know the 397 identifier of the other endpoint with which its wants to connect and 398 SHOULD compare it with the other endpoint's identifier used in 399 ImportedIdentity.context. It is however important to remember that 400 endpoints sharing the same group PSK can always impersonate each 401 other. 403 8. IANA Considerations 405 This document makes no IANA requests. 407 9. References 409 9.1. Normative References 411 [I-D.ietf-tls-dtls13] 412 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 413 Datagram Transport Layer Security (DTLS) Protocol Version 414 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 415 dtls13-37, 9 March 2020, . 418 [I-D.ietf-tls-external-psk-importer] 419 Benjamin, D. and C. Wood, "Importing External PSKs for 420 TLS", Work in Progress, Internet-Draft, draft-ietf-tls- 421 external-psk-importer-03, 15 February 2020, 422 . 425 [I-D.rescorla-tls-ctls] 426 Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS 427 1.3", Work in Progress, Internet-Draft, draft-rescorla- 428 tls-ctls-04, 9 March 2020, . 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, 433 DOI 10.17487/RFC2119, March 1997, 434 . 436 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 437 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 438 May 2017, . 440 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 441 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 442 . 444 9.2. Informative References 446 [Akhmetzyanova] 447 Akhmetzyanova, L., Alekseev, E., Smyshlyaeva, E., and A. 448 Sokolov, "Continuing to reflect on TLS 1.3 with external 449 PSK", 2019, . 451 [GAA] "TR33.919 version 12.0.0 Release 12", n.d., 452 . 456 [Krawczyk] Krawczyk, H., "SIGMA: The 'SIGn-and-MAc' Approach to 457 Authenticated Diffie-Hellman and Its Use in the IKE 458 Protocols", Annual International Cryptology Conference. 459 Springer, Berlin, Heidelberg , 2003, 460 . 463 [LwM2M] "Lightweight Machine to Machine Technical Specification", 464 n.d., 465 . 469 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 470 "Remote Authentication Dial In User Service (RADIUS)", 471 RFC 2865, DOI 10.17487/RFC2865, June 2000, 472 . 474 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 475 Levkowetz, Ed., "Extensible Authentication Protocol 476 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 477 . 479 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 480 Unique IDentifier (UUID) URN Namespace", RFC 4122, 481 DOI 10.17487/RFC4122, July 2005, 482 . 484 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 485 Ciphersuites for Transport Layer Security (TLS)", 486 RFC 4279, DOI 10.17487/RFC4279, December 2005, 487 . 489 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 490 "Transport Layer Security (TLS) Encryption for RADIUS", 491 RFC 6614, DOI 10.17487/RFC6614, May 2012, 492 . 494 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 495 Security (TLS) / Datagram Transport Layer Security (DTLS) 496 Profiles for the Internet of Things", RFC 7925, 497 DOI 10.17487/RFC7925, July 2016, 498 . 500 [Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3 501 with PSK", 2019, . 503 [Sethi] Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks 504 on Secure Device Pairing and Bootstrapping", Proceedings 505 of the 2019 ACM Asia Conference on Computer and 506 Communications Security , 2019, 507 . 509 [SmartCard] 510 "Technical Guideline TR-03112-7 eCard-API-Framework - 511 Protocols", 2015, . 515 Appendix A. Acknowledgements 517 This document is the output of the TLS External PSK Design Team, 518 comprised of the following members: Benjamin Beurdouche, Bjoern 519 Haase, Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan 520 Hoyland, Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen 521 Friel, and Russ Housley. 523 Authors' Addresses 525 Russ Housley 526 Vigil Security 528 Email: housley@vigilsec.com 530 Jonathan Hoyland 531 Cloudflare Ltd. 533 Email: jonathan.hoyland@gmail.com 535 Mohit Sethi 536 Ericsson 538 Email: mohit@piuha.net 540 Christopher A. Wood 542 Email: caw@heapingbits.net