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