idnits 2.17.1 draft-lear-eap-teap-brski-03.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 153: '...two functions co-located, they MUST be...' RFC 2119 keyword, line 336: '...flow, the device SHOULD send a Trusted...' RFC 2119 keyword, line 343: '...ion of step 5, server MUST send a CSR-...' RFC 2119 keyword, line 356: '...ucher TLV, then the device MUST send a...' RFC 2119 keyword, line 376: '... then the device MUST send a PKCS#10 t...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 05, 2019) is 1757 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-22 -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021AR' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE8021X' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Lear 3 Internet-Draft O. Friel 4 Intended status: Standards Track N. Cam-Winget 5 Expires: January 6, 2020 Cisco Systems 6 D. Harkins 7 HP Enterprise 8 July 05, 2019 10 Bootstrapping Key Infrastructure over EAP 11 draft-lear-eap-teap-brski-03 13 Abstract 15 In certain environments, in order for a device to establish any layer 16 three communications, it is necessary for that device to be properly 17 credentialed. This is a relatively easy problem to solve when a 18 device is associated with a human being and has both input and 19 display functions. It is less easy when the human, input, and 20 display functions are not present. To address this case, this memo 21 specifies extensions to the Tunnel Extensible Authentication Protocol 22 (TEAP) method that leverages Bootstrapping Remote Secure Key 23 Infrastructures (BRSKI) in order to provide a credential to a device 24 at layer two. The basis of this work is that a manufacturer will 25 introduce the device and the local deployment through cryptographic 26 means. In this sense the same trust model as BRSKI is used. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 6, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. TEAP BRSKI Architecture . . . . . . . . . . . . . . . . . . . 4 65 3. BRSKI Bootstrap and Enroll Operation . . . . . . . . . . . . 4 66 3.1. Discovery of Trusted MASA . . . . . . . . . . . . . . . . 5 67 3.2. Executing BRSKI in a TEAP Tunnel . . . . . . . . . . . . 5 68 4. PKI Certificate Considerations . . . . . . . . . . . . . . . 9 69 4.1. TEAP Tunnel Establishment . . . . . . . . . . . . . . . . 9 70 4.2. BRSKI Trust Establishment . . . . . . . . . . . . . . . . 11 71 4.3. Certificate Expiration Times . . . . . . . . . . . . . . 12 72 5. Channel and Crypto Binding . . . . . . . . . . . . . . . . . 12 73 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 12 74 6.1. TEAP Server Grants Access . . . . . . . . . . . . . . . . 13 75 6.2. TEAP Server Instructs Client to Perform BRSKI Flow . . . 14 76 6.3. TEAP Server Instructs Client to Reenroll . . . . . . . . 18 77 6.4. Out of Band Reenroll . . . . . . . . . . . . . . . . . . 20 78 7. TEAP TLV Formats . . . . . . . . . . . . . . . . . . . . . . 20 79 7.1. BRSKI TLVs . . . . . . . . . . . . . . . . . . . . . . . 20 80 7.1.1. BRSKI-RequestVoucher TLV . . . . . . . . . . . . . . 20 81 7.1.2. BRSKI-Voucher TLV . . . . . . . . . . . . . . . . . . 21 82 7.1.3. CSR-Attributes TLV . . . . . . . . . . . . . . . . . 22 83 7.2. Existing TEAP TLV Specifications . . . . . . . . . . . . 22 84 7.2.1. PKCS#10 TLV . . . . . . . . . . . . . . . . . . . . . 22 85 7.3. TLV Rules . . . . . . . . . . . . . . . . . . . . . . . . 23 86 8. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 23 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 89 10.1. Issues with Provisionally Authenticated TEAP . . . . . . 24 90 10.2. Attack Against Discovery . . . . . . . . . . . . . . . . 25 91 10.3. TEAP Server as Registration Authority . . . . . . . . . 25 92 10.4. Trust of Registrar . . . . . . . . . . . . . . . . . . . 26 94 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 95 12. Normative References . . . . . . . . . . . . . . . . . . . . 26 96 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 27 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 99 1. Introduction 101 [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) specifies a means to 102 provision credentials to be used as credentials to operationally 103 access networks. It was designed as a standalone means where some 104 limited access to an IP network is already available. This is not 105 always the case. For example, IEEE 802.11 networks generally require 106 authentication prior to any form of address assignment. While it is 107 possible to assign an IP address to a device on some form of an open 108 network, or to accept some sort of default credential to establish 109 initial IP connectivity, the steps that would then follow might well 110 require that the device is placed on a new network, requiring 111 reseting all layer three parameters. 113 A more natural approach in such cases is to more tightly bind the 114 provisioning of credentials with the authentication mechanism. One 115 such way to do this is to make use of the Extensible Authentication 116 Protocol (EAP) [RFC3748] and the Tunnel Extensible Authentication 117 Protocol (TEAP) method [RFC7170]. Thus we define new TEAP Type- 118 Length-Value (TLV) objects that can be used to transport the BRSKI 119 protocol messages within the context of a TEAP TLS tunnel. 121 [RFC7170] discusses the notion of provisioning peers. Several 122 different mechanisms are available. Section 3.8 of that document 123 acknowledges the concept of not initially authenticating the outer 124 TLS session so that provisioning may occur. In addition, exchange of 125 multiple TLV messages between client and EAP server permits multiple 126 provisioning steps. 128 1.1. Terminology 130 The reader is presumed to be familiar with EAP terminology as stated 131 in [RFC3748]. In addition, the following terms are commonly used in 132 this document. 134 o BRSKI: Bootstrapping Remote Secure Key Infrastructures, as defined 135 in [I-D.ietf-anima-bootstrapping-keyinfra]. The term is also used 136 to refer to the flow described in that document. 138 o EST: Enrollment over Secure Transport, as defined in [RFC7030]. 140 o Voucher: a signed JSON object as defined in [RFC8366]. 142 2. TEAP BRSKI Architecture 144 The TEAP BRSKI architecture is illustrated in Section 3. The device 145 talks to the TEAP server via the Authenticator using any compliant 146 transport such as [IEEE8021X]. The architecture illustrated shows an 147 Authenticator distinct from the TEAP server. This is a deployment 148 optimization and when so deployed the communication between 149 Authenticator and TEAP server is a AAA protocol such as RADIUS or 150 DIAMETER. 152 The architecture illustrated shows a co-located TEAP server and BRSKI 153 registrar. Not only are these two functions co-located, they MUST be 154 the same entity. This ensures that the entity identified in the 155 device's voucher request (the TEAP server) is the same entity that 156 signs the voucher request (the registrar). 158 The registrar communicates with the BRSKI MASA service for the 159 purposes of getting signed vouchers. 161 The registrar also communicates with a Certificate Authority in order 162 to issue LDevIDs. The architecture shows the registrar and CA as 163 being two logically separate entities, however the CA may be 164 integrated into the registrar. The device is not explicitly aware of 165 whether the CA and registrar functions are integrated. 167 +--------+ +---------+ +---------+ +------+ 168 | | | | | TEAP |<--->| MASA | 169 | | | Authen- | | server | +------+ 170 | Device |<--->| ticator |<--->| | 171 | | | | | BRSKI | +------+ 172 | | | | |Registrar|<--->| CA | 173 +--------+ +---------+ +---------+ +------+ 175 3. BRSKI Bootstrap and Enroll Operation 177 This section summarises the current BRSKI operation. The BRSKI flow 178 assumes the device has an IDevID and has a manufacturer installed 179 trust anchor that can be used to validate the BRSKI voucher. The 180 BRSKI flow compromises serveral main steps from the perspective of 181 the device: 183 o Step 1: Device discovers the registrar 185 o Step 2: Device establishes provisional TLS connection to registrar 187 o Step 3: Device sends voucher request message and receives signed 188 voucher response 190 o Step 4: Device validates voucher and validates provisional TLS 191 connection to registrar 193 o Step 5: Device downloads additional local domain CA information 195 o Step 6: Device downloads Certificate Signing Request (CSR) 196 attributes 198 o Step 7: Device does a certificate enroll to obtain an LDevID 200 o Step 8: Device periodically reenrolls via EST to refresh its 201 LDevID 203 Most of the operational steps require the device, and thus its 204 internal state machine, to automatically complete the next step 205 without being explicitly instructed to do so by the registrar. For 206 example, the registrar does not explicitly tell the device to 207 download additional local domain CA information, or to do an EST 208 enroll to obtain an LDevID. 210 3.1. Discovery of Trusted MASA 212 BRSKI section 2.8 outlines how the Registrar discovers the correct 213 MASA to connect with. BRSKI section 5.3 outlines how the Registrar 214 can make policy decisions about which devices to trust. 216 Similar approaches are applicable for TEAP servers executing BRSKI. 217 For example, the TEAP server may be configured with a list of trusted 218 manufacturing CAs. During device bootstrap, only devices with an 219 IDevID signed by a trusted manufacturing CA may be allowed to 220 etablishes a TLS connection with the TEAP server, and the TEAP server 221 could then extract the MASA URI from the device's IDevID. 223 3.2. Executing BRSKI in a TEAP Tunnel 225 This section outlines how the main BRSKI steps outlined above map to 226 TEAP, and how BRSKI and enrollment can be accomplished inside a TEAP 227 TLS tunnel. The following new TEAP TLVs are introduced: 229 o BRSKI-VoucherRequest 231 o BRSKI-Voucher 233 o CSR-Attributes 235 The following steps outline how the above BRSKI flow maps to TEAP. 237 o Step 1: Device discovers the registrar 238 When BRSKI is executed in a TEAP tunnel, the device exchanges BRSKI 239 TLVs with the TEAP server. The discovery process for devices is 240 therefore the standard wired or wireless LAN EAP server discovery 241 process. The discovery processes outlined in section 4 of 242 [I-D.ietf-anima-bootstrapping-keyinfra] are not required for initial 243 discovery of the registrar. 245 o Step 2: Device establishes provisional TLS connection to registrar 247 The device establishes an outer TEAP tunnel with the TEAP server and 248 does not validate the server certificate. The device presents its 249 LDevID as its identity certificate if it has a valid LDevID, 250 otherwise it presents its IDevID. The TEAP server validates the 251 device's certificate using its implicit or explicit trust anchor 252 database. If the device presents an IDevID it is verified against a 253 database of trusted manufacturer certificates. Server policy may 254 also be used to control which certificate the device is allowed 255 present, as described in section {pki-certificate-authority- 256 considerations}. 258 If the presented credential is sufficient to grant access, the TEAP 259 server can return a TEAP Result TLV indicating success immediately. 260 The device may still send a Request-Action TLV including a BRSKI- 261 VoucherRequest TLV in response to the TEAP Result TLV if it does not 262 have, but requires, provisioning of trust anchors for validating the 263 TEAP server certificate. Note that no inner EAP method is required 264 for this, only an exchange of TEAP TLVs. 266 [todo] Question: as the device wants the server to reply with a 267 BRSKI-Voucher TLV, does it really send a Request-Action TLV 268 containing a BRSKI-VoucherRequest TLV, or does it send a Request- 269 Action TLV containing a BRSKI-Voucher TLV?? The TEAP draft is a bit 270 ambiguous here. Normally, if one end sends a Request-Action 271 including XXX-TLV, it means it wants the far end ot send an XXX- 272 TLV... 274 [todo] Question: general TEAP protocol question: does the device have 275 to send a Request-Action w/BRSKI-VoucherRequest or can it send a 276 BRSKI-VoucherRequest on its own? I'm not clear on this. 278 If the TEAP server requires that the device execute a BRSKI flow, the 279 server sends a Request-Action TLV that includes a BRSKI- 280 VoucherRequest TLV. For example, if the device presented its IDevID 281 but the TEAP server requires an LDevID. 283 [todo] Question: to nit pick, the server should send a Request-Action 284 TLV including a PKCS#10 TLV to tell the client to enroll. How does 285 the server really know that the client has the correct trust 286 established (as previously received by a BRSKI-Voucher)? If the 287 client sends an IDevID, does server always send a Request-Action 288 including both BRSKI-VoucherRequest and PKCS#10 TLVs? Whats the 289 client behaviour? I assume client can spontaneously send BRSKI- 290 VoucherRequest and/or PCSK#10 without being explicitly instructed to. 291 Just need to get the language correct here. 293 The TEAP server may also require the device to reenroll, for example, 294 if the device presented a valid LDevID that is very closed to 295 expiration. The server may instruct a device to reenroll by sending 296 a Request-Action TLV that includes a zero byte length PKCS#10 TLV. 298 o Step 3: Device sends voucher request message and receives signed 299 voucher response 301 The device sends a BRSKI-RequestVoucher TLV to the TEAP server. The 302 TEAP server forwards the RequestVoucher message to the MASA server, 303 and the MASA server replies with a signed voucher. The TEAP server 304 sends a BRSKI-Voucher TLV to the device. 306 If the MASA server does not issue a signed voucher, the TEAP server 307 sends an EAP-Error TLV with a suitable error code to the device. 309 For wireless devices in particular, it is important that the MASA 310 server only return a voucher for devices known to be associated with 311 a particular registrar. In this sense, success indicates that the 312 device is on the correct network, while failure indicates the device 313 should try to provision itself within wireless networks (e.g, go to 314 the next SSID). 316 o Step 4: Device validates voucher and validates provisional TLS 317 connection to registrar 319 The device validates the signed voucher using its manufacturer 320 installed trust anchor, and uses the CA information in the voucher to 321 validate the TLS connection to the TEAP server. 323 If the device fails to validate the voucher, then it sends a TEAP- 324 Error TLV indicating failiure to the TEAP server. 326 Similarly, if the device validates the voucher, but fails to validate 327 the provisional TLS connection, then it sends a TEAP-Error TLV 328 indicating failure to the TEAP server. Note that the outer TLS 329 tunnel has already been established, thus allowing the client to send 330 a TEAP-Error TLV to the server inside that tunnel to indicate that it 331 failed to verify the provisionally accepted outer TLS tunnel server 332 identity. 334 o Step 5: Device downloads additional local domain CA information 336 On completion of the BRSKI flow, the device SHOULD send a Trusted- 337 Server-Root TLV to the TEAP server in order to discover additional 338 local domain CAs. This is equivalent to section [todo] from 339 [I-D.ietf-anima-bootstrapping-keyinfra]. 341 o Step 6: Device downloads CSR attributes 343 No later than the completion of step 5, server MUST send a CSR- 344 Attributes TLV to peer server in order to discover the correct fields 345 to include when it enrolls to get an LDevID. 347 o Step 7: Device does a certificate enroll to obtain an LDevID 349 When executing the BRSKI flow inside a TEAP tunnel, the device does 350 not directly leverage EST when doing its initial enroll. Instead, 351 the device uses the existing TEAP PKCS#10 and PCKS#7 TEAP mechanisms. 353 Once the BRSKI flow is complete, the device can now send a PKCS#10 354 TLV to enroll and request an LDevID. If the TEAP server instructed 355 the device to start the BRSKI flow via a Request-Action TLV that 356 includes a BRSKI-RequestVoucher TLV, then the device MUST send a 357 PKCS#10 in order to start the enroll process. The TEAP server will 358 handle the PKCS#10 and ultimately return a PKCS#7 including an LDevID 359 to the device. 361 If the TEAP server granted the device access on completion of the 362 outer TEAP TLS tunnel in step 2 without sending a Request-Action TLV, 363 the device does not have to send a PKCS#10 to enroll. 365 At this point, the device is said to be provisioned for local network 366 access, and may authenticate in the future via 802.1X with its newly 367 acquired credentials. 369 o Step 8: Device periodically reenrolls to refresh its LDevID 371 When a device's LDevID is close to expiration, there are two options 372 for re-enrollment in order to obtain a fresh LDevID. As outlined in 373 Step 2 above, the TEAP server may instruct the device to reenroll by 374 sending a Request-Action TLV including a PKCS#10 TLV. If the TEAP 375 server explicilty instructs the device to reenroll via these TLV 376 exchange, then the device MUST send a PKCS#10 to reenroll and request 377 a fresh LDevID. 379 However, the device SHOULD reenroll if it determines that its LDevID 380 is close to expiration without waiting for explicit instruction from 381 the TEAP server. There are two options to do this. 383 Option 1: The device reenrolls for a new LDevID directly with the EST 384 CA outside the context of the 802.1X TEAP flow. The device uses the 385 registrar discovery mechanisms oulined in 386 [I-D.ietf-anima-bootstrapping-keyinfra] to discover the registrar and 387 the device sends the EST reenroll messages to the discovered 388 registrar endpoint. No new TEAP TLVs are defined to facilitate 389 discover of the registrar or EST endpoints inside the context of the 390 TEAP tunnel. 392 Option 2: When the device is performing a periodic 802.1X 393 authentication using its current LDevID, it reenrolls for a new 394 LDevID by sending a PKCS#10 TLV inside the TEAP TLS tunnel. 396 4. PKI Certificate Considerations 398 Careful consideration must be given to PKI certificate authority 399 handling when: 401 o Establishing the TEAP tunnel 403 o Establishing trust using BRSKI 405 Additionally, consideration must be given to IDevID and LDevID 406 expiration times. 408 These are described in more detail here. 410 4.1. TEAP Tunnel Establishment 412 Because this method establishes a client identity, and for purposes 413 of partioning of responsibility, the peer uses a generic identity 414 string of teap-brsk@TBD1 as its network access identifier (NAI). 416 BRSKI section 5.3 outlines the policy decisions a Registrar may make 417 when deciding whether to accept connections from clients. Similarly, 418 the TEAP server operator may configure a set of trusted CAs for 419 validating incoming TLS connections from clients. The operator may 420 want to 'allow any device from a specific vendor', or from a set of 421 vendors, to access the network. Network operators may do this by 422 restricting network access to clients that have a certificate signed 423 by one of a small set of trusted manufacturer/supplier CAs. 425 When the client sends its ClientHello to initiate TLS tunnel 426 establishment, it is possible for the TEAP server to restrict the 427 certificates that the client can use for tunnel establishment by 428 including a list of CA distinguished names in the 429 certificate_authorities field in the CertificateRequest message. The 430 client should only continue with the handshake if it has a 431 certificate signed by one of the indicated CAs. 433 In practice, network operators will likely want to onboard devices 434 from a large number of device manufacturers, with each manufacturer 435 using a different root CA when issuing IDevIDs. If the number of 436 different manufacturer root CAs is large, this could result in very 437 large TLS handshake messages. Therefore, the TEAP server may send a 438 CertificateRequest message and not specify any 439 certificate_authorities, thus allowing the client present a 440 certificate signed by any authority in its Certificate message. 442 If the client has both an IDevID and an LDevID, the client should 443 present the LDevID in preference to its IDevID, if allowed by server 444 policy. 446 Once the client has sent its TLS Finished message, the TEAP server 447 can make a policy decision, based on the CA used to sign the client's 448 certificate, on whether to establish the outer TLS tunnel or not. 450 The TEAP server may delegate policy decisions to the MASA or CA 451 function. For example, the TEAP server may declare EAP success and 452 grant network access if the client presents a valid LDevID signed by 453 a trusted domain CA. However, if the client presents an IDevID 454 signed by a trusted manufacturer CA, the TEAP server may establish 455 the TLS tunnel but not declare EAP success and grant network access 456 until the client successfully completes a BRSKI Voucher exchange and 457 PKCS#10/PKCS#7 exchange inside that tunnel. 459 It is recommended that the client validate the certificate presented 460 by the server in the server's Certificate message, but this may not 461 be possible for clients that have not yet provisioned appropriate 462 trust anchors. If the client is in the provisioning phase and has 463 not yet completed a BRSKI flow, it will not have trust anchors 464 installed yet, and thus will not be able to validate the server's 465 certificate. The client must however note the certificate presented 466 by the server for (i) inclusion in the BRSKI-RequestVoucher TLV and 467 for (ii) validation once the client has discovered the local domain 468 trust anchors. 470 If the client does not present a suitable certificate to the server, 471 the server MUST terminate the connection and fail the EAP request. 472 If the TEAP server is unable to validate the client's certificate 473 using its implicit or explicit trust anchor database it MUST fail the 474 EAP request. 476 On establishment of the outer TLS tunnel, the TEAP server will make a 477 policy decision on next steps. Possible policy decisions include: 479 o Option 1: Server grants client full network access and returns 480 EAP-Success. This will typically happen when the client presents 481 a valid LDevID. Network policy may grant client network access 482 based on IDevID without requiring the device to enroll to obtain 483 an LDevID. 485 o Option 2: Server requires that client perform a full BRSKI flow, 486 and then enroll to get an LDevID. This will typically happen when 487 the client presents a valid IDevID and network policy requires all 488 clients to have LDevIDs. The server sends a Request-Action TLV 489 that includes a BRSKI-RequestVoucher TLV to the client to instruct 490 it to start the BRSKI flow. 492 o Option 3: Server requires that the client reenroll to obtain a new 493 LDevID. This could happen when the client presents a valid LDevID 494 that is very close to expiration time, or the server's policy 495 requires an LDevID update. The server sends an Action-Request TLV 496 including a PKCS#10 TLV to the client to instruct it to reenroll. 498 4.2. BRSKI Trust Establishment 500 If the server requires that client perform a full BRSKI flow, it 501 sends a Request-Action TLV that includes a zero byte length BRSKI- 502 RequestVoucher TLV to the client. The client sends a new BRSKI- 503 RequestVoucher TLV to the server, which contains all data specified 504 in [I-D.ietf-anima-bootstrapping-keyinfra] section 5.2. The client 505 includes the server certificate it received in the server's 506 Certificate message during outer TLS tunnel establishment in the 507 proximity-registrar-cert field. The client signs the request using 508 its IDevID. 510 The server includes all additional information as required by 511 [I-D.ietf-anima-bootstrapping-keyinfra] section 5.4 and signs the 512 request prior to forwarding to the MASA. 514 The MASA responds as per [I-D.ietf-anima-bootstrapping-keyinfra] 515 section 5.5. The response may indicate failure and the server should 516 react accordingly to failures by sending a failure response to the 517 client, and failing the TEAP method. 519 If the MASA replies with a signed voucher and a successful result, 520 the server then forwards this response to the client in a BRSKI- 521 Voucher TLV. 523 When the client receives the signed voucher, it validates the 524 signature using its built in trust anchor list, and extracts the 525 pinned-domain-cert field. The client must use the CA included in the 526 pinned-domain-cert to validate the certificate that was presented by 527 the server when establishing the outer TLS tunnel. If this 528 certificate validation fails, the client must fail the TEAP request 529 and not connect to the network. 531 [TBD- based on client responses, the registrar sends a status update 532 to the MASA] 534 4.3. Certificate Expiration Times 536 [IEEE8021AR] section 7.2.7.2 states: 538 notAfter: The latest time a DevID is expected to be used. Devices 539 possessing an IDevID are expected to operate indefinitely into the 540 future and should use the value 99991231235959Z. Solutions 541 verifying an IDevID are expected to accept this value 542 indefinitely. 544 TEAP servers SHOULD follow the 802.1AR standard when validating 545 IDevIDs. 547 TEAP servers SHOULD reject LDevIDs with expired certificates and 548 SHOULD NOT allow clients to connect with recently expired LDevIDs. 549 If a client presents a recently expired LDevID it SHOULD be forced to 550 authenticate using its IDevID and then reenroll to obtain a valid 551 LDevID. 553 5. Channel and Crypto Binding 555 As the TEAP BRSKI flow does not define or require an inner EAP 556 method, there is no explicit need for exchange of Channel-Binding 557 TLVs between the device and the TEAP server. 559 The TEAP BRSKI TLVs are expected to occur at the beginning of the 560 TEAP Phase 2 and MUST occur before the final Crypto-Binding TLV. 561 This draft does not exclude the possibility of having other EAP 562 methods occur following the TEAP BRSKI TLVs and as such, the Crypto- 563 Binding TLV process rules as defined in [RFC7170] apply. 565 6. Protocol Flows 567 This section outlines protocol flows that map to the three server 568 policy options described in section Section 4.1. The protocol flows 569 illustrate a TLS1.2 exchange. Pertinent notes are outlined in the 570 protocol flows. 572 6.1. TEAP Server Grants Access 574 In this flow, the server grants access as server policy allows the 575 client to access the network based on the identity certificate that 576 the client presented. This means that either (i) the client has 577 previously completed BRSKI and has presented a valid LDevID or (ii) 578 the client presents an IDevID and network policy allows access based 579 purely on IDevID. 581 +----------------+ 582 +--------+ | Authenticator/ | +------+ 583 | Client | | TEAP-Server | | MASA | 584 +--------+ +----------------+ +------+ 585 | EAP-Request/ | | 586 | Type=Identity | | 587 |<------------------------| | 588 | | | 589 | EAP-Response/ | | 590 | Type=Identity | | 591 |------------------------>| | 592 | | | 593 | EAP-Request/ | | 594 | Type=TEAP, | | 595 | TEAP Start, | | 596 | Authority-ID TLV | | 597 |<------------------------| | 598 | | | 599 | EAP-Response/ | | 600 | Type=TEAP, | | 601 | TLS(ClientHello) | | 602 |------------------------>| | 603 | | | 604 | EAP-Request/ | | 605 | Type=TEAP, | | 606 | TLS(ServerHello, | | 607 (1)| Certificate, | | 608 | ServerKeyExchange, | | 609 (2)| CertificateRequest, | | 610 | ServerHelloDone) | | 611 |<------------------------| | 612 | | | 613 | EAP-Response/ | | 614 | Type=TEAP, | | 615 (3)| TLS(Certificate, | | 616 | ClientKeyExchange, | | 617 | CertificateVerify, | | 618 | ChangeCipherSpec, | | 619 | Finished) | | 620 |------------------------>| | 621 | | | 622 | EAP-Request/ | | 623 | Type=TEAP, | | 624 | TLS(ChangeCipherSpec, | | 625 | Finished), | | 626 | {Crypto-Binding TLV, | | 627 | Result TLV=Success} | | 628 |<------------------------| | 629 | | | 630 | EAP-Response/ | | 631 | Type=TEAP, | | 632 | {Crypto-Binding TLV, | | 633 | Result TLV=Success} | | 634 |------------------------>| | 635 | | | 636 | EAP-Success | | 637 |<------------------------| | 639 Figure 1: TEAP Server Grants Access 641 Notes: 643 (1) If the client has completed the BRSKI flow and has locally 644 significant trust anchors, it must validate the Certificate received 645 from the server. If the client has not yet completed the BRSKI flow, 646 then it provisionally accepts the server Certificate and must 647 validate it later once BRSKI is complete. 649 (2) The server may include certificate_authorities field in the 650 CertificateRequest message in order to restrict the identity 651 certificates that the device is allowed present. 653 (3) The device will present its LDevID, if it has one, in preference 654 to its IDevID, if allowed by server policy. 656 6.2. TEAP Server Instructs Client to Perform BRSKI Flow 658 In this flow, the server instructs the client to perform a BRSKI flow 659 by exchanging TLVs once the outer TLS tunnel is established. 661 +----------------+ 662 +--------+ | Authenticator/ | +------+ +----+ 663 | Client | | TEAP-Server | | MASA | | CA | 664 +--------+ +----------------+ +------+ +----+ 665 | EAP-Request/ | | | 666 | Type=Identity | | | 667 |<----------------------------| | | 668 | | | | 669 | EAP-Response/ | | | 670 | Type=Identity | | | 671 |---------------------------->| | | 672 | | | | 673 | EAP-Request/ | | | 674 | Type=TEAP, | | | 675 | TEAP Start, | | | 676 | Authority-ID TLV | | | 677 |<----------------------------| | | 678 | | | | 679 | EAP-Response/ | | | 680 | Type=TEAP, | | | 681 | TLS(ClientHello) | | | 682 |---------------------------->| | | 683 | | | | 684 | EAP-Request/ | | | 685 | Type=TEAP, | | | 686 | TLS(ServerHello, | | | 687 (1)| Certificate, | | | 688 | ServerKeyExchange, | | | 689 | CertificateRequest, | | | 690 | ServerHelloDone) | | | 691 |<----------------------------| | | 692 | | | | 693 | EAP-Response/ | | | 694 | Type=TEAP, | | | 695 | TLS(Certificate | | | 696 | ClientKeyExchange, | | | 697 | CertificateVerify, | | | 698 | ChangeCipherSpec, | | | 699 | Finished) | | | 700 |---------------------------->| | | 701 | | | | 702 | EAP-Request/ | | | 703 | Type=TEAP, | | | 704 | TLS(ChangeCipherSpec, | | | 705 | Finished), | | | 706 | {Crypto-Binding TLV, | | | 707 | Result TLV=Success} | | | 708 |<----------------------------| | | 709 | | | | 710 | EAP-Response/ | | | 711 | Type=TEAP, | | | 712 | {Crypto-Binding TLV, | | | 713 | Result TLV=Success} | | | 714 |---------------------------->| | | 715 | | | | 716 ** At this stage the outer TLS tunnel is established ** 717 ** The following message exchanges are for BRSKI ** 718 | | | | 719 | EAP-Request/ | | | 720 | Type=TEAP, | | | 721 (2)| {Request-Action TLV: | | | 722 | Status=Failure, | | | 723 | Action=Process-TLV, | | | 724 | TLV=Request-Voucher, | | | 725 | TLV=Trusted-Server-Root,| | | 726 | TLV=CSR-Attributes, | | | 727 | TLV=PKCS#10} | | | 728 |<----------------------------| | | 729 | | | | 730 | EAP-Response/ | | | 731 | Type=TEAP, | | | 732 (3)| {Request-Voucher TLV} | | | 733 |---------------------------->| RequestVoucher | | 734 | |--------------->| | 735 | | Voucher | | 736 | |<---------------| | 737 | EAP-Request/ | | | 738 | Type=TEAP, | | | 739 (4)| {Voucher TLV} | | | 740 |<----------------------------| | | 741 | | | | 742 | EAP-Response/ | | | 743 | Type=TEAP, | | | 744 (5)| {Trusted-Server-Root TLV} | | | 745 |---------------------------->| | | 746 | | | | 747 | EAP-Request/ | | | 748 | Type=TEAP, | | | 749 | {Trusted-Server-Root TLV} | | | 750 |<----------------------------| | | 751 | | | | 752 | EAP-Response/ | | | 753 | Type=TEAP, | | | 754 | {CSR-Attributes TLV} | | | 755 |---------------------------->| | | 756 | | | | 757 | EAP-Request/ | | | 758 | Type=TEAP, | | | 759 | {CSR-Attributes TLV} | | | 760 |<----------------------------| | | 761 | | | | 762 | EAP-Response/ | | | 763 | Type=TEAP, | | | 764 | {PKCS#10 TLV} | | | 765 |---------------------------->| | | 766 | | PKCS#10 | | 767 | EAP-Request/ |--------------/ | \----->| 768 | Type=TEAP, | | | 769 | {PKCS#7 TLV, | PKCS#7 | | 770 (6)| Result TLV=Success} |<-------------/ | \------| 771 |<----------------------------| | | 772 | | | | 773 | EAP-Response/ | | | 774 | Type=TEAP, | | | 775 | {Result TLV=Success} | | | 776 |---------------------------->| | | 777 | | | | 778 | EAP-Success | | | 779 |<----------------------------| | | 781 Figure 2: TEAP Server Instructs Client to Perform BRSKI Flow 783 Notes: 785 (1) If the client has not yet completed the BRSKI flow, then it 786 provisionally accepts the server certificate and must validate it 787 later once BRSKI is complete. The server validates the client 788 certificate using its trust anchor database. 790 (2) The server instructs the client to start the BRSKI flow by 791 sending a Request-Action TLV that includes a BRSKI-RequestVoucher 792 TLV. The server also instructs the client to request trust anchors, 793 to request CSR Attrites, and to initiate a PKCS certificate 794 enrolment. As outlined in [RFC7170], the Request-Action TLV is sent 795 after the Crypto-Binding TLV and Result TLV exchange. 797 (3) The client includes the certificate it received from the server 798 in the RequestVoucher message. 800 (4) Once the client receives and validates the voucher signed by the 801 MASA, it must verify the certificate it previously received from the 802 server. 804 (5) As outlined in [RFC7170], the Trusted-Server-Root TLV is 805 exchanged after the Crypto-Binding TLV exchange, and after the client 806 has used the Voucher to authenticate the TEAP server identity. This 807 is equivalent to section [todo] from 808 [I-D.ietf-anima-bootstrapping-keyinfra]. 810 (6) There is no need for an additional Crypto-Binding TLV exchange as 811 there is no inner EAP method. All BRSKI exchanges are simply TLVs 812 exchanged inside the outer TLS tunnel. 814 6.3. TEAP Server Instructs Client to Reenroll 816 In this flow, the server instructs the client to reenroll and get a 817 new LDevID by exchanging TLVs once the outer TLS tunnel is 818 established. 820 +----------------+ 821 +--------+ | Authenticator/ | +------+ +----+ 822 | Client | | TEAP-Server | | MASA | | CA | 823 +--------+ +----------------+ +------+ +----+ 824 | EAP-Request/ | | | 825 | Type=Identity | | | 826 |<------------------------| | | 827 | | | | 828 | EAP-Response/ | | | 829 | Type=Identity | | | 830 |------------------------>| | | 831 | | | | 832 | EAP-Request/ | | | 833 | Type=TEAP, | | | 834 | TEAP Start, | | | 835 | Authority-ID TLV | | | 836 |<------------------------| | | 837 | | | | 838 | EAP-Response/ | | | 839 | Type=TEAP, | | | 840 | TLS(ClientHello) | | | 841 |------------------------>| | | 842 | | | | 843 | EAP-Request/ | | | 844 | Type=TEAP, | | | 845 | TLS(ServerHello, | | | 846 | Certificate, | | | 847 | ServerKeyExchange, | | | 848 | CertificateRequest, | | | 849 | ServerHelloDone) | | | 850 |<------------------------| | | 851 | | | | 852 | EAP-Response/ | | | 853 | Type=TEAP, | | | 854 | TLS(Certificate, | | | 855 | ClientKeyExchange, | | | 856 | CertificateVerify, | | | 857 | ChangeCipherSpec, | | | 858 | Finished) | | | 859 |------------------------>| | | 860 | | | | 861 | EAP-Request/ | | | 862 | Type=TEAP, | | | 863 | TLS(ChangeCipherSpec, | | | 864 | Finished), | | | 865 | {Crypto-Binding TLV, | | | 866 | Result TLV=Success} | | | 867 |<------------------------| | | 868 | | | | 869 | EAP-Response/ | | | 870 | Type=TEAP, | | | 871 | {Crypto-Binding TLV, | | | 872 | Result TLV=Success} | | | 873 |------------------------>| | | 874 | | | | 875 | EAP-Request/ | | | 876 | Type=TEAP, | | | 877 (1)| {Request-Action TLV: | | | 878 | Status=Failure, | | | 879 | Action=Process-TLV, | | | 880 | TLV=PKCS#10} | | | 881 |<------------------------| | | 882 | | | | 883 | EAP-Response/ | | | 884 | Type=TEAP, | | | 885 | {PKCS#10 TLV} | | | 886 |------------------------>| | | 887 | | PKCS#10 | | 888 | EAP-Request/ |--------------/ | \----->| 889 | Type=TEAP, | | | 890 | {PKCS#7 TLV, | PKCS#7 | | 891 | Result TLV=Success} |<-------------/ | \------| 892 |<------------------------| | | 893 | | | | 894 | EAP-Response/ | | | 895 | Type=TEAP, | | | 896 | {Result TLV=Success} | | | 897 |------------------------>| | | 898 | | | | 899 | EAP-Success | | | 900 |<------------------------| | | 901 Figure 3: TEAP Server Instructs Client to Reenroll 903 (1) The server instructs the client to reenroll by sending a Request- 904 Action TLV that includes a PKCS#10 TLV. 906 6.4. Out of Band Reenroll 908 This section shows how the device does a reenroll to refresh its 909 LDEvID directly against the registrar outside the context of the TEAP 910 tunnel. 912 7. TEAP TLV Formats 914 7.1. BRSKI TLVs 916 BRSKI defines 3 new TEAP TLVs. The following table indicates whether 917 the TLVs can be included in Request messages from TEAP server to 918 device, or Response messages from device to TEAP server. 920 +------------------------+----------+ 921 | TLV | Message | 922 +------------------------+----------+ 923 | BRSKI-VoucherRequest | Response | 924 | BRSKI-Voucher | Request | 925 | CSR-Attributes | Response | 926 +------------------------+----------+ 928 These new TLVs are detailed in this section. 930 7.1.1. BRSKI-RequestVoucher TLV 932 This TLV is used by the server as part of a Request-Action TLV to 933 request from the peer that it initiate a voucher request. When used 934 in this fashion, the length of this TLV will be set to zero. The 935 Status field of the Request-Action TLV MUST be set to Failure. 937 It is also used by the peer to initiate the voucher request. When 938 used in this fashion, the length of the TLV will be set to that of 939 the voucher request, as encoded and described in Section 3.3 in 940 [I-D.ietf-anima-bootstrapping-keyinfra]. 942 0 1 2 3 943 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 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 |M|R| TLV=TBD1-VoucherRequest | Length | 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | Value... 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 The M and R bits are always expected to be set to 0. 952 The server is expected to forward the voucher request to the MASA, 953 and then return a voucher in a BRSKI-Voucher TLV as described below. 954 If it is unable to do so, it returns an TEAP Error TLV with one of 955 the defined errors or the following: 957 TBD2-MASA-Notavailable MASA unavailable 958 TBD3-MASA-Refused MASA refuses to sign the voucher 960 The peer terminates the TEAP connection, but may retry at some later 961 point. The backoff mechanism for such retries should be appropriate 962 for the device. Retries MUST occur no more frequently than once 963 every two (TBD) minutes. 965 7.1.2. BRSKI-Voucher TLV 967 This TLV is transmitted from the server to the peer. It contains a 968 signed voucher, as describe in [RFC8366]. 970 0 1 2 3 971 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 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 |M|R| TLV=TBD4-Voucher | Length | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Value... 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 Upon receiving this TLV the peer will validate the signature of the 979 voucher, using its pre-installed manufacturer trust anchor (LDevID). 980 It MUST also validate the certificate used by the server to establish 981 the TLS connection. 983 If successful, it installs the new trust anchor contained in the 984 voucher. 986 Otherwise, the peer transmits an TEAP error TLV with one of the 987 following error messages: 989 TBD5-Invalid-Signature The signature of the voucher signer is invalid 990 TBD6-Invalid-Voucher The form or content of the voucher is not valid 991 TBD7-Invalid-TLS-Signer The certificate used for the TLS connection 992 could not be validated. 994 7.1.3. CSR-Attributes TLV 996 The server SHALL transmit this TLV to the peer, either along with the 997 BRSKI-Voucher TLV or at any time earlier in a communication. The 998 peer shall include attributes required by the server in any following 999 CSR. The value of this TLV is the base64 encoding described in 1000 Section 4.5.2 of [RFC7030]. 1002 0 1 2 3 1003 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 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 |M|R| TLV=TBD8-CSR-Attributes | length | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | Value... 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 Again, the M and R values are set to 0. In the case where the client 1011 is unable to provide the requested attributes, an TEAP-Error is 1012 returned as follows: 1014 TBD9-CSR-Attribute-Fail Unable to supply the requested attributes. 1016 7.2. Existing TEAP TLV Specifications 1018 This section documents allowed usage of existing TEAP TLVs. The 1019 definition of the TLV is not changed, however clarifications on 1020 allowed values for the TLV fields is documented. 1022 7.2.1. PKCS#10 TLV 1024 [RFC7170] defines the PKCS#10 TLV as follows: 1026 0 1 2 3 1027 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 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 |M|R| TLV Type | Length | 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | PKCS#10 Data... 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1034 [RFC7170] does not explicitly allow a Length value of zero. 1036 A Length value of zero is allowed for this TLV when the TEAP server 1037 sends a Request-Action TLV with a child PKCS#10 TLV to the client. 1038 In this scenario, there is no PKCS#10 Data included in the TLV. 1039 Clients MUST NOT send a zero length PKCS#10 TLV to the server. 1041 7.3. TLV Rules 1043 BRSKI TLVs can only be transported inside the TLS tunnel. The 1044 following table provides a guide to which TLVs may be encapsulated in 1045 which kind of packets, and in what quantity. The messages are as 1046 follows: Request is a TEAP Request, Response is a TEAP Response, 1047 Success is a message containing a successful Result TLV, and Failure 1048 is a message containing a failed Result TLV. 1050 The following define the meaning of the table entries in the sections 1051 below: 1053 0 This TLV MUST NOT be present in the message. 1055 0+ Zero or more instances of this TLV MAY be present in the message. 1057 0-1 Zero or one instance of this TLV MAY be present in the message. 1059 1 Exactly one instance of this TLV MUST be present in the message. 1061 Request Response Success Failure TLVs 0 0-1 0 0 BRSKI-VoucherRequest 1062 0-1 0 0 0 BRSKI-Voucher 0 0-1 0 0 CSR-Attributes 1064 8. Fragmentation 1066 TEAP is expected to provide fragmentation support. Thus EAP-TEAP- 1067 BRSKI does not specifically provide any, as it is only expected to be 1068 used as an inner method to TEAP. 1070 9. IANA Considerations 1072 The IANA is requested to add entries into the following tables: 1074 The following new TEAP TLVs are defined: 1076 TBD1-VoucherRequest Described in this document. 1077 TBD4-Voucher Described in this document. 1078 TBD8-CSR-Attributes Described in this document. 1080 The following TEAP Error Codes are defined, with their meanings 1081 listed here and in previous sections: 1083 TBD2-MASA-Notavailable MASA unavailable 1084 TBD3-MASA-Refused MASA refuses to sign the voucher 1085 TBD5-Invalid-Signature The signature of the voucher signer is invalid 1086 TBD6-Invalid-Voucher The form or content of the voucher is not valid 1087 TBD7-Invalid-TLS-Signer The certificate used for the TLS connection 1088 could not be validated. 1089 TBD9-CSR-Attribute-Fail Unable to supply the requested attributes. 1091 10. Security Considerations 1093 BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] provides a zero touch 1094 way for devices to enroll in a certification authority (CA). It 1095 assumes the device has IP connectivity. For networks that will not 1096 grant IP connectivitiy before authenticating (with a local 1097 credential) this poses a Catch-22- can't get on the network without a 1098 credential and can't get a credential without getting on the network. 1100 This protocol provides a way for BRSKI to be in an EAP method which 1101 allows the BRSKI conversation to happen as part of EAP authentication 1102 and prior to obtaining IP connectivity. 1104 The security considerations of 1105 [I-D.ietf-anima-bootstrapping-keyinfra] apply to this protocol. 1106 Running BRSKI through EAP introduces some additional areas of concern 1107 though. 1109 10.1. Issues with Provisionally Authenticated TEAP 1111 This protocol establishes an unauthenticated TLS connection and 1112 passes data through it. Provided that the only messages passed in 1113 this state are self-protected BRSKI messages this does not present a 1114 problem. Passing any other messages or TLVs prior to authentication 1115 of the provisional TLS connection could potentially introduce 1116 security issues. 1118 While the TLS connection is unauthenticated, it must still be 1119 validated to the fullest extent possible. It is critical that the 1120 device and the TEAP server perform all steps in TLS- checking the 1121 validity of the presented certificate, validating the signature using 1122 the public key of the certificate, etc- except ensuring the trust of 1123 the presented certificate. 1125 10.2. Attack Against Discovery 1127 The device discovery technique specified in this protocol is the 1128 standard EAP server discovery process. Since it is trivial to set up 1129 an 802.11 wireless access point and advertise any network, an 1130 attacker can impersonate a legitimate wireless network and attract 1131 unprovisioned pledges. Given that an unprovisioned device will not 1132 know the legitimate network to connect to, it will probably attempt 1133 the first network it finds, making the attack that much easier. This 1134 allows for a "rogue registrar" to provision and take control of the 1135 device. 1137 If the MASA verifies ownership prior to issuance of a voucher, this 1138 attack can be thwarted. But if the MASA is in reduced security mode 1139 and does not verify ownership this attack cannot be prevented. 1140 Registrars SHOULD use the audit log of a MASA when deploying newly 1141 purchased equipment in order to mitigate this attack. 1143 Another way to mitigate this attack is through normal "rogue AP" 1144 detection and prevention. 1146 10.3. TEAP Server as Registration Authority 1148 If the TEAP server is logically separate from the Certification 1149 Authority (CA) (see Section 2) it will be acting as a Registration 1150 Authority (RA) when it obtains the PKCS#10 TLV and replies with a 1151 PKCS#7 TLV (see [RFC7170], Sections 4.2.16 and 4.2.17, respectively). 1152 The assurance a RA makes to a CA is that the public key in the 1153 presented CSR is bound to an authenticated identity in way that will 1154 assure non-repudiation. 1156 To make such an assurance, the TEAP server MUST authenticate the 1157 provisional TLS connection with the device by validating the voucher 1158 response received from the MASA. In addition, it is RECOMMENDED that 1159 the TEAP server indicate that proof-of-possession (see [RFC7170], 1160 Section 3.8.2) is required by including the challengePassword OID in 1161 the CSR Attributes TLV. 1163 10.4. Trust of Registrar 1165 The device accepts a trusted server (CA) certificate and installs it 1166 in its trust anchor database during step 5 (see Section 3.2). This 1167 can happen only after the provisional TLS connection has been 1168 authenticated using the voucher and the Crypto-Binding TLV has been 1169 validated. 1171 11. Acknowledgments 1173 The authors would like to thank Brian Weis for his assistance, and 1174 Alan Dakok for improving language consistency. In addition, with 1175 ruthlessly "borrowed" the concept around NAI handling from Tuomas 1176 Aura and Mohit Sethi. 1178 12. Normative References 1180 [I-D.ietf-anima-bootstrapping-keyinfra] 1181 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 1182 S., and K. Watsen, "Bootstrapping Remote Secure Key 1183 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1184 keyinfra-22 (work in progress), June 2019. 1186 [IEEE8021AR] 1187 Institute for Electrical and Electronics Engineers, 1188 "Secure Device Identity", 1998. 1190 [IEEE8021X] 1191 Institute for Electrical and Electronics Engineers, "IEEE 1192 Standard for Local and metropolitan area networks--Port- 1193 Based Network Access Control", 2010. 1195 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1196 Levkowetz, Ed., "Extensible Authentication Protocol 1197 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1198 . 1200 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1201 "Enrollment over Secure Transport", RFC 7030, 1202 DOI 10.17487/RFC7030, October 2013, 1203 . 1205 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1206 "Tunnel Extensible Authentication Protocol (TEAP) Version 1207 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1208 . 1210 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1211 "A Voucher Artifact for Bootstrapping Protocols", 1212 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1213 . 1215 Appendix A. Changes from Earlier Versions 1217 Draft -03: * Merge EAP server and Registrar * Security considerations 1218 * References improvements * Add Dan Harkins as co-author 1220 Draft -02: * Flow corrections 1222 Draft -01: * Add packet descriptions, IANA considerations, smooth out 1223 language. 1225 Draft -00: 1227 o Initial revision 1229 Authors' Addresses 1231 Eliot Lear 1232 Cisco Systems 1233 Richtistrasse 7 1234 Wallisellen CH-8304 1235 Switzerland 1237 Phone: +41 44 878 9200 1238 Email: lear@cisco.com 1240 Owen Friel 1241 Cisco Systems 1242 170 W. Tasman Dr. 1243 San Jose, CA 95134 1244 United States 1246 Email: ofriel@cisco.com 1248 Nancy Cam-Winget 1249 Cisco Systems 1250 170 W. Tasman Dr. 1251 San Jose, CA 95134 1252 United States 1254 Email: ncamwing@cisco.com 1255 Dan Harkins 1256 HP Enterprise 1257 3333 Scott Boulevard 1258 Santa Clara, CA 95054 1259 United States 1261 Email: dharkins@arubanetworks.com