idnits 2.17.00 (12 Aug 2021) /tmp/idnits34838/draft-lear-eap-teap-brski-06.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 158: '...two functions co-located, they MUST be...' RFC 2119 keyword, line 341: '...flow, the device SHOULD send a Trusted...' RFC 2119 keyword, line 348: '...ion of step 5, server MUST send a CSR-...' RFC 2119 keyword, line 361: '...ucher TLV, then the device MUST send a...' RFC 2119 keyword, line 381: '... then the device MUST send a PKCS#10 t...' (34 more instances...) == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 August 2021) is 262 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) == Outdated reference: draft-ietf-anima-bootstrapping-keyinfra has been published as RFC 8995 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021AR' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021X' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft O. Friel 4 Updates: RFC7170 (if approved) N. Cam-Winget 5 Intended status: Standards Track Cisco Systems 6 Expires: 26 February 2022 D. Harkins 7 HP Enterprise 8 25 August 2021 10 TEAP Update and Extensions for Bootstrapping 11 draft-lear-eap-teap-brski-06 13 Abstract 15 In certain environments, in order for a device to establish any layer 16 three communications, it is necessary for that device to be properly 17 credentialed. This is a relatively easy problem to solve when a 18 device is associated with a human being and has both input and 19 display functions. It is less easy when the human, input, and 20 display functions are not present. To address this case, this memo 21 specifies extensions to the Tunnel Extensible Authentication Protocol 22 (TEAP) method that leverages Bootstrapping Remote Secure Key 23 Infrastructures (BRSKI) in order to provide a credential to a device 24 at layer two. The basis of this work is that a manufacturer will 25 introduce the device and the local deployment through cryptographic 26 means. In this sense the same trust model as BRSKI is used. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on 26 February 2022. 45 Copyright Notice 47 Copyright (c) 2021 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 52 license-info) in effect on the date of publication of this document. 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. Code Components 55 extracted from this document must include Simplified BSD License text 56 as described in Section 4.e of the Trust Legal Provisions and are 57 provided without warranty as described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. TEAP BRSKI Architecture . . . . . . . . . . . . . . . . . . . 4 64 3. BRSKI Bootstrap and Enroll Operation . . . . . . . . . . . . 4 65 3.1. Discovery of Trusted MASA . . . . . . . . . . . . . . . . 5 66 3.2. Executing BRSKI in a TEAP Tunnel . . . . . . . . . . . . 5 67 4. PKI Certificate Considerations . . . . . . . . . . . . . . . 9 68 4.1. TEAP Tunnel Establishment . . . . . . . . . . . . . . . . 9 69 4.2. BRSKI Trust Establishment . . . . . . . . . . . . . . . . 11 70 4.3. Certificate Expiration Times . . . . . . . . . . . . . . 12 71 4.4. LDevID Subject and Subject Alternative Names . . . . . . 12 72 4.5. PKCS#10 Retry Handling . . . . . . . . . . . . . . . . . 13 73 5. Peer Identity . . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Channel and Crypto Binding . . . . . . . . . . . . . . . . . 14 75 7. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 14 76 7.1. TEAP Server Grants Access . . . . . . . . . . . . . . . . 14 77 7.2. TEAP Server Instructs Client to Perform BRSKI Flow . . . 16 78 7.3. TEAP Server Instructs Client to Reenroll . . . . . . . . 20 79 7.4. Out of Band Reenroll . . . . . . . . . . . . . . . . . . 22 80 8. TEAP TLV Formats . . . . . . . . . . . . . . . . . . . . . . 22 81 8.1. New TLVs . . . . . . . . . . . . . . . . . . . . . . . . 22 82 8.1.1. BRSKI-RequestVoucher TLV . . . . . . . . . . . . . . 23 83 8.1.2. BRSKI-Voucher TLV . . . . . . . . . . . . . . . . . . 23 84 8.1.3. CSR-Attributes TLV . . . . . . . . . . . . . . . . . 24 85 8.1.4. Retry-After TLV . . . . . . . . . . . . . . . . . . . 25 86 8.1.5. NAI TLV . . . . . . . . . . . . . . . . . . . . . . . 25 87 8.2. Existing TEAP TLV Specifications . . . . . . . . . . . . 25 88 8.2.1. PKCS#10 TLV . . . . . . . . . . . . . . . . . . . . . 25 89 8.3. TLV Rules . . . . . . . . . . . . . . . . . . . . . . . . 26 90 9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 26 91 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 92 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 93 11.1. Issues with Provisionally Authenticated TEAP . . . . . . 28 94 11.2. Attack Against Discovery . . . . . . . . . . . . . . . . 28 95 11.3. TEAP Server as Registration Authority . . . . . . . . . 28 96 11.4. Trust of Registrar . . . . . . . . . . . . . . . . . . . 29 97 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 98 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 99 13.1. Normative References . . . . . . . . . . . . . . . . . . 29 100 13.2. Informative References . . . . . . . . . . . . . . . . . 30 101 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 30 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 104 1. Introduction 106 [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) specifies a means to 107 provision credentials to be used as credentials to operationally 108 access networks. It was designed as a standalone means where some 109 limited access to an IP network is already available. This is not 110 always the case. For example, IEEE 802.11 networks generally require 111 authentication prior to any form of address assignment. While it is 112 possible to assign an IP address to a device on some form of an open 113 network, or to accept some sort of default credential to establish 114 initial IP connectivity, the steps that would then follow might well 115 require that the device is placed on a new network, requiring 116 reseting all layer three parameters. 118 A more natural approach in such cases is to more tightly bind the 119 provisioning of credentials with the authentication mechanism. One 120 such way to do this is to make use of the Extensible Authentication 121 Protocol (EAP) [RFC3748] and the Tunnel Extensible Authentication 122 Protocol (TEAP) method [RFC7170]. Thus we define new TEAP Type- 123 Length-Value (TLV) objects that can be used to transport the BRSKI 124 protocol messages within the context of a TEAP TLS tunnel. 126 [RFC7170] discusses the notion of provisioning peers. Several 127 different mechanisms are available. Section 3.8 of that document 128 acknowledges the concept of not initially authenticating the outer 129 TLS session so that provisioning may occur. In addition, exchange of 130 multiple TLV messages between client and EAP server permits multiple 131 provisioning steps. 133 1.1. Terminology 135 The reader is presumed to be familiar with EAP terminology as stated 136 in [RFC3748]. In addition, the following terms are commonly used in 137 this document. 139 * BRSKI: Bootstrapping Remote Secure Key Infrastructures, as defined 140 in [I-D.ietf-anima-bootstrapping-keyinfra]. The term is also used 141 to refer to the flow described in that document. 143 * EST: Enrollment over Secure Transport, as defined in [RFC7030]. 145 * Voucher: a signed JSON object as defined in [RFC8366]. 147 2. TEAP BRSKI Architecture 149 The TEAP BRSKI architecture is illustrated in Section 3. The device 150 talks to the TEAP server via the Authenticator using any compliant 151 transport such as [IEEE8021X]. The architecture illustrated shows an 152 Authenticator distinct from the TEAP server. This is a deployment 153 optimization and when so deployed the communication between 154 Authenticator and TEAP server is a AAA protocol such as RADIUS or 155 DIAMETER. 157 The architecture illustrated shows a co-located TEAP server and BRSKI 158 registrar. Not only are these two functions co-located, they MUST be 159 the same entity. This ensures that the entity identified in the 160 device's voucher request (the TEAP server) is the same entity that 161 signs the voucher request (the registrar). 163 The registrar communicates with the BRSKI MASA service for the 164 purposes of getting signed vouchers. 166 The registrar also communicates with a Certificate Authority in order 167 to issue LDevIDs. The architecture shows the registrar and CA as 168 being two logically separate entities, however the CA may be 169 integrated into the registrar. The device is not explicitly aware of 170 whether the CA and registrar functions are integrated. 172 +--------+ +---------+ +---------+ +------+ 173 | | | | | TEAP |<--->| MASA | 174 | | | Authen- | | server | +------+ 175 | Device |<--->| ticator |<--->| | 176 | | | | | BRSKI | +------+ 177 | | | | |Registrar|<--->| CA | 178 +--------+ +---------+ +---------+ +------+ 180 3. BRSKI Bootstrap and Enroll Operation 182 This section summarises the current BRSKI operation. The BRSKI flow 183 assumes the device has an IDevID and has a manufacturer installed 184 trust anchor that can be used to validate the BRSKI voucher. The 185 BRSKI flow compromises serveral main steps from the perspective of 186 the device: 188 * Step 1: Device discovers the registrar 190 * Step 2: Device establishes provisional TLS connection to registrar 192 * Step 3: Device sends voucher request message and receives signed 193 voucher response 195 * Step 4: Device validates voucher and validates provisional TLS 196 connection to registrar 198 * Step 5: Device downloads additional local domain CA information 200 * Step 6: Device downloads Certificate Signing Request (CSR) 201 attributes 203 * Step 7: Device does a certificate enroll to obtain an LDevID 205 * Step 8: Device periodically reenrolls via EST to refresh its 206 LDevID 208 Most of the operational steps require the device, and thus its 209 internal state machine, to automatically complete the next step 210 without being explicitly instructed to do so by the registrar. For 211 example, the registrar does not explicitly tell the device to 212 download additional local domain CA information, or to do an EST 213 enroll to obtain an LDevID. 215 3.1. Discovery of Trusted MASA 217 BRSKI section 2.8 outlines how the Registrar discovers the correct 218 MASA to connect with. BRSKI section 5.3 outlines how the Registrar 219 can make policy decisions about which devices to trust. 221 Similar approaches are applicable for TEAP servers executing BRSKI. 222 For example, the TEAP server may be configured with a list of trusted 223 manufacturing CAs. During device bootstrap, only devices with an 224 IDevID signed by a trusted manufacturing CA may be allowed to 225 etablishes a TLS connection with the TEAP server, and the TEAP server 226 could then extract the MASA URI from the device's IDevID. 228 3.2. Executing BRSKI in a TEAP Tunnel 230 This section outlines how the main BRSKI steps outlined above map to 231 TEAP, and how BRSKI and enrollment can be accomplished inside a TEAP 232 TLS tunnel. The following new TEAP TLVs are introduced: 234 * BRSKI-VoucherRequest 236 * BRSKI-Voucher 238 * CSR-Attributes 240 The following steps outline how the above BRSKI flow maps to TEAP. 242 * Step 1: Device discovers the registrar 243 When BRSKI is executed in a TEAP tunnel, the device exchanges BRSKI 244 TLVs with the TEAP server. The discovery process for devices is 245 therefore the standard wired or wireless LAN EAP server discovery 246 process. The discovery processes outlined in section 4 of 247 [I-D.ietf-anima-bootstrapping-keyinfra] are not required for initial 248 discovery of the registrar. 250 * Step 2: Device establishes provisional TLS connection to registrar 252 The device establishes an outer TEAP tunnel with the TEAP server and 253 does not validate the server certificate. The device presents its 254 LDevID as its identity certificate if it has a valid LDevID, 255 otherwise it presents its IDevID. The TEAP server validates the 256 device's certificate using its implicit or explicit trust anchor 257 database. If the device presents an IDevID it is verified against a 258 database of trusted manufacturer certificates. Server policy may 259 also be used to control which certificate the device is allowed 260 present, as described in section {pki-certificate-authority- 261 considerations}. 263 If the presented credential is sufficient to grant access, the TEAP 264 server can return a TEAP Result TLV indicating success immediately. 265 The device may still send a Request-Action TLV including a BRSKI- 266 VoucherRequest TLV in response to the TEAP Result TLV if it does not 267 have, but requires, provisioning of trust anchors for validating the 268 TEAP server certificate. Note that no inner EAP method is required 269 for this, only an exchange of TEAP TLVs. 271 [todo] Question: as the device wants the server to reply with a 272 BRSKI-Voucher TLV, does it really send a Request-Action TLV 273 containing a BRSKI-VoucherRequest TLV, or does it send a Request- 274 Action TLV containing a BRSKI-Voucher TLV?? The TEAP draft is a bit 275 ambiguous here. Normally, if one end sends a Request-Action 276 including XXX-TLV, it means it wants the far end ot send an XXX- 277 TLV... 279 [todo] Question: general TEAP protocol question: does the device have 280 to send a Request-Action w/BRSKI-VoucherRequest or can it send a 281 BRSKI-VoucherRequest on its own? I'm not clear on this. 283 If the TEAP server requires that the device execute a BRSKI flow, the 284 server sends a Request-Action TLV that includes a BRSKI- 285 VoucherRequest TLV. For example, if the device presented its IDevID 286 but the TEAP server requires an LDevID. 288 [todo] Question: to nit pick, the server should send a Request-Action 289 TLV including a PKCS#10 TLV to tell the client to enroll. How does 290 the server really know that the client has the correct trust 291 established (as previously received by a BRSKI-Voucher)? If the 292 client sends an IDevID, does server always send a Request-Action 293 including both BRSKI-VoucherRequest and PKCS#10 TLVs? Whats the 294 client behaviour? I assume client can spontaneously send BRSKI- 295 VoucherRequest and/or PCSK#10 without being explicitly instructed to. 296 Just need to get the language correct here. 298 The TEAP server may also require the device to reenroll, for example, 299 if the device presented a valid LDevID that is very closed to 300 expiration. The server may instruct a device to reenroll by sending 301 a Request-Action TLV that includes a zero byte length PKCS#10 TLV. 303 * Step 3: Device sends voucher request message and receives signed 304 voucher response 306 The device sends a BRSKI-RequestVoucher TLV to the TEAP server. The 307 TEAP server forwards the RequestVoucher message to the MASA server, 308 and the MASA server replies with a signed voucher. The TEAP server 309 sends a BRSKI-Voucher TLV to the device. 311 If the MASA server does not issue a signed voucher, the TEAP server 312 sends an EAP-Error TLV with a suitable error code to the device. 314 For wireless devices in particular, it is important that the MASA 315 server only return a voucher for devices known to be associated with 316 a particular registrar. In this sense, success indicates that the 317 device is on the correct network, while failure indicates the device 318 should try to provision itself within wireless networks (e.g, go to 319 the next SSID). 321 * Step 4: Device validates voucher and validates provisional TLS 322 connection to registrar 324 The device validates the signed voucher using its manufacturer 325 installed trust anchor, and uses the CA information in the voucher to 326 validate the TLS connection to the TEAP server. 328 If the device fails to validate the voucher, then it sends a TEAP- 329 Error TLV indicating failiure to the TEAP server. 331 Similarly, if the device validates the voucher, but fails to validate 332 the provisional TLS connection, then it sends a TEAP-Error TLV 333 indicating failure to the TEAP server. Note that the outer TLS 334 tunnel has already been established, thus allowing the client to send 335 a TEAP-Error TLV to the server inside that tunnel to indicate that it 336 failed to verify the provisionally accepted outer TLS tunnel server 337 identity. 339 * Step 5: Device downloads additional local domain CA information 341 On completion of the BRSKI flow, the device SHOULD send a Trusted- 342 Server-Root TLV to the TEAP server in order to discover additional 343 local domain CAs. This is equivalent to section [todo] from 344 [I-D.ietf-anima-bootstrapping-keyinfra]. 346 * Step 6: Device downloads CSR attributes 348 No later than the completion of step 5, server MUST send a CSR- 349 Attributes TLV to peer server in order to discover the correct fields 350 to include when it enrolls to get an LDevID. 352 * Step 7: Device does a certificate enroll to obtain an LDevID 354 When executing the BRSKI flow inside a TEAP tunnel, the device does 355 not directly leverage EST when doing its initial enroll. Instead, 356 the device uses the existing TEAP PKCS#10 and PCKS#7 TEAP mechanisms. 358 Once the BRSKI flow is complete, the device can now send a PKCS#10 359 TLV to enroll and request an LDevID. If the TEAP server instructed 360 the device to start the BRSKI flow via a Request-Action TLV that 361 includes a BRSKI-RequestVoucher TLV, then the device MUST send a 362 PKCS#10 in order to start the enroll process. The TEAP server will 363 handle the PKCS#10 and ultimately return a PKCS#7 including an LDevID 364 to the device. 366 If the TEAP server granted the device access on completion of the 367 outer TEAP TLS tunnel in step 2 without sending a Request-Action TLV, 368 the device does not have to send a PKCS#10 to enroll. 370 At this point, the device is said to be provisioned for local network 371 access, and may authenticate in the future via 802.1X with its newly 372 acquired credentials. 374 * Step 8: Device periodically reenrolls to refresh its LDevID 376 When a device's LDevID is close to expiration, there are two options 377 for re-enrollment in order to obtain a fresh LDevID. As outlined in 378 Step 2 above, the TEAP server may instruct the device to reenroll by 379 sending a Request-Action TLV including a PKCS#10 TLV. If the TEAP 380 server explicilty instructs the device to reenroll via these TLV 381 exchange, then the device MUST send a PKCS#10 to reenroll and request 382 a fresh LDevID. 384 However, the device SHOULD reenroll if it determines that its LDevID 385 is close to expiration without waiting for explicit instruction from 386 the TEAP server. There are two options to do this. 388 Option 1: The device reenrolls for a new LDevID directly with the EST 389 CA outside the context of the 802.1X TEAP flow. The device uses the 390 registrar discovery mechanisms oulined in 391 [I-D.ietf-anima-bootstrapping-keyinfra] to discover the registrar and 392 the device sends the EST reenroll messages to the discovered 393 registrar endpoint. No new TEAP TLVs are defined to facilitate 394 discover of the registrar or EST endpoints inside the context of the 395 TEAP tunnel. 397 Option 2: When the device is performing a periodic 802.1X 398 authentication using its current LDevID, it reenrolls for a new 399 LDevID by sending a PKCS#10 TLV inside the TEAP TLS tunnel. 401 4. PKI Certificate Considerations 403 There are multiple noteworthy PKI certificate handling 404 considerations. These include: 406 * PKI CA handling when establishing the TEAP tunnel 408 * PKI CA handling establishing trust using BRSKI 410 * IDevID and LDevID expiration times 412 * Specifying LDevID Subject and Subject Alternative Names 414 * PKCS#10 retry handling 416 These are described in more detail here. 418 4.1. TEAP Tunnel Establishment 420 Because this method establishes a client identity, if the peer has 421 not been previously bootstrapped, or otherwise cannot successfully 422 authenticate, it will use a generic identity string of teap- 423 bootstrap@TBD1 as its network access identifier (NAI). 425 BRSKI section 5.3 outlines the policy decisions a Registrar may make 426 when deciding whether to accept connections from clients. Similarly, 427 the TEAP server operator may configure a set of trusted CAs for 428 validating incoming TLS connections from clients. The operator may 429 want to 'allow any device from a specific vendor', or from a set of 430 vendors, to access the network. Network operators may do this by 431 restricting network access to clients that have a certificate signed 432 by one of a small set of trusted manufacturer/supplier CAs. 434 When the client sends its ClientHello to initiate TLS tunnel 435 establishment, it is possible for the TEAP server to restrict the 436 certificates that the client can use for tunnel establishment by 437 including a list of CA distinguished names in the 438 certificate_authorities field in the CertificateRequest message. The 439 client should only continue with the handshake if it has a 440 certificate signed by one of the indicated CAs. 442 In practice, network operators will likely want to onboard devices 443 from a large number of device manufacturers, with each manufacturer 444 using a different root CA when issuing IDevIDs. If the number of 445 different manufacturer root CAs is large, this could result in very 446 large TLS handshake messages. Therefore, the TEAP server may send a 447 CertificateRequest message and not specify any 448 certificate_authorities, thus allowing the client present a 449 certificate signed by any authority in its Certificate message. 451 If the client has both an IDevID and an LDevID, the client should 452 present the LDevID in preference to its IDevID, if allowed by server 453 policy. 455 Once the client has sent its TLS Finished message, the TEAP server 456 can make a policy decision, based on the CA used to sign the client's 457 certificate, on whether to establish the outer TLS tunnel or not. 459 The TEAP server may delegate policy decisions to the MASA or CA 460 function. For example, the TEAP server may declare EAP success and 461 grant network access if the client presents a valid LDevID signed by 462 a trusted domain CA. However, if the client presents an IDevID 463 signed by a trusted manufacturer CA, the TEAP server may establish 464 the TLS tunnel but not declare EAP success and grant network access 465 until the client successfully completes a BRSKI Voucher exchange and 466 PKCS#10/PKCS#7 exchange inside that tunnel. 468 It is recommended that the client validate the certificate presented 469 by the server in the server's Certificate message, but this may not 470 be possible for clients that have not yet provisioned appropriate 471 trust anchors. If the client is in the provisioning phase and has 472 not yet completed a BRSKI flow, it will not have trust anchors 473 installed yet, and thus will not be able to validate the server's 474 certificate. The client must however note the certificate presented 475 by the server for (i) inclusion in the BRSKI-RequestVoucher TLV and 476 for (ii) validation once the client has discovered the local domain 477 trust anchors. 479 If the client does not present a suitable certificate to the server, 480 the server MUST terminate the connection and fail the EAP request. 481 If the TEAP server is unable to validate the client's certificate 482 using its implicit or explicit trust anchor database it MUST fail the 483 EAP request. 485 On establishment of the outer TLS tunnel, the TEAP server will make a 486 policy decision on next steps. Possible policy decisions include: 488 * Option 1: Server grants client full network access and returns 489 EAP-Success. This will typically happen when the client presents 490 a valid LDevID. Network policy may grant client network access 491 based on IDevID without requiring the device to enroll to obtain 492 an LDevID. 494 * Option 2: Server requires that client perform a full BRSKI flow, 495 and then enroll to get an LDevID. This will typically happen when 496 the client presents a valid IDevID and network policy requires all 497 clients to have LDevIDs. The server sends a Request-Action TLV 498 that includes a BRSKI-RequestVoucher TLV to the client to instruct 499 it to start the BRSKI flow. 501 * Option 3: Server requires that the client reenroll to obtain a new 502 LDevID. This could happen when the client presents a valid LDevID 503 that is very close to expiration time, or the server's policy 504 requires an LDevID update. The server sends an Action-Request TLV 505 including a PKCS#10 TLV to the client to instruct it to reenroll. 507 4.2. BRSKI Trust Establishment 509 If the server requires that client perform a full BRSKI flow, it 510 sends a Request-Action TLV that includes a zero byte length BRSKI- 511 RequestVoucher TLV to the client. The client sends a new BRSKI- 512 RequestVoucher TLV to the server, which contains all data specified 513 in [I-D.ietf-anima-bootstrapping-keyinfra] section 5.2. The client 514 includes the server certificate it received in the server's 515 Certificate message during outer TLS tunnel establishment in the 516 proximity-registrar-cert field. The client signs the request using 517 its IDevID. 519 The server includes all additional information as required by 520 [I-D.ietf-anima-bootstrapping-keyinfra] section 5.4 and signs the 521 request prior to forwarding to the MASA. 523 The MASA responds as per [I-D.ietf-anima-bootstrapping-keyinfra] 524 section 5.5. The response may indicate failure and the server should 525 react accordingly to failures by sending a failure response to the 526 client, and failing the TEAP method. 528 If the MASA replies with a signed voucher and a successful result, 529 the server then forwards this response to the client in a BRSKI- 530 Voucher TLV. 532 When the client receives the signed voucher, it validates the 533 signature using its built in trust anchor list, and extracts the 534 pinned-domain-cert field. The client must use the CA included in the 535 pinned-domain-cert to validate the certificate that was presented by 536 the server when establishing the outer TLS tunnel. If this 537 certificate validation fails, the client must fail the TEAP request 538 and not connect to the network. 540 [TBD- based on client responses, the registrar sends a status update 541 to the MASA] 543 4.3. Certificate Expiration Times 545 [IEEE8021AR] section 7.2.7.2 states: 547 notAfter: The latest time a DevID is expected to be used. Devices 548 possessing an IDevID are expected to operate indefinitely into the 549 future and should use the value 99991231235959Z. Solutions 550 verifying an IDevID are expected to accept this value 551 indefinitely. 553 TEAP servers SHOULD follow the 802.1AR standard when validating 554 IDevIDs. 556 TEAP servers SHOULD reject LDevIDs with expired certificates and 557 SHOULD NOT allow clients to connect with recently expired LDevIDs. 558 If a client presents a recently expired LDevID it SHOULD be forced to 559 authenticate using its IDevID and then reenroll to obtain a valid 560 LDevID. 562 4.4. LDevID Subject and Subject Alternative Names 564 BRSKI section 5.9.2 specifies that the pledge MUST send a CSR 565 Attributes request to the registrar. The registrar MAY use this 566 mechanism to instruct the pledge about the identities it should 567 include in the CSR request it sends as part of enrollment. The 568 registrar may use this mechanism to tell the pledge what Subject or 569 Subject Alternative Name identity information to include in its CSR 570 request. This can be useful if the Subject must have a specific 571 value in order to complete enrollment with the CA. 573 4.5. PKCS#10 Retry Handling 575 They will be scenarios where the TEAP server is willing to handle a 576 PKCS#10 request from a client and issue a certificate via a PKCS#7 577 response, however, the TEAP server is unable to immediately 578 completely the request and needs to instruct the client to retry 579 later after a specified time interval. 581 A new Retry-After TLV is defined that the TEAP server uses to specify 582 a retry interval in seconds. New error codes are defined to handle 583 these two alternate retry scenarios. 585 * The TEAP tunnel remains up: The client is instructed to resend the 586 PKCS#10 request after a retry interval but inside the same TEAP 587 tunnel. The TEAP server returns a Retry-After TLV to the client, 588 and returns an Error TLV with a new code in the 1000-1999 range. 590 * The TEAP tunnel is torn down: The client is instructed to 591 establish a new TEAP connection and TEAP tunnel after a retry 592 interval, and resend the PKCS#10 request indside the new tunnel. 593 The TEAP server returns a Retry-After TLV to the client, and 594 returns an Error TLV with a new code in the 2000-2999 range. 596 5. Peer Identity 598 EAP [RFC3748] recommends that "the Identity Response be used 599 primarily for routing purposes and selecting which EAP method to 600 use". NAI [RFC7542] recommends ommitting the username part of an NAI 601 in order to support username privacy, where appropriate. 603 A device that has not been bootstrapped at all SHOULD send an 604 identity of teap-bootstrap@TBD1. Otherwise, a device SHOULD send its 605 configured NAI. 607 The TEAP server may specify an NAI that it wishes the device to use. 608 For example, the server may want a bootstrapped device to use an NAI 609 of "abc123@example.com", or simply an NAI of "@example.com". This 610 could be desirable in order to facilitate roaming scenarios. The 611 server can do this by sending the device an NAI TLV inside the TEAP 612 tunnel. 614 If the server specifies an NAI TLV, and the device handles the TLV, 615 the device MAY use the specified NAI in all subsequent EAP 616 authentication flows. If the device is not willing to handle the NAI 617 TLV, it MUST reply with an Error TLV. 619 Authentication servers implementing this specification MAY reply with 620 an Error TLV to any unrecognized NAI, or MAY attempt to bootstrap the 621 device, regardless of the NAI. A device receving an Error from the 622 server MAY attempt a new session without the NAI in order to 623 bootstrap. 625 6. Channel and Crypto Binding 627 As the TEAP BRSKI flow does not define or require an inner EAP 628 method, there is no explicit need for exchange of Channel-Binding 629 TLVs between the device and the TEAP server. 631 The TEAP BRSKI TLVs are expected to occur at the beginning of the 632 TEAP Phase 2 and MUST occur before the final Crypto-Binding TLV. 633 This draft does not exclude the possibility of having other EAP 634 methods occur following the TEAP BRSKI TLVs and as such, the Crypto- 635 Binding TLV process rules as defined in [RFC7170] apply. 637 7. Protocol Flows 639 This section outlines protocol flows that map to the three server 640 policy options described in section Section 4.1. The protocol flows 641 illustrate a TLS1.2 exchange. Pertinent notes are outlined in the 642 protocol flows. 644 7.1. TEAP Server Grants Access 646 In this flow, the server grants access as server policy allows the 647 client to access the network based on the identity certificate that 648 the client presented. This means that either (i) the client has 649 previously completed BRSKI and has presented a valid LDevID or (ii) 650 the client presents an IDevID and network policy allows access based 651 purely on IDevID. 653 ,------. ,----------. 654 |Client| |TEAPServer| 655 `--+---' `----+-----' 656 | EAP-Request/ | 657 | Identity | 658 | <--------------------- 659 | | 660 | EAP-Response/ | 661 | Type=Identity | 662 | ---------------------> 663 | | 664 | EAP-Request/ | 665 | Type=TEAP, | 666 | TEAP Start, | 667 | Authority-ID TLV | 668 | <--------------------- 669 | | 670 | EAP-Response/ | 671 | Type=TEAP, | 672 | TLS(ClientHello) | 673 | ---------------------> 674 | | 675 | EAP-Request/ | 676 ,---!. | Type=TEAP, | 677 |(1)|_\| TLS(ServerHello, | 678 |(2) || ServerKeyExchange, | 679 `-----'| ServerHelloDone) | 680 | <--------------------- 681 | | 682 | EAP-Response/ | 683 | Type=TEAP, | 684 ,---!. | ClientKeyExchange, | 685 |(3)|_\| CertificateVerify, | 686 `-----'| ChangeCipherSpec, | 687 | Finished) | 688 | ---------------------> 689 | | 690 | EAP-Request/ | 691 | Type=TEAP, | 692 | TLS(ChangeCipherSpec,| 693 | Finished), | 694 | {Crypto-Binding TLV, | 695 | Result TLV=Success} | 696 | <--------------------- 697 | | 698 | EAP-Response/ | 699 | Type=TEAP, | 700 | {Crypto-Binding TLV, | 701 | Result TLV=Success} | 702 | ---------------------> 703 | | 704 | EAP-Success | 705 | <--------------------- 706 ,--+---. ,----+-----. 707 |Client| |TEAPServer| 708 `------' `----------' 710 Figure 1: TEAP Server Grants Access 712 Notes: 714 (1) If the client has completed the BRSKI flow and has locally 715 significant trust anchors, it must validate the Certificate received 716 from the server. If the client has not yet completed the BRSKI flow, 717 then it provisionally accepts the server Certificate and must 718 validate it later once BRSKI is complete. 720 (2) The server may include certificate_authorities field in the 721 CertificateRequest message in order to restrict the identity 722 certificates that the device is allowed present. 724 (3) The device will present its LDevID, if it has one, in preference 725 to its IDevID, if allowed by server policy. 727 7.2. TEAP Server Instructs Client to Perform BRSKI Flow 729 In this two part flow, the server instructs the client to perform a 730 BRSKI flow by exchanging TLVs once the outer TLS tunnel is 731 established. After that, enrollment takes place. 733 In the first part of the flow, the MASA is depicted on the right. 735 ,------. ,----------. ,----. 736 |Client| |TEAPServer| |MASA| 737 `--+---' `----+-----' `-+--' 738 | EAP-Request/ | | 739 | Type=Identity | | 740 | <----------------------------------- | 741 | | | 742 | EAP-Response/ | | 743 | Type=Identity | | 744 | -----------------------------------> | 745 | | | 746 | EAP-Request/ | | 747 ,---!. | Type=TEAP, | | 748 |(1)|_\| TEAP Start, | | 749 `-----'| Authority-ID TLV | | 750 | <----------------------------------- | 751 | | | 752 | EAP-Response/ | | 753 | Type=TEAP, | | 754 | TLS(ClientHello) | | 755 | -----------------------------------> | 756 | | | 757 | EAP-Request/ | | 758 | Type=TEAP, | | 759 | TLS(ServerHello, | | 760 | Certificate, | | 761 | ServerKeyExchange, | | 762 | CertificateRequest, | | 763 | ServerHelloDone) | | 764 | <----------------------------------- | 765 | | | 766 | EAP-Response/ | | 767 | Type=TEAP, | | 768 | TLS(Certificate | | 769 | ClientKeyExchange, | | 770 | CertificateVerify, | | 771 | ChangeCipherSpec, | | 772 | Finished) | | 773 | -----------------------------------> | 774 | | | 775 | EAP-Request/ | | 776 | Type=TEAP, | | 777 | TLS(ChangeCipherSpec, | | 778 | Finished), | | 779 | {Crypto-Binding TLV, | | 780 | Result TLV=Success} | | 781 | <----------------------------------- | 782 | | | 783 | EAP-Response/ | | 784 | ,Type=TEAP, | | 785 | {Crypto-Binding TLV, | | 786 | Result TLV=Success} | | 787 | -----------------------------------> | 788 | | | 789 ,-------------------------------------------------!. | 790 |At this stage the outer TLS tunnel is established|_\ | 791 |The following message exchanges are for BRSKI | | 792 `---------------------------------------------------' | 793 | EAP-Request/ | | 794 | Type=TEAP, | | 795 | {Request-Action TLV: | | 796 | Status=Failure, | | 797 ,---!. | Action=Process-TLV, | | 798 |(2)|_\| TLV=Request-Voucher, | | 799 `-----'| TLV=Trusted-Server-Root, | | 800 | TLV=CSR-Attributes, | | 801 | TLV=PKCS#10} | | 802 | <----------------------------------- | 803 | | | 804 | EAP-Response/ | | 805 ,---!. | Type=TEAP, | | 806 |(3)|_\| {Request-Voucher TLV} | | 807 `-----'| -----------------------------------> | 808 | | | 809 | | RequestVoucher | 810 | | -----------------> 811 | | | 812 | | Voucher | 813 | | <----------------- 814 | | | 815 | EAP-Request/ | | 816 ,---!. | Type=TEAP, | | 817 |(4)|_\| {Voucher TLV} | | 818 `-----'| <----------------------------------- | 819 | | | 820 | EAP-Response/ | | 821 | Type=TEAP,{Trusted-Server-Root TLV}| | 822 | -----------------------------------> | 823 | | | 824 | EAP-Request/ | | 825 ,---!. | Type=TEAP, | | 826 |(5)|_\| {Trusted-Server-Root TLV} | | 827 `-----'| <----------------------------------- | 828 | | | 829 | EAP-Response/ | | 830 | Type=TEAP,{CSR-Attributes TLV} | | 831 | -----------------------------------> | 832 | | | 833 | EAP-Request/ | | 834 | Type=TEAP, | | 835 | {CSR-Attributes TLV} | | 836 | <----------------------------------- | 837 ,--+---. ,----+-----. ,-+--. 838 |Client| |TEAPServer| |MASA| 839 `------' `----------' `----' 841 Figure 2: TEAP Server Instructs Client to Perform BRSKI Flow 843 The second part of the flow depicts the CA on the right. 845 ,------. ,----------. ,--. 846 |Client| |TEAPServer| |CA| 847 `--+---' `----+-----' `+-' 848 | EAP-Response/ | | 849 | Type=TEAP | | 850 | {PKCS#10 TLV} | | 851 | --------------------> | 852 | | | 853 | | PKCS#10 | 854 | | ----------------> 855 | | | 856 | | PKCS#7 | 857 | | <---------------- 858 | | | 859 | EAP-Request/ | | 860 | Type=TEAP, | | 861 | {PKCS#7 TLV, | | 862 | Result TLV=Success} | | 863 | <-------------------- | 864 | | | 865 | Eap-Response/ | | 866 | Type=TEAP | | 867 | {Result TLV=Success}| | 868 | --------------------> | 869 | | | 870 | EAP-Success | | 871 | <-------------------- | 872 ,--+---. ,----+-----. ,+-. 873 |Client| |TEAPServer| |CA| 874 `------' `----------' `--' 876 Figure 3: Enrollment after BRSKI Flow 878 Notes: 880 (1) If the client has not yet completed the BRSKI flow, then it 881 provisionally accepts the server certificate and must validate it 882 later once BRSKI is complete. The server validates the client 883 certificate using its trust anchor database. 885 (2) The server instructs the client to start the BRSKI flow by 886 sending a Request-Action TLV that includes a BRSKI-RequestVoucher 887 TLV. The server also instructs the client to request trust anchors, 888 to request CSR Attrites, and to initiate a PKCS certificate 889 enrolment. As outlined in [RFC7170], the Request-Action TLV is sent 890 after the Crypto-Binding TLV and Result TLV exchange. 892 (3) The client includes the certificate it received from the server 893 in the RequestVoucher message. 895 (4) Once the client receives and validates the voucher signed by the 896 MASA, it must verify the certificate it previously received from the 897 server. 899 (5) As outlined in [RFC7170], the Trusted-Server-Root TLV is 900 exchanged after the Crypto-Binding TLV exchange, and after the client 901 has used the Voucher to authenticate the TEAP server identity. This 902 is equivalent to section [todo] from 903 [I-D.ietf-anima-bootstrapping-keyinfra]. 905 (6) There is no need for an additional Crypto-Binding TLV exchange as 906 there is no inner EAP method. All BRSKI exchanges are simply TLVs 907 exchanged inside the outer TLS tunnel. 909 7.3. TEAP Server Instructs Client to Reenroll 911 In this flow, the server instructs the client to reenroll and get a 912 new LDevID by exchanging TLVs once the outer TLS tunnel is 913 established. 915 ,------. ,----------. ,--. 916 |Client| |TEAPServer| |CA| 917 `--+---' `----+-----' `+-' 918 | EAP-Request/ | | 919 | Identity | | 920 | <------------------------------ | 921 | | | 922 | EAP-Response/ | | 923 | Type=Identity | | 924 | ------------------------------> | 925 | | | 926 | EAP-Request/ | | 927 | Type=TEAP, | | 928 | TEAP Start, | | 929 | Authority-ID TLV | | 930 | <------------------------------ | 931 | | | 932 | EAP-Response/ | | 933 | Type=TEAP, | | 934 | TLS(ClientHello) | | 935 | ------------------------------> | 936 | | | 937 | EAP-Request/ | | 938 | Type=TEAP, | | 939 | TLS(ServerHello, | | 940 | ServerKeyExchange, | | 941 | ServerHelloDone) | | 942 | <------------------------------ | 943 | | | 944 | EAP-Response/ | | 945 | Type=TEAP, | | 946 | ClientKeyExchange, | | 947 | CertificateVerify, | | 948 | ChangeCipherSpec, | | 949 | Finished) | | 950 | ------------------------------> | 951 | | | 952 | EAP-Request/ | | 953 | Type=TEAP, | | 954 | TLS(ChangeCipherSpec, | | 955 | Finished), | | 956 | {Crypto-Binding TLV, | | 957 | Result TLV=Success} | | 958 | <------------------------------ | 959 | | | 960 | EAP-Response/ | | 961 | Type=TEAP, | | 962 | {Crypto-Binding TLV, | | 963 | Result TLV=Success} | | 964 | ------------------------------> | 965 | | | 966 | EAP-Request/ | | 967 | Type=TEAP,{Request-Action TLV:| | 968 ,---!. | Status=Failure, | | 969 |(1)|_\| Action=Process-TLV, | | 970 `-----'| TLV=PKCS#10} | | 971 | <------------------------------ | 972 | | | 973 | EAP-Response/ | | 974 | Type=TEAP | | 975 | {PKCS#10 TLV} | | 976 | ------------------------------> | 977 | | | 978 | | PKCS#10 | 979 | | ----------------> 980 | | | 981 | | PKCS#7 | 982 | | <---------------- 983 | | | 984 | EAP-Request/ | | 985 | Type=TEAP, | | 986 | {PKCS#7 TLV, | | 987 | Result TLV=Success} | | 988 | <------------------------------ | 989 | | | 990 | Eap-Response/ | | 991 | Type=TEAP | | 992 | {Result TLV=Success} | | 993 | ------------------------------> | 994 | | | 995 | EAP-Success | | 996 | <------------------------------ | 997 | | | 998 | EAP-Success | | 999 | <------------------------------ | 1000 ,--+---. ,----+-----. ,+-. 1001 |Client| |TEAPServer| |CA| 1002 `------' `----------' `--' 1004 Figure 4: TEAP Server Instructs Client to Reenroll 1006 (1) The server instructs the client to reenroll by sending a Request- 1007 Action TLV that includes a PKCS#10 TLV. 1009 7.4. Out of Band Reenroll 1011 This section shows how the device does a reenroll to refresh its 1012 LDEvID directly against the registrar outside the context of the TEAP 1013 tunnel. 1015 8. TEAP TLV Formats 1017 8.1. New TLVs 1019 This document defines 5 new TEAP TLVs. The following table indicates 1020 whether the TLVs can be included in Request messages from TEAP server 1021 to device, or Response messages from device to TEAP server. 1023 +------------------------+----------+ 1024 | TLV | Message | 1025 +------------------------+----------+ 1026 | BRSKI-VoucherRequest | Response | 1027 | BRSKI-Voucher | Request | 1028 | CSR-Attributes | Response | 1029 | Retry-After | Response | 1030 | NAI-Identity | Request | 1031 +------------------------+----------+ 1033 These new TLVs are detailed in this section. 1035 8.1.1. BRSKI-RequestVoucher TLV 1037 This TLV is used by the server as part of a Request-Action TLV to 1038 request from the peer that it initiate a voucher request. When used 1039 in this fashion, the length of this TLV will be set to zero. The 1040 Status field of the Request-Action TLV MUST be set to Failure. 1042 It is also used by the peer to initiate the voucher request. When 1043 used in this fashion, the length of the TLV will be set to that of 1044 the voucher request, as encoded and described in Section 3.3 in 1045 [I-D.ietf-anima-bootstrapping-keyinfra]. 1047 0 1 2 3 1048 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 |M|R| TLV=TBD1-VoucherRequest | Length | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | Value... 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 The M and R bits are always expected to be set to 0. 1057 The server is expected to forward the voucher request to the MASA, 1058 and then return a voucher in a BRSKI-Voucher TLV as described below. 1059 If it is unable to do so, it returns an TEAP Error TLV with one of 1060 the defined errors or the following: 1062 TBD2-MASA-Notavailable MASA unavailable 1063 TBD3-MASA-Refused MASA refuses to sign the voucher 1065 The peer terminates the TEAP connection, but may retry at some later 1066 point. The backoff mechanism for such retries should be appropriate 1067 for the device. Retries MUST occur no more frequently than once 1068 every two (TBD) minutes. 1070 8.1.2. BRSKI-Voucher TLV 1072 This TLV is transmitted from the server to the peer. It contains a 1073 signed voucher, as describe in [RFC8366]. 1075 0 1 2 3 1076 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 |M|R| TLV=TBD4-Voucher | Length | 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1080 | Value... 1081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 Upon receiving this TLV the peer will validate the signature of the 1084 voucher, using its pre-installed manufacturer trust anchor (LDevID). 1085 It MUST also validate the certificate used by the server to establish 1086 the TLS connection. 1088 If successful, it installs the new trust anchor contained in the 1089 voucher. 1091 Otherwise, the peer transmits an TEAP error TLV with one of the 1092 following error messages: 1094 TBD5-Invalid-Signature The signature on the voucher is invalid 1095 TBD6-Invalid-Voucher The form or content of the voucher is invalid 1096 TBD7-Invalid-TLS-Signer The certificate used for the TLS connection 1097 could not be validated. 1099 8.1.3. CSR-Attributes TLV 1101 The server SHALL transmit this TLV to the peer, either along with the 1102 BRSKI-Voucher TLV or at any time earlier in a communication. The 1103 peer shall include attributes required by the server in any following 1104 CSR. The value of this TLV is the base64 encoding described in 1105 Section 4.5.2 of [RFC7030]. 1107 The TEAP server MAY use this TLV to specify the subject identity 1108 information to include in Subject or Subjecet Alternate Name fields 1109 in any following CSR. 1111 0 1 2 3 1112 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1114 |M|R| TLV=TBD8-CSR-Attributes | length | 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | Value... 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1119 Again, the M and R values are set to 0. In the case where the client 1120 is unable to provide the requested attributes, an TEAP-Error is 1121 returned as follows: 1123 TBD9-CSR-Attribute-Fail Unable to supply the requested attributes. 1125 8.1.4. Retry-After TLV 1127 The server MUST transmit this TLV to the peer when repling to a 1128 PKCS#10 TLV request from the peer where the server is willing to 1129 fulfill the request and issue a certificate via a PKCS#7 response, 1130 but is unable to fulfill the request immediately. This TLV is used 1131 to tell the peer the mimimum lenght of time it MUST wait before 1132 resending the PKCS#10 request. The value of this TLV is the time in 1133 seconds that the peer MUST wait before resending the PKCS#10 request. 1134 The peer MUST resend the exact same PKCS#10 request. 1136 0 1 2 3 1137 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 |M|R| TLV=TBD10-Retry-After | length | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Value... 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1144 Again, the M and R values are set to 0. 1146 8.1.5. NAI TLV 1148 The server may use this TLV to provision a realm-specific NAI on the 1149 device. 1151 0 1 2 3 1152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 |M|R| TLV=TBD10-NAI | length | 1155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1156 | Value... 1157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 Again, the M and R values are set to 0. 1161 8.2. Existing TEAP TLV Specifications 1163 This section documents allowed usage of existing TEAP TLVs. The 1164 definition of the TLV is not changed, however clarifications on 1165 allowed values for the TLV fields is documented. 1167 8.2.1. PKCS#10 TLV 1169 [RFC7170] defines the PKCS#10 TLV as follows: 1171 0 1 2 3 1172 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1174 |M|R| TLV Type | Length | 1175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1176 | PKCS#10 Data... 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1179 [RFC7170] does not explicitly allow a Length value of zero. 1181 A Length value of zero is allowed for this TLV when the TEAP server 1182 sends a Request-Action TLV with a child PKCS#10 TLV to the client. 1183 In this scenario, there is no PKCS#10 Data included in the TLV. 1184 Clients MUST NOT send a zero length PKCS#10 TLV to the server. 1186 8.3. TLV Rules 1188 BRSKI TLVs can only be transported inside the TLS tunnel. The 1189 following table provides a guide to which TLVs may be encapsulated in 1190 which kind of packets, and in what quantity. The messages are as 1191 follows: Request is a TEAP Request, Response is a TEAP Response, 1192 Success is a message containing a successful Result TLV, and Failure 1193 is a message containing a failed Result TLV. 1195 The following define the meaning of the table entries in the sections 1196 below: 1198 0 This TLV MUST NOT be present in the message. 1200 0+ Zero or more instances of this TLV MAY be present in the message. 1202 0-1 Zero or one instance of this TLV MAY be present in the message. 1204 1 Exactly one instance of this TLV MUST be present in the message. 1206 Request Response Success Failure TLVs 0 0-1 0 0 BRSKI-VoucherRequest 1207 0-1 0 0 0 BRSKI-Voucher 0 0-1 0 0 CSR-Attributes 1209 9. Fragmentation 1211 TEAP is expected to provide fragmentation support. Thus EAP-TEAP- 1212 BRSKI does not specifically provide any, as it is only expected to be 1213 used as an inner method to TEAP. 1215 10. IANA Considerations 1217 The IANA is requested to add entries into the following tables: 1219 The following new TEAP TLVs are defined: 1221 TBD1-VoucherRequest Described in this document. 1222 TBD4-Voucher Described in this document. 1223 TBD8-CSR-Attributes Described in this document. 1224 TBD10-Retry-After Described in this document. 1226 The following TEAP Error Codes are defined, with their meanings 1227 listed here and in previous sections: 1229 TBD2-MASA-Notavailable MASA unavailable 1230 TBD3-MASA-Refused MASA refuses to sign the voucher 1231 TBD5-Invalid-Signature The signature on the voucher is invalid 1232 TBD6-Invalid-Voucher The form or content of the voucher is invalid 1233 TBD7-Invalid-TLS-Signer The certificate used for the TLS connection 1234 could not be validated. 1235 TBD9-CSR-Attribute-Fail Unable to supply the requested attributes. 1236 TBD11-Retry-PKCS#10 Retry PKCS#10 Request (1000 range code) 1237 TBD12-Retry-PKCS#10 Retry PKCS#10 Request (2000 range code) 1238 TBD13-NAI-Rejected The device will not use the indicated 1239 NAI (1000 range code) 1241 [[ TODO: is there a registry of NAIs that map to TEAP methods? e.g. 1242 @eap-teap.net is reserved to indicate the peer wants to use TEAP 1243 method ]] 1245 11. Security Considerations 1247 BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] provides a zero touch 1248 way for devices to enroll in a certification authority (CA). It 1249 assumes the device has IP connectivity. For networks that will not 1250 grant IP connectivitiy before authenticating (with a local 1251 credential) this poses a Catch-22- can't get on the network without a 1252 credential and can't get a credential without getting on the network. 1254 This protocol provides a way for BRSKI to be in an EAP method which 1255 allows the BRSKI conversation to happen as part of EAP authentication 1256 and prior to obtaining IP connectivity. 1258 The security considerations of 1259 [I-D.ietf-anima-bootstrapping-keyinfra] apply to this protocol. 1260 Running BRSKI through EAP introduces some additional areas of concern 1261 though. 1263 11.1. Issues with Provisionally Authenticated TEAP 1265 This protocol establishes an unauthenticated TLS connection and 1266 passes data through it. Provided that the only messages passed in 1267 this state are self-protected BRSKI messages this does not present a 1268 problem. Passing any other messages or TLVs prior to authentication 1269 of the provisional TLS connection could potentially introduce 1270 security issues. 1272 While the TLS connection is unauthenticated, it must still be 1273 validated to the fullest extent possible. It is critical that the 1274 device and the TEAP server perform all steps in TLS- checking the 1275 validity of the presented certificate, validating the signature using 1276 the public key of the certificate, etc- except ensuring the trust of 1277 the presented certificate. 1279 11.2. Attack Against Discovery 1281 The device discovery technique specified in this protocol is the 1282 standard EAP server discovery process. Since it is trivial to set up 1283 an 802.11 wireless access point and advertise any network, an 1284 attacker can impersonate a legitimate wireless network and attract 1285 unprovisioned pledges. Given that an unprovisioned device will not 1286 know the legitimate network to connect to, it will probably attempt 1287 the first network it finds, making the attack that much easier. This 1288 allows for a "rogue registrar" to provision and take control of the 1289 device. 1291 If the MASA verifies ownership prior to issuance of a voucher, this 1292 attack can be thwarted. But if the MASA is in reduced security mode 1293 and does not verify ownership this attack cannot be prevented. 1294 Registrars SHOULD use the audit log of a MASA when deploying newly 1295 purchased equipment in order to mitigate this attack. 1297 Another way to mitigate this attack is through normal "rogue AP" 1298 detection and prevention. 1300 11.3. TEAP Server as Registration Authority 1302 If the TEAP server is logically separate from the Certification 1303 Authority (CA) (see Section 2) it will be acting as a Registration 1304 Authority (RA) when it obtains the PKCS#10 TLV and replies with a 1305 PKCS#7 TLV (see [RFC7170], Sections 4.2.16 and 4.2.17, respectively). 1306 The assurance a RA makes to a CA is that the public key in the 1307 presented CSR is bound to an authenticated identity in way that will 1308 assure non-repudiation. 1310 To make such an assurance, the TEAP server MUST authenticate the 1311 provisional TLS connection with the device by validating the voucher 1312 response received from the MASA. In addition, it is RECOMMENDED that 1313 the TEAP server indicate that proof-of-possession (see [RFC7170], 1314 Section 3.8.2) is required by including the challengePassword OID in 1315 the CSR Attributes TLV. 1317 11.4. Trust of Registrar 1319 The device accepts a trusted server (CA) certificate and installs it 1320 in its trust anchor database during step 5 (see Section 3.2). This 1321 can happen only after the provisional TLS connection has been 1322 authenticated using the voucher and the Crypto-Binding TLV has been 1323 validated. 1325 12. Acknowledgments 1327 The authors would like to thank Brian Weis for his assistance, and 1328 Alan Dakok for improving language consistency. In addition, with 1329 ruthlessly "borrowed" the concept around NAI handling from Tuomas 1330 Aura and Mohit Sethi. 1332 13. References 1334 13.1. Normative References 1336 [I-D.ietf-anima-bootstrapping-keyinfra] 1337 Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M. 1338 H., and K. Watsen, "Bootstrapping Remote Secure Key 1339 Infrastructure (BRSKI)", Work in Progress, Internet-Draft, 1340 draft-ietf-anima-bootstrapping-keyinfra-45, 11 November 1341 2020, . 1344 [IEEE8021AR] 1345 Institute for Electrical and Electronics Engineers, 1346 "Secure Device Identity", 1998. 1348 [IEEE8021X] 1349 Institute for Electrical and Electronics Engineers, "IEEE 1350 Standard for Local and metropolitan area networks--Port- 1351 Based Network Access Control", 2010. 1353 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1354 Levkowetz, Ed., "Extensible Authentication Protocol 1355 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1356 . 1358 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1359 "Enrollment over Secure Transport", RFC 7030, 1360 DOI 10.17487/RFC7030, October 2013, 1361 . 1363 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1364 "Tunnel Extensible Authentication Protocol (TEAP) Version 1365 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1366 . 1368 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1369 "A Voucher Artifact for Bootstrapping Protocols", 1370 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1371 . 1373 13.2. Informative References 1375 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1376 DOI 10.17487/RFC7542, May 2015, 1377 . 1379 Appendix A. Changes from Earlier Versions 1381 Draft -06: * nothing more than version bump 1383 Draft -03: * Merge EAP server and Registrar * Security considerations 1384 * References improvements * Add Dan Harkins as co-author 1386 Draft -02: * Flow corrections 1388 Draft -01: * Add packet descriptions, IANA considerations, smooth out 1389 language. 1391 Draft -00: 1393 * Initial revision 1395 Authors' Addresses 1397 Eliot Lear 1398 Cisco Systems 1399 Richtistrasse 7 1400 CH-8304 Wallisellen 1401 Switzerland 1403 Phone: +41 44 878 9200 1404 Email: lear@cisco.com 1405 Owen Friel 1406 Cisco Systems 1407 170 W. Tasman Dr. 1408 San Jose, CA, 95134 1409 United States 1411 Email: ofriel@cisco.com 1413 Nancy Cam-Winget 1414 Cisco Systems 1415 170 W. Tasman Dr. 1416 San Jose, CA, 95134 1417 United States 1419 Email: ncamwing@cisco.com 1421 Dan Harkins 1422 HP Enterprise 1423 3333 Scott Boulevard 1424 Santa Clara, CA, 95054 1425 United States 1427 Email: dharkins@arubanetworks.com