idnits 2.17.1 draft-friel-tls-eap-dpp-02.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 144: '...e TLS 1.3 handshake. This key MUST be...' RFC 2119 keyword, line 168: '...f this extension SHALL consist of the ...' RFC 2119 keyword, line 192: '...ound, the server MAY proceed with the ...' RFC 2119 keyword, line 193: '...y as input to the key schedule, or MAY...' RFC 2119 keyword, line 296: '...dentity response SHOULD contain simply...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1158 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) -- Looks like a reference, but probably isn't: '32' on line 159 == Outdated reference: A later version (-06) exists of draft-lear-eap-teap-brski-05 -- Obsolete informational reference (is this intentional?): RFC 4282 (Obsoleted by RFC 7542) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 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: August 26, 2021 Hewlett-Packard Enterprise 6 February 22, 2021 8 Bootstrapped TLS Authentication 9 draft-friel-tls-eap-dpp-02 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 August 26, 2021. 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 Key Extension . . . . . . . . . . . . . . . . . 4 60 2.2. Server Ephemeral Keys . . . . . . . . . . . . . . . . . . 4 61 2.3. Changes to TLS 1.3 Handshake . . . . . . . . . . . . . . 5 62 2.4. Changes to TLS 1.3 Key Schedule . . . . . . . . . . . . . 6 63 3. Using TLS Bootstrapping in EAP . . . . . . . . . . . . . . . 7 64 4. Summary of Work . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 67 7. Informative References . . . . . . . . . . . . . . . . . . . 8 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. [Stajano]] 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 extensions 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 [Stajano]). 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 into the TLS 1.3 handshake. This key MUST be 145 from a cryptosystem suitable for doing (EC)DH. When using the 146 bootstrapping extension, two (EC)DH operations are performed, a 147 static-ephemeral (using the client's bootstrapping key and an 148 ephemeral key generated by the server) and an ephemeral-ephemeral 149 (using the client's ephemeral key and an ephemeral key generated by 150 the server). 152 2.1. Bootstrap Key Extension 154 This document defines the "bskey_share" extension. 156 struct { 157 select (Handshake.msg_type) { 158 case client_hello: 159 opaque bskey[32]; 161 case server_hello: 162 opaque bskey_exchange<1..2^16-1>; 163 }; 164 } BootstrapKey; 166 The BootstrapKey extension is used by the client in its ClientHello 167 message to specify its bootstrapping key identifier. The 'bskey' 168 field of this extension SHALL consist of the base64 encoded SHA256 169 digest of the DER-encoded ASN.1 subjectPublicKeyInfo representation 170 of the bootstrapping public key. 172 The BoostrapKey extension is used by the server in its ServerHello 173 message to specify its ephemeral ECDH keying information. The 174 'key_exchange' field contains the key exchange information on the 175 curve that the bootstrapping key is on. 177 2.2. Server Ephemeral Keys 179 The server generates two ephemeral key pairs: one that is used for 180 the static-ephemeral (bootstrap) ECDH exchange and is exchanged in 181 the "bskey_share" extension, and one that is used for the ephemeral- 182 ephemeral (TLS key_share) DH exchange and is exchanged in the 183 "key_share" extension. The "bskey_share" and "key_share" keys are 184 independent. The key_share keys may be Finite Field DH keys. 186 2.3. Changes to TLS 1.3 Handshake 188 The client identifies the bootstrapping key in the ClientHello using 189 the BootstrapKey extension 'bskey' field. The server looks up the 190 client's bootstrapping key in its database by checking the SHA256 191 hash of each entry with the value received in the ClientHello. If no 192 match is found, the server MAY proceed with the TLS handshake without 193 using the bootstrapping key as input to the key schedule, or MAY 194 terminate the TLS handshake with an alert. 196 [[ TODO: should we define an explicit unknown_bsk_identity alert, 197 similar to unknown_psk_identity ]] 199 If the server found the matching bootstrap key, the server generates 200 an ephemeral ECDH keypair on the curve indicated in the bootstrap 201 public key information, and performs an ECDH operation using the 202 client bootstrap key and the server's ephemeral keypair. The server 203 includes a BootstrapKey extension in its ServerHello that includes 204 its ephemeral ECDH public key in the 'key_exchange' field. This 205 explicitly confirms to the client that the server has performed an 206 ECDH operation using the bootstrap key, and has injected the output 207 into the key schedule. 209 This is in addition to, and independent from, the (EC)DH that the 210 server carries out when handling the key_share extension. 212 The handshake is shown in Figure 1. 214 Client Server 215 -------- -------- 216 ClientHello 217 + bskey_share 218 + key_share --------> 219 ServerHello 220 + bskey_share 221 + key_share 222 {EncryptedExtensions} 223 {Finished} 224 <-------- [Application Data*] 225 {Finished} --------> 226 [Application Data] <-------> [Application Data] 228 Figure 1: TLS 1.3 TLS-POK Handshake 230 2.4. Changes to TLS 1.3 Key Schedule 232 [[ TODO: The key schedule mechanism needs to closed. ]] 234 Multiple options for modifying the TLS 1.3 key schedule have been 235 proporsed recently including [I-D.stebila-tls-hybrid-design] and 236 [I-D.jhoyla-tls-extended-key-schedule]. The key schedule used for 237 TLS-POK will align with the final direction chosen by the TLS WG. 239 This document proposes aligning with the model outlined in 240 [I-D.jhoyla-tls-extended-key-schedule] where the shared secrets 241 derived from the bskey and key_share key exchanges are injected 242 together into the key schedule to create the Handshake Secret. 244 The key schedule for TLS-POK is as follows: 246 0 247 | 248 v 249 PSK -> HKDF-Extract = Early Secret 250 | 251 +-----> Derive-Secret(...) 252 +-----> Derive-Secret(...) 253 +-----> Derive-Secret(...) 254 | 255 v 256 Derive-Secret(., "derived", "") 257 | 258 v 259 bskey_input || (EC)DHE -> HKDF-Extract = Handshake Secret 260 | 261 +-----> Derive-Secret(...) 262 +-----> Derive-Secret(...) 263 | 264 v 265 Derive-Secret(., "derived", "") 266 | 267 v 268 0 -> HKDF-Extract = Master Secret 269 | 270 +-----> Derive-Secret(...) 271 +-----> Derive-Secret(...) 272 +-----> Derive-Secret(...) 273 +-----> Derive-Secret(...) 275 3. Using TLS Bootstrapping in EAP 277 Enterprise deployments typically require an 802.1X/EAP-based 278 authentication to obtain network access. Protocols like [RFC7030] 279 can be used to enroll devices into a Certification Authority to allow 280 them to authenticate using 802.1X/EAP. But this creates a Catch-22 281 where a certificate is needed for network access and network access 282 is needed to obtain certificate. 284 Devices whose bootstrapping key can been obtained in an out-of-band 285 fashion can perform an EAP-TLS-based exchange, for instance 286 [RFC7170], and authenticate the TLS exchange using the bootstrapping 287 extensions defined in Section 2. This network connectivity can then 288 be used to perform an enrollment protocol (such as provided by 289 [RFC7170]) to obtain a credential for subsequent network connectivity 290 and certificate lifecycle maintenance. 292 Upon "link up", an Authenticator on an 802.1X-protected port will 293 issue an EAP Identify request to the newly connected peer. For 294 unprovisioned devices that desire to take advantage of TLS-POK, there 295 is no initial realm in which to construct an NAI (see [RFC4282]) so 296 the initial EAP Identity response SHOULD contain simply the name 297 "TLS-POK" in order to indicate to the Authenticator that an EAP 298 method that supports TLS-POK SHOULD be started. 300 Authenticating Peer Authenticator 301 ------------------- ------------- 302 <- EAP-Request/ 303 Identity 305 EAP-Response/ 306 Identity (TLS-POK) -> 308 <- EAP-Request/ 309 EAP-Type=TEAP 310 (TLS Start) 311 . 312 . 313 . 315 4. Summary of Work 317 [TODO: agree with WG chairs where this work lives and where it should 318 be documented.] 320 The protocol outlined here can be broadly broken up into 3 distinct 321 areas: 323 o TLS extensions to transport the bootstrap public key identifier 325 o TLS key schedule enhancements to inject bootstrap public key 326 keying material 328 o TEAP extensions to leverage the new TLS-POK handshake for trust 329 establishment 331 This document captures all 3 areas, but it may be more appropriate to 332 split the work into multiple documents e.g.: 334 o piggy back on top of [I-D.jhoyla-tls-extended-key-schedule] for 335 TLS key schedule enhancements 337 o include the TEAP extensions in [I-D.lear-eap-teap-brski] draft 339 5. IANA Considerations 341 IANA will allocated an ExtensionType for the bskey extension from the 342 appropriate TLS 1.3 repository and replace TBD in this document with 343 that number. 345 6. Security Considerations 347 Bootstrap and trust establishment by the TLS server is based on proof 348 of knowledge of the client's bootstrap public key. An attack on the 349 bootstrapping method which substitutes the public key of a corrupted 350 device for the public key of an honest device can result in the TLS 351 sever on-boarding and trusting the corrupted device. 353 Trust on the part of the client is not strong and is based on an 354 assumption that the public bootstrapping key is not widely 355 disseminated. If an adversary has knowledge of the bootstrap public 356 key, the adversary may be able to make the client bootstrap against 357 the adversary's network. For example, if an adversary intercepts and 358 scans QR labels on clients, and the adversary can force the client to 359 connect to its server, then the adversary can complete the TLS-POK 360 handshake with the client and the client will connect to the 361 adversary's server. Since physical possession implies ownership, 362 there is nothing to prevent a stolen device from being on-boarded. 364 7. Informative References 366 [DPP] Wi-Fi Alliance, "Device Provisioning Profile", 2020. 368 [I-D.jhoyla-tls-extended-key-schedule] 369 Hoyland, J. and C. Wood, "TLS 1.3 Extended Key Schedule", 370 draft-jhoyla-tls-extended-key-schedule-03 (work in 371 progress), December 2020. 373 [I-D.lear-eap-teap-brski] 374 Lear, E., Friel, O., Cam-Winget, N., and D. Harkins, "TEAP 375 Update and Extensions for Bootstrapping", draft-lear-eap- 376 teap-brski-05 (work in progress), November 2019. 378 [I-D.stebila-tls-hybrid-design] 379 Steblia, D., Fluhrer, S., and S. Gueron, "Hybrid key 380 exchange in TLS 1.3", draft-stebila-tls-hybrid-design-03 381 (work in progress), February 2020. 383 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 384 Network Access Identifier", RFC 4282, 385 DOI 10.17487/RFC4282, December 2005, 386 . 388 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 389 Housley, R., and W. Polk, "Internet X.509 Public Key 390 Infrastructure Certificate and Certificate Revocation List 391 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 392 . 394 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 395 "Enrollment over Secure Transport", RFC 7030, 396 DOI 10.17487/RFC7030, October 2013, 397 . 399 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 400 "Tunnel Extensible Authentication Protocol (TEAP) Version 401 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 402 . 404 [Stajano] Anderson, S., "The Ressurecting Ducking: Security Issues 405 for Ad-Hoc Wireless Networks", 1999. 407 Authors' Addresses 409 Owen Friel 410 Cisco 412 Email: ofriel@cisco.com 413 Dan Harkins 414 Hewlett-Packard Enterprise 416 Email: daniel.harkins@hpe.com