idnits 2.17.1 draft-lear-eap-teap-brski-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 281: '...flow, the device SHOULD send a Trusted...' RFC 2119 keyword, line 286: '...ion of step 5, server MUST send a CSR-...' RFC 2119 keyword, line 299: '...ucher TLV, then the device MUST send a...' RFC 2119 keyword, line 319: '... then the device MUST send a PKCS#10 t...' RFC 2119 keyword, line 322: '...ever, the device SHOULD reenroll if it...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2018) is 1988 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: April 21, 2019 Cisco Systems 6 October 18, 2018 8 Bootstrapping Key Infrastructure over EAP 9 draft-lear-eap-teap-brski-01 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. The basis of this work is that a manufacturer will 23 introduce the device and the local deployment through cryptographic 24 means. In this sense the same trust model as BRSKI is used. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 21, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. TEAP BRSKI Architecture . . . . . . . . . . . . . . . . . . . 3 63 3. BRSKI Bootstrap and Enroll Operation . . . . . . . . . . . . 4 64 3.1. Executing BRSKI in a TEAP Tunnel . . . . . . . . . . . . 5 65 4. PKI Certificate Authority Considerations . . . . . . . . . . 8 66 4.1. TEAP Tunnel Establishment . . . . . . . . . . . . . . . . 8 67 4.2. BRSKI Trust Establishment . . . . . . . . . . . . . . . . 9 68 5. Channel and Crypto Binding . . . . . . . . . . . . . . . . . 10 69 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 10 70 6.1. TEAP Server Grants Access . . . . . . . . . . . . . . . . 10 71 6.2. TEAP Server Instructs Client to Perform BRSKI Flow . . . 12 72 6.3. TEAP Server Instructs Client to Reenroll . . . . . . . . 13 73 6.4. Out of Band Reenroll . . . . . . . . . . . . . . . . . . 14 74 7. TEAP TLV Formats . . . . . . . . . . . . . . . . . . . . . . 14 75 7.1. BRSKI TLVs . . . . . . . . . . . . . . . . . . . . . . . 14 76 7.1.1. BRSKI-RequestVoucher TLV . . . . . . . . . . . . . . 15 77 7.1.2. BRSKI-Voucher TLV . . . . . . . . . . . . . . . . . . 16 78 7.1.3. CSR-Attributes TLV . . . . . . . . . . . . . . . . . 16 79 7.2. Existing TEAP TLV Specifications . . . . . . . . . . . . 17 80 7.2.1. PKCS#10 TLV . . . . . . . . . . . . . . . . . . . . . 17 81 8. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 17 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 85 12. Informative References . . . . . . . . . . . . . . . . . . . 18 86 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 downloads additional local domain CA information 187 o Step 6: Device downloads Certificate Signing Reqeust (CSR) 188 attributes 190 o Step 7: Device does an EST enroll to obtain an LDevID 191 o Step 8: Device periodically reenrolls via EST to refresh its 192 LDevID 194 Most of the operational steps require the device, and thus its 195 internal state machine, to automatically complete the next step 196 without being explicitly instructed to do so by the registrar. For 197 example, the registrar does not explicitly tell the device to 198 download additional local domain CA information, or to do an EST 199 enroll to obtain an LDevID. 201 3.1. Executing BRSKI in a TEAP Tunnel 203 This section outlines how the main BRSKI steps outlined above map to 204 TEAP, and how BRSKI and enrollment can be accomplished inside a TEAP 205 TLS tunnel. The following new TEAP TLVs are introduced: 207 o BRSKI-VoucherRequest 209 o BRSKI-Voucher 211 o CSR-Attributes 213 The following steps outline how the above BRSKI flow maps to TEAP. 215 o Step 1: Device discovers the registrar 217 When BRSKI is executed in a TEAP tunnel, the device exchanges BRSKI 218 TLVs with the TEAP server. The discovery process for devices is 219 therefore the standard wired or wireless LAN EAP server discovery 220 process. The discovery processes outlined in section 4 of 221 [I-D.ietf-anima-bootstrapping-keyinfra] are not required for initial 222 discovery of the registrar. 224 o Step 2: Device establishes provisional TLS connection to registrar 226 The device establishes an outer TEAP tunnel with the TEAP server and 227 does not validate the server certificate. Similarly, at this 228 provisioning stage, the server does not validate the certificate of 229 the device. The device presents its LDevID as its identity 230 certificate if it has a valid LDevID, otherwise it presents its 231 IDevID. Server policy may also be used to control which certificate 232 the device is allowed present, as described in section Section 4. 234 If the presented credential is sufficient to grant access, the TEAP 235 server can return an EAP-Success immediately. The device may still 236 send a BRSKI-RequestVoucher TLV in response to the EAP-Success if it 237 does not have, but requires, trust anchors for validating the TEAP 238 server certificate. 240 If the TEAP server requires that the device execute a BRSKI flow, it 241 sends a Request-Action TLV that includes a BRSKI-VoucherRequest TLV. 242 For example, if the device presented its IDevID but the TEAP server 243 requires an LDevID. 245 The TEAP server may also require the device to reenroll, for example, 246 if the device presented a valid LDevID that is very closed to 247 expiration. The server may instruct a device to reenroll by sending 248 a Request-Action TLV that includes a zero byte length PKCS#10 TLV. 250 o Step 3: Device sends voucher request message and receives signed 251 voucher response 253 The device sends a BRSKI-RequestVoucher TLV to the TEAP server. The 254 TEAP server forwards the RequestVoucher message to the MASA server, 255 and the MASA server replies with a signed voucher. The TEAP server 256 sends a BRSKI-Voucher TLV to the device. 258 If the MASA server does not issue a signed voucher, the TEAP server 259 sends an EAP-Error TLV with a suitable error code to the device. 261 For wireless devices in particular, it is important that the MASA 262 server only return a voucher for devices known to be associated with 263 a particular registrar. In this sense, success indicates that the 264 device is on the correct network, while failure indicates the device 265 should try to provision itself within wireless networks (e.g, go to 266 the next SSID). 268 o Step 4: Device validates voucher and validates provisional TLS 269 connection to registrar 271 The device validates the signed voucher using its manufacturer 272 installed trust anchor, and uses the CA information in the voucher to 273 validate the outer TEAP TLS connection to the TEAP server. 275 If the device fails to validate the voucher, or fails to validate the 276 outer TEAP TLS connection, then it sends a TEAP-Error TLV indicating 277 failure to the TEAP server. 279 o Step 5: Device downloads additional local domain CA information 281 On completion of the BRSKI flow, the device SHOULD send a Trusted- 282 Server-Root TLV to the TEAP server in order to discover additional 283 local domain CAs. 285 o Step 6: Device downloads CSR attributes 286 No later than the completion of step 5, server MUST send a CSR- 287 Attributes TLV to peer server in order to discover the correct fields 288 to include when it enrolls to get an LDevID. 290 o Step 7: Device does an EST enroll to obtain an LDevID 292 When executing the BRSKI flow inside a TEAP tunnel, the device does 293 not directly leverage EST when doing its initial enroll. Instead, 294 the device uses the existing TEAP PKCS#10 and PCKS#7 TEAP mechanisms. 296 Once the BRSKI flow is complete, the device can now send a PKCS#10 297 TLV to enroll and request an LDevID. If the TEAP server instructed 298 the device to start the BRSKI flow via a Request-Action TLV that 299 includes a BRSKI-RequestVoucher TLV, then the device MUST send a 300 PKCS#10 in order to start the enroll process. The TEAP server will 301 handle the PKCS#10 and ultimately return a PKCS#7 including an LDevID 302 to the device. 304 If the TEAP server granted the device access on completion of the 305 outer TEAP TLS tunnel in step 2 without sending a Request-Action TLV, 306 the device does not have to send a PKCS#10 to enroll. 308 At this point, the device is said to be provisioned for local network 309 access, and may authenticate in the future via 802.1X with its newly 310 acquired credentials. 312 o Step 8: Device periodically reenrolls to refresh its LDevID 314 When a device's LDevID is close to expiration, there are two options 315 for re-enrollment in order to obtain a fresh LDevID. As outlined in 316 Step 2 above, the TEAP server may instruct the device to reenroll by 317 sending a Request-Action TLV including a PKCS#10 TLV. If the TEAP 318 server explicilty instructs the device to reenroll via these TLV 319 exchange, then the device MUST send a PKCS#10 to reenroll and request 320 a fresh LDevID. 322 However, the device SHOULD reenroll if it determines that its LDevID 323 is close to expiration wihtout waiting for explicit instruction from 324 the TEAP server. There are two options to do this. 326 Option 1: The device reenrolls for a new LDevID directly with the EST 327 CA outside the context of the 802.1X TEAP flow. The device uses the 328 registrar discovery mechanisms oulined in 329 [I-D.ietf-anima-bootstrapping-keyinfra] to discover the registrar and 330 the device sends the EST reenroll messages to the discovered 331 registrar endpoint. No new TEAP TLVs are defined to facilitate 332 discover of the registrar or EST endpoints inside the context of the 333 TEAP tunnel. 335 Option 2: When the device is performing a periodic 802.1X 336 authentication using its current LDevID, it reenrolls for a new 337 LDevID by sending a PKCS#10 TLV inside the TEAP TLS tunnel. 339 4. PKI Certificate Authority Considerations 341 Careful consideration must be given to PKI certificate authority 342 handling when: 344 o Establishing the TEAP tunnel 346 o Establishing trust using BRSKI 348 These are described in more detail here. 350 4.1. TEAP Tunnel Establishment 352 The client sends its ClientHello to initiate TLS tunnel 353 establishment. It is possible for the TEAP server to restrict the 354 certificates that the client can use for tunnel establishment by 355 including a list of CA distinguished names in the 356 certificate_authorities field in the CertificateRequest message. 357 Network operators may want to do this in order to restrict netwok 358 access to clients that have a certificate signed by one of a small 359 set of trusted manufacturer/supplier CAs. If the client has both an 360 IDevID and an LDevID, the client should present the LDevID in 361 preference to its IDevID if allowed by server policy. 363 In practice, network operators will likely want to onboard devices 364 from a large number of device manufacturers, with each manufacturer 365 using a different root CA when issuing IDevIDs. If the number of 366 different manufacturer root CAs is large, this could result in very 367 large TLS handshake messages. Operators may prefer to include no CAs 368 in the certificate_authorities field thus allowing devices to present 369 IDevIDs signed by any CA when establishing the TEAP tunnel, and 370 instead enforce policy at LDevID enrollment time. 372 It is recommended that the client validate the certificate presented 373 by the server in the server's Certificate message, but this may not 374 be possible for clients that have not yet provisioned appropriate 375 trust anchors. If the client is in the provisioning phase and has 376 not yet completed a BRSKI flow, it will not have trust anchors 377 installed yet, and thus will not be able to validate the server's 378 certificate. The client must however note the certificate presented 379 by the server for (i) inclusion in the BRSKI-RequestVoucher TLV and 380 for (ii) validation once the client has discovered the local domain 381 trust anchors. 383 If the client does not present a suitable certificate to the server, 384 the server MUST terminate the connection and fail the EAP request. 386 On establishment of the outer TLS tunnel, the TEAP server will make a 387 policy decision on next steps. Possible policy decisions include: 389 o Option 1: Server grants client full network access and returns 390 EAP-Success. This will typically happen when the client presents 391 a valid LDevID. Network policy may grant client network access 392 based on IDevID without requiring the device to enroll to obtain 393 an LDevID. 395 o Option 2: Server requires that client perform a full BRSKI flow, 396 and then enroll to get an LDevID. This will typically happen when 397 the client presents a valid IDevID and network policy requires all 398 clients to have LDevIDs. The server sends a Request-Action TLV 399 that includes a BRSKI-RequestVoucher TLV to the client to instruct 400 it to start the BRSKI flow. 402 o Option 3: Server requires that the client reenroll to obtain a new 403 LDevID. This could happen when the client presents a valid LDevID 404 that is very close to expiration time, or the server's policy 405 requires an LDevID update. The server sends an Action-Request TLV 406 including a PKCS#10 TLV to the client to instruct it to reenroll. 408 4.2. BRSKI Trust Establishment 410 If the server requires that client perform a full BRSKI flow, it 411 sends a Request-Action TLV that includes a zero byte length BRSKI- 412 RequestVoucher TLV to the client. The client sends a new BRSKI- 413 RequestVoucher TLV to the server, which contains all data specified 414 in [I-D.ietf-anima-bootstrapping-keyinfra] section 5.2. The client 415 includes the server certificate it received in the server's 416 Certificate message during outer TLS tunnel establishment in the 417 proximity-registrar-cert field. The client signs the request using 418 its IDevID. 420 The server includes all additional information as required by 421 [I-D.ietf-anima-bootstrapping-keyinfra] section 5.4 and signs the 422 request prior to forwarding to the MASA. 424 The MASA responds as per [I-D.ietf-anima-bootstrapping-keyinfra] 425 section 5.5. The response may indicate failure and the server should 426 react accordingly to failures by sending a failure response to the 427 client, and failing the TEAP method. 429 If the MASA replies with a signed voucher and a successful result, 430 the server then forwards this response to the client in a BRSKI- 431 Voucher TLV. 433 When the client receives the signed voucher, it validates the 434 signature using its built in trust anchor list, and extracts the 435 pinned-domain-cert field. The client must use the CA included in the 436 pinned-domain-cert to validate the certificate that was presented by 437 the server when establishing the outer TLS tunnel. If this 438 certificate validation fails, the client must fail the TEAP request 439 and not connect to the network. 441 [TBD- based on client responses, the registrar sends a status update 442 to the MASA] 444 5. Channel and Crypto Binding 446 As the TEAP BRSKI flow does not define or require an inner EAP 447 method, there is no explicit need for exchange of Channel-Binding 448 TLVs between the device and the TEAP server. 450 The TEAP BRSKI TLVs are expected to occur at the beginning of the 451 TEAP Phase 2 and MUST occur before the final Crypto-Binding TLV. 452 This draft does not exclude the possibility of having other EAP 453 methods occur following the TEAP BRSKI TLVs and as such, the Crypto- 454 Binding TLV process rules as defined in [RFC7170] apply. 456 6. Protocol Flows 458 This section outlines protocol flows that map to the 3 server policy 459 options described in section Section 4.1. The protocol flows 460 illustrate a TLS1.2 exchange. 462 [[TODO]] MISSING EAP Start/identity/Crypto binding, etc. Flows 463 illustrative, but not 100% accurate. 465 6.1. TEAP Server Grants Access 466 +--------+ +-------------+ +------+ 467 | Client | | TEAP-Server | | MASA | 468 +--------+ +-------------+ +------+ 469 | | | 470 | ClientHello | | 471 |------------------------>| | 472 | ServerHello, | | 473 | Certificate(1), | | 474 | ServerKeyExchange, | | 475 | CertificateRequest(2), | | 476 | ServerHelloDone, | | 477 |<------------------------| | 478 | Certificate(3), | | 479 | ClientKeyExchange, | | 480 | CertificateVerify, | | 481 | ChangeCipherSpec, | | 482 | Finished | | 483 |------------------------>| | 484 | ChangeCipherSpec, | | 485 | Finished | | 486 |<------------------------| | 487 | Crypto-Binding TLV | | 488 |<------------------------| | 489 | Crypto-Binding TLV | | 490 |------------------------>| | 491 | Result TLV | | 492 |<------------------------| | 493 | Result TLV | | 494 |------------------------>| | 495 | EAP-Success | | 496 |<------------------------| | 498 Figure 1: TEAP Server Grants Access 500 Notes: 502 (1) If the client has completed the BRSKI flow yet, it must validate 503 the Certificate received from the server. If the client has not yet 504 completed the BRSKI flow, then it provisionally accepts the server 505 Certificate and must validate it later once BRSKI is complete. 507 (2) The server may include certificate_authorities field in the 508 CertificateRequest message in order to restrict the identity 509 certificates that the device is allowed present. 511 (3) The device will present its LDevID, if it has one, in preference 512 to its IDevID, if allowed by server policy. 514 6.2. TEAP Server Instructs Client to Perform BRSKI Flow 516 +--------+ +-------------+ +------+ 517 | Client | | TEAP-Server | | MASA | 518 +--------+ +-------------+ +------+ 519 | | | 520 | ClientHello | | 521 |------------------------>| | 522 | ServerHello, etc.(1) | | 523 |<------------------------| | 524 | etc., Finished | | 525 |------------------------>| | 526 | etc., Finished | | 527 |<------------------------| | 528 | BRSKI-RequestAction(2) | | 529 |<------------------------| | 530 | BRSKI-RequestVoucher(3) | | 531 |------------------------>| RequestVoucher | 532 | |--------------->| 533 | | Voucher | 534 | BRSKI-Voucher(4) |<---------------| 535 |<------------------------| | 536 | Trusted-Server-Root | | 537 |------------------------>| | 538 | Trusted-Server-Root | | 539 |<------------------------| | 540 | CSR-Attributes | | 541 |<------------------------| | 542 | PKCS#10 | | 543 |------------------------>| | 544 | PKCS#7 | | 545 |<------------------------| | 546 | Crypto-Binding TLV | | 547 |<------------------------| | 548 | Crypto-Binding TLV | | 549 |------------------------>| | 550 | Result TLV | | 551 |<------------------------| | 552 | Result TLV | | 553 |------------------------>| | 554 | EAP-Success | | 555 |<------------------------| | 557 Figure 2: TEAP Server Instructs Client to Perform BRSKI Flow 559 Notes: 561 (1) If the client has not yet completed the BRSKI flow, then it 562 provisionally accepts the server certificate and must validate it 563 later once BRSKI is complete. 565 (2) The server instructs the client to start the BRSKI flow by 566 sending a RequestAction TLV that includes a BRSKI-RequestVoucher TLV. 568 (3) The client includes the certificate it received from the server 569 in the RequestVoucher message. 571 (4) Once the client receives and validates the voucher signed by the 572 MASA, it must verify the certificate it previously received from the 573 server. 575 6.3. TEAP Server Instructs Client to Reenroll 576 +--------+ +-------------+ +------+ 577 | Client | | TEAP-Server | | MASA | 578 +--------+ +-------------+ +------+ 579 | | | 580 | ClientHello | | 581 |----------------------->| | 582 | ServerHello, etc. | | 583 |<-----------------------| | 584 | etc., Finished | | 585 |----------------------->| | 586 | etc., Finished | | 587 |<-----------------------| | 588 | RequestAction: PKCS#10 | | 589 |<-----------------------| | 590 | CSR-Attributes | | 591 |<-----------------------| | 592 | PKCS#10 | | 593 |----------------------->| | 594 | PKCS#7 | | 595 |<-----------------------| | 596 | Crypto-Binding TLV | | 597 |<-----------------------| | 598 | Crypto-Binding TLV | | 599 |----------------------->| | 600 | Result TLV | | 601 |<-----------------------| | 602 | Result TLV | | 603 |----------------------->| | 604 | EAP-Success | | 605 |<-----------------------| | 607 Figure 3: TEAP Server Instructs Client to Reenroll 609 6.4. Out of Band Reenroll 611 This section shows how the device does a reenroll to refresh its 612 LDEvID directly against the registrar outside the context of the TEAP 613 tunnel. 615 7. TEAP TLV Formats 617 7.1. BRSKI TLVs 619 BRSKI defines 3 new TEAP TLVs. The following table indicates whether 620 the TLVs can be included in Request messages from TEAP server to 621 device, or Response messages from device to TEAP server. 623 +------------------------+----------+ 624 | TLV | Message | 625 +------------------------+----------+ 626 | BRSKI-VoucherRequest | Response | 627 | BRSKI-Voucher | Request | 628 | CSR-Attributes | Response | 629 +------------------------+----------+ 631 These new TLVs are detailed in this section. 633 7.1.1. BRSKI-RequestVoucher TLV 635 This TLV is used by the server as part of an Action-Request to 636 request from the peer that it initiate a voucher request. When used 637 in this fashion, the length of this TLV will be set to zero. 639 It is also used by the peer to initiate the voucher request. When 640 used in this fashion, the length of the TLV will be set to that of 641 the voucher request, as encoded and described in Section 3.3 in 642 [I-D.ietf-anima-bootstrapping-keyinfra]. 644 0 1 2 3 645 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 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 |M|R| TLV=TBD1-VoucherRequest | Length | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Value... 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 The M and R bits are always expected to be set to 0. 654 The server is expected to forward the voucher request to the MASA, 655 and then return a voucher in a BRSKI-Voucher TLV as described below. 656 If it is unable to do so, it returns an TEAP Error TLV with one of 657 the defined errors or the following: 659 TBD2-MASA-Notavailable MASA unavailable 660 TBD3-MASA-Refused MASA refuses to sign the voucher 662 The peer terminates the TEAP connection, but may retry at some later 663 point. The backoff mechanism for such retries should be appropriate 664 for the device. Retries MUST occur no more frequently than once 665 every two (XXX) minutes. 667 7.1.2. BRSKI-Voucher TLV 669 This TLV is transmitted from the server to the peer. It contains a 670 signed voucher, as describe in [RFC8366]. 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 |M|R| TLV=TBD4-Voucher | Length | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Value... 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 Upon receiving this TLV the peer will validate the signature of the 681 voucher, using its pre-installed manufacturer trust anchor (LDevID). 682 It MUST also validate the certificate used by the server to establish 683 the TLS connection. 685 If successful, it installs the new trust anchor contained in the 686 voucher. 688 Otherwise, the peer transmits an TEAP error TLV with one of the 689 following error messages: 691 TBD5-Invalid-Signature The signature of the voucher signer is invalid 692 TBD6-Invalid-Voucher The form or content of the voucher is not valid 693 TBD7-Invalid-TLS-Signer The certificate used for the TLS connection 694 could not be validated. 696 7.1.3. CSR-Attributes TLV 698 The server SHALL transmit this TLV to the peer, either along with the 699 BRSKI-Voucher TLV or at any time earlier in a communication. The 700 peer shall include attributes required by the server in any following 701 CSR. The value of this TLV is the base64 encoding described in 702 Section 4.5.2 of [RFC7030]. 704 0 1 2 3 705 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 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 |M|R| TLV=TBD8-CSR-Attributes | length | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Value... 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 Again, the M and R values are set to 0. In the case where the client 713 is unable to provide the requested attributes, an TEAP-Error is 714 returned as follows: 716 TBD9-CSR-Attribute-Fail Unable to supply the requested attributes. 718 7.2. Existing TEAP TLV Specifications 720 This section documents allowed usage of existing TEAP TLVs. The 721 definition of the TLV is not changed, however clarifications on 722 allowed values for the TLV fields is documented. 724 7.2.1. PKCS#10 TLV 726 [RFC7170] defines the PKCS#10 TLV as follows: 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 |M|R| TLV Type | Length | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | PKCS#10 Data... 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 736 [RFC7170] does not explicitly allow a Length value of zero. 738 A Length value of zero is allowed for this TLV when the TEAP server 739 sends a Request-Action TLV with a child PKCS#10 TLV to the client. 740 In this scenario, there is no PKCS#10 Data included in the TLV. 741 Clients MUST NOT send a zero length PKCS#10 TLV to the server. 743 8. Fragmentation 745 TLS is expected to provide fragmentation support. Thus EAP-TEAP- 746 BRSKI does not specifically provide any, as it is only expected to be 747 used as an inner method to TEAP. 749 9. IANA Considerations 751 The IANA is requested to add entries into the following tables: 753 The following new TEAP TLVs are defined: 755 TBD1-VoucherRequest Described in this document. 756 TBD4-Voucher Described in this document. 757 TBD8-CSR-Attributes Described in this document. 759 The following TEAP Error Codes are defined, with their meanings 760 listed here and in previous sections: 762 TBD2-MASA-Notavailable MASA unavailable 763 TBD3-MASA-Refused MASA refuses to sign the voucher 764 TBD5-Invalid-Signature The signature of the voucher signer is invalid 765 TBD6-Invalid-Voucher The form or content of the voucher is not valid 766 TBD7-Invalid-TLS-Signer The certificate used for the TLS connection 767 could not be validated. 768 TBD9-CSR-Attribute-Fail Unable to supply the requested attributes. 770 10. Security Considerations 772 There will be many. 774 11. Acknowledgments 776 The authors would like to thank Brian Weis for his assistance, and 777 Alan Dakok for improving language consistency. 779 12. Informative References 781 [I-D.ietf-anima-bootstrapping-keyinfra] 782 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 783 S., and K. Watsen, "Bootstrapping Remote Secure Key 784 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 785 keyinfra-16 (work in progress), June 2018. 787 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 788 Levkowetz, Ed., "Extensible Authentication Protocol 789 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 790 . 792 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 793 "Enrollment over Secure Transport", RFC 7030, 794 DOI 10.17487/RFC7030, October 2013, 795 . 797 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 798 "Tunnel Extensible Authentication Protocol (TEAP) Version 799 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 800 . 802 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 803 "A Voucher Artifact for Bootstrapping Protocols", 804 RFC 8366, DOI 10.17487/RFC8366, May 2018, 805 . 807 Appendix A. Changes from Earlier Versions 809 Draft -01: * Add packet descriptions, IANA considerations, smooth out 810 language. 812 Draft -00: 814 o Initial revision 816 Authors' Addresses 818 Eliot Lear 819 Cisco Systems 820 Richtistrasse 7 821 Wallisellen CH-8304 822 Switzerland 824 Phone: +41 44 878 9200 825 Email: lear@cisco.com 827 Owen Friel 828 Cisco Systems 829 170 W. Tasman Dr. 830 San Jose, CA 95134 831 United States 833 Email: ofriel@cisco.com 835 Nancy Cam-Winget 836 Cisco Systems 837 170 W. Tasman Dr. 838 San Jose, CA 95134 839 United States 841 Email: ncamwing@cisco.com