idnits 2.17.1 draft-lear-eap-teap-brski-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 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 (February 22, 2019) is 1888 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-18 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: August 26, 2019 Cisco Systems 6 February 22, 2019 8 Bootstrapping Key Infrastructure over EAP 9 draft-lear-eap-teap-brski-02 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 August 26, 2019. 43 Copyright Notice 45 Copyright (c) 2019 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 . . . . . . . . 15 73 6.4. Out of Band Reenroll . . . . . . . . . . . . . . . . . . 17 74 7. TEAP TLV Formats . . . . . . . . . . . . . . . . . . . . . . 18 75 7.1. BRSKI TLVs . . . . . . . . . . . . . . . . . . . . . . . 18 76 7.1.1. BRSKI-RequestVoucher TLV . . . . . . . . . . . . . . 18 77 7.1.2. BRSKI-Voucher TLV . . . . . . . . . . . . . . . . . . 19 78 7.1.3. CSR-Attributes TLV . . . . . . . . . . . . . . . . . 19 79 7.2. Existing TEAP TLV Specifications . . . . . . . . . . . . 20 80 7.2.1. PKCS#10 TLV . . . . . . . . . . . . . . . . . . . . . 20 81 8. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 20 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 84 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 85 12. Informative References . . . . . . . . . . . . . . . . . . . 21 86 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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 Because this method establishes a client identity, and for purposes 353 of partioning of responsibility, the peer uses a generic identity 354 string of teap-brsk@TBD1 as its network access identifier (NAI). 356 The client sends its ClientHello to initiate TLS tunnel 357 establishment. It is possible for the TEAP server to restrict the 358 certificates that the client can use for tunnel establishment by 359 including a list of CA distinguished names in the 360 certificate_authorities field in the CertificateRequest message. 361 Network operators may want to do this in order to restrict netwok 362 access to clients that have a certificate signed by one of a small 363 set of trusted manufacturer/supplier CAs. If the client has both an 364 IDevID and an LDevID, the client should present the LDevID in 365 preference to its IDevID if allowed by server policy. 367 In practice, network operators will likely want to onboard devices 368 from a large number of device manufacturers, with each manufacturer 369 using a different root CA when issuing IDevIDs. If the number of 370 different manufacturer root CAs is large, this could result in very 371 large TLS handshake messages. Operators may prefer to include no CAs 372 in the certificate_authorities field thus allowing devices to present 373 IDevIDs signed by any CA when establishing the TEAP tunnel, and 374 instead enforce policy at LDevID enrollment time. 376 It is recommended that the client validate the certificate presented 377 by the server in the server's Certificate message, but this may not 378 be possible for clients that have not yet provisioned appropriate 379 trust anchors. If the client is in the provisioning phase and has 380 not yet completed a BRSKI flow, it will not have trust anchors 381 installed yet, and thus will not be able to validate the server's 382 certificate. The client must however note the certificate presented 383 by the server for (i) inclusion in the BRSKI-RequestVoucher TLV and 384 for (ii) validation once the client has discovered the local domain 385 trust anchors. 387 If the client does not present a suitable certificate to the server, 388 the server MUST terminate the connection and fail the EAP request. 390 On establishment of the outer TLS tunnel, the TEAP server will make a 391 policy decision on next steps. Possible policy decisions include: 393 o Option 1: Server grants client full network access and returns 394 EAP-Success. This will typically happen when the client presents 395 a valid LDevID. Network policy may grant client network access 396 based on IDevID without requiring the device to enroll to obtain 397 an LDevID. 399 o Option 2: Server requires that client perform a full BRSKI flow, 400 and then enroll to get an LDevID. This will typically happen when 401 the client presents a valid IDevID and network policy requires all 402 clients to have LDevIDs. The server sends a Request-Action TLV 403 that includes a BRSKI-RequestVoucher TLV to the client to instruct 404 it to start the BRSKI flow. 406 o Option 3: Server requires that the client reenroll to obtain a new 407 LDevID. This could happen when the client presents a valid LDevID 408 that is very close to expiration time, or the server's policy 409 requires an LDevID update. The server sends an Action-Request TLV 410 including a PKCS#10 TLV to the client to instruct it to reenroll. 412 4.2. BRSKI Trust Establishment 414 If the server requires that client perform a full BRSKI flow, it 415 sends a Request-Action TLV that includes a zero byte length BRSKI- 416 RequestVoucher TLV to the client. The client sends a new BRSKI- 417 RequestVoucher TLV to the server, which contains all data specified 418 in [I-D.ietf-anima-bootstrapping-keyinfra] section 5.2. The client 419 includes the server certificate it received in the server's 420 Certificate message during outer TLS tunnel establishment in the 421 proximity-registrar-cert field. The client signs the request using 422 its IDevID. 424 The server includes all additional information as required by 425 [I-D.ietf-anima-bootstrapping-keyinfra] section 5.4 and signs the 426 request prior to forwarding to the MASA. 428 The MASA responds as per [I-D.ietf-anima-bootstrapping-keyinfra] 429 section 5.5. The response may indicate failure and the server should 430 react accordingly to failures by sending a failure response to the 431 client, and failing the TEAP method. 433 If the MASA replies with a signed voucher and a successful result, 434 the server then forwards this response to the client in a BRSKI- 435 Voucher TLV. 437 When the client receives the signed voucher, it validates the 438 signature using its built in trust anchor list, and extracts the 439 pinned-domain-cert field. The client must use the CA included in the 440 pinned-domain-cert to validate the certificate that was presented by 441 the server when establishing the outer TLS tunnel. If this 442 certificate validation fails, the client must fail the TEAP request 443 and not connect to the network. 445 [TBD- based on client responses, the registrar sends a status update 446 to the MASA] 448 5. Channel and Crypto Binding 450 As the TEAP BRSKI flow does not define or require an inner EAP 451 method, there is no explicit need for exchange of Channel-Binding 452 TLVs between the device and the TEAP server. 454 The TEAP BRSKI TLVs are expected to occur at the beginning of the 455 TEAP Phase 2 and MUST occur before the final Crypto-Binding TLV. 456 This draft does not exclude the possibility of having other EAP 457 methods occur following the TEAP BRSKI TLVs and as such, the Crypto- 458 Binding TLV process rules as defined in [RFC7170] apply. 460 6. Protocol Flows 462 This section outlines protocol flows that map to the 3 server policy 463 options described in section Section 4.1. The protocol flows 464 illustrate a TLS1.2 exchange. Pertinent notes are outlined in the 465 protocol flows. 467 6.1. TEAP Server Grants Access 469 In this flow, the server grants access as server policy allows the 470 client to access the network based on the identity certificate that 471 the client presented. This means that either (i) the client has 472 previously completed BRSKI and has presented a valid LDevID or (ii) 473 the client presents an IDevID and network policy allows access based 474 purely on IDevID. 476 +--------+ +-------------+ +------+ 477 | Client | | TEAP-Server | | MASA | 478 +--------+ +-------------+ +------+ 479 | EAP-Request/ | | 480 | Type=Identity | | 481 |<------------------------| | 482 | | | 483 | EAP-Response/ | | 484 | Type=Identity | | 485 |------------------------>| | 486 | | | 487 | EAP-Request/ | | 488 | Type=TEAP, | | 489 | TEAP Start, | | 490 | Authority-ID TLV | | 491 |<------------------------| | 492 | | | 493 | EAP-Response/ | | 494 | Type=TEAP, | | 495 | TLS(ClientHello) | | 496 |------------------------>| | 497 | | | 498 | EAP-Request/ | | 499 | Type=TEAP, | | 500 | TLS(ServerHello, | | 501 (1)| Certificate, | | 502 | ServerKeyExchange, | | 503 (2)| CertificateRequest, | | 504 | ServerHelloDone) | | 505 |<------------------------| | 506 | | | 507 | EAP-Response/ | | 508 | Type=TEAP, | | 509 (3)| TLS(Certificate, | | 510 | ClientKeyExchange, | | 511 | CertificateVerify, | | 512 | ChangeCipherSpec, | | 513 | Finished) | | 514 |------------------------>| | 515 | | | 516 | EAP-Request/ | | 517 | Type=TEAP, | | 518 | TLS(ChangeCipherSpec, | | 519 | Finished), | | 520 | {Crypto-Binding TLV, | | 521 | Result TLV=Success} | | 522 |<------------------------| | 523 | | | 524 | EAP-Response/ | | 525 | Type=TEAP, | | 526 | {Crypto-Binding TLV, | | 527 | Result TLV=Success} | | 528 |------------------------>| | 529 | | | 530 | EAP-Success | | 531 |<------------------------| | 533 Figure 1: TEAP Server Grants Access 535 Notes: 537 (1) If the client has completed the BRSKI flow and has locally 538 significant trust anchors, it must validate the Certificate received 539 from the server. If the client has not yet completed the BRSKI flow, 540 then it provisionally accepts the server Certificate and must 541 validate it later once BRSKI is complete. 543 (2) The server may include certificate_authorities field in the 544 CertificateRequest message in order to restrict the identity 545 certificates that the device is allowed present. 547 (3) The device will present its LDevID, if it has one, in preference 548 to its IDevID, if allowed by server policy. 550 6.2. TEAP Server Instructs Client to Perform BRSKI Flow 552 In this flow, the server instructs the client to perform a BRSKI flow 553 by exchanging TLVs once the outer TLS tunnel is established. 555 +--------+ +-------------+ +------+ 556 | Client | | TEAP-Server | | MASA | 557 +--------+ +-------------+ +------+ 558 | EAP-Request/ | | 559 | Type=Identity | | 560 |<----------------------------| | 561 | | | 562 | EAP-Response/ | | 563 | Type=Identity | | 564 |---------------------------->| | 565 | | | 566 | EAP-Request/ | | 567 | Type=TEAP, | | 568 | TEAP Start, | | 569 | Authority-ID TLV | | 570 |<----------------------------| | 571 | | | 572 | EAP-Response/ | | 573 | Type=TEAP, | | 574 | TLS(ClientHello) | | 575 |---------------------------->| | 576 | | | 577 | EAP-Request/ | | 578 | Type=TEAP, | | 579 | TLS(ServerHello, | | 580 (1)| Certificate, | | 581 | ServerKeyExchange, | | 582 | CertificateRequest, | | 583 | ServerHelloDone) | | 584 |<----------------------------| | 585 | | | 586 | EAP-Response/ | | 587 | Type=TEAP, | | 588 | TLS(Certificate | | 589 | ClientKeyExchange, | | 590 | CertificateVerify, | | 591 | ChangeCipherSpec, | | 592 | Finished) | | 593 |---------------------------->| | 594 | | | 595 | EAP-Request/ | | 596 | Type=TEAP, | | 597 | TLS(ChangeCipherSpec, | | 598 | Finished), | | 599 | {Crypto-Binding TLV, | | 600 | Result TLV=Success} | | 601 |<----------------------------| | 602 | | | 603 | EAP-Response/ | | 604 | Type=TEAP, | | 605 | {Crypto-Binding TLV, | | 606 | Result TLV=Success} | | 607 |---------------------------->| | 608 | | | 609 ** At this stage the outer TLS tunnel is established ** 610 ** The following message exchanges are for BRSKI ** 611 | | | 612 | EAP-Request/ | | 613 | Type=TEAP, | | 614 (2)| {Request-Action TLV: | | 615 | Status=Failure, | | 616 | Action=Process-TLV, | | 617 | TLV=Request-Voucher, | | 618 | TLV=Trusted-Server-Root,| | 619 | TLV=CSR-Attributes, | | 620 | TLV=PKCS#10} | | 621 |<----------------------------| | 622 | | | 623 | EAP-Response/ | | 624 | Type=TEAP, | | 625 (3)| {Request-Voucher TLV} | | 626 |---------------------------->| RequestVoucher | 627 | |--------------->| 628 | | Voucher | 629 | |<---------------| 630 | EAP-Request/ | | 631 | Type=TEAP, | | 632 (4)| {Voucher TLV} | | 633 |<----------------------------| | 634 | | | 635 | EAP-Response/ | | 636 | Type=TEAP, | | 637 (5)| {Trusted-Server-Root TLV} | | 638 |---------------------------->| | 639 | | | 640 | EAP-Request/ | | 641 | Type=TEAP, | | 642 | {Trusted-Server-Root TLV} | | 643 |<----------------------------| | 644 | | | 645 | EAP-Response/ | | 646 | Type=TEAP, | | 647 | {CSR-Attributes TLV} | | 648 |---------------------------->| | 649 | | | 650 | EAP-Request/ | | 651 | Type=TEAP, | | 652 | {CSR-Attributes TLV} | | 653 |<----------------------------| | 654 | | | 655 | EAP-Response/ | | 656 | Type=TEAP, | | 657 | {PKCS#10 TLV} | | 658 |---------------------------->| | 659 | | | 660 | EAP-Request/ | | 661 | Type=TEAP, | | 662 | {PKCS#7 TLV, | | 663 (6)| Result TLV=Success} | | 664 |<----------------------------| | 665 | | | 666 | EAP-Response/ | | 667 | Type=TEAP, | | 668 | {Result TLV=Success} | | 669 |---------------------------->| | 670 | | | 671 | EAP-Success | | 672 |<----------------------------| | 674 Figure 2: TEAP Server Instructs Client to Perform BRSKI Flow 676 Notes: 678 (1) If the client has not yet completed the BRSKI flow, then it 679 provisionally accepts the server certificate and must validate it 680 later once BRSKI is complete. 682 (2) The server instructs the client to start the BRSKI flow by 683 sending a Request-Action TLV that includes a BRSKI-RequestVoucher 684 TLV. The server also instructs the client to request trust anchors, 685 to request CSR Attrites, and to initiate a PKCS certificate 686 enrolment. As outlined in [RFC7170], the Request-Action TLV is sent 687 after the Crypto-Binding TLV and Result TLV exchange. 689 (3) The client includes the certificate it received from the server 690 in the RequestVoucher message. 692 (4) Once the client receives and validates the voucher signed by the 693 MASA, it must verify the certificate it previously received from the 694 server. 696 (5) As outlined in [RFC7170], the Trusted-Server-Root TLV is 697 exchanged after the Crypto-Binding TLV exchange, and after the client 698 has used the Voucher to authenticate the TEAP server identity. 700 (6) There is not need for an additional Crypto-Binding TLV exchange 701 as there is no inner EAP method. All BRSKI exchanges are simply TLVs 702 exchanged inside the outer TLS tunnel. 704 6.3. TEAP Server Instructs Client to Reenroll 706 In this flow, the server instructs the client to reenroll and get a 707 new LDevID by exchanging TLVs once the outer TLS tunnel is 708 established. 710 +--------+ +-------------+ +------+ 711 | Client | | TEAP-Server | | MASA | 712 +--------+ +-------------+ +------+ 713 | EAP-Request/ | | 714 | Type=Identity | | 715 |<------------------------| | 716 | | | 717 | EAP-Response/ | | 718 | Type=Identity | | 719 |------------------------>| | 720 | | | 721 | EAP-Request/ | | 722 | Type=TEAP, | | 723 | TEAP Start, | | 724 | Authority-ID TLV | | 725 |<------------------------| | 726 | | | 727 | EAP-Response/ | | 728 | Type=TEAP, | | 729 | TLS(ClientHello) | | 730 |------------------------>| | 731 | | | 732 | EAP-Request/ | | 733 | Type=TEAP, | | 734 | TLS(ServerHello, | | 735 | Certificate, | | 736 | ServerKeyExchange, | | 737 | CertificateRequest, | | 738 | ServerHelloDone) | | 739 |<------------------------| | 740 | | | 741 | EAP-Response/ | | 742 | Type=TEAP, | | 743 | TLS(Certificate, | | 744 | ClientKeyExchange, | | 745 | CertificateVerify, | | 746 | ChangeCipherSpec, | | 747 | Finished) | | 748 |------------------------>| | 749 | | | 750 | EAP-Request/ | | 751 | Type=TEAP, | | 752 | TLS(ChangeCipherSpec, | | 753 | Finished), | | 754 | {Crypto-Binding TLV, | | 755 | Result TLV=Success} | | 756 |<------------------------| | 757 | | | 758 | EAP-Response/ | | 759 | Type=TEAP, | | 760 | {Crypto-Binding TLV, | | 761 | Result TLV=Success} | | 762 |------------------------>| | 763 | | | 764 | EAP-Request/ | | 765 | Type=TEAP, | | 766 (1)| {Request-Action TLV: | | 767 | Status=Failure, | | 768 | Action=Process-TLV, | | 769 | TLV=PKCS#10} | | 770 |<------------------------| | 771 | | | 772 | EAP-Response/ | | 773 | Type=TEAP, | | 774 | {PKCS#10 TLV} | | 775 |------------------------>| | 776 | | | 777 | EAP-Request/ | | 778 | Type=TEAP, | | 779 | {PKCS#7 TLV, | | 780 | Result TLV=Success} | | 781 |<------------------------| | 782 | | | 783 | EAP-Response/ | | 784 | Type=TEAP, | | 785 | {Result TLV=Success} | | 786 |------------------------>| | 787 | | | 788 | EAP-Success | | 789 |<------------------------| | 791 Figure 3: TEAP Server Instructs Client to Reenroll 793 (1) The server instructs the client to reenroll by sending a Request- 794 Action TLV that includes a PKCS#10 TLV. 796 6.4. Out of Band Reenroll 798 This section shows how the device does a reenroll to refresh its 799 LDEvID directly against the registrar outside the context of the TEAP 800 tunnel. 802 7. TEAP TLV Formats 804 7.1. BRSKI TLVs 806 BRSKI defines 3 new TEAP TLVs. The following table indicates whether 807 the TLVs can be included in Request messages from TEAP server to 808 device, or Response messages from device to TEAP server. 810 +------------------------+----------+ 811 | TLV | Message | 812 +------------------------+----------+ 813 | BRSKI-VoucherRequest | Response | 814 | BRSKI-Voucher | Request | 815 | CSR-Attributes | Response | 816 +------------------------+----------+ 818 These new TLVs are detailed in this section. 820 7.1.1. BRSKI-RequestVoucher TLV 822 This TLV is used by the server as part of an Action-Request to 823 request from the peer that it initiate a voucher request. When used 824 in this fashion, the length of this TLV will be set to zero. 826 It is also used by the peer to initiate the voucher request. When 827 used in this fashion, the length of the TLV will be set to that of 828 the voucher request, as encoded and described in Section 3.3 in 829 [I-D.ietf-anima-bootstrapping-keyinfra]. 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 |M|R| TLV=TBD1-VoucherRequest | Length | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Value... 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 The M and R bits are always expected to be set to 0. 841 The server is expected to forward the voucher request to the MASA, 842 and then return a voucher in a BRSKI-Voucher TLV as described below. 843 If it is unable to do so, it returns an TEAP Error TLV with one of 844 the defined errors or the following: 846 TBD2-MASA-Notavailable MASA unavailable 847 TBD3-MASA-Refused MASA refuses to sign the voucher 849 The peer terminates the TEAP connection, but may retry at some later 850 point. The backoff mechanism for such retries should be appropriate 851 for the device. Retries MUST occur no more frequently than once 852 every two (XXX) minutes. 854 7.1.2. BRSKI-Voucher TLV 856 This TLV is transmitted from the server to the peer. It contains a 857 signed voucher, as describe in [RFC8366]. 859 0 1 2 3 860 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 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 |M|R| TLV=TBD4-Voucher | Length | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Value... 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 Upon receiving this TLV the peer will validate the signature of the 868 voucher, using its pre-installed manufacturer trust anchor (LDevID). 869 It MUST also validate the certificate used by the server to establish 870 the TLS connection. 872 If successful, it installs the new trust anchor contained in the 873 voucher. 875 Otherwise, the peer transmits an TEAP error TLV with one of the 876 following error messages: 878 TBD5-Invalid-Signature The signature of the voucher signer is invalid 879 TBD6-Invalid-Voucher The form or content of the voucher is not valid 880 TBD7-Invalid-TLS-Signer The certificate used for the TLS connection 881 could not be validated. 883 7.1.3. CSR-Attributes TLV 885 The server SHALL transmit this TLV to the peer, either along with the 886 BRSKI-Voucher TLV or at any time earlier in a communication. The 887 peer shall include attributes required by the server in any following 888 CSR. The value of this TLV is the base64 encoding described in 889 Section 4.5.2 of [RFC7030]. 891 0 1 2 3 892 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 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 |M|R| TLV=TBD8-CSR-Attributes | length | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Value... 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 Again, the M and R values are set to 0. In the case where the client 900 is unable to provide the requested attributes, an TEAP-Error is 901 returned as follows: 903 TBD9-CSR-Attribute-Fail Unable to supply the requested attributes. 905 7.2. Existing TEAP TLV Specifications 907 This section documents allowed usage of existing TEAP TLVs. The 908 definition of the TLV is not changed, however clarifications on 909 allowed values for the TLV fields is documented. 911 7.2.1. PKCS#10 TLV 913 [RFC7170] defines the PKCS#10 TLV as follows: 915 0 1 2 3 916 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 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 918 |M|R| TLV Type | Length | 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | PKCS#10 Data... 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 923 [RFC7170] does not explicitly allow a Length value of zero. 925 A Length value of zero is allowed for this TLV when the TEAP server 926 sends a Request-Action TLV with a child PKCS#10 TLV to the client. 927 In this scenario, there is no PKCS#10 Data included in the TLV. 928 Clients MUST NOT send a zero length PKCS#10 TLV to the server. 930 8. Fragmentation 932 TLS is expected to provide fragmentation support. Thus EAP-TEAP- 933 BRSKI does not specifically provide any, as it is only expected to be 934 used as an inner method to TEAP. 936 9. IANA Considerations 938 The IANA is requested to add entries into the following tables: 940 The following new TEAP TLVs are defined: 942 TBD1-VoucherRequest Described in this document. 943 TBD4-Voucher Described in this document. 944 TBD8-CSR-Attributes Described in this document. 946 The following TEAP Error Codes are defined, with their meanings 947 listed here and in previous sections: 949 TBD2-MASA-Notavailable MASA unavailable 950 TBD3-MASA-Refused MASA refuses to sign the voucher 951 TBD5-Invalid-Signature The signature of the voucher signer is invalid 952 TBD6-Invalid-Voucher The form or content of the voucher is not valid 953 TBD7-Invalid-TLS-Signer The certificate used for the TLS connection 954 could not be validated. 955 TBD9-CSR-Attribute-Fail Unable to supply the requested attributes. 957 10. Security Considerations 959 There will be many. 961 11. Acknowledgments 963 The authors would like to thank Brian Weis for his assistance, and 964 Alan Dakok for improving language consistency. In addition, with 965 ruthlessly "borrowed" the concept around NAI handling from Tuomas 966 Aura and Mohit Sethi. 968 12. Informative References 970 [I-D.ietf-anima-bootstrapping-keyinfra] 971 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 972 S., and K. Watsen, "Bootstrapping Remote Secure Key 973 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 974 keyinfra-18 (work in progress), January 2019. 976 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 977 Levkowetz, Ed., "Extensible Authentication Protocol 978 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 979 . 981 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 982 "Enrollment over Secure Transport", RFC 7030, 983 DOI 10.17487/RFC7030, October 2013, 984 . 986 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 987 "Tunnel Extensible Authentication Protocol (TEAP) Version 988 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 989 . 991 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 992 "A Voucher Artifact for Bootstrapping Protocols", 993 RFC 8366, DOI 10.17487/RFC8366, May 2018, 994 . 996 Appendix A. Changes from Earlier Versions 998 Draft -01: * Add packet descriptions, IANA considerations, smooth out 999 language. 1001 Draft -00: 1003 o Initial revision 1005 Authors' Addresses 1007 Eliot Lear 1008 Cisco Systems 1009 Richtistrasse 7 1010 Wallisellen CH-8304 1011 Switzerland 1013 Phone: +41 44 878 9200 1014 Email: lear@cisco.com 1016 Owen Friel 1017 Cisco Systems 1018 170 W. Tasman Dr. 1019 San Jose, CA 95134 1020 United States 1022 Email: ofriel@cisco.com 1023 Nancy Cam-Winget 1024 Cisco Systems 1025 170 W. Tasman Dr. 1026 San Jose, CA 95134 1027 United States 1029 Email: ncamwing@cisco.com