idnits 2.17.1 draft-lear-eap-teap-brski-00.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 290: '...flow, the device SHOULD send a Trusted...' RFC 2119 keyword, line 296: '...ep 6, the device MUST send a CSR-Attri...' RFC 2119 keyword, line 309: '...ucher TLV, then the device MUST send a...' RFC 2119 keyword, line 330: '... then the device MUST send a PKCS#10 t...' RFC 2119 keyword, line 396: '... the server MUST terminate the conne...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2018) is 2125 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: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-16 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 Intended status: Standards Track N. Cam-Winget 5 Expires: December 31, 2018 Cisco Systems 6 June 29, 2018 8 Bootstrapping Key Infrastructure over EAP 9 draft-lear-eap-teap-brski-00 11 Abstract 13 In certain environments, in order for a device to establish any layer 14 three communications, it is necessary for that device to be properly 15 credentialed. This is a relatively easy problem to solve when a 16 device is associated with a human being and has both input and 17 display functions. It is less easy when the human, input, and 18 display functions are not present. To address this case, this memo 19 specifies extensions to the Tunnel Extensible Authentication Protocol 20 (TEAP) method that leverages Bootstrapping Remote Secure Key 21 Infrastructures (BRSKI) in order to provide a credential to a device 22 at layer two. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 31, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. TEAP BRSKI Architecture . . . . . . . . . . . . . . . . . . . 3 61 3. BRSKI Bootstrap and Enroll Operation . . . . . . . . . . . . 4 62 3.1. Executing BRSKI in a TEAP Tunnel . . . . . . . . . . . . 5 63 4. PKI Certificate Authority Considerations . . . . . . . . . . 8 64 4.1. TEAP Tunnel Establishment . . . . . . . . . . . . . . . . 8 65 4.2. BRSKI Trust Establishment . . . . . . . . . . . . . . . . 9 66 5. Channel and Crypto Binding . . . . . . . . . . . . . . . . . 10 67 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.1. TEAP Server Grants Access . . . . . . . . . . . . . . . . 11 69 6.2. TEAP Server Instructs Client to Perform BRSKI Flow . . . 12 70 6.3. TEAP Server Instructs Client to Reenroll . . . . . . . . 13 71 6.4. Out of Band Reenroll . . . . . . . . . . . . . . . . . . 14 72 7. TEAP TLV Formats . . . . . . . . . . . . . . . . . . . . . . 15 73 7.1. BRSKI TLVs . . . . . . . . . . . . . . . . . . . . . . . 15 74 7.1.1. BRSKI-RequestVoucher TLV . . . . . . . . . . . . . . 15 75 7.1.2. BRSKI-Voucher TLV . . . . . . . . . . . . . . . . . . 15 76 7.1.3. BRSKI-VoucherStatus TLV . . . . . . . . . . . . . . . 15 77 7.1.4. EnrollmentStatus TLV . . . . . . . . . . . . . . . . 15 78 7.1.5. CSR-Attributes TLV . . . . . . . . . . . . . . . . . 15 79 7.2. Existing TEAP TLV Specifications . . . . . . . . . . . . 15 80 7.2.1. PKCS#10 TLV . . . . . . . . . . . . . . . . . . . . . 16 81 8. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 16 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 85 12. Informative References . . . . . . . . . . . . . . . . . . . 16 86 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 89 1. Introduction 91 [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) specifies a means to 92 provision credentials to be used as credentials to operationally 93 access networks. It was designed as a standalone means where some 94 limited access to an IP network is already available. This is not 95 always the case. For example, IEEE 802.11 networks generally require 96 authentication prior to any form of address assignment. While it is 97 possible to assign an IP address to a device on some form of an open 98 network, or to accept some sort of default credential to establish 99 initial IP connectivity, the steps that would then follow might well 100 require that the device is placed on a new network, requiring 101 reseting all layer three parameters. 103 A more natural approach in such cases is to more tightly bind the 104 provisioning of credentials with the authentication mechanism. One 105 such way to do this is to make use of the Extensible Authentication 106 Protocol (EAP) [RFC3748] and the Tunnel Extensible Authentication 107 Protocol (TEAP) method [RFC7170]. Thus we define new TEAP Type- 108 Length-Value (TLV) objects that can be used to transport the BRSKI 109 protocol messages within the context of a TEAP TLS tunnel. 111 [RFC7170] discusses the notion of provisioning peers. Several 112 different mechanisms are available. Section 3.8 of that document 113 acknowledges the concept of not initially authenticating the outer 114 TLS session so that provisioning may occur. In addition, exchange of 115 multiple TLV messages between client and EAP server permits multiple 116 provisioning steps. 118 1.1. Terminology 120 The reader is presumed to be familiar with EAP terminology as stated 121 in [RFC3748]. In addition, the following terms are commonly used in 122 this document. 124 o BRSKI: Bootstrapping Remote Secure Key Infrastructures, as defined 125 in [I-D.ietf-anima-bootstrapping-keyinfra]. The term is also used 126 to refer to the flow described in that document. 128 o EST: Enrollment over Secure Transport, as defined in [RFC7030]. 130 o voucher: a signed json object as defined in [RFC8366]. 132 2. TEAP BRSKI Architecture 134 The TEAP BRSKI architecture is illustrated in Section 3. The device 135 talks to the TEAP server via the Authenticator as per any normal EAP 136 exchange. There is no need for an inner EAP method server, and there 137 is no explicit EAP method type defined for BRSKI. 139 The architecture illustrated shows the TEAP server and Registrar 140 function as being two logically separate entities, however the BRSKI 141 Registrar functionality may be integrated into the TEAP server. The 142 device is not explicitly aware of where the Registrar functionality 143 is deployed when executing BRSKI inside a TEAP tunnel. Note that the 144 device may connect directly to the Registrar for the purposes of 145 certificate reenrollment, but this happens outside the context to 146 801.1X and TEAP authentication. 148 The Registrar in turn communicates with the BRSKI MASA service for 149 the purposes of getting signed vouchers. [[TODO: I guess we should 150 mention TEAP server talking to vendor default Registrar in the 151 cloud]] 153 The Registrar also comunicates with a Certificate Authority in order 154 to issue LDevIDs. The architecture shows the Registrar and CA as 155 being two logically separate entities, however the CA may be 156 integrated into the Registrar. The device is not explicitly aware of 157 whether the CA and Registrar functions are integrated. 159 +--------+ +---------+ +--------+ +---------+ +------+ 160 | | | | | | | |<--->| MASA | 161 | | | Authen- | | TEAP | | BRSKI | +------+ 162 | Device |<--->| ticator |<--->| server |<--->|Registrar| 163 | | | | | | | | +------+ 164 | | | | | | | |<--->| CA | 165 +--------+ +---------+ +--------+ +---------+ +------+ 167 3. BRSKI Bootstrap and Enroll Operation 169 This section summarises the current BRSKI operation. The BRSKI flow 170 assumes the device has an IDevID and has a manufacturer installed 171 trust anchor that can be used to validate the BRSKI voucher. The 172 BRSKI flow compromises serveral main steps from the perspective of 173 the device: 175 o Step 1: Device discovers the Registrar 177 o Step 2: Device establishes provisional TLS connection to Registrar 179 o Step 3: Device sends voucher request message and receives signed 180 voucher response 182 o Step 4: Device validates voucher and validates provisional TLS 183 connection to Registrar 185 o Step 5: Device sends Voucher Status Telemetry message 187 o Step 6: Device downloads additional local domain CA information 189 o Step 7: Device downloads Certificate Signing Reqeust (CSR) 190 attributes 192 o Step 8: Device does an EST enroll to obtain an LDevID 194 o Step 9: Device sends Enrollment Status Telemetry message 196 o Step 10: Device periodically reenrolls via EST to refresh its 197 LDevID 199 Most of the operational steps require the device, and thus its 200 internal state machine, to automatically complete the next step 201 without being explicitly instructed to do so by the Registrar. For 202 example, the Registrar does not explicitly tell the device to 203 download additional local domain CA information, or to do an EST 204 enroll to obtain an LDevID. 206 3.1. Executing BRSKI in a TEAP Tunnel 208 This section outlines how the main BRSKI steps outlined above map to 209 TEAP, and how BRSKI and enrollment can be accomplished inside a TEAP 210 TLS tunnel. The following new TEAP TLVs are introduced: 212 o BRSKI-VoucherRequest 214 o BRSKI-Voucher 216 o BRSKI-VoucherStatus 218 o EnrollmentStatus 220 o CSR-Attributes 222 The following steps outline how the above BRSKI flow maps to TEAP. 224 o Step 1: Device discovers the Registrar 226 When BRSKI is executed in a TEAP tunnel, the device exchanges BRSKI 227 TLVs with the TEAP server. The discovery process for devices is 228 therefore the standard wired or wireless LAN EAP server discovery 229 process. The discovery processes outlined in section 4 of 230 [I-D.ietf-anima-bootstrapping-keyinfra] are not required for initial 231 discovery of the Registrar. 233 o Step 2: Device establishes provisional TLS connection to Registrar 235 The device establishes an outer TEAP tunnel with the TEAP server and 236 does not validate the server certificate. The device presents its 237 LDevID as its identity certificate if it has a valid LDevID, 238 otherwise it presents its IDevID. Server policy may also be used to 239 control which certificate the device is allowed present, as described 240 in section Section 4. 242 If the presented credential is sufficient to grant access, the TEAP 243 server can return an EAP-Success immediately. The device may still 244 send a BRSKI-RequestVoucher TLV in response to the EAP-Success if it 245 does not have, but requires, trust anchors for validating the TEAP 246 server certificate. 248 If the TEAP server requires that the device execute a BRSKI flow, it 249 sends a Request-Action TLV that includes a BRSKI-VoucherRequest TLV. 250 For example, if the device presented its IDevID but the TEAP server 251 requires an LDevID. 253 The TEAP server may also require the device to reenroll, for example, 254 if the device presented a valid LDevID that is very closed to 255 expiration. The server may instruct a device to reenroll by sending 256 a Request-Action TLV that includes a zero byte length PKCS#10 TLV. 258 o Step 3: Device sends voucher request message and receives signed 259 voucher response 261 The device sends a BRSKI-RequestVoucher TLV to the TEAP server. The 262 TEAP server forwards the RequestVoucher message to the MASA server, 263 and the MASA server replies with a signed voucher. The TEAP server 264 sends a BRSKI-Voucher TLV to the device. 266 If the MASA server does not issue a signed voucher, the TEAP server 267 sends an EAP-Error TLV with a suitable error code to the device. 269 o Step 4: Device validates voucher and validates provisional TLS 270 connection to Registrar 272 The device validates the signed voucher using its manufacturer 273 installed trust anchor, and uses the CA information in the voucher to 274 validate the outer TEAP TLS connection to the TEAP server. 276 If the device fails to validate the voucher, or fails to validate the 277 outer TEAP TLS connection, then it sends a BRSKI-VoucherStatus TLV 278 indicating failure to the TEAP server. 280 o Step 5: Device sends Voucher Status Telemetry message 282 On successfully validating the voucher and outer TEAP TLS connection, 283 the device sends a BRSKI-VoucherStatus TLV to the TEAP server. 285 Once step 5 is complete, the device has completed the BRSKI flow and 286 has established trust with the network. 288 o Step 6: Device downloads additional local domain CA information 290 On completion of the BRSKI flow, the device SHOULD send a Trusted- 291 Server-Root TLV to the TEAP server in order to discover additional 292 local domain CAs. 294 o Step 7: Device downloads CSR attributes 296 On completion of step 6, the device MUST send a CSR-Attributes TLV to 297 the TEAP server in order to discover the correct fields to include 298 when it enrolls to get an LDevID. 300 o Step 8: Device does an EST enroll to obtain an LDevID 302 When executing the BRSKI flow inside a TEAP tunnel, the device does 303 not directly leverage EST when doing its initial enroll. Instead, 304 the device uses the existing TEAP PKCS#10 and PCKS#7 TEAP mechanisms. 306 Once the BRSKI flow is complete, the device can now send a PKCS#10 307 TLV to enroll and request an LDevID. If the TEAP server instructed 308 the device to start the BRSKI flow via a Request-Action TLV that 309 includes a BRSKI-RequestVoucher TLV, then the device MUST send a 310 PKCS#10 in order to start the enroll process. The TEAP server will 311 handle the PKCS#10 and ultimately return a PKCS#7 including an LDevID 312 to the device. 314 If the TEAP server granted the device access on completion of the 315 outer TEAP TLS tunnel in step 2 without sending a Request-Action TLV, 316 the device does not have to send a PKCS#10 to enroll. 318 o Step 9: Device sends Enrollment Status Telemetry message 320 On completion of certificate enrollment, the device sends an 321 EnrollmentStatus TLV to the TEAP server. 323 o Step 10: Device periodically reenrolls to refresh its LDevID 325 When a device's LDevID is close to expiration, there are two options 326 for re-enrollment in order to obtain a fresh LDevID. As outlined in 327 Step 2 above, the TEAP server may instruct the device to reenroll by 328 sending a Request-Action TLV including a PKCS#10 TLV. If the TEAP 329 server explicilty instructs the device to reenroll via these TLV 330 exchange, then the device MUST send a PKCS#10 to reenroll and request 331 a fresh LDevID. 333 However, the device should be capabale of autonomic reenrollment if 334 it determines that its LDevID is close to expiration wihtout waiting 335 for explicit instruction from the TEAP server. There are two options 336 to do this. 338 Option 1: The device reenrolls for a new LDevID directly with the EST 339 CA outside the context of the 802.1X TEAP authentication flow. The 340 device uses the Registrar discovery mechanisms oulined in 341 [I-D.ietf-anima-bootstrapping-keyinfra] to discover the Registrar and 342 the device sends the EST reenroll messages to the discovered 343 Registrar endpoint. No new TEAP TLVs are defined to facilitate 344 discover of the Registrar or EST endpoints inside the context of the 345 TEAP tunnel. 347 Option 2: When the device is perfroming a periodic 802.1X 348 authentication using its current LDevID, it reenrolls for a new 349 LDevID by sending a PKCS#10 TLV inside the TEAP TLS tunnel. 351 4. PKI Certificate Authority Considerations 353 Careful consideration must be given to PKI certificate authority 354 handling when: 356 o Establishing the TEAP tunnel 358 o Establishing trust using BRSKI 360 These are described in more detail here. 362 4.1. TEAP Tunnel Establishment 364 The client sends its ClientHello to initiate TLS tunnel 365 establishment. It is possible for the TEAP server to restrict the 366 certificates that the client can use for tunnel establishment by 367 including a list of CA distinguished names in the 368 certificate_authorities field in the CertificateRequest message. 369 Network operators may want to do this in order to restrict netwok 370 access to clients that have a certificate signed by one of a small 371 set of trusted manufacturer/supplier CAs. If the client has both an 372 IDevID and an LDevID, the client should present the LDevID in 373 preference to its IDevID if allowed by server policy. 375 In practice, network operators will likely want to onboard devices 376 from a large number of device manufacturers, with each manufacturer 377 using a different root CA when issuing IDevIDs. If the number of 378 different manufacturer root CAs is large, this could result in very 379 large TLS handshake messages. Operators may prefer to include no CAs 380 in the certificate_authorities field thus allowing devices to present 381 IDevIDs signed by any CA when establishing the TEAP tunnel, and 382 instead enforce policy at LDevID enrollment time. 384 It is recommended that the client validate the certificate presented 385 by the server in the server's Certificate message, but this may not 386 be possible for bootstrapping clients that do not have appropriate 387 trust anchors installed yet. If the client is bootstrapping and has 388 not yet completed a BRSKI flow, it will not have trust anchors 389 installed yet, and thus will not be able to validate the server's 390 certificate. The client must however note the certificate presented 391 by the server for (i) inclusion in the BRSKI-RequestVoucher TLV and 392 for (ii) validation once the client has discovered the local domain 393 trust anchors. 395 If the client does not present a suitable certificate to the server, 396 the server MUST terminate the connection and fail the EAP request. 398 On establishment of the outer TLS tunnel, the TEAP server will make a 399 policy decision on next steps. Possible policy decisions include: 401 o Option 1: Server grants client full network access and returns 402 EAP-Success. This will typically happen when the client presents 403 a valid LDevID. Network policy may grant client network access 404 based on IDevID without requiring the device to enroll to obtain 405 an LDevID. 407 o Option 2: Server requires that client perform a full BRSKI flow, 408 and then enroll to get an LDevID. This will typically happen when 409 the client presents a valid IDevID and network policy requires all 410 clients to have LDevIDs. The server sends a Request-Action TLV 411 that includes a BRSKI-RequestVoucher TLV to the client to instruct 412 it to start the BRSKI flow. 414 o Option 3: Server requires that the client reenroll to obtain a new 415 LDevID. This could happen when the client presents a valid LDevID 416 that is very close to expiration time, or the server's policy 417 requires an LDevID update. The server sends an Action-Request TLV 418 including a PKCS#10 TLV to the client to instruct it to reenroll. 420 4.2. BRSKI Trust Establishment 422 If the server requires that client perform a full BRSKI flow, it 423 sends a Request-Action TLV that includes a zero byte length BRSKI- 424 RequestVoucher TLV to the client. The client sends a new BRSKI- 425 RequestVoucher TLV to the server, which contains all data specified 426 in [I-D.ietf-anima-bootstrapping-keyinfra] section 5.2. The client 427 includes the server certificate it received in the server's 428 Certificate message during outer TLS tunnel establishment in the 429 proximity-registrar-cert field. The client signs the request using 430 its IDevID. 432 The server includes all additional information as required by 433 [I-D.ietf-anima-bootstrapping-keyinfra] section 5.4 and signs the 434 request prior to forwarding to the MASA. 436 The MASA responds as per [I-D.ietf-anima-bootstrapping-keyinfra] 437 section 5.5. The response may indicate failure and the server should 438 react accordingly to failures by sending a failure response to the 439 client, and failing the TEAP method. 441 If the MASA replies with a signed voucher and a successful result, 442 the server then forwards this response to the client in a BRSKI- 443 Voucher TLV. 445 When the client receives the signed voucher, it validates the 446 signature using its built in trust anchor list, and extracts the 447 pinned-domain-cert field. The client must use the CA included in the 448 pinned-domain-cert to validate the certificate that was presented by 449 the server when establishing the outer TLS tunnel. If this 450 certificate validation fails, the client must fail the TEAP request 451 and not connect to the network. 453 If the client successfully validates the server certificate, then it 454 must send voucher status telemetry, as required by 455 [I-D.ietf-anima-bootstrapping-keyinfra] section 5.6 to the server, in 456 a new BRSKI-VoucherTelemetry TLV. 458 5. Channel and Crypto Binding 460 As the TEAP BRSKI flow does not define or require an inner EAP 461 method, there is no explicit need for exchange of Channel-Binding 462 TLVs between the device and the TEAP server. 464 The TEAP BRSKI TLVs are expected to occur at the beginning of the 465 TEAP Phase 2 and MUST occur before the final Crypto-Binding TLV. 466 This draft does not exclude the possibility of having other EAP 467 methods occur following the TEAP BRSKI TLVs and as such, the Crypto- 468 Binding TLV process rules as defined in [RFC7170] apply. 470 6. Protocol Flows 472 This section outlines protocol flows that map to the 3 server policy 473 options described in section Section 4.1. The protocol flows 474 illustrate a TLS1.2 exchange. 476 [[TODO]] MISSING EAP Start/identity/Crypto binding, etc. Flows 477 illustrative, but not 100% accurate. 479 6.1. TEAP Server Grants Access 481 +--------+ +-------------+ +------+ 482 | Client | | TEAP-Server | | MASA | 483 +--------+ +-------------+ +------+ 484 | | | 485 | ClientHello | | 486 |------------------------>| | 487 | ServerHello, | | 488 | Certificate(1), | | 489 | ServerKeyExchange, | | 490 | CertificateRequest(2), | | 491 | ServerHelloDone, | | 492 |<------------------------| | 493 | Certificate(3), | | 494 | ClientKeyExchange, | | 495 | CertificateVerify, | | 496 | ChangeCipherSpec, | | 497 | Finished | | 498 |------------------------>| | 499 | ChangeCipherSpec, | | 500 | Finished | | 501 |<------------------------| | 502 | Crypto-Binding TLV | | 503 |<------------------------| | 504 | Crypto-Binding TLV | | 505 |------------------------>| | 506 | Result TLV | | 507 |<------------------------| | 508 | Result TLV | | 509 |------------------------>| | 510 | EAP-Success | | 511 |<------------------------| | 513 Figure 1: TEAP Server Grants Access 515 Notes: 517 (1) If the client has completed the BRSKI flow yet, it must validate 518 the Certificate received from the server. If the client has not yet 519 completed the BRSKI flow, then it provisionally accepts the server 520 Certificate and must validate it later once BRSKI is complete. 522 (2) The server may include certificate_authorities field in the 523 CertificateRequest message in order to restrict the identity 524 certificates that the device is allowed present. 526 (3) The device will present its LDevID, if it has one, in preference 527 to its IDevID, if allowed by server policy. 529 6.2. TEAP Server Instructs Client to Perform BRSKI Flow 531 +--------+ +-------------+ +------+ 532 | Client | | TEAP-Server | | MASA | 533 +--------+ +-------------+ +------+ 534 | | | 535 | ClientHello | | 536 |------------------------>| | 537 | ServerHello, etc.(1) | | 538 |<------------------------| | 539 | etc., Finished | | 540 |------------------------>| | 541 | etc., Finished | | 542 |<------------------------| | 543 | BRSKI-RequestAction(2) | | 544 |<------------------------| | 545 | BRSKI-RequestVoucher(3) | | 546 |------------------------>| RequestVoucher | 547 | |--------------->| 548 | | Voucher | 549 | BRSKI-Voucher(4) |<---------------| 550 |<------------------------| | 551 | BRSKI-VoucherStatus | | 552 |------------------------>| | 553 | Trusted-Server-Root | | 554 |------------------------>| | 555 | Trusted-Server-Root | | 556 |<------------------------| | 557 | CSR-Attributes | | 558 |------------------------>| | 559 | CSR-Attributes | | 560 |<------------------------| | 561 | PKCS#10 | | 562 |------------------------>| | 563 | PKCS#7 | | 564 |<------------------------| | 565 | EnrollmentStatus | | 566 |------------------------>| | 567 | Crypto-Binding TLV | | 568 |<------------------------| | 569 | Crypto-Binding TLV | | 570 |------------------------>| | 571 | Result TLV | | 572 |<------------------------| | 573 | Result TLV | | 574 |------------------------>| | 575 | EAP-Success | | 576 |<------------------------| | 578 Figure 2: TEAP Server Instructs Client to Perform BRSKI Flow 580 Notes: 582 (1) If the client has not yet completed the BRSKI flow, then it 583 provisionally accepts the server certificate and must validate it 584 later once BRSKI is complete. 586 (2) The server instructs the client to start the BRSKI flow by 587 sending a RequestAction TLV that includes a BRSKI-RequestVoucher TLV. 589 (3) The client includes the certificate it received from the server 590 in the RequestVoucher message. 592 (4) Once the client receives and validates the voucher signed by the 593 MASA, it must verify the certificate it previously received from the 594 server. 596 6.3. TEAP Server Instructs Client to Reenroll 597 +--------+ +-------------+ +------+ 598 | Client | | TEAP-Server | | MASA | 599 +--------+ +-------------+ +------+ 600 | | | 601 | ClientHello | | 602 |----------------------->| | 603 | ServerHello, etc. | | 604 |<-----------------------| | 605 | etc., Finished | | 606 |----------------------->| | 607 | etc., Finished | | 608 |<-----------------------| | 609 | RequestAction: PKCS#10 | | 610 |<-----------------------| | 611 | CSR-Attributes | | 612 |----------------------->| | 613 | CSR-Attributes | | 614 |<-----------------------| | 615 | PKCS#10 | | 616 |----------------------->| | 617 | PKCS#7 | | 618 |<-----------------------| | 619 | EnrollmentStatus | | 620 |----------------------->| | 621 | Crypto-Binding TLV | | 622 |<-----------------------| | 623 | Crypto-Binding TLV | | 624 |----------------------->| | 625 | Result TLV | | 626 |<-----------------------| | 627 | Result TLV | | 628 |----------------------->| | 629 | EAP-Success | | 630 |<-----------------------| | 632 Figure 3: TEAP Server Instructs Client to Reenroll 634 [[TODO: Hmm, as BRSKI mandates client requests CSR-Attributes, should 635 the server send a RequestAction and include two TLVs: one CSR- 636 Attributes and one PKCS#10 ? ]] 638 6.4. Out of Band Reenroll 640 This section shows how the device does a reenroll to refresh its 641 LDEvID directly against the Registrar outside the context of the TEAP 642 tunnel. 644 7. TEAP TLV Formats 646 7.1. BRSKI TLVs 648 BRSKI defines 6 new TEAP TLVs. The following table indicates whether 649 the TLVs can be included in Request messages from TEAP server to 650 device, or Response messages from device to TEAP server. 652 +------------------------+----------+ 653 | TLV | Message | 654 +------------------------+----------+ 655 | BRSKI-VoucherRequest | Response | 656 | BRSKI-Voucher | Request | 657 | BRSKI-VoucherStatus | Response | 658 | EnrollmentStatus | Response | 659 | CSR-Attributes | Response | 660 +------------------------+----------+ 662 These new TLVs are detailed in this section. 664 7.1.1. BRSKI-RequestVoucher TLV 666 To be completed. 668 7.1.2. BRSKI-Voucher TLV 670 To be completed. 672 7.1.3. BRSKI-VoucherStatus TLV 674 To be completed. 676 7.1.4. EnrollmentStatus TLV 678 To be completed. 680 7.1.5. CSR-Attributes TLV 682 To be completed. 684 7.2. Existing TEAP TLV Specifications 686 This section documents allowed usage of existing TEAP TLVs. The 687 definition of the TLV is not changed, however clarifications on 688 allowed values for the TLV fields is documented. 690 7.2.1. PKCS#10 TLV 692 [RFC7170] defines the PKCS#10 TLV as follows: 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 |M|R| TLV Type | Length | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | PKCS#10 Data... 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 702 [RFC7170] does not explicitly allow a Length value of zero. 704 A Length value of zero is allowed for this TLV when the TEAP server 705 sends a Request-Action TLV with a child PKCS#10 TLV to the client. 706 In this scenario, there is no PKCS#10 Data included in the TLV. 707 Clients MUST NOT send a zero length PKCS#10 TLV to the server. 709 8. Fragmentation 711 TLS is expected to provide fragmentation support. Thus EAP-TEAP- 712 BRSKI does not specifically provide any, as it is only expected to be 713 used as an inner method to TEAP. 715 9. IANA Considerations 717 TBD. 719 10. Security Considerations 721 There will be many. 723 11. Acknowledgments 725 The authors would like to thank Brian Weis for his assistance. 727 12. Informative References 729 [I-D.ietf-anima-bootstrapping-keyinfra] 730 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 731 S., and K. Watsen, "Bootstrapping Remote Secure Key 732 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 733 keyinfra-16 (work in progress), June 2018. 735 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 736 Levkowetz, Ed., "Extensible Authentication Protocol 737 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 738 . 740 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 741 "Enrollment over Secure Transport", RFC 7030, 742 DOI 10.17487/RFC7030, October 2013, 743 . 745 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 746 "Tunnel Extensible Authentication Protocol (TEAP) Version 747 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 748 . 750 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 751 "A Voucher Artifact for Bootstrapping Protocols", 752 RFC 8366, DOI 10.17487/RFC8366, May 2018, 753 . 755 Appendix A. Changes from Earlier Versions 757 Draft -00: 759 o Initial revision 761 Authors' Addresses 763 Eliot Lear 764 Cisco Systems 765 Richtistrasse 7 766 Wallisellen CH-8304 767 Switzerland 769 Phone: +41 44 878 9200 770 Email: lear@cisco.com 772 Owen Friel 773 Cisco Systems 774 170 W. Tasman Dr. 775 San Jose, CA 95134 776 United States 778 Email: ofriel@cisco.com 779 Nancy Cam-Winget 780 Cisco Systems 781 170 W. Tasman Dr. 782 San Jose, CA 95134 783 United States 785 Email: ncamwing@cisco.com