idnits 2.17.1 draft-lear-eap-teap-brski-04.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 159: '...two functions co-located, they MUST be...' RFC 2119 keyword, line 343: '...flow, the device SHOULD send a Trusted...' RFC 2119 keyword, line 350: '...ion of step 5, server MUST send a CSR-...' RFC 2119 keyword, line 363: '...ucher TLV, then the device MUST send a...' RFC 2119 keyword, line 382: '... then the device MUST send a PKCS#10 t...' (29 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 13, 2019) is 1684 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-26 -- 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: March 16, 2020 Cisco Systems 6 D. Harkins 7 HP Enterprise 8 September 13, 2019 10 Bootstrapping Key Infrastructure over EAP 11 draft-lear-eap-teap-brski-04 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 March 16, 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 4.4. LDevID Subject and Subject Alternative Names . . . . . . 12 73 4.5. PKCS#10 Retry Handling . . . . . . . . . . . . . . . . . 13 74 5. Peer Identity . . . . . . . . . . . . . . . . . . . . . . . . 13 75 6. Channel and Crypto Binding . . . . . . . . . . . . . . . . . 14 76 7. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 14 77 7.1. TEAP Server Grants Access . . . . . . . . . . . . . . . . 14 78 7.2. TEAP Server Instructs Client to Perform BRSKI Flow . . . 16 79 7.3. TEAP Server Instructs Client to Reenroll . . . . . . . . 19 80 7.4. Out of Band Reenroll . . . . . . . . . . . . . . . . . . 21 81 8. TEAP TLV Formats . . . . . . . . . . . . . . . . . . . . . . 22 82 8.1. New TLVs . . . . . . . . . . . . . . . . . . . . . . . . 22 83 8.1.1. BRSKI-RequestVoucher TLV . . . . . . . . . . . . . . 22 84 8.1.2. BRSKI-Voucher TLV . . . . . . . . . . . . . . . . . . 23 85 8.1.3. CSR-Attributes TLV . . . . . . . . . . . . . . . . . 23 86 8.1.4. Retry-After TLV . . . . . . . . . . . . . . . . . . . 24 87 8.1.5. NAI TLV . . . . . . . . . . . . . . . . . . . . . . . 24 88 8.2. Existing TEAP TLV Specifications . . . . . . . . . . . . 25 89 8.2.1. PKCS#10 TLV . . . . . . . . . . . . . . . . . . . . . 25 90 8.3. TLV Rules . . . . . . . . . . . . . . . . . . . . . . . . 25 91 9. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 26 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 94 11.1. Issues with Provisionally Authenticated TEAP . . . . . . 27 95 11.2. Attack Against Discovery . . . . . . . . . . . . . . . . 27 96 11.3. TEAP Server as Registration Authority . . . . . . . . . 28 97 11.4. Trust of Registrar . . . . . . . . . . . . . . . . . . . 28 98 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 99 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 100 13.1. Normative References . . . . . . . . . . . . . . . . . . 28 101 13.2. Informative References . . . . . . . . . . . . . . . . . 29 102 Appendix A. Changes from Earlier Versions . . . . . . . . . . . 29 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 105 1. Introduction 107 [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI) specifies a means to 108 provision credentials to be used as credentials to operationally 109 access networks. It was designed as a standalone means where some 110 limited access to an IP network is already available. This is not 111 always the case. For example, IEEE 802.11 networks generally require 112 authentication prior to any form of address assignment. While it is 113 possible to assign an IP address to a device on some form of an open 114 network, or to accept some sort of default credential to establish 115 initial IP connectivity, the steps that would then follow might well 116 require that the device is placed on a new network, requiring 117 reseting all layer three parameters. 119 A more natural approach in such cases is to more tightly bind the 120 provisioning of credentials with the authentication mechanism. One 121 such way to do this is to make use of the Extensible Authentication 122 Protocol (EAP) [RFC3748] and the Tunnel Extensible Authentication 123 Protocol (TEAP) method [RFC7170]. Thus we define new TEAP Type- 124 Length-Value (TLV) objects that can be used to transport the BRSKI 125 protocol messages within the context of a TEAP TLS tunnel. 127 [RFC7170] discusses the notion of provisioning peers. Several 128 different mechanisms are available. Section 3.8 of that document 129 acknowledges the concept of not initially authenticating the outer 130 TLS session so that provisioning may occur. In addition, exchange of 131 multiple TLV messages between client and EAP server permits multiple 132 provisioning steps. 134 1.1. Terminology 136 The reader is presumed to be familiar with EAP terminology as stated 137 in [RFC3748]. In addition, the following terms are commonly used in 138 this document. 140 o BRSKI: Bootstrapping Remote Secure Key Infrastructures, as defined 141 in [I-D.ietf-anima-bootstrapping-keyinfra]. The term is also used 142 to refer to the flow described in that document. 144 o EST: Enrollment over Secure Transport, as defined in [RFC7030]. 146 o Voucher: a signed JSON object as defined in [RFC8366]. 148 2. TEAP BRSKI Architecture 150 The TEAP BRSKI architecture is illustrated in Section 3. The device 151 talks to the TEAP server via the Authenticator using any compliant 152 transport such as [IEEE8021X]. The architecture illustrated shows an 153 Authenticator distinct from the TEAP server. This is a deployment 154 optimization and when so deployed the communication between 155 Authenticator and TEAP server is a AAA protocol such as RADIUS or 156 DIAMETER. 158 The architecture illustrated shows a co-located TEAP server and BRSKI 159 registrar. Not only are these two functions co-located, they MUST be 160 the same entity. This ensures that the entity identified in the 161 device's voucher request (the TEAP server) is the same entity that 162 signs the voucher request (the registrar). 164 The registrar communicates with the BRSKI MASA service for the 165 purposes of getting signed vouchers. 167 The registrar also communicates with a Certificate Authority in order 168 to issue LDevIDs. The architecture shows the registrar and CA as 169 being two logically separate entities, however the CA may be 170 integrated into the registrar. The device is not explicitly aware of 171 whether the CA and registrar functions are integrated. 173 +--------+ +---------+ +---------+ +------+ 174 | | | | | TEAP |<--->| MASA | 175 | | | Authen- | | server | +------+ 176 | Device |<--->| ticator |<--->| | 177 | | | | | BRSKI | +------+ 178 | | | | |Registrar|<--->| CA | 179 +--------+ +---------+ +---------+ +------+ 181 3. BRSKI Bootstrap and Enroll Operation 183 This section summarises the current BRSKI operation. The BRSKI flow 184 assumes the device has an IDevID and has a manufacturer installed 185 trust anchor that can be used to validate the BRSKI voucher. The 186 BRSKI flow compromises serveral main steps from the perspective of 187 the device: 189 o Step 1: Device discovers the registrar 191 o Step 2: Device establishes provisional TLS connection to registrar 193 o Step 3: Device sends voucher request message and receives signed 194 voucher response 196 o Step 4: Device validates voucher and validates provisional TLS 197 connection to registrar 199 o Step 5: Device downloads additional local domain CA information 201 o Step 6: Device downloads Certificate Signing Request (CSR) 202 attributes 204 o Step 7: Device does a certificate enroll to obtain an LDevID 206 o Step 8: Device periodically reenrolls via EST to refresh its 207 LDevID 209 Most of the operational steps require the device, and thus its 210 internal state machine, to automatically complete the next step 211 without being explicitly instructed to do so by the registrar. For 212 example, the registrar does not explicitly tell the device to 213 download additional local domain CA information, or to do an EST 214 enroll to obtain an LDevID. 216 3.1. Discovery of Trusted MASA 218 BRSKI section 2.8 outlines how the Registrar discovers the correct 219 MASA to connect with. BRSKI section 5.3 outlines how the Registrar 220 can make policy decisions about which devices to trust. 222 Similar approaches are applicable for TEAP servers executing BRSKI. 223 For example, the TEAP server may be configured with a list of trusted 224 manufacturing CAs. During device bootstrap, only devices with an 225 IDevID signed by a trusted manufacturing CA may be allowed to 226 etablishes a TLS connection with the TEAP server, and the TEAP server 227 could then extract the MASA URI from the device's IDevID. 229 3.2. Executing BRSKI in a TEAP Tunnel 231 This section outlines how the main BRSKI steps outlined above map to 232 TEAP, and how BRSKI and enrollment can be accomplished inside a TEAP 233 TLS tunnel. The following new TEAP TLVs are introduced: 235 o BRSKI-VoucherRequest 237 o BRSKI-Voucher 239 o CSR-Attributes 241 The following steps outline how the above BRSKI flow maps to TEAP. 243 o Step 1: Device discovers the registrar 245 When BRSKI is executed in a TEAP tunnel, the device exchanges BRSKI 246 TLVs with the TEAP server. The discovery process for devices is 247 therefore the standard wired or wireless LAN EAP server discovery 248 process. The discovery processes outlined in section 4 of 249 [I-D.ietf-anima-bootstrapping-keyinfra] are not required for initial 250 discovery of the registrar. 252 o Step 2: Device establishes provisional TLS connection to registrar 254 The device establishes an outer TEAP tunnel with the TEAP server and 255 does not validate the server certificate. The device presents its 256 LDevID as its identity certificate if it has a valid LDevID, 257 otherwise it presents its IDevID. The TEAP server validates the 258 device's certificate using its implicit or explicit trust anchor 259 database. If the device presents an IDevID it is verified against a 260 database of trusted manufacturer certificates. Server policy may 261 also be used to control which certificate the device is allowed 262 present, as described in section {pki-certificate-authority- 263 considerations}. 265 If the presented credential is sufficient to grant access, the TEAP 266 server can return a TEAP Result TLV indicating success immediately. 267 The device may still send a Request-Action TLV including a BRSKI- 268 VoucherRequest TLV in response to the TEAP Result TLV if it does not 269 have, but requires, provisioning of trust anchors for validating the 270 TEAP server certificate. Note that no inner EAP method is required 271 for this, only an exchange of TEAP TLVs. 273 [todo] Question: as the device wants the server to reply with a 274 BRSKI-Voucher TLV, does it really send a Request-Action TLV 275 containing a BRSKI-VoucherRequest TLV, or does it send a Request- 276 Action TLV containing a BRSKI-Voucher TLV?? The TEAP draft is a bit 277 ambiguous here. Normally, if one end sends a Request-Action 278 including XXX-TLV, it means it wants the far end ot send an XXX- 279 TLV... 281 [todo] Question: general TEAP protocol question: does the device have 282 to send a Request-Action w/BRSKI-VoucherRequest or can it send a 283 BRSKI-VoucherRequest on its own? I'm not clear on this. 285 If the TEAP server requires that the device execute a BRSKI flow, the 286 server sends a Request-Action TLV that includes a BRSKI- 287 VoucherRequest TLV. For example, if the device presented its IDevID 288 but the TEAP server requires an LDevID. 290 [todo] Question: to nit pick, the server should send a Request-Action 291 TLV including a PKCS#10 TLV to tell the client to enroll. How does 292 the server really know that the client has the correct trust 293 established (as previously received by a BRSKI-Voucher)? If the 294 client sends an IDevID, does server always send a Request-Action 295 including both BRSKI-VoucherRequest and PKCS#10 TLVs? Whats the 296 client behaviour? I assume client can spontaneously send BRSKI- 297 VoucherRequest and/or PCSK#10 without being explicitly instructed to. 298 Just need to get the language correct here. 300 The TEAP server may also require the device to reenroll, for example, 301 if the device presented a valid LDevID that is very closed to 302 expiration. The server may instruct a device to reenroll by sending 303 a Request-Action TLV that includes a zero byte length PKCS#10 TLV. 305 o Step 3: Device sends voucher request message and receives signed 306 voucher response 308 The device sends a BRSKI-RequestVoucher TLV to the TEAP server. The 309 TEAP server forwards the RequestVoucher message to the MASA server, 310 and the MASA server replies with a signed voucher. The TEAP server 311 sends a BRSKI-Voucher TLV to the device. 313 If the MASA server does not issue a signed voucher, the TEAP server 314 sends an EAP-Error TLV with a suitable error code to the device. 316 For wireless devices in particular, it is important that the MASA 317 server only return a voucher for devices known to be associated with 318 a particular registrar. In this sense, success indicates that the 319 device is on the correct network, while failure indicates the device 320 should try to provision itself within wireless networks (e.g, go to 321 the next SSID). 323 o Step 4: Device validates voucher and validates provisional TLS 324 connection to registrar 326 The device validates the signed voucher using its manufacturer 327 installed trust anchor, and uses the CA information in the voucher to 328 validate the TLS connection to the TEAP server. 330 If the device fails to validate the voucher, then it sends a TEAP- 331 Error TLV indicating failiure to the TEAP server. 333 Similarly, if the device validates the voucher, but fails to validate 334 the provisional TLS connection, then it sends a TEAP-Error TLV 335 indicating failure to the TEAP server. Note that the outer TLS 336 tunnel has already been established, thus allowing the client to send 337 a TEAP-Error TLV to the server inside that tunnel to indicate that it 338 failed to verify the provisionally accepted outer TLS tunnel server 339 identity. 341 o Step 5: Device downloads additional local domain CA information 343 On completion of the BRSKI flow, the device SHOULD send a Trusted- 344 Server-Root TLV to the TEAP server in order to discover additional 345 local domain CAs. This is equivalent to section [todo] from 346 [I-D.ietf-anima-bootstrapping-keyinfra]. 348 o Step 6: Device downloads CSR attributes 350 No later than the completion of step 5, server MUST send a CSR- 351 Attributes TLV to peer server in order to discover the correct fields 352 to include when it enrolls to get an LDevID. 354 o Step 7: Device does a certificate enroll to obtain an LDevID 356 When executing the BRSKI flow inside a TEAP tunnel, the device does 357 not directly leverage EST when doing its initial enroll. Instead, 358 the device uses the existing TEAP PKCS#10 and PCKS#7 TEAP mechanisms. 360 Once the BRSKI flow is complete, the device can now send a PKCS#10 361 TLV to enroll and request an LDevID. If the TEAP server instructed 362 the device to start the BRSKI flow via a Request-Action TLV that 363 includes a BRSKI-RequestVoucher TLV, then the device MUST send a 364 PKCS#10 in order to start the enroll process. The TEAP server will 365 handle the PKCS#10 and ultimately return a PKCS#7 including an LDevID 366 to the device. 368 If the TEAP server granted the device access on completion of the 369 outer TEAP TLS tunnel in step 2 without sending a Request-Action TLV, 370 the device does not have to send a PKCS#10 to enroll. 372 At this point, the device is said to be provisioned for local network 373 access, and may authenticate in the future via 802.1X with its newly 374 acquired credentials. 376 o Step 8: Device periodically reenrolls to refresh its LDevID 377 When a device's LDevID is close to expiration, there are two options 378 for re-enrollment in order to obtain a fresh LDevID. As outlined in 379 Step 2 above, the TEAP server may instruct the device to reenroll by 380 sending a Request-Action TLV including a PKCS#10 TLV. If the TEAP 381 server explicilty instructs the device to reenroll via these TLV 382 exchange, then the device MUST send a PKCS#10 to reenroll and request 383 a fresh LDevID. 385 However, the device SHOULD reenroll if it determines that its LDevID 386 is close to expiration without waiting for explicit instruction from 387 the TEAP server. There are two options to do this. 389 Option 1: The device reenrolls for a new LDevID directly with the EST 390 CA outside the context of the 802.1X TEAP flow. The device uses the 391 registrar discovery mechanisms oulined in 392 [I-D.ietf-anima-bootstrapping-keyinfra] to discover the registrar and 393 the device sends the EST reenroll messages to the discovered 394 registrar endpoint. No new TEAP TLVs are defined to facilitate 395 discover of the registrar or EST endpoints inside the context of the 396 TEAP tunnel. 398 Option 2: When the device is performing a periodic 802.1X 399 authentication using its current LDevID, it reenrolls for a new 400 LDevID by sending a PKCS#10 TLV inside the TEAP TLS tunnel. 402 4. PKI Certificate Considerations 404 There are multiple noteworthy PKI certificate handling 405 considerations. These include: 407 o PKI CA handling when establishing the TEAP tunnel 409 o PKI CA handling establishing trust using BRSKI 411 o IDevID and LDevID expiration times 413 o Specifying LDevID Subject and Subject Alternative Names 415 o PKCS#10 retry handling 417 These are described in more detail here. 419 4.1. TEAP Tunnel Establishment 421 Because this method establishes a client identity, and for purposes 422 of partioning of responsibility, the peer uses a generic identity 423 string of teap-brsk@TBD1 as its network access identifier (NAI). 425 BRSKI section 5.3 outlines the policy decisions a Registrar may make 426 when deciding whether to accept connections from clients. Similarly, 427 the TEAP server operator may configure a set of trusted CAs for 428 validating incoming TLS connections from clients. The operator may 429 want to 'allow any device from a specific vendor', or from a set of 430 vendors, to access the network. Network operators may do this by 431 restricting network access to clients that have a certificate signed 432 by one of a small set of trusted manufacturer/supplier CAs. 434 When the client sends its ClientHello to initiate TLS tunnel 435 establishment, it is possible for the TEAP server to restrict the 436 certificates that the client can use for tunnel establishment by 437 including a list of CA distinguished names in the 438 certificate_authorities field in the CertificateRequest message. The 439 client should only continue with the handshake if it has a 440 certificate signed by one of the indicated CAs. 442 In practice, network operators will likely want to onboard devices 443 from a large number of device manufacturers, with each manufacturer 444 using a different root CA when issuing IDevIDs. If the number of 445 different manufacturer root CAs is large, this could result in very 446 large TLS handshake messages. Therefore, the TEAP server may send a 447 CertificateRequest message and not specify any 448 certificate_authorities, thus allowing the client present a 449 certificate signed by any authority in its Certificate message. 451 If the client has both an IDevID and an LDevID, the client should 452 present the LDevID in preference to its IDevID, if allowed by server 453 policy. 455 Once the client has sent its TLS Finished message, the TEAP server 456 can make a policy decision, based on the CA used to sign the client's 457 certificate, on whether to establish the outer TLS tunnel or not. 459 The TEAP server may delegate policy decisions to the MASA or CA 460 function. For example, the TEAP server may declare EAP success and 461 grant network access if the client presents a valid LDevID signed by 462 a trusted domain CA. However, if the client presents an IDevID 463 signed by a trusted manufacturer CA, the TEAP server may establish 464 the TLS tunnel but not declare EAP success and grant network access 465 until the client successfully completes a BRSKI Voucher exchange and 466 PKCS#10/PKCS#7 exchange inside that tunnel. 468 It is recommended that the client validate the certificate presented 469 by the server in the server's Certificate message, but this may not 470 be possible for clients that have not yet provisioned appropriate 471 trust anchors. If the client is in the provisioning phase and has 472 not yet completed a BRSKI flow, it will not have trust anchors 473 installed yet, and thus will not be able to validate the server's 474 certificate. The client must however note the certificate presented 475 by the server for (i) inclusion in the BRSKI-RequestVoucher TLV and 476 for (ii) validation once the client has discovered the local domain 477 trust anchors. 479 If the client does not present a suitable certificate to the server, 480 the server MUST terminate the connection and fail the EAP request. 481 If the TEAP server is unable to validate the client's certificate 482 using its implicit or explicit trust anchor database it MUST fail the 483 EAP request. 485 On establishment of the outer TLS tunnel, the TEAP server will make a 486 policy decision on next steps. Possible policy decisions include: 488 o Option 1: Server grants client full network access and returns 489 EAP-Success. This will typically happen when the client presents 490 a valid LDevID. Network policy may grant client network access 491 based on IDevID without requiring the device to enroll to obtain 492 an LDevID. 494 o Option 2: Server requires that client perform a full BRSKI flow, 495 and then enroll to get an LDevID. This will typically happen when 496 the client presents a valid IDevID and network policy requires all 497 clients to have LDevIDs. The server sends a Request-Action TLV 498 that includes a BRSKI-RequestVoucher TLV to the client to instruct 499 it to start the BRSKI flow. 501 o Option 3: Server requires that the client reenroll to obtain a new 502 LDevID. This could happen when the client presents a valid LDevID 503 that is very close to expiration time, or the server's policy 504 requires an LDevID update. The server sends an Action-Request TLV 505 including a PKCS#10 TLV to the client to instruct it to reenroll. 507 4.2. BRSKI Trust Establishment 509 If the server requires that client perform a full BRSKI flow, it 510 sends a Request-Action TLV that includes a zero byte length BRSKI- 511 RequestVoucher TLV to the client. The client sends a new BRSKI- 512 RequestVoucher TLV to the server, which contains all data specified 513 in [I-D.ietf-anima-bootstrapping-keyinfra] section 5.2. The client 514 includes the server certificate it received in the server's 515 Certificate message during outer TLS tunnel establishment in the 516 proximity-registrar-cert field. The client signs the request using 517 its IDevID. 519 The server includes all additional information as required by 520 [I-D.ietf-anima-bootstrapping-keyinfra] section 5.4 and signs the 521 request prior to forwarding to the MASA. 523 The MASA responds as per [I-D.ietf-anima-bootstrapping-keyinfra] 524 section 5.5. The response may indicate failure and the server should 525 react accordingly to failures by sending a failure response to the 526 client, and failing the TEAP method. 528 If the MASA replies with a signed voucher and a successful result, 529 the server then forwards this response to the client in a BRSKI- 530 Voucher TLV. 532 When the client receives the signed voucher, it validates the 533 signature using its built in trust anchor list, and extracts the 534 pinned-domain-cert field. The client must use the CA included in the 535 pinned-domain-cert to validate the certificate that was presented by 536 the server when establishing the outer TLS tunnel. If this 537 certificate validation fails, the client must fail the TEAP request 538 and not connect to the network. 540 [TBD- based on client responses, the registrar sends a status update 541 to the MASA] 543 4.3. Certificate Expiration Times 545 [IEEE8021AR] section 7.2.7.2 states: 547 notAfter: The latest time a DevID is expected to be used. Devices 548 possessing an IDevID are expected to operate indefinitely into the 549 future and should use the value 99991231235959Z. Solutions 550 verifying an IDevID are expected to accept this value 551 indefinitely. 553 TEAP servers SHOULD follow the 802.1AR standard when validating 554 IDevIDs. 556 TEAP servers SHOULD reject LDevIDs with expired certificates and 557 SHOULD NOT allow clients to connect with recently expired LDevIDs. 558 If a client presents a recently expired LDevID it SHOULD be forced to 559 authenticate using its IDevID and then reenroll to obtain a valid 560 LDevID. 562 4.4. LDevID Subject and Subject Alternative Names 564 BRSKI section 5.9.2 specifies that the pledge MUST send a CSR 565 Attributes request to the registrar. The registrar MAY use this 566 mechanism to instruct the pledge about the identities it should 567 include in the CSR request it sends as part of enrollment. The 568 registrar may use this mechanism to tell the pledge what Subject or 569 Subject Alternative Name identity information to include in its CSR 570 request. This can be useful if the Subject must have a specific 571 value in order to complete enrollment with the CA. 573 4.5. PKCS#10 Retry Handling 575 They will be scenarios where the TEAP server is willing to handle a 576 PKCS#10 request from a client and issue a certificate via a PKCS#7 577 response, however, the TEAP server is unable to immediately 578 completely the request and needs to instruct the client to retry 579 later after a specified time interval. 581 A new Retry-After TLV is defined that the TEAP server uses to specify 582 a retry interval in seconds. New error codes are defined to handle 583 these two alternate retry scenarios. 585 o The TEAP tunnel remains up: The client is instructed to resend the 586 PKCS#10 request after a retry interval but inside the same TEAP 587 tunnel. The TEAP server returns a Retry-After TLV to the client, 588 and returns an Error TLV with a new code in the 1000-1999 range. 590 o The TEAP tunnel is torn down: The client is instructed to 591 establish a new TEAP connection and TEAP tunnel after a retry 592 interval, and resend the PKCS#10 request indside the new tunnel. 593 The TEAP server returns a Retry-After TLV to the client, and 594 returns an Error TLV with a new code in the 2000-2999 range. 596 5. Peer Identity 598 EAP [RFC3748] recommends that "the Identity Response be used 599 primarily for routing purposes and selecting which EAP method to 600 use". NAI [RFC7542] recommends ommitting the username part of an NAI 601 in order to support username privacy, where appropriate. 603 Therefore, the device initially uses the generic identity string of 604 "@IANA-TBD.ARPA" as its NAI when sending the EAP Identity Response 605 message. This informs the authenticator that the device wishes to 606 use the TEAP method. 608 [[ TODO: It is unclear from EAP [RFC3748] how the server should reply 609 if it is not willing to offer the TEAP method. EAP offers no 610 specific error code to indicate the reason why the request is 611 rejected. ]] 613 The TEAP server may specify an NAI that it wishes the device to use. 614 For example, the server may want a bootstrapped device to use an NAI 615 of "abc123@example.com", or simply an NAI of "@example.com". This 616 could be desirable in order to facilitate roaming scenarios. The 617 server can do this by sending the device an NAI TLV inside the TEAP 618 tunnel. 620 If the server specifies an NAI TLV, and the device handles the TLV, 621 the device MUST use the specified NAI in all subsequent EAP 622 authentication flows. If the device is not willing to handle the NAI 623 TLV, it MUST reply with an Error TLV. 625 [[ TODO: It is unclear from EAP how the server should reply in a 626 roaming scenario where a device sends an NAI of "@example.com" and 627 the server is unable to handle the request / is not federated with 628 example.com / cannot reach example.com. EAP offers no specific error 629 code to indicate the reason why the request is rejected. ]] 631 6. Channel and Crypto Binding 633 As the TEAP BRSKI flow does not define or require an inner EAP 634 method, there is no explicit need for exchange of Channel-Binding 635 TLVs between the device and the TEAP server. 637 The TEAP BRSKI TLVs are expected to occur at the beginning of the 638 TEAP Phase 2 and MUST occur before the final Crypto-Binding TLV. 639 This draft does not exclude the possibility of having other EAP 640 methods occur following the TEAP BRSKI TLVs and as such, the Crypto- 641 Binding TLV process rules as defined in [RFC7170] apply. 643 7. Protocol Flows 645 This section outlines protocol flows that map to the three server 646 policy options described in section Section 4.1. The protocol flows 647 illustrate a TLS1.2 exchange. Pertinent notes are outlined in the 648 protocol flows. 650 7.1. TEAP Server Grants Access 652 In this flow, the server grants access as server policy allows the 653 client to access the network based on the identity certificate that 654 the client presented. This means that either (i) the client has 655 previously completed BRSKI and has presented a valid LDevID or (ii) 656 the client presents an IDevID and network policy allows access based 657 purely on IDevID. 659 +----------------+ 660 +--------+ | Authenticator/ | +------+ 661 | Client | | TEAP-Server | | MASA | 662 +--------+ +----------------+ +------+ 663 | EAP-Request/ | | 664 | Type=Identity | | 665 |<------------------------| | 666 | | | 667 | EAP-Response/ | | 668 | Type=Identity | | 669 |------------------------>| | 670 | | | 671 | EAP-Request/ | | 672 | Type=TEAP, | | 673 | TEAP Start, | | 674 | Authority-ID TLV | | 675 |<------------------------| | 676 | | | 677 | EAP-Response/ | | 678 | Type=TEAP, | | 679 | TLS(ClientHello) | | 680 |------------------------>| | 681 | | | 682 | EAP-Request/ | | 683 | Type=TEAP, | | 684 | TLS(ServerHello, | | 685 (1)| Certificate, | | 686 | ServerKeyExchange, | | 687 (2)| CertificateRequest, | | 688 | ServerHelloDone) | | 689 |<------------------------| | 690 | | | 691 | EAP-Response/ | | 692 | Type=TEAP, | | 693 (3)| TLS(Certificate, | | 694 | ClientKeyExchange, | | 695 | CertificateVerify, | | 696 | ChangeCipherSpec, | | 697 | Finished) | | 698 |------------------------>| | 699 | | | 700 | EAP-Request/ | | 701 | Type=TEAP, | | 702 | TLS(ChangeCipherSpec, | | 703 | Finished), | | 704 | {Crypto-Binding TLV, | | 705 | Result TLV=Success} | | 706 |<------------------------| | 707 | | | 708 | EAP-Response/ | | 709 | Type=TEAP, | | 710 | {Crypto-Binding TLV, | | 711 | Result TLV=Success} | | 712 |------------------------>| | 713 | | | 714 | EAP-Success | | 715 |<------------------------| | 717 Figure 1: TEAP Server Grants Access 719 Notes: 721 (1) If the client has completed the BRSKI flow and has locally 722 significant trust anchors, it must validate the Certificate received 723 from the server. If the client has not yet completed the BRSKI flow, 724 then it provisionally accepts the server Certificate and must 725 validate it later once BRSKI is complete. 727 (2) The server may include certificate_authorities field in the 728 CertificateRequest message in order to restrict the identity 729 certificates that the device is allowed present. 731 (3) The device will present its LDevID, if it has one, in preference 732 to its IDevID, if allowed by server policy. 734 7.2. TEAP Server Instructs Client to Perform BRSKI Flow 736 In this flow, the server instructs the client to perform a BRSKI flow 737 by exchanging TLVs once the outer TLS tunnel is established. 739 +----------------+ 740 +--------+ | Authenticator/ | +------+ +----+ 741 | Client | | TEAP-Server | | MASA | | CA | 742 +--------+ +----------------+ +------+ +----+ 743 | EAP-Request/ | | | 744 | Type=Identity | | | 745 |<----------------------------| | | 746 | | | | 747 | EAP-Response/ | | | 748 | Type=Identity | | | 749 |---------------------------->| | | 750 | | | | 751 | EAP-Request/ | | | 752 | Type=TEAP, | | | 753 | TEAP Start, | | | 754 | Authority-ID TLV | | | 755 |<----------------------------| | | 756 | | | | 757 | EAP-Response/ | | | 758 | Type=TEAP, | | | 759 | TLS(ClientHello) | | | 760 |---------------------------->| | | 761 | | | | 762 | EAP-Request/ | | | 763 | Type=TEAP, | | | 764 | TLS(ServerHello, | | | 765 (1)| Certificate, | | | 766 | ServerKeyExchange, | | | 767 | CertificateRequest, | | | 768 | ServerHelloDone) | | | 769 |<----------------------------| | | 770 | | | | 771 | EAP-Response/ | | | 772 | Type=TEAP, | | | 773 | TLS(Certificate | | | 774 | ClientKeyExchange, | | | 775 | CertificateVerify, | | | 776 | ChangeCipherSpec, | | | 777 | Finished) | | | 778 |---------------------------->| | | 779 | | | | 780 | EAP-Request/ | | | 781 | Type=TEAP, | | | 782 | TLS(ChangeCipherSpec, | | | 783 | Finished), | | | 784 | {Crypto-Binding TLV, | | | 785 | Result TLV=Success} | | | 786 |<----------------------------| | | 787 | | | | 788 | EAP-Response/ | | | 789 | Type=TEAP, | | | 790 | {Crypto-Binding TLV, | | | 791 | Result TLV=Success} | | | 792 |---------------------------->| | | 793 | | | | 794 ** At this stage the outer TLS tunnel is established ** 795 ** The following message exchanges are for BRSKI ** 796 | | | | 797 | EAP-Request/ | | | 798 | Type=TEAP, | | | 799 (2)| {Request-Action TLV: | | | 800 | Status=Failure, | | | 801 | Action=Process-TLV, | | | 802 | TLV=Request-Voucher, | | | 803 | TLV=Trusted-Server-Root,| | | 804 | TLV=CSR-Attributes, | | | 805 | TLV=PKCS#10} | | | 806 |<----------------------------| | | 807 | | | | 808 | EAP-Response/ | | | 809 | Type=TEAP, | | | 810 (3)| {Request-Voucher TLV} | | | 811 |---------------------------->| RequestVoucher | | 812 | |--------------->| | 813 | | Voucher | | 814 | |<---------------| | 815 | EAP-Request/ | | | 816 | Type=TEAP, | | | 817 (4)| {Voucher TLV} | | | 818 |<----------------------------| | | 819 | | | | 820 | EAP-Response/ | | | 821 | Type=TEAP, | | | 822 (5)| {Trusted-Server-Root TLV} | | | 823 |---------------------------->| | | 824 | | | | 825 | EAP-Request/ | | | 826 | Type=TEAP, | | | 827 | {Trusted-Server-Root TLV} | | | 828 |<----------------------------| | | 829 | | | | 830 | EAP-Response/ | | | 831 | Type=TEAP, | | | 832 | {CSR-Attributes TLV} | | | 833 |---------------------------->| | | 834 | | | | 835 | EAP-Request/ | | | 836 | Type=TEAP, | | | 837 | {CSR-Attributes TLV} | | | 838 |<----------------------------| | | 839 | | | | 840 | EAP-Response/ | | | 841 | Type=TEAP, | | | 842 | {PKCS#10 TLV} | | | 843 |---------------------------->| | | 844 | | PKCS#10 | | 845 | EAP-Request/ |--------------/ | \----->| 846 | Type=TEAP, | | | 847 | {PKCS#7 TLV, | PKCS#7 | | 848 (6)| Result TLV=Success} |<-------------/ | \------| 849 |<----------------------------| | | 850 | | | | 851 | EAP-Response/ | | | 852 | Type=TEAP, | | | 853 | {Result TLV=Success} | | | 854 |---------------------------->| | | 855 | | | | 856 | EAP-Success | | | 857 |<----------------------------| | | 859 Figure 2: TEAP Server Instructs Client to Perform BRSKI Flow 861 Notes: 863 (1) If the client has not yet completed the BRSKI flow, then it 864 provisionally accepts the server certificate and must validate it 865 later once BRSKI is complete. The server validates the client 866 certificate using its trust anchor database. 868 (2) The server instructs the client to start the BRSKI flow by 869 sending a Request-Action TLV that includes a BRSKI-RequestVoucher 870 TLV. The server also instructs the client to request trust anchors, 871 to request CSR Attrites, and to initiate a PKCS certificate 872 enrolment. As outlined in [RFC7170], the Request-Action TLV is sent 873 after the Crypto-Binding TLV and Result TLV exchange. 875 (3) The client includes the certificate it received from the server 876 in the RequestVoucher message. 878 (4) Once the client receives and validates the voucher signed by the 879 MASA, it must verify the certificate it previously received from the 880 server. 882 (5) As outlined in [RFC7170], the Trusted-Server-Root TLV is 883 exchanged after the Crypto-Binding TLV exchange, and after the client 884 has used the Voucher to authenticate the TEAP server identity. This 885 is equivalent to section [todo] from 886 [I-D.ietf-anima-bootstrapping-keyinfra]. 888 (6) There is no need for an additional Crypto-Binding TLV exchange as 889 there is no inner EAP method. All BRSKI exchanges are simply TLVs 890 exchanged inside the outer TLS tunnel. 892 7.3. TEAP Server Instructs Client to Reenroll 894 In this flow, the server instructs the client to reenroll and get a 895 new LDevID by exchanging TLVs once the outer TLS tunnel is 896 established. 898 +----------------+ 899 +--------+ | Authenticator/ | +------+ +----+ 900 | Client | | TEAP-Server | | MASA | | CA | 901 +--------+ +----------------+ +------+ +----+ 902 | EAP-Request/ | | | 903 | Type=Identity | | | 904 |<------------------------| | | 905 | | | | 906 | EAP-Response/ | | | 907 | Type=Identity | | | 908 |------------------------>| | | 909 | | | | 910 | EAP-Request/ | | | 911 | Type=TEAP, | | | 912 | TEAP Start, | | | 913 | Authority-ID TLV | | | 914 |<------------------------| | | 915 | | | | 916 | EAP-Response/ | | | 917 | Type=TEAP, | | | 918 | TLS(ClientHello) | | | 919 |------------------------>| | | 920 | | | | 921 | EAP-Request/ | | | 922 | Type=TEAP, | | | 923 | TLS(ServerHello, | | | 924 | Certificate, | | | 925 | ServerKeyExchange, | | | 926 | CertificateRequest, | | | 927 | ServerHelloDone) | | | 928 |<------------------------| | | 929 | | | | 930 | EAP-Response/ | | | 931 | Type=TEAP, | | | 932 | TLS(Certificate, | | | 933 | ClientKeyExchange, | | | 934 | CertificateVerify, | | | 935 | ChangeCipherSpec, | | | 936 | Finished) | | | 937 |------------------------>| | | 938 | | | | 939 | EAP-Request/ | | | 940 | Type=TEAP, | | | 941 | TLS(ChangeCipherSpec, | | | 942 | Finished), | | | 943 | {Crypto-Binding TLV, | | | 944 | Result TLV=Success} | | | 945 |<------------------------| | | 946 | | | | 947 | EAP-Response/ | | | 948 | Type=TEAP, | | | 949 | {Crypto-Binding TLV, | | | 950 | Result TLV=Success} | | | 951 |------------------------>| | | 952 | | | | 953 | EAP-Request/ | | | 954 | Type=TEAP, | | | 955 (1)| {Request-Action TLV: | | | 956 | Status=Failure, | | | 957 | Action=Process-TLV, | | | 958 | TLV=PKCS#10} | | | 959 |<------------------------| | | 960 | | | | 961 | EAP-Response/ | | | 962 | Type=TEAP, | | | 963 | {PKCS#10 TLV} | | | 964 |------------------------>| | | 965 | | PKCS#10 | | 966 | EAP-Request/ |--------------/ | \----->| 967 | Type=TEAP, | | | 968 | {PKCS#7 TLV, | PKCS#7 | | 969 | Result TLV=Success} |<-------------/ | \------| 970 |<------------------------| | | 971 | | | | 972 | EAP-Response/ | | | 973 | Type=TEAP, | | | 974 | {Result TLV=Success} | | | 975 |------------------------>| | | 976 | | | | 977 | EAP-Success | | | 978 |<------------------------| | | 980 Figure 3: TEAP Server Instructs Client to Reenroll 982 (1) The server instructs the client to reenroll by sending a Request- 983 Action TLV that includes a PKCS#10 TLV. 985 7.4. Out of Band Reenroll 987 This section shows how the device does a reenroll to refresh its 988 LDEvID directly against the registrar outside the context of the TEAP 989 tunnel. 991 8. TEAP TLV Formats 993 8.1. New TLVs 995 This document defines 5 new TEAP TLVs. The following table indicates 996 whether the TLVs can be included in Request messages from TEAP server 997 to device, or Response messages from device to TEAP server. 999 +------------------------+----------+ 1000 | TLV | Message | 1001 +------------------------+----------+ 1002 | BRSKI-VoucherRequest | Response | 1003 | BRSKI-Voucher | Request | 1004 | CSR-Attributes | Response | 1005 | Retry-After | Response | 1006 | NAI-Identity | Request | 1007 +------------------------+----------+ 1009 These new TLVs are detailed in this section. 1011 8.1.1. BRSKI-RequestVoucher TLV 1013 This TLV is used by the server as part of a Request-Action TLV to 1014 request from the peer that it initiate a voucher request. When used 1015 in this fashion, the length of this TLV will be set to zero. The 1016 Status field of the Request-Action TLV MUST be set to Failure. 1018 It is also used by the peer to initiate the voucher request. When 1019 used in this fashion, the length of the TLV will be set to that of 1020 the voucher request, as encoded and described in Section 3.3 in 1021 [I-D.ietf-anima-bootstrapping-keyinfra]. 1023 0 1 2 3 1024 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 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 |M|R| TLV=TBD1-VoucherRequest | Length | 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Value... 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 The M and R bits are always expected to be set to 0. 1033 The server is expected to forward the voucher request to the MASA, 1034 and then return a voucher in a BRSKI-Voucher TLV as described below. 1035 If it is unable to do so, it returns an TEAP Error TLV with one of 1036 the defined errors or the following: 1038 TBD2-MASA-Notavailable MASA unavailable 1039 TBD3-MASA-Refused MASA refuses to sign the voucher 1041 The peer terminates the TEAP connection, but may retry at some later 1042 point. The backoff mechanism for such retries should be appropriate 1043 for the device. Retries MUST occur no more frequently than once 1044 every two (TBD) minutes. 1046 8.1.2. BRSKI-Voucher TLV 1048 This TLV is transmitted from the server to the peer. It contains a 1049 signed voucher, as describe in [RFC8366]. 1051 0 1 2 3 1052 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 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 |M|R| TLV=TBD4-Voucher | Length | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | Value... 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 Upon receiving this TLV the peer will validate the signature of the 1060 voucher, using its pre-installed manufacturer trust anchor (LDevID). 1061 It MUST also validate the certificate used by the server to establish 1062 the TLS connection. 1064 If successful, it installs the new trust anchor contained in the 1065 voucher. 1067 Otherwise, the peer transmits an TEAP error TLV with one of the 1068 following error messages: 1070 TBD5-Invalid-Signature The signature on the voucher is invalid 1071 TBD6-Invalid-Voucher The form or content of the voucher is invalid 1072 TBD7-Invalid-TLS-Signer The certificate used for the TLS connection 1073 could not be validated. 1075 8.1.3. CSR-Attributes TLV 1077 The server SHALL transmit this TLV to the peer, either along with the 1078 BRSKI-Voucher TLV or at any time earlier in a communication. The 1079 peer shall include attributes required by the server in any following 1080 CSR. The value of this TLV is the base64 encoding described in 1081 Section 4.5.2 of [RFC7030]. 1083 The TEAP server MAY use this TLV to specify the subject identity 1084 information to include in Subject or Subjecet Alternate Name fields 1085 in any following CSR. 1087 0 1 2 3 1088 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 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 |M|R| TLV=TBD8-CSR-Attributes | length | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | Value... 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 Again, the M and R values are set to 0. In the case where the client 1096 is unable to provide the requested attributes, an TEAP-Error is 1097 returned as follows: 1099 TBD9-CSR-Attribute-Fail Unable to supply the requested attributes. 1101 8.1.4. Retry-After TLV 1103 The server MUST transmit this TLV to the peer when repling to a 1104 PKCS#10 TLV request from the peer where the server is willing to 1105 fulfill the request and issue a certificate via a PKCS#7 response, 1106 but is unable to fulfill the request immediately. This TLV is used 1107 to tell the peer the mimimum lenght of time it MUST wait before 1108 resending the PKCS#10 request. The value of this TLV is the time in 1109 seconds that the peer MUST wait before resending the PKCS#10 request. 1110 The peer MUST resend the exact same PKCS#10 request. 1112 0 1 2 3 1113 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 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 |M|R| TLV=TBD10-Retry-After | length | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Value... 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 Again, the M and R values are set to 0. 1122 8.1.5. NAI TLV 1124 The server may use this TLV to provision a realm-specific NAI on the 1125 device. 1127 0 1 2 3 1128 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 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 |M|R| TLV=TBD10-NAI | length | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Value... 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 Again, the M and R values are set to 0. 1137 8.2. Existing TEAP TLV Specifications 1139 This section documents allowed usage of existing TEAP TLVs. The 1140 definition of the TLV is not changed, however clarifications on 1141 allowed values for the TLV fields is documented. 1143 8.2.1. PKCS#10 TLV 1145 [RFC7170] defines the PKCS#10 TLV as follows: 1147 0 1 2 3 1148 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 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 |M|R| TLV Type | Length | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | PKCS#10 Data... 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1155 [RFC7170] does not explicitly allow a Length value of zero. 1157 A Length value of zero is allowed for this TLV when the TEAP server 1158 sends a Request-Action TLV with a child PKCS#10 TLV to the client. 1159 In this scenario, there is no PKCS#10 Data included in the TLV. 1160 Clients MUST NOT send a zero length PKCS#10 TLV to the server. 1162 8.3. TLV Rules 1164 BRSKI TLVs can only be transported inside the TLS tunnel. The 1165 following table provides a guide to which TLVs may be encapsulated in 1166 which kind of packets, and in what quantity. The messages are as 1167 follows: Request is a TEAP Request, Response is a TEAP Response, 1168 Success is a message containing a successful Result TLV, and Failure 1169 is a message containing a failed Result TLV. 1171 The following define the meaning of the table entries in the sections 1172 below: 1174 0 This TLV MUST NOT be present in the message. 1176 0+ Zero or more instances of this TLV MAY be present in the message. 1178 0-1 Zero or one instance of this TLV MAY be present in the message. 1180 1 Exactly one instance of this TLV MUST be present in the message. 1182 Request Response Success Failure TLVs 0 0-1 0 0 BRSKI-VoucherRequest 1183 0-1 0 0 0 BRSKI-Voucher 0 0-1 0 0 CSR-Attributes 1185 9. Fragmentation 1187 TEAP is expected to provide fragmentation support. Thus EAP-TEAP- 1188 BRSKI does not specifically provide any, as it is only expected to be 1189 used as an inner method to TEAP. 1191 10. IANA Considerations 1193 The IANA is requested to add entries into the following tables: 1195 The following new TEAP TLVs are defined: 1197 TBD1-VoucherRequest Described in this document. 1198 TBD4-Voucher Described in this document. 1199 TBD8-CSR-Attributes Described in this document. 1200 TBD10-Retry-After Described in this document. 1202 The following TEAP Error Codes are defined, with their meanings 1203 listed here and in previous sections: 1205 TBD2-MASA-Notavailable MASA unavailable 1206 TBD3-MASA-Refused MASA refuses to sign the voucher 1207 TBD5-Invalid-Signature The signature on the voucher is invalid 1208 TBD6-Invalid-Voucher The form or content of the voucher is invalid 1209 TBD7-Invalid-TLS-Signer The certificate used for the TLS connection 1210 could not be validated. 1211 TBD9-CSR-Attribute-Fail Unable to supply the requested attributes. 1212 TBD11-Retry-PKCS#10 Retry PKCS#10 Request (1000 range code) 1213 TBD12-Retry-PKCS#10 Retry PKCS#10 Request (2000 range code) 1214 TBD13-NAI-Rejected The device will not use the indicated 1215 NAI (1000 range code) 1217 [[ TODO: is there a registry of NAIs that map to TEAP methods? e.g. 1218 @eap-teap.net is reserved to indicate the peer wants to use TEAP 1219 method ]] 1221 11. Security Considerations 1223 BRSKI [I-D.ietf-anima-bootstrapping-keyinfra] provides a zero touch 1224 way for devices to enroll in a certification authority (CA). It 1225 assumes the device has IP connectivity. For networks that will not 1226 grant IP connectivitiy before authenticating (with a local 1227 credential) this poses a Catch-22- can't get on the network without a 1228 credential and can't get a credential without getting on the network. 1230 This protocol provides a way for BRSKI to be in an EAP method which 1231 allows the BRSKI conversation to happen as part of EAP authentication 1232 and prior to obtaining IP connectivity. 1234 The security considerations of 1235 [I-D.ietf-anima-bootstrapping-keyinfra] apply to this protocol. 1236 Running BRSKI through EAP introduces some additional areas of concern 1237 though. 1239 11.1. Issues with Provisionally Authenticated TEAP 1241 This protocol establishes an unauthenticated TLS connection and 1242 passes data through it. Provided that the only messages passed in 1243 this state are self-protected BRSKI messages this does not present a 1244 problem. Passing any other messages or TLVs prior to authentication 1245 of the provisional TLS connection could potentially introduce 1246 security issues. 1248 While the TLS connection is unauthenticated, it must still be 1249 validated to the fullest extent possible. It is critical that the 1250 device and the TEAP server perform all steps in TLS- checking the 1251 validity of the presented certificate, validating the signature using 1252 the public key of the certificate, etc- except ensuring the trust of 1253 the presented certificate. 1255 11.2. Attack Against Discovery 1257 The device discovery technique specified in this protocol is the 1258 standard EAP server discovery process. Since it is trivial to set up 1259 an 802.11 wireless access point and advertise any network, an 1260 attacker can impersonate a legitimate wireless network and attract 1261 unprovisioned pledges. Given that an unprovisioned device will not 1262 know the legitimate network to connect to, it will probably attempt 1263 the first network it finds, making the attack that much easier. This 1264 allows for a "rogue registrar" to provision and take control of the 1265 device. 1267 If the MASA verifies ownership prior to issuance of a voucher, this 1268 attack can be thwarted. But if the MASA is in reduced security mode 1269 and does not verify ownership this attack cannot be prevented. 1270 Registrars SHOULD use the audit log of a MASA when deploying newly 1271 purchased equipment in order to mitigate this attack. 1273 Another way to mitigate this attack is through normal "rogue AP" 1274 detection and prevention. 1276 11.3. TEAP Server as Registration Authority 1278 If the TEAP server is logically separate from the Certification 1279 Authority (CA) (see Section 2) it will be acting as a Registration 1280 Authority (RA) when it obtains the PKCS#10 TLV and replies with a 1281 PKCS#7 TLV (see [RFC7170], Sections 4.2.16 and 4.2.17, respectively). 1282 The assurance a RA makes to a CA is that the public key in the 1283 presented CSR is bound to an authenticated identity in way that will 1284 assure non-repudiation. 1286 To make such an assurance, the TEAP server MUST authenticate the 1287 provisional TLS connection with the device by validating the voucher 1288 response received from the MASA. In addition, it is RECOMMENDED that 1289 the TEAP server indicate that proof-of-possession (see [RFC7170], 1290 Section 3.8.2) is required by including the challengePassword OID in 1291 the CSR Attributes TLV. 1293 11.4. Trust of Registrar 1295 The device accepts a trusted server (CA) certificate and installs it 1296 in its trust anchor database during step 5 (see Section 3.2). This 1297 can happen only after the provisional TLS connection has been 1298 authenticated using the voucher and the Crypto-Binding TLV has been 1299 validated. 1301 12. Acknowledgments 1303 The authors would like to thank Brian Weis for his assistance, and 1304 Alan Dakok for improving language consistency. In addition, with 1305 ruthlessly "borrowed" the concept around NAI handling from Tuomas 1306 Aura and Mohit Sethi. 1308 13. References 1310 13.1. Normative References 1312 [I-D.ietf-anima-bootstrapping-keyinfra] 1313 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 1314 and K. Watsen, "Bootstrapping Remote Secure Key 1315 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 1316 keyinfra-26 (work in progress), August 2019. 1318 [IEEE8021AR] 1319 Institute for Electrical and Electronics Engineers, 1320 "Secure Device Identity", 1998. 1322 [IEEE8021X] 1323 Institute for Electrical and Electronics Engineers, "IEEE 1324 Standard for Local and metropolitan area networks--Port- 1325 Based Network Access Control", 2010. 1327 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1328 Levkowetz, Ed., "Extensible Authentication Protocol 1329 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 1330 . 1332 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 1333 "Enrollment over Secure Transport", RFC 7030, 1334 DOI 10.17487/RFC7030, October 2013, 1335 . 1337 [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, 1338 "Tunnel Extensible Authentication Protocol (TEAP) Version 1339 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, 1340 . 1342 [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, 1343 "A Voucher Artifact for Bootstrapping Protocols", 1344 RFC 8366, DOI 10.17487/RFC8366, May 2018, 1345 . 1347 13.2. Informative References 1349 [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, 1350 DOI 10.17487/RFC7542, May 2015, 1351 . 1353 Appendix A. Changes from Earlier Versions 1355 Draft -03: * Merge EAP server and Registrar * Security considerations 1356 * References improvements * Add Dan Harkins as co-author 1358 Draft -02: * Flow corrections 1360 Draft -01: * Add packet descriptions, IANA considerations, smooth out 1361 language. 1363 Draft -00: 1365 o Initial revision 1367 Authors' Addresses 1369 Eliot Lear 1370 Cisco Systems 1371 Richtistrasse 7 1372 Wallisellen CH-8304 1373 Switzerland 1375 Phone: +41 44 878 9200 1376 Email: lear@cisco.com 1378 Owen Friel 1379 Cisco Systems 1380 170 W. Tasman Dr. 1381 San Jose, CA 95134 1382 United States 1384 Email: ofriel@cisco.com 1386 Nancy Cam-Winget 1387 Cisco Systems 1388 170 W. Tasman Dr. 1389 San Jose, CA 95134 1390 United States 1392 Email: ncamwing@cisco.com 1394 Dan Harkins 1395 HP Enterprise 1396 3333 Scott Boulevard 1397 Santa Clara, CA 95054 1398 United States 1400 Email: dharkins@arubanetworks.com