idnits 2.17.00 (12 Aug 2021) /tmp/idnits26374/draft-ietf-tls-external-psk-guidance-04.txt: -(670): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. 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 (9 December 2021) is 163 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 408 -- Looks like a reference, but probably isn't: '256' on line 402 -- Looks like a reference, but probably isn't: '16' on line 408 == Outdated reference: A later version (-08) exists of draft-ietf-tls-external-psk-importer-06 == Outdated reference: A later version (-05) exists of draft-ietf-tls-ctls-04 == Outdated reference: draft-ietf-tls-dtls13 has been published as RFC 9147 == Outdated reference: A later version (-05) exists of draft-irtf-cfrg-cpace-03 == Outdated reference: A later version (-08) exists of draft-irtf-cfrg-opaque-07 Summary: 0 errors (**), 0 flaws (~~), 7 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: 12 June 2022 Cloudflare Ltd. 6 M. Sethi 7 Ericsson 8 C.A. Wood 9 Cloudflare 10 9 December 2021 12 Guidance for External PSK Usage in TLS 13 draft-ietf-tls-external-psk-guidance-04 15 Abstract 17 This document provides usage guidance for external Pre-Shared Keys 18 (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. 19 This document lists TLS security properties provided by PSKs under 20 certain assumptions, and then demonstrates how violations of these 21 assumptions lead to attacks. This document discusses PSK use cases 22 and provisioning processes. This document provides advice for 23 applications to help meet these assumptions. This document also 24 lists the privacy and security properties that are not provided by 25 TLS 1.3 when external PSKs are used. 27 Discussion Venues 29 This note is to be removed before publishing as an RFC. 31 Source for this draft and an issue tracker can be found at 32 https://github.com/tlswg/external-psk-design-team. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at https://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 12 June 2022. 50 Copyright Notice 52 Copyright (c) 2021 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 Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 68 3. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 4. PSK Security Properties . . . . . . . . . . . . . . . . . . . 4 70 4.1. Shared PSKs . . . . . . . . . . . . . . . . . . . . . . . 4 71 4.2. PSK Entropy . . . . . . . . . . . . . . . . . . . . . . . 5 72 5. External PSKs in Practice . . . . . . . . . . . . . . . . . . 6 73 5.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 6 74 5.2. Provisioning Examples . . . . . . . . . . . . . . . . . . 7 75 5.3. Provisioning Constraints . . . . . . . . . . . . . . . . 8 76 6. Recommendations for External PSK Usage . . . . . . . . . . . 8 77 6.1. Stack Interfaces . . . . . . . . . . . . . . . . . . . . 9 78 6.1.1. PSK Identity Encoding and Comparison . . . . . . . . 10 79 6.1.2. PSK Identity Collisions . . . . . . . . . . . . . . . 11 80 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 85 10.2. Informative References . . . . . . . . . . . . . . . . . 13 86 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 This document provides guidance on the use of external Pre-Shared 92 Keys (PSKs) in Transport Layer Security (TLS) 1.3 [RFC8446]. This 93 guidance also applies to Datagram TLS (DTLS) 1.3 94 [I-D.ietf-tls-dtls13] and Compact TLS 1.3 [I-D.ietf-tls-ctls]. For 95 readability, this document uses the term TLS to refer to all such 96 versions. 98 External PSKs are symmetric secret keys provided to the TLS protocol 99 implementation as external inputs. External PSKs are provisioned 100 out-of-band. 102 This document lists TLS security properties provided by PSKs under 103 certain assumptions and demonstrates how violations of these 104 assumptions lead to attacks. This document discusses PSK use cases, 105 provisioning processes, and TLS stack implementation support in the 106 context of these assumptions. This document also provides advice for 107 applications in various use cases to help meet these assumptions. 109 There are many resources that provide guidance for password 110 generation and verification aimed towards improving security. 111 However, there is no such equivalent for external Pre-Shared Keys 112 (PSKs) in TLS. This document aims to reduce that gap. 114 2. Conventions and Definitions 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in 119 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 3. Notation 124 For purposes of this document, a "logical node" is a computing 125 presence that other parties can interact with via the TLS protocol. 126 A logical node could potentially be realized with multiple physical 127 instances operating under common administrative control, e.g., a 128 server farm. An "endpoint" is a client or server participating in a 129 connection. 131 4. PSK Security Properties 133 The use of a previously established PSK allows TLS nodes to 134 authenticate the endpoint identities. It also offers other benefits, 135 including resistance to attacks in presence of quantum computes; see 136 Section 4.2 for related discussion. However, these keys do not 137 provide privacy protection of endpoint identities, nor do they 138 provide non-repudiation (one endpoint in a connection can deny the 139 conversation); see Section 7 for related discussion. 141 PSK authentication security implicitly assumes one fundamental 142 property: each PSK is known to exactly one client and one server, and 143 that these never switch roles. If this assumption is violated, then 144 the security properties of TLS are severely weakened as discussed 145 below. 147 4.1. Shared PSKs 149 As discussed in Section 5.1, to demonstrate their attack, [AASS19] 150 describes scenarios where multiple clients or multiple servers share 151 a PSK. If this is done naively by having all members share a common 152 key, then TLS authenticates only group membership, and the security 153 of the overall system is inherently rather brittle. There are a 154 number of obvious weaknesses here: 156 1. Any group member can impersonate any other group member. 158 2. If PSK is combined with a fresh ephemeral key exchange, then 159 compromise of a group member that knows the resulting shared 160 secret will enable the attacker to passively read (and actively 161 modify) traffic. 163 3. If PSK is not combined with fresh ephemeral key exchange, then 164 compromise of any group member allows the attacker to passively 165 read (and actively modify) all traffic. 167 Additionally, a malicious non-member can reroute handshakes between 168 honest group members to connect them in unintended ways, as described 169 below. Note that a partial mitigiation against this class of attack 170 is available: each group member includes the SNI extension [RFC6066] 171 and terminates the connection on mismatch between the presented SNI 172 value and the receiving member's known identity. See [Selfie] for 173 details. 175 To illustrate the rerouting attack, consider the group of peers who 176 know the PSK be A, B, and C. The attack proceeds as follows: 178 1. A sends a ClientHello to B. 180 2. The attacker intercepts the message and redirects it to C. 182 3. C responds with a second flight (ServerHello, ...) to A. 184 4. A sends a Finished message to B. A has completed the handshake, 185 ostensibly with B. 187 5. The attacker redirects the Finished message to C. C has 188 completed the handshake with A. 190 In this attack, peer authentication is not provided. Also, if C 191 supports a weaker set of cipher suites than B, cryptographic 192 algorithm downgrade attacks might be possible. This rerouting is a 193 type of identity misbinding attack [Krawczyk][Sethi]. Selfie attack 194 [Selfie] is a special case of the rerouting attack against a group 195 member that can act both as TLS server and client. In the Selfie 196 attack, a malicious non-member reroutes a connection from the client 197 to the server on the same endpoint. 199 Finally, in addition to these weaknesses, sharing a PSK across nodes 200 may negatively affect deployments. For example, revocation of 201 individual group members is not possible without establishing a new 202 PSK for all of the non-revoked members. 204 4.2. PSK Entropy 206 Entropy properties of external PSKs may also affect TLS security 207 properties. For example, if a high entropy PSK is used, then PSK- 208 only key establishment modes provide expected security properties for 209 TLS, including, for example, including establishing the same session 210 keys between peers, secrecy of session keys, peer authentication, and 211 downgrade protection. See [RFC8446], Appendix E.1 for an explanation 212 of these properties. However, these modes lack forward security. 213 Forward security may be achieved by using a PSK-DH mode, or, 214 alternatively, by using PSKs with short lifetimes. 216 In contrast, if a low entropy PSK is used, then PSK-only key 217 establishment modes are subject to passive exhaustive search attacks 218 which will reveal the traffic keys. PSK-DH modes are subject to 219 active attacks in which the attacker impersonates one side. The 220 exhaustive search phase of these attacks can be mounted offline if 221 the attacker captures a single handshake using the PSK, but those 222 attacks will not lead to compromise of the traffic keys for that 223 connection because those also depend on the Diffie-Hellman (DH) 224 exchange. Low entropy keys are only secure against active attack if 225 a password-authenticated key exchange (PAKE) is used with TLS. The 226 Crypto Forum Research Group (CFRG) is currently working on specifying 227 recommended PAKEs (see [I-D.irtf-cfrg-cpace] and 228 [I-D.irtf-cfrg-opaque], for the symmetric and asymmetric cases, 229 respectively). 231 5. External PSKs in Practice 233 PSK ciphersuites were first specified for TLS in 2005. PSKs are now 234 an integral part of the TLS version 1.3 specification [RFC8446]. TLS 235 1.3 also uses PSKs for session resumption. It distinguishes these 236 resumption PSKs from external PSKs which have been provisioned out- 237 of-band. This section describes known use cases and provisioning 238 processes for external PSKs with TLS. 240 5.1. Use Cases 242 This section lists some example use-cases where pair-wise external 243 PSKs, i.e., external PSKs that are shared between only one server and 244 one client, have been used for authentication in TLS. 246 * Device-to-device communication with out-of-band synchronized keys. 247 PSKs provisioned out-of-band for communicating with known 248 identities, wherein the identity to use is discovered via a 249 different online protocol. 251 * Intra-data-center communication. Machine-to-machine communication 252 within a single data center or PoP may use externally provisioned 253 PSKs, primarily for the purposes of supporting TLS connections 254 with early data; see Section 8 for considerations when using early 255 data with external PSKs. 257 * Certificateless server-to-server communication. Machine-to- 258 machine communication may use externally provisioned PSKs, 259 primarily for the purposes of establishing TLS connections without 260 requiring the overhead of provisioning and managing PKI 261 certificates. 263 * Internet of Things (IoT) and devices with limited computational 264 capabilities. [RFC7925] defines TLS and DTLS profiles for 265 resource-constrained devices and suggests the use of PSK 266 ciphersuites for compliant devices. The Open Mobile Alliance 267 Lightweight Machine to Machine Technical Specification [LwM2M] 268 states that LwM2M servers MUST support the PSK mode of DTLS. 270 * Securing RADIUS [RFC2865] with TLS. PSK ciphersuites are optional 271 for this use case, as specified in [RFC6614]. 273 * 3GPP server to user equipment authentication. The Generic 274 Authentication Architecture (GAA) defined by 3GGP mentions that 275 TLS-PSK ciphersuites can be used between server and user equipment 276 for authentication [GAA]. 278 * Smart Cards. The electronic German ID (eID) card supports 279 authentication of a card holder to online services with TLS-PSK 280 [SmartCard]. 282 * Quantum resistance. Some deployments may use PSKs (or combine 283 them with certificate-based authentication as described in 284 [RFC8773]) because of the protection they provide against quantum 285 computers. 287 There are also use cases where PSKs are shared between more than two 288 entities. Some examples below (as noted by Akhmetzyanova et al. 289 [AASS19]): 291 * Group chats. In this use-case, group participants may be 292 provisioned an external PSK out-of-band for establishing 293 authenticated connections with other members of the group. 295 * Internet of Things (IoT) and devices with limited computational 296 capabilities. Many PSK provisioning examples are possible in this 297 use-case. For example, in a given setting, IoT devices may all 298 share the same PSK and use it to communicate with a central server 299 (one key for n devices), have their own key for communicating with 300 a central server (n keys for n devices), or have pairwise keys for 301 communicating with each other (n^2 keys for n devices). 303 5.2. Provisioning Examples 305 The exact provisioning process depends on the system requirements and 306 threat model. Whenever possible, avoid sharing a PSK between nodes; 307 however, sharing a PSK among several node is sometimes unavoidable. 308 When PSK sharing happens, other accommodations SHOULD be used as 309 discussed in Section 6. 311 Examples of PSK provisioning processes are included below. 313 * Many industrial protocols assume that PSKs are distributed and 314 assigned manually via one of the following approaches: typing the 315 PSK into the devices, or using a Trust On First Use (TOFU) 316 approach with a device completely unprotected before the first 317 login did take place. Many devices have very limited UI. For 318 example, they may only have a numeric keypad or even less number 319 of buttons. When the TOFU approach is not suitable, entering the 320 key would require typing it on a constrained UI. 322 * Some devices provision PSKs via an out-of-band, cloud-based 323 syncing protocol. 325 * Some secrets may be baked into or hardware or software device 326 components. Moreover, when this is done at manufacturing time, 327 secrets may be printed on labels or included in a Bill of 328 Materials for ease of scanning or import. 330 5.3. Provisioning Constraints 332 PSK provisioning systems are often constrained in application- 333 specific ways. For example, although one goal of provisioning is to 334 ensure that each pair of nodes has a unique key pair, some systems do 335 not want to distribute pair-wise shared keys to achieve this. As 336 another example, some systems require the provisioning process to 337 embed application-specific information in either PSKs or their 338 identities. Identities may sometimes need to be routable, as is 339 currently under discussion for EAP-TLS-PSK 340 [I-D.mattsson-emu-eap-tls-psk]. 342 6. Recommendations for External PSK Usage 344 Recommended requirements for applications using external PSKs are as 345 follows: 347 1. Each PSK SHOULD be derived from at least 128 bits of entropy, 348 MUST be at least 128 bits long, and SHOULD be combined with an 349 ephemeral key exchange exchange, e.g., by using the "psk_dhe_ke" 350 Pre-Shared Key Exchange Mode in TLS 1.3, for forward secrecy. As 351 discussed in Section 4, low entropy PSKs, i.e., those derived 352 from less than 128 bits of entropy, are subject to attack and 353 SHOULD be avoided. If only low-entropy keys are available, then 354 key establishment mechanisms such as Password Authenticated Key 355 Exchange (PAKE) that mitigate the risk of offline dictionary 356 attacks SHOULD be employed. Note that no such mechanisms have 357 yet been standardised, and further that these mechanisms will not 358 necessarily follow the same architecture as the process for 359 incorporating external PSKs described in 360 [I-D.ietf-tls-external-psk-importer]. 362 2. Unless other accommodations are made to mitigate the risks of 363 PSKs known to a group, each PSK MUST be restricted in its use to 364 at most two logical nodes: one logical node in a TLS client role 365 and one logical node in a TLS server role. (The two logical 366 nodes MAY be the same, in different roles.) Two acceptable 367 accommodations are described in 368 [I-D.ietf-tls-external-psk-importer]: (1) exchanging client and 369 server identifiers over the TLS connection after the handshake, 370 and (2) incorporating identifiers for both the client and the 371 server into the context string for an external PSK importer. 373 3. Nodes SHOULD use external PSK importers 374 [I-D.ietf-tls-external-psk-importer] when configuring PSKs for a 375 client-server pair when applicable. Importers make provisioning 376 external PSKs easier and less error prone by deriving a unique, 377 imported PSK from the external PSK for each key derivation 378 function a node supports. See the Security Considerations in 379 [I-D.ietf-tls-external-psk-importer] for more information. 381 4. Where possible the main PSK (that which is fed into the importer) 382 SHOULD be deleted after the imported keys have been generated. 383 This prevents an attacker from bootstrapping a compromise of one 384 node into the ability to attack connections between any node; 385 otherwise the attacker can recover the main key and then re-run 386 the importer itself. 388 6.1. Stack Interfaces 390 Most major TLS implementations support external PSKs. Stacks 391 supporting external PSKs provide interfaces that applications may use 392 when configuring PSKs for individual connections. Details about some 393 existing stacks at the time of writing are below. 395 * OpenSSL and BoringSSL: Applications can specify support for 396 external PSKs via distinct ciphersuites in TLS 1.2 and below. 397 They also then configure callbacks that are invoked for PSK 398 selection during the handshake. These callbacks must provide a 399 PSK identity and key. The exact format of the callback depends on 400 the negotiated TLS protocol version, with new callback functions 401 added specifically to OpenSSL for TLS 1.3 [RFC8446] PSK support. 402 The PSK length is validated to be between [1, 256] bytes. The PSK 403 identity may be up to 128 bytes long. 405 * mbedTLS: Client applications configure PSKs before creating a 406 connection by providing the PSK identity and value inline. 407 Servers must implement callbacks similar to that of OpenSSL. Both 408 PSK identity and key lengths may be between [1, 16] bytes long. 410 * gnuTLS: Applications configure PSK values, either as raw byte 411 strings or hexadecimal strings. The PSK identity and key size are 412 not validated. 414 * wolfSSL: Applications configure PSKs with callbacks similar to 415 OpenSSL. 417 6.1.1. PSK Identity Encoding and Comparison 419 Section 5.1 of [RFC4279] mandates that the PSK identity should be 420 first converted to a character string and then encoded to octets 421 using UTF-8. This was done to avoid interoperability problems 422 (especially when the identity is configured by human users). On the 423 other hand, [RFC7925] advises implementations against assuming any 424 structured format for PSK identities and recommends byte-by-byte 425 comparison for any operation. When PSK identities are configured 426 manually it is important to be aware that due to encoding issues 427 visually identical strings may, in fact, differ. 429 TLS version 1.3 [RFC8446] follows the same practice of specifying the 430 PSK identity as a sequence of opaque bytes (shown as opaque 431 identity<1..2^16-1> in the specification) that thus is compared on a 432 byte-by-byte basis. [RFC8446] also requires that the PSK identities 433 are at least 1 byte and at the most 65535 bytes in length. Although 434 [RFC8446] does not place strict requirements on the format of PSK 435 identities, we do however note that the format of PSK identities can 436 vary depending on the deployment: 438 * The PSK identity MAY be a user configured string when used in 439 protocols like Extensible Authentication Protocol (EAP) [RFC3748]. 440 gnuTLS for example treats PSK identities as usernames. 442 * PSK identities MAY have a domain name suffix for roaming and 443 federation. In applications and settings where the domain name 444 suffix is privacy sensitive, this practice is NOT RECOMMENDED. 446 * Deployments should take care that the length of the PSK identity 447 is sufficient to avoid collisions. 449 6.1.2. PSK Identity Collisions 451 It is possible, though unlikely, that an external PSK identity may 452 clash with a resumption PSK identity. The TLS stack implementation 453 and sequencing of PSK callbacks influences the application's behavior 454 when identity collisions occur. When a server receives a PSK 455 identity in a TLS 1.3 ClientHello, some TLS stacks execute the 456 application's registered callback function before checking the 457 stack's internal session resumption cache. This means that if a PSK 458 identity collision occurs, the application's external PSK usage will 459 typically take precedence over the internal session resumption path. 461 Since resumption PSK identities are assigned by the TLS stack 462 implementation, it is RECOMMENDED that these identifiers be assigned 463 in a manner that lets resumption PSKs be distinguished from external 464 PSKs to avoid concerns with collisions altogether. 466 7. Privacy Considerations 468 PSK privacy properties are orthogonal to security properties 469 described in Section 4. TLS does little to keep PSK identity 470 information private. For example, an adversary learns information 471 about the external PSK or its identifier by virtue of it appearing in 472 cleartext in a ClientHello. As a result, a passive adversary can 473 link two or more connections together that use the same external PSK 474 on the wire. Depending on the PSK identity, a passive attacker may 475 also be able to identify the device, person, or enterprise running 476 the TLS client or TLS server. An active attacker can also use the 477 PSK identity to suppress handshakes or application data from a 478 specific device by blocking, delaying, or rate-limiting traffic. 479 Techniques for mitigating these risks require further analysis and 480 are out of scope for this document. 482 In addition to linkability in the network, external PSKs are 483 intrinsically linkable by PSK receivers. Specifically, servers can 484 link successive connections that use the same external PSK together. 485 Preventing this type of linkability is out of scope. 487 8. Security Considerations 489 Security considerations are provided throughout this document. It 490 bears repeating that there are concerns related to the use of 491 external PSKs regarding proper identification of TLS 1.3 endpoints 492 and additional risks when external PSKs are known to a group. 494 It is NOT RECOMMENDED to share the same PSK between more than one 495 client and server. However, as discussed in Section 5.1, there are 496 application scenarios that may rely on sharing the same PSK among 497 multiple nodes. [I-D.ietf-tls-external-psk-importer] helps in 498 mitigating rerouting and Selfie style reflection attacks when the PSK 499 is shared among multiple nodes. This is achieved by correctly using 500 the node identifiers in the ImportedIdentity.context construct 501 specified in [I-D.ietf-tls-external-psk-importer]. One solution 502 would be for each endpoint to select one globally unique identifier 503 and use it in all PSK handshakes. The unique identifier can, for 504 example, be one of its MAC addresses, a 32-byte random number, or its 505 Universally Unique IDentifier (UUID) [RFC4122]. Note that such 506 persistent, global identifiers have privacy implications; see 507 Section 7. 509 Each endpoint SHOULD know the identifier of the other endpoint with 510 which its wants to connect and SHOULD compare it with the other 511 endpoint's identifier used in ImportedIdentity.context. It is 512 however important to remember that endpoints sharing the same group 513 PSK can always impersonate each other. 515 Considerations for external PSK usage extend beynond proper 516 identification. When early data is used with an external PSK, the 517 random value in the ClientHello is the only source of entropy that 518 contributes to key diversity between sessions. As a result, when an 519 external PSK is used more than one time, the random number source on 520 the client has a significant role in the protection of the early 521 data. 523 9. IANA Considerations 525 This document makes no IANA requests. 527 10. References 529 10.1. Normative References 531 [I-D.ietf-tls-external-psk-importer] 532 Benjamin, D. and C. A. Wood, "Importing External PSKs for 533 TLS", Work in Progress, Internet-Draft, draft-ietf-tls- 534 external-psk-importer-06, 3 December 2020, 535 . 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, 540 DOI 10.17487/RFC2119, March 1997, 541 . 543 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 544 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 545 May 2017, . 547 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 548 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 549 . 551 10.2. Informative References 553 [AASS19] Akhmetzyanova, L., Alekseev, E., Smyshlyaeva, E., and A. 554 Sokolov, "Continuing to reflect on TLS 1.3 with external 555 PSK", 2019, . 557 [GAA] "TR33.919 version 12.0.0 Release 12", n.d., 558 . 562 [I-D.ietf-tls-ctls] 563 Rescorla, E., Barnes, R., and H. Tschofenig, "Compact TLS 564 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 565 ctls-04, 25 October 2021, 566 . 569 [I-D.ietf-tls-dtls13] 570 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 571 Datagram Transport Layer Security (DTLS) Protocol Version 572 1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 573 dtls13-43, 30 April 2021, 574 . 577 [I-D.irtf-cfrg-cpace] 578 Abdalla, M., Haase, B., and J. Hesse, "CPace, a balanced 579 composable PAKE", Work in Progress, Internet-Draft, draft- 580 irtf-cfrg-cpace-03, 15 November 2021, 581 . 584 [I-D.irtf-cfrg-opaque] 585 Bourdrez, D., Krawczyk, H., Lewi, K., and C. A. Wood, "The 586 OPAQUE Asymmetric PAKE Protocol", Work in Progress, 587 Internet-Draft, draft-irtf-cfrg-opaque-07, 25 October 588 2021, . 591 [I-D.mattsson-emu-eap-tls-psk] 592 Mattsson, J. P., Sethi, M., Aura, T., and O. Friel, "EAP- 593 TLS with PSK Authentication (EAP-TLS-PSK)", Work in 594 Progress, Internet-Draft, draft-mattsson-emu-eap-tls-psk- 595 00, 9 March 2020, . 598 [Krawczyk] Krawczyk, H., "SIGMA: The ‘SIGn-and-MAc’ Approach to 599 Authenticated Diffie-Hellman and Its Use in the IKE 600 Protocols", Annual International Cryptology Conference. 601 Springer, Berlin, Heidelberg , 2003, 602 . 605 [LwM2M] "Lightweight Machine to Machine Technical Specification", 606 n.d., 607 . 611 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 612 "Remote Authentication Dial In User Service (RADIUS)", 613 RFC 2865, DOI 10.17487/RFC2865, June 2000, 614 . 616 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 617 Levkowetz, Ed., "Extensible Authentication Protocol 618 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 619 . 621 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 622 Unique IDentifier (UUID) URN Namespace", RFC 4122, 623 DOI 10.17487/RFC4122, July 2005, 624 . 626 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 627 Ciphersuites for Transport Layer Security (TLS)", 628 RFC 4279, DOI 10.17487/RFC4279, December 2005, 629 . 631 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 632 Extensions: Extension Definitions", RFC 6066, 633 DOI 10.17487/RFC6066, January 2011, 634 . 636 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 637 "Transport Layer Security (TLS) Encryption for RADIUS", 638 RFC 6614, DOI 10.17487/RFC6614, May 2012, 639 . 641 [RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer 642 Security (TLS) / Datagram Transport Layer Security (DTLS) 643 Profiles for the Internet of Things", RFC 7925, 644 DOI 10.17487/RFC7925, July 2016, 645 . 647 [RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based 648 Authentication with an External Pre-Shared Key", RFC 8773, 649 DOI 10.17487/RFC8773, March 2020, 650 . 652 [Selfie] Drucker, N. and S. Gueron, "Selfie: reflections on TLS 1.3 653 with PSK", 2019, . 655 [Sethi] Sethi, M., Peltonen, A., and T. Aura, "Misbinding Attacks 656 on Secure Device Pairing and Bootstrapping", Proceedings 657 of the 2019 ACM Asia Conference on Computer and 658 Communications Security , 2019, 659 . 661 [SmartCard] 662 "Technical Guideline TR-03112-7 eCard-API-Framework – 663 Protocols", 2015, . 667 Appendix A. Acknowledgements 669 This document is the output of the TLS External PSK Design Team, 670 comprised of the following members: Benjamin Beurdouche, Björn Haase, 671 Christopher Wood, Colm MacCarthaigh, Eric Rescorla, Jonathan Hoyland, 672 Martin Thomson, Mohamad Badra, Mohit Sethi, Oleg Pekar, Owen Friel, 673 and Russ Housley. 675 This document was improved by a high quality review by Ben Kaduk. 677 Authors' Addresses 679 Russ Housley 680 Vigil Security 682 Email: housley@vigilsec.com 684 Jonathan Hoyland 685 Cloudflare Ltd. 687 Email: jonathan.hoyland@gmail.com 689 Mohit Sethi 690 Ericsson 692 Email: mohit@piuha.net 694 Christopher A. Wood 695 Cloudflare 697 Email: caw@heapingbits.net