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