idnits 2.17.1 draft-friel-tls-eap-dpp-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 145: '....3 handshake. This key MUST be from a...' RFC 2119 keyword, line 196: '...ound, the server SHALL terminate the T...' RFC 2119 keyword, line 204: '...1.3 key schedule SHALL include both th...' RFC 2119 keyword, line 212: '...ertTypeExtension SHALL always indicate...' RFC 2119 keyword, line 213: '...he client's Certificate SHALL be ECDSA...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 09, 2021) is 1022 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Experimental RFC: RFC 8773 -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Friel 3 Internet-Draft Cisco 4 Intended status: Standards Track D. Harkins 5 Expires: January 10, 2022 Hewlett-Packard Enterprise 6 July 09, 2021 8 Bootstrapped TLS Authentication 9 draft-friel-tls-eap-dpp-03 11 Abstract 13 This document defines a TLS extension that enables a server to prove 14 to a client that it has knowledge of the public key of a key pair 15 where the client has knowledge of the private key of the key pair. 16 Unlike standard TLS key exchanges, the public key is never exchanged 17 in TLS protocol messages. Proof of knowledge of the public key is 18 used by the client to bootstrap trust in the server. The use case 19 outlined in this document is to establish trust in an EAP server. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 10, 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Bootstrap Key Pair . . . . . . . . . . . . . . . . . . . 2 57 1.2. Alignment with Wi-Fi Alliance Device Provisioning Profile 3 58 2. Bootstrapping in TLS 1.3 . . . . . . . . . . . . . . . . . . 4 59 2.1. Bootstrap Extended PSK . . . . . . . . . . . . . . . . . 4 60 2.2. Changes to TLS 1.3 Handshake . . . . . . . . . . . . . . 5 61 3. Using TLS Bootstrapping in EAP . . . . . . . . . . . . . . . 6 62 4. Summary of Work . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 67 7.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 On-boarding of devices with no, or limited, user interface can be 73 difficult. Typically, a credential is needed to access the network 74 and network connectivity is needed to obtain a credential. This 75 poses a catch-22. 77 If trust in the integrity of a device's public key can be obtained in 78 an out-of-band fashion, a device can be authenticated and provisioned 79 with a usable credential for network access. While this 80 authentication can be strong, the device's authentication of the 81 network is somewhat weaker. [duckling] presents a functional 82 security model to address this asymmetry. 84 There are on-boarding protocols, such as [DPP], to address this use 85 case but they have drawbacks. [DPP] for instance does not support 86 wired network access. This document describes an on-boarding 87 protocol, which we refer to as TLS Proof of Knowledge or TLS-POK. 89 1.1. Bootstrap Key Pair 91 The mechanism for on-boarding of devices defined in this document 92 relies on bootstrap key pairs. A client device has an associated 93 elliptic curve (EC) key pair. The key pair may be static and baked 94 into device firmware at manufacturing time, or may be dynamic and 95 generated at on-boarding time by the device. If this public key, 96 specifically the ASN.1 SEQUENCE SubjectPublicKeyInfo from [RFC5280], 97 can be shared in a trustworthy manner with a TLS server, a form of 98 "origin entity authentication" (the step from which all subsequent 99 authentication proceeds) can be obtained. 101 The exact mechanism by which the server gains knowledge of the public 102 key is out of scope of this specification, but possible mechanisms 103 include scanning a QR code to obtain a base64 encoding of the 104 ASN.1-formatted public key or upload of a Bill of Materials (BOM). 105 If the QR code is physically attached to the client device, or the 106 BOM is associated with the device, the assumption is that the public 107 key obtained in this bootstrapping method belongs to the client. In 108 this model, physical possession of the device implies legitimate 109 ownership. 111 The server may have knowledge of multiple bootstrap public keys 112 corresponding to multiple devices, and TLS extensions are defined in 113 this document that enable the server to identity a specific bootstrap 114 public key correspinding to a specific device. 116 Using the process defined herein, the client proves to the server 117 that it has possession of the private analog to its public 118 bootstrapping key. Provided that the mechanism in which the server 119 obtained the bootstrapping key is trustworthy, a commensurate amount 120 of authenticity of the resulting connection can be obtained. The 121 server also proves that it knows the client's public key which, if 122 the client does not gratuitously expose its public key, can be used 123 to obtain a modicum of correctness, that the client is connecting to 124 the correct network (see [duckling]). 126 1.2. Alignment with Wi-Fi Alliance Device Provisioning Profile 128 The definition of the boostrap public key aligns with that given in 129 [DPP]. This, for example, enables the QR code format as defined in 130 [DPP] to be reused for TLS-POK. Therefore, a device that supports 131 both wired LAN and Wi-Fi LAN connections can have a single QR code 132 printed on its label, and the bootstrap key can be used for DPP if 133 the device bootstraps against a Wi-Fi network, or TLS-POK if the 134 device bootstraps against a wired network. Similarly, a common 135 bootstrap public key format could be imported in a BOM into a server 136 that handles devices connecting over both wired and Wi-Fi networks. 138 Any bootstrapping method defined for, or used by, [DPP] is compatible 139 with TLS-POK. 141 2. Bootstrapping in TLS 1.3 143 The bootstrapping modifications introduce an extension to identify a 144 "bootstrapping" key which is converted into an external PSK and used 145 directly in the TLS 1.3 handshake. This key MUST be from a 146 cryptosystem suitable for doing ECDSA. 148 2.1. Bootstrap Extended PSK 150 This document defines the "bskey" extended PSK type by expanding on 151 the work in [extensible-psks]. 153 enum { 154 bskey(TBD), (255) 155 } ExtendedPskIdentityType; 157 A bskey PSK is a varient of an external PSK which, in this case, is 158 derived from a public key. 160 The PSKIdentity of a bskey extended PSK is encoded with a string 161 derived from the DER-encoded ASN.1 subjectPublicKeyInfo 162 representation of the bootstrapping public key. 164 struct { 165 opaque identity<1..2^32-1> 166 } BootstrapPSKIdentity; 168 Both the bskey PSK and the BootstrapPSKIdentity are computed using 169 [RFC5869] with the hash algorithm from the ciphersuite: 171 bskeypsk = HKDF-Expand(HKDF-Extract(<>, bskey), 172 "tls13-extended-psk-bskey", L) 173 identity = HKDF-Expand(HKDF-Extract(<>, bskey), 174 "tls13-psk-identity-bskey", L) 175 where: 176 - <> is a NULL salt 177 - bskey is the DER-encoded ASN.1 subjectPublicKeyInfo 178 representation of the bootstrapping key 179 - L is the length of the digest of the underlying hash 180 algorithm 182 A performance versus storage tradeoff a server can choose is to 183 precompute the identity of every bootstrapped key with every hash 184 algorithm that it uses in TLS and use that to quickly lookup the 185 bootstrap key and generate the PSK. Servers that choose not to 186 employ this optimization will have to do a runtime check with every 187 bootstrap key it holds against the identity the client provides. 189 2.2. Changes to TLS 1.3 Handshake 191 The client includes the "tls_cert_with_extern_psk" extension in the 192 ClientHello, per [RFC8773], and identifies the bootstrapping key 193 using the BootstrapPSKIdentity extension. The server looks up the 194 client's bootstrapping key in its database by checking the hash of 195 each entry with the value received in the ClientHello. If no match 196 is found, the server SHALL terminate the TLS handshake with an alert. 198 [[ TODO: should we define an explicit unknown_bsk_identity alert, 199 similar to unknown_psk_identity ]] 201 If the server found the matching bootstrap key, it generates the 202 bskeypsk and includes the "tls_cert_with_extern_psk" extension in the 203 ServerHello message. When these extensions have been successfully 204 negotiated, the TLS 1.3 key schedule SHALL include both the bskeypsk 205 in the Early Secret derivation and an (EC)DHE shared secret value in 206 the Handshake Secret derivation. 208 After successful negotiation of these extensions, the full TLS 1.3 209 handshake is performed with the additional caveat that the client 210 authenticates with a raw public key (its bootstrapping key) per 211 [RFC7250]. The bootstrapping key is always an elliptic curve public 212 key, therefore the ClientCertTypeExtension SHALL always indicate 213 RawPublicKey and the type of the client's Certificate SHALL be ECDSA 214 and contain the client's bootstrapping key as a DER-encoded ASN.1 215 subjectPublicKeyInfo SEQUENCE. 217 [[DISCUSS: since the bskey identity is being negotiated we already 218 know what the client cert type will be, the ClientCertTypeExtension 219 is superfluous. Should it be removed from this spec?]] 221 When the server processes the client's Certificate it MUST ensure 222 that it is identical to the bootstrapping public key that it used to 223 generate an external PSK and PSKIdentifier for this handshake. 225 When clients use the [duckling] form of authentication, they MAY 226 forgo the checking of the server's certificate in the 227 CertificateVerify and rely on the integrity of the bootstrapping 228 method employed to distribute its key in order to validate trust in 229 the authenticated TLS connection. 231 The handshake is shown in Figure 1. 233 Client Server 234 -------- -------- 235 ClientHello 236 + bskey_id 237 + cert_with_extern_psk 238 + client_cert_type=RawPublicKey 239 + key_share --------> 240 ServerHello 241 + bskey_id 242 + cert_with_extern_psk 243 + client_cert_type=RawPublicKey 244 + key_share 245 {EncryptedExtensions} 246 {CertificateRequest} 247 {Certificate} 248 {CertificateVerify} 249 <-------- {Finished} 250 {Certificate} 251 {CertificateVerify} 252 {Finished} --------> 253 [Application Data] <-------> [Application Data] 255 Figure 1: TLS 1.3 TLS-POK Handshake 257 3. Using TLS Bootstrapping in EAP 259 Enterprise deployments typically require an 802.1X/EAP-based 260 authentication to obtain network access. Protocols like [RFC7030] 261 can be used to enroll devices into a Certification Authority to allow 262 them to authenticate using 802.1X/EAP. But this creates a Catch-22 263 where a certificate is needed for network access and network access 264 is needed to obtain certificate. 266 Devices whose bootstrapping key can been obtained in an out-of-band 267 fashion can perform an EAP-TLS-based exchange, for instance 268 [RFC7170], and authenticate the TLS exchange using the bootstrapping 269 extensions defined in Section 2. This network connectivity can then 270 be used to perform an enrollment protocol (such as provided by 271 [RFC7170]) to obtain a credential for subsequent network connectivity 272 and certificate lifecycle maintenance. 274 Upon "link up", an Authenticator on an 802.1X-protected port will 275 issue an EAP Identify request to the newly connected peer. For 276 unprovisioned devices that desire to take advantage of TLS-POK, there 277 is no initial realm in which to construct an NAI (see [RFC4282]) so 278 the initial EAP Identity response SHOULD contain simply the name 279 "TLS-POK" in order to indicate to the Authenticator that an EAP 280 method that supports TLS-POK SHOULD be started. 282 Authenticating Peer Authenticator 283 ------------------- ------------- 284 <- EAP-Request/ 285 Identity 287 EAP-Response/ 288 Identity (TLS-POK) -> 290 <- EAP-Request/ 291 EAP-Type=TEAP 292 (TLS Start) 293 . 294 . 295 . 297 4. Summary of Work 299 [TODO: agree with WG chairs where this work lives and where it should 300 be documented.] 302 The protocol outlined here can be broadly broken up into 4 distinct 303 areas: 305 o TLS extensions to transport the bootstrap public key identifier 307 o Use of the TLS 1.3 extension for certificate-based authentication 308 with an external PSK 310 o The client's use of a raw public key in its certificate 312 o TEAP extensions to leverage the new TLS-POK handshake for trust 313 establishment 315 This document captures all 4 areas, but it may be more appropriate to 316 merge into an existing document. 318 5. IANA Considerations 320 IANA will allocated an ExtensionPSKIdentityType for the bskey type 321 from the TLS 1.3 repository created by [extensible-psks] and replace 322 TBD in this document with that number. 324 6. Security Considerations 326 Bootstrap and trust establishment by the TLS server is based on proof 327 of knowledge of the client's bootstrap public key, a non-public 328 datum. The TLS server obtains proof that the client knows its 329 bootstrap public key and, in addition, also possesses its 330 corresponding private analog. 332 Trust on the part of the client is based on validation of the server 333 certificate and the TLS 1.3 handshake. In addition, the client 334 assumes that knowledge of its public bootstrapping key is not widely 335 disseminated and therefore any device that proves knowledge of it is 336 the appropriate device from which to receive provisioning, for 337 instance via [RFC7170]. 339 An attack on the bootstrapping method which substitutes the public 340 key of a corrupted device for the public key of an honest device can 341 result in the TLS sever on-boarding and trusting the corrupted 342 device. 344 If an adversary has knowledge of the bootstrap public key, the 345 adversary may be able to make the client bootstrap against the 346 adversary's network. For example, if an adversary intercepts and 347 scans QR labels on clients, and the adversary can force the client to 348 connect to its server, then the adversary can complete the TLS-POK 349 handshake with the client and the client will connect to the 350 adversary's server. Since physical possession implies ownership, 351 there is nothing to prevent a stolen device from being on-boarded. 353 7. References 355 7.1. Normative References 357 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 358 Key Derivation Function (HKDF)", RFC 5869, 359 DOI 10.17487/RFC5869, May 2010, 360 . 362 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 363 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 364 Transport Layer Security (TLS) and Datagram Transport 365 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 366 June 2014, . 368 [RFC8773] Housley, R., "TLS 1.3 Extension for Certificate-Based 369 Authentication with an External Pre-Shared Key", RFC 8773, 370 DOI 10.17487/RFC8773, March 2020, 371 . 373 7.2. Informative References 375 [DPP] Wi-Fi Alliance, "Device Provisioning Profile", 2020. 377 [duckling] 378 Stajano, F. and E. Rescorla, "The Ressurecting Ducking: 379 Security Issues for Ad-Hoc Wireless Networks", 1999. 381 [extensible-psks] 382 Wood, C. and R. Anderson, "Extensible Pre-Shared Key Types 383 for TLS", n.d., . 386 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 387 Network Access Identifier", RFC 4282, 388 DOI 10.17487/RFC4282, December 2005, 389 . 391 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 392 Housley, R., and W. Polk, "Internet X.509 Public Key 393 Infrastructure Certificate and Certificate Revocation List 394 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 395 . 397 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 398 "Enrollment over Secure Transport", RFC 7030, 399 DOI 10.17487/RFC7030, October 2013, 400 . 402 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 403 "Tunnel Extensible Authentication Protocol (TEAP) Version 404 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 405 . 407 Authors' Addresses 409 Owen Friel 410 Cisco 412 Email: ofriel@cisco.com 414 Dan Harkins 415 Hewlett-Packard Enterprise 417 Email: daniel.harkins@hpe.com