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