idnits 2.17.1 draft-dekok-emu-eap-usability-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC7585, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC12, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- No information found for rfc12 - is the name correct? -- The document date (12 July 2021) is 1017 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) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) == Outdated reference: A later version (-21) exists of draft-ietf-emu-eap-tls13-15 == Outdated reference: A later version (-10) exists of draft-josefsson-pppext-eap-tls-eap-06 -- Obsolete informational reference (is this intentional?): RFC 2716 (Obsoleted by RFC 5216) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group DeKok, Alan 3 INTERNET-DRAFT Network RADIUS 4 Updates: 7585 12 July 2021 5 Category: Standards Track 6 Expires: January 12, 2022 8 EAP Usability 9 draft-dekok-emu-eap-usability-00.txt 11 Abstract 13 This document defines methods which enable simpler deployment of TLS- 14 based EAP methods. It defines new certificate fields, and uses 15 existing certificate fields in order describe new methods for 16 bootstrapping security. The methods defined here change TLS-based 17 EAP supplicant configuration from a complex and insecure process to 18 one that is automated, and is essentially trivial. These methods are 19 still, however, compatible with existing standards and practices. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 12, 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info/) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction ............................................. 5 62 1.1. Requirements Language ............................... 6 63 2. Historical Problems ...................................... 7 64 2.1. Supplicant Changes over Time ........................ 7 65 2.1.1. Phone Vendor One ............................... 7 66 2.1.2. Phone Vendor Two ............................... 8 67 2.1.3. Operating System Vendor One .................... 9 68 2.1.4. Operating System Vendor Two .................... 9 69 2.1.5. Operating System Vendor Three .................. 9 70 2.2. Problems with Certificates .......................... 10 71 2.2.1. Problematic Use of Certificate Stores .......... 10 72 2.2.2. Problematic use of key purpose fields .......... 11 73 2.2.3. Problematic Use of Certificates ................ 12 74 2.2.4. Obtaining Certificates with the new OIDs ....... 13 75 3. Principles and Guidelines ................................ 15 76 3.1. Network Configuration Guidelines .................... 15 77 4. New Recommendations for Certificates with EAP ............ 17 78 4.1. Comparison to HTTPS ................................. 17 79 4.2. Additional Information Required ..................... 18 80 5. How It Works in Practice ................................. 19 81 5.1. A worked example for EAP-TLS ........................ 19 82 5.1.1. The Problem Statement .......................... 19 83 5.1.2. Obtaining the Certificates ..................... 20 84 5.1.3. Configuring the end user device ................ 21 85 5.1.4. Obtaining Network Access ....................... 22 86 5.2. Other TLS-based EAP methods ......................... 23 87 5.3. EAP methods which do not use TLS .................... 24 88 5.4. Other Methods of Provisioning ....................... 24 89 5.5. Trust on First Use Can be Secure .................... 25 90 5.6. Additional Considerations ........................... 26 91 6. Extending the Solution ................................... 28 92 6.1. Bootstrapping via EST ............................... 28 93 6.1.1. Closing the loop ............................... 29 94 6.2. Bootstrapping via DNS ............................... 30 95 6.2.1. CERT records ................................... 30 96 6.2.2. CERT record labels for Server Certificates ..... 32 97 6.2.3. CERT record labels for CA Certificates ......... 32 98 7. Related issues ........................................... 33 99 7.1. Provisioning Issues ................................. 33 100 7.1.1. Bootstrapping via a Separate Network ........... 33 101 7.1.2. Configuration Change is just Refresh ........... 34 102 7.1.3. Secure versus Insecure Provisioning ............ 35 103 7.2. Issues related to Security .......................... 35 104 7.2.1. Why id-on-naiRealm ............................. 36 105 7.2.2. Resumption ..................................... 36 106 7.2.3. Choosing EAP Types ............................. 37 107 7.2.4. User Experience ................................ 37 108 7.3. Issues related to Certificates ...................... 38 109 7.3.1. Public CA versus Private CA .................... 38 110 7.3.2. Limitations of public CAs ...................... 39 111 7.3.3. CA Chains ...................................... 40 112 7.3.4. Delegated Authentication ....................... 41 113 7.3.5. Identification of Networks ..................... 41 114 7.4. Anti-solutions ...................................... 42 115 7.4.1. MDM Products Are not the Solution .............. 42 116 7.4.2. EST and similar protocols do not solve all of th 44 117 7.4.3. Captive Portals and Hotspots ................... 45 118 7.5. id-kp-eapOverLAN May not be sufficient .............. 45 119 7.6. Guest Networks ...................................... 45 120 7.7. Using TLS with protocols other than EAP ............. 47 121 8. Moving to the new methods ................................ 48 122 8.1. Using the new OIDs .................................. 48 123 8.2. Recommendations for EAP peers and authenticators .... 49 124 8.3. Principles and Guidelines ........................... 51 125 9. Security Considerations .................................. 52 126 9.1. On Identities and Service Discovery ................. 52 127 9.2. Password Hashing and Storage ........................ 52 128 10. IANA Considerations ..................................... 53 129 10.1. Key Purpose OIDs ................................... 53 130 10.2. Underscored and Globally Scoped DNS Node Names ..... 54 131 11. References .............................................. 54 132 11.1. Normative References ............................... 54 133 11.2. Informative References ............................. 55 135 1. Introduction 137 TLS [RFC8446] has been widely deployed, and is used with EAP 138 [RFC3748] and with RADIUS [RFC2865]. Historically, these 139 specifications have been written to define the protocols "on the 140 wire", with minimal description of use-cases and usability. The 141 success of these specifications has been that perhaps a billion 142 devices use EAP. The failure of these specifications is that EAP can 143 be still difficult to use, both for administrators and for end users. 145 Even with a clear standard, implementations do not always follow the 146 specifications exactly. In some cases implementations do less than 147 what is recommended, which can cause security and inter-operability 148 issues. In other cases, implementors do more than what is 149 recommended, as they have found the specifications insufficient to 150 address practical requirements. In other cases, there is no 151 standard, so implementators make individual choices as to how their 152 implementations work. Even worse, implementors change their 153 implementations over time, to solve problems which are not addressed 154 in the standards. 156 All of these issues lead to confusion for end users and 157 administrators. These issues lead to decreased security of the 158 protocols, and decreased trust in the protocols. 160 The result of the above problems is software where many critical 161 aspects of its operation are vendor-defined. This wide variation 162 gives a poor experience for all parties involved, and contributes to 163 decreased security. 165 This document therefore defines method to enable the simple and easy 166 deployment of TLS-based EAP methods. It defines new certificate 167 fields, and describes how those fields can be used to gain network 168 access easily and securely. The processes it defines are clear and 169 straightforward. The end user experience is understandable, and 170 difficult to get wrong. 172 That is, this specification removes the need to rely on end users to 173 make security decisions. History shows us that such reliance is 174 misplaced. Instead, we rely on the global certificate system which 175 has proven to work well, along with a few changes to the behavior of 176 EAP systems. 178 These ideas are not new. [RFC4334] Section 1 says: 180 Automated selection of client certificates for use with PPP and 181 IEEE 802.1X is highly desirable. By using certificate extensions 182 to identify the intended environment for a particular certificate, 183 the need for user input is minimized. 185 We extend the above statements to include server certificates, and to 186 further define automated processes by which. In addition, where 187 [RFC4334] describes the "automated selection of client certificates", 188 we invert that use-case to show how certificates can be used to 189 automate network configuration, via a set of simple and clearly 190 defined processes. 192 The document begins with an overview of the current situation. We 193 describe the problems which have motivated this document. First by 194 showing how the behavior of multiple vendor implementations has 195 changed over time. We then discuss problems with the ways that 196 certificate are handled. We discuss how the standards contradict 197 each other, and how current practices contradict, ignore, or extend 198 the standards in incompatible ways. 200 The document begins with a worked example, initially just for EAP- 201 TLS, and then showing how the processes described for EAP-TLS can be 202 easily applied to other EAP methods. 204 We extend the given solution by using DNS and HTTPS to perform 205 initial bootstrapping of the supplicant configuration. We show how 206 supplicants can be configured securely by leveraging the existing 207 trust in the web PKI. This bootstrapping requires no changes to 208 supplicant code or behavior. 210 We finally summarize the work by giving a set of specific 211 recommendations. 213 1.1. Requirements Language 215 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 216 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 217 "OPTIONAL" in this document are to be interpreted as described in BCP 218 14 [RFC2119] [RFC8174] when, and only when, they appear in all 219 capitals, as shown here. 221 2. Historical Problems 223 There have historically been a number of issues with configuring 224 devices for EAP authentication. The overly positive description of 225 this history is that it has resulted in a wide variety of tools and 226 products available to configure EAP on end-user devices. In addition 227 to the wide variety of configuration products, the behavior of native 228 supplicants has also varied widely over time. 230 These issues point to an underlying problem which has, as yet, been 231 unresolved. Each vendor of configuration products or devices to be 232 configured has largely been performing searches by "trial and error" 233 in order to find the best user experience. The result, of course, 234 has been a frustrating experience for both users and for vendors. 236 We do not discuss Mobile Device Management (MDM) vendors or vendors 237 of other supplicant configuration products here. Their products are 238 largely tools which use the APIs presented by supplicant vendors, and 239 attempt to hide the complexity from end users. 241 We also do not discuss the behavior of EAP servers (authenticators) 242 or RADIUS servers. The issues seen by supplicants are largely 243 related to user experience, and have little effect on the "on the 244 wire" protocol. As such, RADIUS servers have been required to make 245 correspondingly fewer changes to their implementations. In addition, 246 RADIUS servers are generally designed to be complex, with complex 247 policies. These policies enable their administrators to change the 248 behavior of the software without resorting to product upgrades. 250 As a result, we focus initially on supplicants, how their behavior 251 has changed over time, and the publicly visible effects of those 252 changes. 254 2.1. Supplicant Changes over Time 256 In this section we discuss how the behavior of multiple supplicants 257 has changed over time. We do not name the vendors of these 258 supplicants, as there is no need to blame them for being unable to 259 solve an industry-wide problem. 261 2.1.1. Phone Vendor One 263 This vendor has been gradually disabling the supplicant 264 configuraration API. Instead, configuration product vendors are able 265 to influence the user interface with suggested prompts at different 266 points in the authentication framework. 268 It appears that the goal is to give the user control over the 269 network. A related goal is to require the user's consent before 270 making changes to the network. 272 The system also treats SSIDs as defining a location, even though 273 SSIDs are not inherently location-specific. This mislabelling means 274 that users' are shown prompts about location, when in fact the 275 operation being performed is connecting to an SSID. 277 The effect of these issues is that the user is unable to meaningfully 278 consent. There may insufficient information available, the available 279 information may be meaningless to the end user, or the information 280 given to the end user is simply wrong. 282 This vendor has changed how manual connections are managed over time. 283 The user is not always prompted, but the systems behavior has gone 284 through the following changes to connection requirements: 286 * do not perform certificate validation * validate that the root CA 287 is in the system certificate store * validate that the root CA is in 288 the WiFi certificate store * require a DNS name for the RADIUS 289 server. 291 None of these solutions are optimal. 293 2.1.2. Phone Vendor Two 295 This vendor has a standard format for WiFi configuration files. The 296 user can manually install the configuration, but that configuration 297 is not active until an additional manual step is performed to enable 298 it. 300 A standard configuration is useful, but the configuration file is not 301 typically signed, even though that is supported. It appears that the 302 the manual enablement step is an attempt to work around the lack of 303 authentication for the configuration files. 305 As was seen in the previous section, the end user has no meaningful 306 information about the configuration. This lack of information means 307 that the user is conditioned to simply accept the configuration and 308 enable it, without paying attention to its contents. 310 This vendor does, however, provide a robust API. This API permits a 311 rich ecosystem of MDM products which automate the configuration of 312 end-user devices. 314 2.1.3. Operating System Vendor One 316 This vendor has been gradually disabling their WLAN API. The 317 remaining APIs permit MDM solutions to associate a user identity with 318 a particular network. However, there is no ability to set a root CA 319 or a RADIUS server DNS host name. 321 When the user connects to the network, a prompt is shown which asks 322 the user if the server is valid. The server certificate is presented 323 to the user, but the user has no information about which root CA is 324 acceptable or not. Instead, the user is shown fields from an unknown 325 certificate, and is asked to validate that the certificate is 326 acceptable. 328 Again, the user has insufficient information to meaningfully consent. 329 Which again means that the only course of action is to mindlessly 330 click on "accept". 332 2.1.4. Operating System Vendor Two 334 This vendor retains a rich WLAN API, but has removed the ability to 335 configure specific users. Instead, only system-wide profiles can be 336 set. 338 This vendor provides for easy installation of additional root CAs, 339 but those root CAs are permitted to be used for any purpose. Which 340 means that a malicious private CA can issue HTTPS certificates for 341 any domain. These fake certificates will be silently accepted by the 342 systems browser as being valid. The user will be unable to 343 distinguish malicious sites presenting those fake certificates from 344 the genuine domains. 346 It is difficult to overstate the negative security impact of that 347 process. 349 An MDM product adding a private CA generally requires a privileged 350 account to install the CA. A user can install a CA manually, but the 351 operating system will show the user large amounts of text in order to 352 warn the user about the security issues of this process. The user, 353 of course, has no way of understanding many of these warnings, and is 354 left again to mindlessly click on "accept". 356 2.1.5. Operating System Vendor Three 358 This vendor retains a rich WLAN API, and a number of tools by which 359 network configuration can be performed. These tools are widely used 360 by MDM vendors to automate the configuration of networks. 362 However, the end user experience is still complex. The user still 363 must manually select each individual parameter from multiple options. 364 This capability gives the user a substantial amount of control over 365 the process, but does not provide any more information than is 366 available in other operating systems. 368 This process of allowing the end user to configure everything is 369 useful for experienced and knowledgable users. However, it leaves 370 the average user with a bewildering set of choices, most of which are 371 meaningless or opaque. The user is then left to mindlessly follow 372 online guides, which may or may not work, and which do not give the 373 user enough information to give informed consent for the actions that 374 are being taken. 376 2.2. Problems with Certificates 377 The widely (and wildly) changing behavior of supplicant software is 378 not the end of the story, however. There are a large number of 379 problems related to the use and abuse of certificates. These issues 380 are discussed in more detail in this section. 382 2.2.1. Problematic Use of Certificate Stores 384 Some EAP peers use a different certificate store for EAP than for 385 other (e.g. web) applications. In practice, the use-case of 386 "downloading video from a known source" is substantially different 387 from the use-case of "sending authentication credentials to a known 388 destination". As such, the certificate stores should be different 389 for these two use-cases. 391 When a CA is allowed to be used for EAP, then the implication is that 392 all certificates signed by that CA are allowed to be used for EAP. 393 This result is not secure. It permits attackers to get a valid 394 server certificate from a public CA, and then to set up an EAP 395 server. Naive EAP peers will then send user credentials to the 396 malicious server. Worse, there is no general way for any third-party 397 to detect that this impersonation has happened. It is only visible 398 to EAP peers who are in a small geographic area. 400 Tests have shown that in a university environment, up to fifty 401 percent of EAP peers will connect to a malicious SSID without 402 checking the CA or server certificate. In effect, these peers will 403 send authentication credentials to anyone who asks. 405 The security problems associated with such behavior cannot be 406 overstated. 408 However, not all EAP peers uses separate certificate stores. Using 409 one certificate store is less of an issue when "self signed" or 410 "private" CAs are used. The use of private CAs for EAP means that 411 the EAP system is now more secure. However, the addition of private 412 CAs to a global certificate store means that those private CAs can 413 now issue certificates for well-known public web sites. The 414 possibility of such forgery has made it difficult for MDM vendors or 415 site administrators to create and use private CAs. 417 As such, we reiterate that the certificate stores SHOULD be different 418 for these each application or use-case. Where the system cannot 419 tolerate multiple different stores, it SHOULD at least mark each CA 420 certificate with an annotation as to its intended purpose. While 421 there is a "key purpose" field defined for certificates, we will see 422 that this field is not always suitable for differentiating 423 certificate purposes. 425 2.2.2. Problematic use of key purpose fields 427 [RFC5216] Section 5.3 makes the following recommendations about the 428 certificate used by the EAP-TLS server: 430 In the case of the EAP-TLS peer, this involves ensuring that the 431 certificate presented by the EAP-TLS server was intended to be 432 used as a server certificate. Implementations SHOULD use the 433 Extended Key Usage (see Section 4.2.1.13 of RFC3280) extension and 434 ensure that at least one of the following is true: 435 1) The certificate issuer included no Extended Key Usage 436 identifiers in the certificate. 437 2) The issuer included the anyExtendedKeyUsage identifier in the 438 certificate ... 439 3) The issuer included the id-kp-serverAuth identifier in the 440 certificate ... 442 These recommendations have also been used in EAP-TLS [EAPTLS], EAP- 443 TTLS [RFC5281], PEAP [PEAP] and [MSPEAP], EAP-FAST [RFC4851], and 444 TEAP [RFC7170]. 446 We first note that this document extends and strengthens the 447 suggestion that systems ensure "that the certificate presented by the 448 EAP-TLS server was intended to be used as a server certificate." We 449 also extend this recommendation to client certificates, further 450 strengthening the security around TLS-based EAP methods. 452 However there is an issue with the [RFC5216] recommendations. These 453 recommendations appear to be in direct conflict with the definition 454 of id-kp-serverAuth from [RFC5280] 4.2.1.12, and of the requirements 455 for its usage: 457 If the extension is present, then the certificate MUST only be 458 used for one of the purposes indicated. If multiple purposes are 459 indicated the application need not recognize all purposes 460 indicated, as long as the intended purpose is present. 461 ... If a certificate contains both a key usage extension and an 462 extended key usage extension, then both extensions MUST be 463 processed independently and the certificate MUST only be used for 464 a purpose consistent with both extensions. If there is no purpose 465 consistent with both extensions, then the certificate MUST NOT be 466 used for any purpose. 467 ... 468 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 469 -- TLS WWW server authentication 471 This definition shows that id-kp-serverAuth is intended for "WWW 472 server" usage, which is in conflict with how it is defined in 473 [RFC5216]. Similar issues exist for the id-kp-clientAuth OID, in 474 that it is intended for "WWW client", which is not correct for EAP. 476 It appears that the recommendations made in [RFC5216] were taken from 477 [RFC2716], and were made for entirely practical reasons. The desire 478 was for users of EAP to be able to obtain certificates from public 479 root CAs. However, those root CAs could not (or would not) issue 480 certificates which contained OIDs other than id-kp-serverAuth. 481 Therefore as work around, [RFC5216] Section 5.3 allowed for a wide 482 variety of EKUs to be used in server certificates. These 483 certificates could then come from private CAs, or from publicly known 484 root CAs. 486 We believe that the long-term correct solution is to define and use 487 additional key purpose OIDs. These key purpose OIDs can initially be 488 used by EAP implementations along with private CAs. As support for 489 these OIDs becomes more widely available, it may be possible for 490 public CAs to issue purpose-specific certificates. 492 The problematic use of id-kp-serverAuth has had a number of impacts, 493 past the issue of contradictory specifications. These impacts result 494 in certificates being used in problematic ways, which we discuss 495 below. 497 2.2.3. Problematic Use of Certificates 499 The current workarounds to the contradictions in the specifications 500 are two-fold. One, is simply to get certificates with id-kp- 501 serverAuth from a public CA, and hope that using it for EAP either is 502 acceptable, or that it is not noticed. Another is to use a self- 503 signed CA. Both work-arounds have problems. 505 Many people prefer to use public CAs, as they are seen as "better" 506 than self-signed CAs. However, using a public CA likely means 507 violating the terms of use of that CA. Which means that the network 508 continues to work so long as this mis-use is not reported. 510 It can be useful instead to use private CA. A private CA can add id- 511 kp-serverAuth without violating any terms of use, or it can omit the 512 key purpose OIDs, or it can add custom key purpose OIDs. 514 However, in addition to the problems noted in the earlier section, 515 private CAs are not installed by default in client devices. This 516 limitation means that these CAs must be provisioned somehow. As seen 517 above, these provisioning methods can be complex and prone to 518 failure. 520 As such, there is no simple, easy, way for administrators to both 521 obtain and provision certificates for use with EAP. 523 We also note that these OIDs are used not only for EAP, but that they 524 are also used for other public-facing TLS services such as XMPP, 525 SMTPS, LDAPS, etc. Those protocols may have similar issues with 526 alleged mis-use of these OIDs. If these use-cases are forbidden user 527 CAB guidelines, then this would seem to be a serious problem with the 528 global certificate framework. 530 We leave the solution of these issues as a point of discussion for 531 the wider Internet community. 533 2.2.4. Obtaining Certificates with the new OIDs 535 Most CAs currently offer limited support for non-"WWW" OIDs in 536 certificates. In many cases, the Certificate Signing Request (CSR) 537 supplied by the customer is (in practice) used only as a vague 538 suggestion. While the CA generally does not add any fields, it may 539 drop fields that it does not recognize or support. Or, the CA may 540 discard the CSR entirely. 542 [CAB] Section 7.1.2.3 makes it difficult for existing CAs to issue 543 client certificates which contain the new OIDs: 545 Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth 546 [RFC5280] or both values MUST be present. id-kp-emailProtection 547 [RFC5280] MAY be present. Other values SHOULD NOT be present. The 548 value anyExtendedKeyUsage MUST NOT be present. 550 Further, the requirements of [CAB] Section 7.1.2.4 essentially 551 forbids CAs from signing certificates which are intended for use with 552 EAP: 554 CAs SHALL NOT issue a Certificate with: 556 a. Extensions that do not apply in the context of the public 557 Internet (such as an extKeyUsage value for a service that is only 558 valid in the context of a privately managed network), unless: 560 None of the reasons listed after "unless" allow for CAs to issue 561 certificates for use with EAP in a privately managed network. 563 This behavior by CAs makes it difficult in practice, if not 564 impossible, to obtain non-"WWW" certificates from a public CA. 566 The suggestion given here is to simply use self-signed CAs. This 567 suggestion is not always practical. 569 It is possible to define CAs for "walled gardens" with a private CA. 570 One example is certificates used internally in an organization, or in 571 a group such as Eduroam [RFC7593] and [EDUROAM]. In those 572 situations, the members requesting certificates have already 573 validated, and there is already a legal framework in place to protect 574 the parties. 576 Other suggestions have been that it is relatively simple to set up a 577 new CA, with new procedures and requirements. Given the regulatory 578 requirements around CAs, it appears that new public-facing CAs have 579 to be well funded. i.e. requiring many millions of dollars. It is 580 therefore difficult, if not impossible, for small public-facing CAs 581 to be created. 583 The goal of this document is to permit better behavior for EAP peers 584 and authenticators. If this specification is widely deployed, then 585 there may be sufficient demand for CAs to offer new certificates 586 which are marked as fit for their intended purpose. 588 3. Principles and Guidelines 590 After analysis of the historical practices and standards for EAP, we 591 came to a set of guidelines which are outlined in this section. 592 Application of these guidelines drove the rest of the specification 593 which we define herein. 595 3.1. Network Configuration Guidelines 597 It is RECOMMENDED that the guidelines given below are followed when 598 developing new network configuration standards and methods: 600 * Automated provisioning is strongly preferred to manual 601 provisioning. We define "automated provisioning" as provisioning 602 which is performed via software, with little or no user 603 intervention. Automation minimizes the possibility for end users 604 to create broken or insecure configurations. 606 * Manual provisioning should be limited to "Trust on first use" 607 (ToFU), and cached or "pinned" after that. That is, manual 608 provisioning should be limited to allowing a user to approve 609 validation decisions which have been made by the system. 611 * Relying on end users to manually configure complex systems 612 is strongly discouraged. Complex systems are difficult to 613 configure, and improperly configured systems create many issues 614 related to security, usability, and network access. 616 * Configuration should be "pinned" in order to permit systems to 617 detect and prevent unauthorized changes, and to detect malicious 618 networks which claim to be updated versions of the true network. 620 * The identity and role of both parties should be exchanged, and 621 verified. In practice, this suggestion often means that TLS-based 622 EAP methods are preferred to ones which only do name / password 623 credential verification. 625 * The previous requirement usually means that the both parties know 626 which RFC 7542 NAI realm is being used. This realm serves a 627 similar purpose to the the DNS host name used in other TLS-based 628 protocols such as HTTPS. As such, similar methods can be used to 629 validate certificate authenticity. This NAI realm is contained in 630 an id-on-naiRealm field, as defined in [RFC7585] Section 2.2 632 * For TLS-based EAP methods, trust should be based on a 633 certification authority (CA), which signs certificates for a 634 particular realm. If the CA is trusted, then everything derived 635 from that CA can be trusted. If the CA is not trusted, then it is 636 impossible to trust anything derived from an untrusted CA. 638 * CAs should also be associated with permitted uses. For example, a 639 root CA which is trusted for web surfing is not necessarily trusted 640 for use with EAP authentication. In practice this means either 641 having separate certificate stores for different purposes, or 642 annotating root certificates with their permitted uses. 644 We believe that these recommendations are correct, simple, practical, 645 and will improve security and usability for all participants in EAP. 646 We show that there is a clear upgrade path from current behavior to 647 better behavior. Each step of that upgrade path is simple, and 648 involves minimal change for end users or administrators. 650 4. New Recommendations for Certificates with EAP 652 The first step towards a complete solution is to define new OIDs. 653 These OIDs indicate that certificates are intended for use with an 654 EAP server, or an EAP peer. 656 The following key usage purposes are defined within id-kp: 658 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 660 id-kp-eapServer OBJECT IDENTIFIER ::= { id-kp TBD-1 } 661 -- TLS EAP server authentication 662 -- Key usage bits that may be consistent: digitalSignature, 663 -- keyEncipherment or keyAgreement 665 id-kp-eapClient OBJECT IDENTIFIER ::= { id-kp TBD-2 } 666 -- TLS EAP peer authentication 667 -- Key usage bits that may be consistent: digitalSignature, 668 -- and/or keyAgreement 670 These EKU fields mirror id-kp-serverAuth, and id-kp-clientAuth, 671 respectively. 673 We also rely on id-on-naiRealm, as defined in [RFC7585] Section 2.2. 674 This field contains the NAI realm [RFC7542] in which the user has an 675 identity, and for which the EAP server is performing authentication. 677 4.1. Comparison to HTTPS 679 We can further explain how these fields help EAP by comparison with 680 how certificates are used for HTTPS [RFC2818]: 682 * HTTPS uses id-kp-serverAuth to indicate that a certificate 683 is permitted to be used with an HTTPS server. We 684 define id-kp-eapServer which indicates that a 685 certificate is permitted to be used with an EAP 686 server. 688 * HTTPS uses id-kp-clientAuth to indicate that a certificate 689 is permitted to be used with an HTTPS client. We 690 define id-kp-eapClient which indicates that a 691 certificate is permitted to be used with an EAP 692 client. 694 * HTTPS uses id-ce-subjectAltName with dNSName [RFC5280] to contain 695 the DNS name of the server to which the client is 696 connecting. We use id-on-naiRealm [RFC7585] to 697 indicate the NAI realm of the server to which the 698 client is authenticating. 700 4.2. Additional Information Required 702 When combined with a clearly defined process, the above definitions 703 allow devices to use TLS-based EAP methods with no more complexity 704 than is seen when browsing the web. That is, in many situations, all 705 the end device needs is the following: 707 * network access (trusted or not) * an account in a domain, e.g. 708 "user@example.com" * one or more trusted root CAs from the web PKI. 710 This information can be used to securely obtain network access. The 711 procedures outlined here work with both public CAs and private CAs. 713 We will first describe how these fields can be used to make EAP 714 authentication easier to use. Once we have described a worked 715 example using these fields, we will show how to extend the solution 716 to solve the remaining open issues. 718 5. How It Works in Practice 720 In this section we provide a worked example for EAP-TLS. This 721 discussion uses EAP-TLS as an example, but the methods discussed here 722 are not limited to that use-case. Describing a specific EAP method 723 allows us to discuss every aspect of the proposal, without worrying 724 about how similar methods are applicable to different situations. 726 We expand the discussion later in this section to show how these 727 methods are applicable to other TLS-based EAP methods. 729 5.1. A worked example for EAP-TLS 731 We explain how this specification works via an example using EAP-TLS. 732 We start off with the problem statement, then how the certificates 733 might be obtained, then how the EAP peer is configured using 734 information in the certificates, and finally how the device obtains 735 network access. 737 5.1.1. The Problem Statement 739 For the initial worked example, we assume that we are trying to solve 740 the limited problem of an end user who has a WiFi enabled device such 741 as a laptop. The user wishes to use that device to get online, via 742 the simplest possible method. There is an administrator who also 743 wishes to get that user online, and wishes to configure the end user 744 device to do EAP-TLS. 746 We also presume that there are some additional pieces of the 747 solution, as follows: 749 * There may be a Wireless LAN (WLAN) System Service identifier 750 (SSID) which is used for WiFI authentication. This information can 751 be realized in the certificate field id-pe-wlanSSID, as defined in 752 [RFC4334] Section 3. 754 * All parties know which NAI realm [RFC7542] is being being used. 755 For example, an individual may work for a company "example.com". 756 This information is placed into the certificate field id-on- 757 naiRealm, as defined in [RFC7585] Section 2.2. 759 * We use the new EKU field id-kp-eapServer. This field indicates 760 that a certificate is intended to be used as a server certificate 761 within EAP. 763 * We use the new EKU field id-kp-eapClient. This field indicates 764 that a certificate is intended to be used as a client certificate 765 within EAP. 767 Knowing the name of the SSID is necessary, but perhaps not 768 sufficient. Some environments may have additional security 769 requirements, such as mandating that only WPA3-192-bit connections 770 may be used. This information should likely go into another field of 771 the certificate. For the purposes of this document, we will assume 772 that knowing the SSID name is acceptable. 774 EAP methods are also used to authenticate users when SSIDs are not 775 available (e.g. wired 802.1X), the use of id-pe-wlanSSID is 776 recommended, but is not required. For the purpose of this section, 777 we assume that WiFi access is being configured. Later discussion 778 will show how the methods outlined here can be applied to other forms 779 of network access. 781 As we will see below, this information is sufficient to configure 782 EAP-TLS securely, and with minimal effort by the end user. 784 5.1.2. Obtaining the Certificates 786 The administrator begins by obtaining a server certificate from a 787 root CA. This CA can be public or private. The only requirement is 788 that the CA is willing to sign certificates which contain an id-on- 789 naiRealm field, and which also contain the id-kp-eapServer field 790 which indicates that this certificate is suitable for use with EAP. 791 The rest of the fields, and the validation process for those fields, 792 can be identical to the processes used today. 794 The use of the new EKU fields here is intended to illustrate the end 795 goal of simplifying deployments. As we will see later, there are 796 intermediate steps which do not require the new EKU fields. 798 The administrator also obtains a client certificate, which will be 799 given to the end user for installation on the device. This client 800 certificate is issued via a hierarchy which ends in the root CA that 801 has issued the previously mentioned server certificate. The rest of 802 the certificate hierachy here is not important to this example. We 803 only presume that it exists; that it is valid; and therefore that it 804 is trusted. 806 The client certificate contains an id-on-naiRealm field, which has 807 the same NAI realm as seen in the server certificate. The client 808 certificate also contains the id-kp-eapClient field which indicates 809 that this certificate is suitable for use with EAP. The client 810 certificate may also contain a id-pe-wlanSSID field, though this is 811 not required. 813 We presume that the client certificate also has an associated private 814 key, and that this key is encrypted using a password. 816 We now have enough information to configure the end user device. 818 5.1.3. Configuring the end user device 820 The administrator configures the end device with the client 821 certificate, along with its associated private key and password. For 822 the purposes of this example, it is not important how the device 823 obtains that information. As noted earlier, the distribution problem 824 will be solved later in this document by extending the solution. 826 The configuration may also include the entire certificate chain up 827 to, and including, the root CA. Not all of these certificates are 828 always required, as they can be exchanged in the initial EAP-TLS 829 session. 831 We note here that the configuration of the end user device is not 832 embodied in a downloadable executable, or in a vendor-specific 833 configuration file. Instead, the configuration is given in the form 834 of standardized certificates which have been marked up to express 835 their intended usage. 837 When the end user receives the client certificate (and possibly 838 certificate chain), it can be installed on the device immediately. 839 When the certificate is installed, it causes a number of additional 840 steps to be taken by the device which is using that certificate. 841 These steps are new to EAP peers, and are not performed today. 843 First, the device determines that this certificate contains id-kp- 844 eapClient, which indicates that this certificate is intended to be 845 used for EAP. If there is a certificate chain, then those 846 certificates can be saved. If the client certificate contains id-pe- 847 wlanSSID, then the device uses that information to configure itself 848 so that it will connect to the named SSID, and to perform EAP-TLS 849 authentication using this client certificate. 851 This process is similar to that outlined in [RFC4334]. The changes 852 we make over that specification are new extensions to the 853 certificates, and additional steps which mandate new behavior. 855 Finally, if there is a root CA in the certificate chain, that the 856 root CA is installed. The device also annotates this root CA (pre- 857 existing or otherwise) as being trusted to issue certificates for use 858 with EAP. As we will see, the device can also require the EAP server 859 certificate to contain id-kp-eapServer, along with an id-on-naiRealm 860 value which matches the id-on-naiRealm which is in the client 861 certificate. 863 At this point, the end user device is fully configured for using EAP- 864 TLS with a particular SSID. 866 5.1.4. Obtaining Network Access 868 When the end user device wishes to obtain network access, it can for 869 the most part follow the methods used prior to the publication of 870 this specification. There are, of course, a few changes which 871 simplify the process and make it more secure. 873 For privacy, the device uses an anonymous identifier in the EAP 874 Response Identity field. This identifier is the NAI realm which is 875 taken from the id-on-naiRealm field of the client certificate. 876 Taking the NAI realm from the client certificate means that there is 877 no need for the user to configure the publicly visible EAP Response 878 Identity. This usage also provides for the anonymity required in 879 [EAPTLS]. 881 In order to provide for privacy of the client certificate, TLS 1.3 is 882 used. Older versions of TLS are NOT RECOMMENDED. 884 When the EAP-TLS connection is established, the device verifies that 885 the server certificate which is presented also contains a id-on- 886 naiRealm field, which matches the value in the client certificate. 887 This validation is similar to the validation of DNS names performed 888 by web browsers when accessing HTTPS sites. However, as DNS is not 889 available during EAP authentication, the id-on-naiRealm field is used 890 instead to validate the server certificate. 892 For clarity, we repeat the instructions in [RFC7585] Section 2.2, for 893 matching the NAI realm: 895 The comparison of an NAIRealm to the NAI realm as derived from 896 user input with this algorithm is a byte-by-byte comparison, 897 except for the optional leftmost dot-separated part of the value 898 whose content is a single "*" character; such labels match all 899 strings in the same dot-separated part of the NAI realm. If at 900 least one of the sAN:otherName:NAIRealm values match the NAI 901 realm, the server is considered authorized; if none match, the 902 server is considered unauthorized. 904 Since multiple names and multiple name forms may occur in the 905 subjectAltName extension, an arbitrary number of NAIRealms can be 906 specified in a certificate. 908 The device also verifies that the server certificate also contains 909 the id-kp-eapServer field. It verifies that the certificate is 910 signed by a root CA which is annotated as being permitted for use 911 with an EAP server. If these verification steps fail, then the 912 client stops the authentication process, as it has determined that 913 the network is not trusted. 915 If all of these verification steps pass, then the end user device can 916 trust the EAP server, and be authenticated to the network. 918 We note here that from the perspective of the end user, the only 919 actions which have performed have been (1) to install a certificate, 920 and (2) to enter a password for that certificate. This process is 921 substantially simpler than most WiFi configuration processes used 922 today. This process is also likely to be easy to follow for most 923 users. 925 5.2. Other TLS-based EAP methods 927 While the above example discusses EAP-TLS, it is easily extensible to 928 any other TLS-based EAP methods. Instead of distributing a client 929 certificate to end users, the administrator can distribute a server 930 certificate and/or a root CA which is intended for use with EAP. For 931 simplicity, the server certificate should also contain id-pe- 932 wlanSSID, which informs the client as to which SSID(s) should be used 933 for authentication. 935 We reiterate that the public EAP Response Identity used should always 936 be in the form "@realm", as per [EAPTLS] Section 2.1.7. The user's 937 full identity should only be sent inside of the TLS tunnel. We also 938 recommend that the inner authentication methods use the full identity 939 of "user@realm", and not just the "user" portion. 941 The end device then follows the same process to configure the SSID 942 for authentication, to mark up the SSID as being used with a 943 particular NAI realm, and to annotate the root CA as being permitted 944 for use with EAP. Again, having an SSID here simply makes this 945 example clearer, this specification does not mandate its use, and 946 this specification is applicable to any type of network access which 947 uses EAP. 949 When the device connects, it does not need to verify that the server 950 certificate being presented is the same as was used for 951 configuration. Instead, the device simply has to "pin" the 952 combination of SSID, NAI realm, and root CA. This pinning allows for 953 flexibility in accepting other server certificates, while preventing 954 down-grade attacks which attempt to supply different root CAs for 955 that NAI realm. This pinning means that the device associates the 956 SSID and NAI realm with a particular root CA, and then does not 957 permit that NAI realm to authenticate to an EAP server which does not 958 use the same permitted root CA. 960 The only requirement on the new server certificate is that it has to 961 match the same criteria as outlined in the previous section. That 962 is, the certificate must contain id-kp-eapServer, it must have a 963 matching id-on-naiRealm, and it must be be signed by a root CA which 964 the supplicant has permitted to be used with EAP. 966 The device can then safely send authentication credentials inside of 967 the TLS tunnel. This process is substantially similar to that used to 968 log into an HTTPS enabled web site. The only difference here is that 969 the device must associate the user's credentials with EAP and an NAI 970 realm, instead of with the web and a DNS host name. 972 5.3. EAP methods which do not use TLS 974 Unfortunately, the methods outlined here apply only to TLS-based EAP 975 methods. This limitation is because we are leveraging the TLS 976 certificate format in order to both define additional permitted uses 977 for those certificates, and to inform devices how non-TLS systems 978 should be configured. 980 This extra information is simply not possible to add to other EAP 981 methods such as EAP-PWD [RFC5931]. Those methods typically 982 authenticate users, but do not provide for carrying additional 983 information. Those methods also generally do not provide for the 984 mutual exchange of identities, and for mutual authentication. 986 Authentication protocols such as EAP-PWD are simple enough that it is 987 both impossible, and generally unnecessary, for them to use the 988 methods outlined in this specification. That is, the cryptographic 989 guarantees in EAP-PWD ensure that it is always safe to perform EAP- 990 PWD with unknown EAP servers, as there is no possibility for leakage 991 of user credentials. As such, there is less need to verify the 992 identity of the EAP-PWD server. 994 5.4. Other Methods of Provisioning 996 The EAP-TLS example described how provisioning was done via an 997 administrator sending certificates to an end user. This process is 998 not always necessary. 1000 For EAP-TLS, [EAPTLS] Section 2.1.5 provides for the protocol to be 1001 used without peer authentication. This capability can be leveraged 1002 to perform provisioning. All that is needed on the device is for the 1003 EAP peer to have a pre-configured root CA, and to know the NAI realm 1004 which it belongs to, and which is being used for provisioning. 1006 For the purposes of this section, we assume that the root CA known to 1007 the device is willing to issue and sign server certificates which 1008 contain the id-kp-eapServer and id-on-naiRealm fields. As we will 1009 see below, this assumption may be difficult to achieve in practice. 1011 When the device connects to a network, it can perform the 1012 verification steps outlined above. That is, the server certificate 1013 presented has a matching id-on-naiRealm field; the server certificate 1014 contains id-kp-eapServer; and that the server certificate is signed 1015 by a known root CA. The root CA does not necessarily have to be 1016 annotated as being permitted for EAP. 1018 If all of those requirements are satisfied, then the device can 1019 obtain limited network access. The device can then leverage normal 1020 networking protocols to download provisioning information, which is 1021 then used to configure the device. As noted above, this provisioning 1022 information needs to be little more than a client certificate. 1024 For example, the device could use Enrolment over Secure Transport 1025 (EST) [RFC7030]. It could also use vendor-specific methods. 1027 This process works because every device capable of doing TLS is 1028 shipped with a set of known root CAs, which are intended for use with 1029 the web. In addition, every end user wishing to connect to a known 1030 network is aware of the identity of that network (e.g. 1031 "example.com"), and their their identity in that network (e.g. 1032 "user@example.com"). 1034 If the device does not have a root CA configured, as we will see 1035 below, it can use the limited authorization network with other 1036 protocols such as DNS. The device could use DNS to query a pre- 1037 defined SRV record (as with [RFC7585] Section 3). The results of 1038 that record could be a "self signed" root CA. Certificates can 1039 therefore be obtained over DNS, such as via the methods outlined in 1040 [RFC4398]. 1042 The only requirement here is that the DNS record be obtained securely 1043 (DNSSec or DNS over TLS), otherwise an attacker could forge the 1044 response, or replace the root CA in transit. 1046 Other methods are also possible, though not discussed here. 1048 5.5. Trust on First Use Can be Secure 1050 Similar provisioning methods can be be used for other TLS-based EAP 1051 methods. In those methods, when a device connects to the network, it 1052 could prompt the user for a username (with an NAI realm) and 1053 password. Then, it could use that information to derive the NAI 1054 Realm, and perform the verification steps described previously. The 1055 device simply needs to know that it is trying to authenticate to a 1056 specific NAI Realm before verifying the server certificate, and needs 1057 to verify that server certificate prior to sending any user identity 1058 or authentication credentials to the EAP server. 1060 That is, a device which knows that it is trying to authenticate to a 1061 realm "example.com", can then verify that the server certificate 1062 contains id-on-naiRealm which matches "example.com". This process is 1063 similar to a web browser that wishes to connect to a web site for 1064 "example.com". The client already knows that "example.com" is the 1065 desired destination, which then means that the client must verify 1066 that the site which it connects to has a certificate matching 1067 "example.com". 1069 If the device is not configured with any realm, then it has no way of 1070 determining whether or not it should trust any EAP server. As such, 1071 the use of the NAI realm is a critical component of this 1072 specification. 1074 This process is close to "Trust on First Use" (ToFU) provisioning, 1075 with minimal knowledge required, and with a high degree of security. 1076 From the point of view of the end user, the only actions which have 1077 been taken are to select an SSID, and then to enter a name and 1078 password. The process outlined here ensures that the user is 1079 authenticated to a known and trusted network, and that the EAP peer 1080 sends the identity and authentication credentials only to known and 1081 trusted networks. 1083 Some EAP methods such as TEAP [RFC7170] support provisioning of end 1084 user devices. Since this provisioning information is automatic, it 1085 can include additional information not discussed here. The process, 1086 however, remains substantially similar. The client can download one 1087 or more certificates, and then perform the validation and 1088 configuration steps outlined above. 1090 5.6. Additional Considerations 1092 Note that there is no requirement that the device use only the SSID 1093 given in the id-pe-wlanSSID field of a certificate. If the device 1094 sees an authorized server certificate on a different SSID, then it 1095 should proceed with authentication as discussed previously. 1097 However, the EAP server may not permit the client to be authenticated 1098 via other SSIDs. It is therefore RECOMMENDED that channel bindings 1099 [RFC6677] are used in all EAP methods, in order to inform the server 1100 about the clients local environment. Channel bindings also solve 1101 problems with supplicants that do MAC address randomization: The real 1102 MAC address is sent inside of the TLS tunnel, as part of the channel 1103 binding exchange. 1105 Similarly, there is no requirement for the device to "pin" a 1106 particular server certificate. If the presented server certificate 1107 meets the criteria of known root CA; containing id-kp-eapServer; and 1108 matching id-on-naiRealm, then the connection can be trusted. In 1109 fact, there is no need to cache the server certificate at all. 1111 6. Extending the Solution 1113 The process described above greatly simplifies the usability of EAP, 1114 and its security. We can, however, do better. 1116 The process described above requires changes to both supplicants, and 1117 to the systems which issue certificates. These changes are useful, 1118 but are not always trivial. Further, the processes still have a 1119 bootstrapping problem, which was waved away in Section 2.2.3 during 1120 the discussion of the worked example. The bootstrapping problem was 1121 somewhat addressed by the use of ToFU provisioning in Section 2.6, 1122 but there are still open issues with respect to security and 1123 provisioning. 1125 In this section, we describe a few was in which the remaining issues 1126 may be addressed, in order to come up with a complete solution to the 1127 problem. We first describe protocols such as EST [RFC7030], and then 1128 later how DNS may also be used. 1130 6.1. Bootstrapping via EST 1132 EST [RFC7030] can be used to distribute previously created 1133 certificates for CAs and servers. It can also be used by clients to 1134 request new client certificates. As there is no distinction in EST 1135 between public CAs and private CAs, either can be used. This feature 1136 enables EST-capable systems to use the new OIDs defined here. 1138 The use of EST therefore solves the certificate distribution problem 1139 which was described earlier in the worked example for EAP-TLS. 1141 However, the requirement here is that the client implements EST, and 1142 not all currently do. Another requirement is that EST uses the 1143 ".well-known" relative URL from [RFC5785], and both specifications 1144 assume implicitely that the base domain is rooted both in the web, 1145 and in the top-level subdomain. For example the base URL for 1146 "example.com" is given as "www.example.com". While the ".well-known" 1147 prefix is capable of being used with other portions of the domain 1148 name tree, there is no standard way for a client and server to agree 1149 on its location. The location is simply implicit in the protocol. 1151 This limitation is an issue mainly because we wish to use automatic 1152 enrollment schemes in "captive portal" or "walled gardens", which 1153 have limited network access. It may be possible for a system with 1154 limited network access to reach a URI such as 1155 "https://www.example.com/.well-known/". However, there is no 1156 guarantee that the administrator of the main web server system for a 1157 domain is the same as the administrator of the captive portal system. 1159 As a result, we need a way for both the client to discover the URI to 1160 use, and for that URI to point to a web sever which is controlled by 1161 the administrator of the captive portal system. The solution here is 1162 to use DNS. 1164 We define a DNS SRV record which points to the EST server for this 1165 NAI realm. In order to provide for the separation of 1166 responsibilities, we make this record specific to EAP. 1168 The format of the SRV record is as follows: 1170 _est._eap. 1172 An EAP client system can query for this record, and then connect to 1173 the ".well-known" service at the provided host, in order to perform 1174 EST. This record may point to the main EST server for a domain, or 1175 it may point to a separate EST server which is specifically used for 1176 EAP. We believe that it is important to make provisions for 1177 separation of services such as these, even if this separation is not 1178 always used. 1180 We note that the DNS resource record type here is SRV and not URI, as 1181 we only need to define the hostname and port for the EST server. The 1182 rest of the URI is defined by EST. 1184 We discuss the use of DNS in more detail in the next section. 1186 6.1.1. Closing the loop 1188 An EAP peer which has a username, password, and NAI realm can 1189 leverage EST to securely provision client certificates for use with 1190 TLS-based EAP methods. 1192 The device first discovers the location of the EST server via the DNS 1193 lookup above. It can then download any necessary CAs, using the 1194 methods outlined in [RFC7030] Section 4.1 The device then uses the 1195 username and password with HTTP basic authentication in order to 1196 authenticate itself to the EST server. Finally, the device can 1197 request that the EST server create and sign a client certificate, 1198 using the methods outlined in [RFC7030] Section 4.2. 1200 One benefit of this method is that the key associated with the client 1201 certificate can be generated automatically by the client device, and 1202 hidden from the user. This secrecy ensures that the client 1203 certificate is associated with a particular device, and that the user 1204 is prevented from copying the certificate to multiple devices. 1206 6.2. Bootstrapping via DNS 1208 We have seen above that the EAP configuration problem can be largely 1209 reduced to getting a properly formed certificate onto the device. We 1210 show here how to use DNS to bootstrap the certificate installation. 1211 This bootstrapping process requires no changes to supplicants or to 1212 systems which certificates. Instead, it requires only that: 1214 * certificates be placed at a well-known URI, 1216 * this URI is found DNS CERT records [RFC4398], 1218 * an independent tool downloads the certificates and uses them 1219 to configure EAP as described above, 1221 * the end user or device knows the NAIRealm to which it is 1222 supposed to connect. 1224 This process leverages both DNS, and the existing "web" root CA 1225 infrastructure in order to securely configure EAP, with minimal 1226 manual intervention. 1228 6.2.1. CERT records 1230 The process begins with the administrator obtaining one or more 1231 server certificates as described above, and then placing them at a 1232 well-known URI. The administrator then adds records to DNS which 1233 point to the certificates. The client can then download these server 1234 certificates, and configure its EAP system to use these certificates 1235 when authenticating to the relevant NAI realm. 1237 For the purpose of this section, we assume that the server 1238 certificates are signed by a CA which is already known to the client 1239 system. In the next section, we extend this process to downloading 1240 new CA certificates. 1242 The information stored in DNS is a CERT record as described in 1243 [RFC4398] Section 2. If the DNS record is served over a secure 1244 transport such as DNSSec, DNS over HTTP, or DNS over TLS, then the 1245 record can directly contain the certificate. If the DNS record is 1246 served over an insecure transport, then the "type" field MUST be one 1247 with contains a URI. These requirements typically mean that value of 1248 the "type" field will be (4), for IPKIX, which points to the URL of 1249 an X.509 data object. 1251 In order for this process to be secure, the URL MUST be within same 1252 domain (NAI realm) as the CERT resource record. The URL MUST be 1253 secured with TLS transport. The certificate presented at that URL 1254 MUST be issued by a root CA which is generally already known to the 1255 device. The certificate presented at the URL MUST pass all normal 1256 HTTPS validation, including that for id-ce-subjectAltName. 1258 That is, when the client accesses a URL pointed to by a CERT record, 1259 certificate validation for that access MUST be performed as per 1260 [RFC5280]. If any of these validation steps fail, then the client 1261 MUST NOT download or use any further data presented by that server. 1263 Further, the contents of the data at that URL MUST be a X.509 1264 certificate. 1266 The downloaded certificate MUST be one with is suitable for TLS-based 1267 EAP methods, as described in [EAPTLS]. The client system MUST verify 1268 that the server certificate matches the NAI realm which is being 1269 used, either via the steps defined here, or via the host name 1270 matching defined in [EAPTLS]. If the certificate does not match the 1271 NAI realm, then it is discarded and not used for EAP. 1273 An issue is that [EAPTLS] provides for host name matching, but not 1274 for NAI realm matching. The two are similar, but not identical. If 1275 we recall [RFC7542] Section 2.5, the NAI realm is defined as: 1277 * Realms MUST be of the form that can be registered as a Fully 1278 Qualified Domain Name (FQDN) within the DNS. 1280 Certificates of the form supported by [EAPTLS] therefore may still 1281 match the given NAI realm. 1283 The downloaded certificate SHOULD also contain id-pe-wlanSSID, in 1284 order to inform the device as to which SSID is suggested for network 1285 access. 1287 Note that there is no requirement for this server certificate to 1288 contain the id-kp-eapServer OID defined here. It is RECOMMENDED to 1289 include that OID, but it is not required. 1291 These requirements ensure that devices can leverage the existing web 1292 framework to securely download certificates which are to be used for 1293 EAP. 1295 The use of insecure transport for DNS is acceptable, as it is only 1296 being used to transport a URL, which is itself protected by TLS. The 1297 URL validation requirements above ensure that an attacker can only 1298 point the device to pre-existing URIs within the given domain, which 1299 contain information not under the control of the attacker. 1301 6.2.2. CERT record labels for Server Certificates 1303 The next problem is to define a well-known name for this record. We 1304 leverage the [RFC8552] "Underscored" naming of attribute leaves in 1305 order to provde for well-known names. We define a series of names, 1306 which are all rooted from the NAI realm given by the user. 1308 We note here that the insecurity of plain UDP DNS may, in fact, be of 1309 use here. For example, the administrator of a captive portal can 1310 modify the captive portal DNS server in order to serve records for 1311 the "top level" domain, which not normally be permitted. Since this 1312 use of DNS names is only visible from within the captive portal, 1313 there is no security impact outside of this limited network. 1315 The format of the CERT record is as follows: 1317 _server._cert._eap. 1319 It can be beneficial to use a DNS CERT record instead of Enrolment 1320 over Secure Transport (EST) [RFC7030], as our goal here is to simply 1321 obtain a pre-existing certificate, and not to generate new 1322 certificates. In some cases, the URL provided by DNS can just be the 1323 URL of a certificate hosted by an EST server. 1325 In some cases, the downloaded certificate may be from a CA which is 1326 not known to the device. For example, when the CA is a "private CA" 1327 which is not in the root CA list for web PKI. The next section 1328 addresses this issue. 1330 6.2.3. CERT record labels for CA Certificates 1332 This CA certificate may be obtained via EST, as described in 1333 [RFC7030] Sections 2.1 and 4.1.2. The device can also look up the CA 1334 certificate via a similar process to obtaining the server 1335 certificate, by querying for a CERT record at the following name: 1337 _ca._cert._eap. 1339 Again, the URL presented here MUST match all of the requirements 1340 given earlier for the certificate obtained from the 1341 "_server._cert._eap." record. The only restriction on the 1342 contents and/or format of the downloaded CA certificate is that it 1343 MUST permit the previously downloaded server certificate to be 1344 verified. If the server certificate cannot be verified using this CA 1345 certificate, then both certificates MUST be discarded. 1347 Since this new CA has been downloaded from a trusted source, the CA 1348 can also be given limited trust. That is, the downloaded CA SHOULD 1349 be trusted to issue certificates for use with EAP, but only for the 1350 NA realm in question. The downloaded CA MUST NOT be trusted for any 1351 other use-cases or purposes. This limitation ensures that private 1352 CAs cannot be used to spoof public web sites from unrelated 1353 organizations. 1355 This requirement in effect mandates implementations to create 1356 multiple certificate stores. This limitation is the minimal change 1357 required to supplicant implementations in order to support the core 1358 of this specification. Every other change suggested here can either 1359 be pushed to an auxiliary tool, or can be delayed until a later step. 1361 That is, the user-visible workflow here can be implemented with 1362 minimal changes to the supplicant software which implements EAP. 1364 7. Related issues 1366 We discuss related issues in this section. The items discussed here 1367 are individually useful to discuss, but do not follow a clear 1368 developmental flow. As such, they are placed into a separate 1369 section. 1371 7.1. Provisioning Issues 1373 There are a number of issues related to provisioning. We show that 1374 there is no need to use a single network for all of the above 1375 discovery and configuration. We show that configuration updates are 1376 simple, and are no more difficult than repeating the initial 1377 provisioning. Finally, we describe why the methods defined herein 1378 are significantly more secure than ToFU. 1380 7.1.1. Bootstrapping via a Separate Network 1382 There is no requirement that a particular network provide all of the 1383 bootstrapping outlined above via a "guest network". It is also 1384 possible to leverage the public Internet in order to bootstrap 1385 authentication to a private network which requires EAP 1386 authentication. 1388 For example, a mobile phone may be trying to connect to a WiFi SSID, 1389 while it also has additional network access via 3G or LTE. There is 1390 no requirement here for the WiFi network to provide a guest network 1391 with full provisioning capabilities. Instead, the phone can simply 1392 try to do unauthenticated EAP-TLS. During the EAP-TLS negotiation, 1393 the device will obtain a copy of the server certificate. This 1394 certificate should contain id-on-naiRealm. 1396 The device can then use the LTE connection, and the process outlined 1397 above (DNS, EST, etc.) in order to verify that the server certificate 1398 is the one which meets all of the criteria necessary for full 1399 authentication. Once the server certificate is validated and the 1400 device has updated its configuration, it can drop the EAP-TLS 1401 connection, and re-authenticate using any TLS-based EAP method. 1403 With this process, the experience for the end user would be little 1404 more than: 1406 * select an SSID, 1408 * be informed that this is a network associated with a particular NAI 1409 realm (i.e. domain), 1411 * be informed that the network is secure and is trusted, 1413 * be requested to enter an identity and password within that domain, 1415 * enter that identity and password, and obtain network access. 1417 This process is little different from using a web browser to navigate 1418 to a web site, and ensuring that the green "lock" icon is set for 1419 that site. 1421 7.1.2. Configuration Change is just Refresh 1423 Any automatic provisioning scheme has the problem of performing 1424 change control. In our case, updating the configuration which a new 1425 set of data is largely just repeating the bootstrapping process. The 1426 questions then become how often to check for updates, how long to 1427 cache configuration, etc. 1429 It is RECOMMENDED that HTTPS servers which provide the certificates 1430 described in the previous section set the Cache-Control [RFC7234] 1431 directive in the response. It is RECOMMENDED that the "max-age" 1432 directive ([RFC7234] Section 5.2.2.8) be used. The value returned 1433 SHOULD NOT be less than one day (86400 seconds), and MUST NOT go past 1434 the expiry date of the certificate which is being returned. 1436 The supplicant which is retrieiving the certificate SHOULD annotate 1437 the certificate with the value of the "max-age" directive. The 1438 supplicant SHOULD perform the bootstrapping checks again prior to the 1439 "max-age" time limit being reached. 1441 Where "max-age" is not returned, the supplicant SHOULD refresh the 1442 bootstrapping checks again no more than once per day. It SHOULD 1443 track when the certificate was downloaded, and then perform these 1444 checks no later than when the certificate is halfway to expiry, taken 1445 from when the supplicant first downloaded the certificate. 1447 When either the root CA or server CA has expired, the supplicant MUST 1448 NOT use them to obtain network access. It SHOULD refresh the 1449 certificates at that time. If the certificates are not refreshed, 1450 then the relevant configuration SHOULD be deleted. 1452 If the refreshed certificate is identical to the previously 1453 downloaded certificate, then the supplicant takes no actions other 1454 than to update its refresh timers. 1456 If the refreshed certificate has changed, then the supplicant 1457 performs all of the validation checks described above. If the tests 1458 pass, the new certificate can be used in place of the previous one. 1459 Note that there is no need to "tear down" the current network 1460 connection if the current certificate is still valid. The new 1461 configuration should be used only when the device next requests 1462 network access. 1464 As the old credentials are usually still valid, device SHOULD keep 1465 the old credentials around until such time as it has verified that 1466 the new credentials work. If the new credentials do not obtain 1467 satisfactory network access, then they should be discarded, and the 1468 device should try again not sooner than one day later. 1470 TBD: There should also be fine-grained methods to control when a new 1471 configuration is downloaded, and separately when it is applied. For 1472 client certificates, we can use the "notBefore" field, which 1473 indicates that the certificate is not valid before a particular time. 1475 7.1.3. Secure versus Insecure Provisioning 1477 We now revisit the discussion of ToFU first mentioned above. We note 1478 that the process defined here isn't even "trust on first use". 1479 Instead, it is leveraging the web PKI in order to get secure, 1480 authenticated downloads of non-web certificates. ToFU provision such 1481 as used in TEAP is essentially a standardized way to download 1482 security configuration from an insecure source. 1484 Our proposal here begins with the naiRealm, and then uses trusted 1485 roots and secure protocols to download security configuration from a 1486 known and trusted source. While this process is more complex than 1487 TEAP, in that it requires DNS and HTTPS, it is also more secure. 1489 7.2. Issues related to Security 1491 We explain why id-on-naiRealm was chosen. We describe some issues 1492 related to resumption, and the use of certificates in a multi-server 1493 environment. We explain how this solution can be extended to 1494 configure individual EAP types. We explain how this solution is 1495 applicable when either private or public CAs are used. We conclude 1496 by explaining how the user experience offered by this solution 1497 creates a simple and clear user experience. 1499 7.2.1. Why id-on-naiRealm 1501 Server certificates used with EAP have historically contained DNS 1502 names. This practice is largely because the certificates are "TLS 1503 web server" certificates. However, [RFC7585] Section 2.2 explains 1504 why DNS names are not appropriate: 1506 Current subjectAltName fields do not semantically allow an NAI 1507 realm to be expressed; the field subjectAltName:dNSName is 1508 syntactically a good match but would inappropriately conflate DNS 1509 names and NAI realm names. Thus, this specification defines a new 1510 subjectAltName field to hold either a single NAI realm name or a 1511 wildcard name matching a set of NAI realms. 1513 We extend the above requirement to say that the wildcard name MUST be 1514 limited to a subset of one realm. That is, a wildcard of 1515 "*.example.com" is permitted, but a wildcard of "*", or "*.com", is 1516 forbidden. 1518 Although this recommendation was done in the context of RADIUS, this 1519 field is exactly what is needed for EAP. The definition is the same 1520 (NAI), and the use-cases are the same. 1522 7.2.2. Resumption 1524 [RFC8446] Section 4.6.1 discusses resumption: 1526 Clients MUST only resume if the new SNI value is valid for the 1527 server certificate presented in the original session and SHOULD 1528 only resume if the SNI value matches the one used in the original 1529 session. The latter is a performance optimization: normally, 1530 there is no reason to expect that different servers covered by a 1531 single certificate would be able to accept each other's tickets; 1532 hence, attempting resumption in that case would waste a single-use 1533 ticket. If such an indication is provided (externally or by any 1534 other means), clients MAY resume with a different SNI value. 1535 -0.3i 1537 Similar requirements apply for EAP, except that clients check id- 1538 on-naiRealm instead of using SNI. 1540 Where multiple servers are in an high availability or load-balance 1541 group, they SHOULD use the same certificate. Where the same 1542 certificate is used, then either the resumption master secret MUST 1543 be shared among all systems, or the tickets MUST be accessible to 1544 all systems. Preferably by putting them into an external data 1545 store. 1547 7.2.3. Choosing EAP Types 1549 We note that this specification does not define which EAP type is 1550 used by the supplicant, except implicitly. That is, if the 1551 supplicant is given a client certificate, then it is presumed that 1552 EAP-TLS is being used. Otherwise, the supplicant should choose some 1553 other TLS-based EAP type. 1555 It would be possbile define new OIDs which define a list of EAP types 1556 that the EAP server will accept. These OIDs can then be placed in a 1557 server certificate, where they can inform the supplicant as to which 1558 EAP types should be used. 1560 7.2.4. User Experience 1562 It is RECOMMENDED that the system notify any end user of the 1563 configuration changes being performed. It is RECOMMENDED that these 1564 notifications give sufficient information to the end user, so that an 1565 informed decision can be made. It is RECOMMENDED that these 1566 notifications allow the user to stop or cancel the process at any 1567 time. 1569 The goal of the user experience described that it should be little 1570 different from using a web browser to navigate to a web site, and 1571 ensuring that the green "lock" icon is set for that site. 1573 Is is therefore RECOMMENDED that supplicant vendors update their user 1574 interfaces to clearly distinguish between "trusted" and "untrusted" 1575 network access. A "trusted" network is one which satisfies all of 1576 the criteria outlined herein. An "untrusted" network is one which 1577 satisfies only some, or none of the criteria outlined here. 1579 It is likely a good idea to update the graphical user interface (GUI) 1580 for as supplicant with a green / red lock icon, similar to that used 1581 in web browsers. Further, the GUI should also include the naiRealm 1582 which has been verified, as web browsers show the domain name which 1583 has been verified. This information is enough to give the user 1584 enough information to meaningfully consent to obtaining network 1585 access, and to enter credentials. 1587 That is, if the user sees that the operating-system GUI window says 1588 "this site is trusted", and also "you are accessing the example.com 1589 domain", then the user can safely enter credentials for that domain. 1591 This workflow is familiar to end users, and has been proven to be at 1592 least moderately successful in the web. 1594 7.3. Issues related to Certificates 1596 There are a number of other issues related to certificates, in 1597 addition to those which have been raised above. 1599 TBD: more explanation of the trailing sections. 1601 7.3.1. Public CA versus Private CA 1603 Nothing in this specification requires the use of either a public or 1604 private CA. Both are possible, and both have issues. 1606 The main issue with using a private CA is that it is not already on 1607 the device, and has to be provisioned. While there are many possible 1608 methods of provisioning this information, we define here only a few 1609 straightforward methods. We hope that the method proposed here (DNS 1610 + HTTPS) is clear, and simple for administrators to implement. 1612 There is still the requirement that the client device have new 1613 software to obtain this information and call the supplicant API. 1614 However, this process is no different than installing custom MDM 1615 software. 1617 Private CAs have the benefit of being able to sign certificates with 1618 any EKU they desire. These certificates can then be marked with an 1619 EKU as being intended for a particular use, and supplicant software 1620 can verify these EKU fields. 1622 The issues with public CAs are described above. Public CAs are 1623 likely to refuse to sign certificates which contain the EKUs proposed 1624 here, and appear to be uninterested in offering a different product 1625 which would sign such certificates. Further, using these 1626 certificates for EAP appears to be against their intended purpose, 1627 and is therefore misuse. 1629 However, the benefit of using public CAs is that they are already 1630 configured on most devices, and it is relatively simple to obtain 1631 certificates from them. 1633 In the end, local administrators can choose whatever CA is best for 1634 them. Our goal here is to simplify the process of using a CA and 1635 server certificate for EAP. It is best to give administrators and 1636 implementors a few simple options which meet their needs, rather than 1637 mandating one particular solution which is likely to not meet the 1638 needs of a large set of users. 1640 7.3.2. Limitations of public CAs 1642 Recent changes to the CAB guidelines limit certificate validity 1643 periods to 397 days. While this change may be good for the larger 1644 WWW framework, it is not clear how it benefits other protocols such 1645 as EAP. Additional changes include limiting the kind of domain 1646 validation methods permitted, and forbidding file-based validation 1647 for wildcard certificates. 1649 Part of EAP "best practices" is to ensure that EAP (or AAA) servers 1650 have minimal exposure to the public Internet. In order to use 1651 certificates from a public CA therefore, administators must choose 1652 between either exposing their EAP server via WWW (in order to perform 1653 validation), or to expose a different WWW server, and then also 1654 simultaneously install the same certificate on the EAP system. 1655 Neither option is a good one. 1657 In addition, limiting the certificate validity period means that 1658 clients see the server certificate change much more often than has 1659 been previously the case. This higher volume of changes was 1660 historically perhaps not an issue, as we have seen above that some 1661 systems perform limited checks on server certificates. 1663 The benefit of the process outlined here is that the server 1664 certificate either becomes trivially verifiable (even if it changes), 1665 or installing a new server certificate becomes a trivial and secure 1666 process. 1668 On the other hand, if there is no automated process to update the EAP 1669 client configuration, then users will simply be trained to mindlessly 1670 click "accept" when they are presented with a new certificate. As 1671 this process will happen much more often than has historically been 1672 the case, this maladaptive behavior by users will be even more 1673 strongly enforced. 1675 Another issue with public CAs is that intermediate CA certificates 1676 are significantly more expensive than a server certificate. The 1677 reason here appears to be economic: if intermediate CA certs were 1678 cheap, then an organization would simply purchase one, and then use 1679 that CA cert to issue many server certificates. 1681 This limitations means that EAP-TLS is significantly more difficult 1682 to deploy in practice and PEAP or TTLS. The administrator has to 1683 choose between either purchasing an extremely expensive intermediate 1684 CA certificate, or using a private CA. 1686 The use of intermediate CAs has other issues, as we will see in the 1687 next section. 1689 7.3.3. CA Chains 1691 Some administrators wish to use multiple CAs for security. For 1692 example, a large organization could have one CA which is controlled 1693 by a security group. That CA could issue intermediate CA 1694 certificates to other groups with the organization. These CAs could 1695 be issued on multiple grounds, such as geographic location, or 1696 function units. 1698 In practice, this process could result in there being one CA which is 1699 used for EAP / AAA, another CA which is used for internal web sites, 1700 and another CA for organizational Virtual Private Network (VPN) 1701 usage. 1703 We have worked through all of the examples and discussion above by 1704 largely assuming that there was one "root" CA. Now that we see this 1705 assumption is insufficient, we must then discuss, and solve, the 1706 issue of intermediate CAs. 1708 If an application were to simply trust the "root" CA, then by 1709 inference it would also trust all intermediate CAs. This trust means 1710 that an EAP administrator who can issue client certificates could 1711 potentially configure that client certificate for use in another 1712 protocol, such as with a VPN. Such misuse could lead to unauthorized 1713 users obtaining access to resources. 1715 The solution here is two-fold. One, applications which accept client 1716 certificates SHOULD be configured to trust a particular issuing CA, 1717 which may not be the "root" CA. That is, simply having a certificate 1718 store of root CAs is insufficient. Instead, the application needs to 1719 track a particular intermediate CA. 1721 Another solution is to simply move to purpose-specific EKU fields. 1722 An EAP client which follows this specification can require that the 1723 EAP server contain an id-kp-eapServer field. The EAP client can then 1724 rely on policy within the issuing framework to ensure that all 1725 relevant certificates also have an id-kp-eapServer field. Similarly, 1726 and EAP server which follows this specification can ensure that EAP 1727 clients are presenting certificates which contain id-kp-eapClient. 1729 That is, the use of id-kp-serverAuth for all possible applications 1730 means that it is impossible to limit the use of certificates to one 1731 particular application. An administrator or end user is free to 1732 (mis-)use any certificate for almost any purpose. 1734 We would suggest that having purpose-specific key usage fields is 1735 preferable. Such fields would make it simpler for both clients and 1736 servers to have more fine-grained control over certificate usage. 1738 7.3.4. Delegated Authentication 1740 In some cases an organization may delegate EAP / AAA functionality to 1741 another organization. This can happen for example, when an 1742 organization does not wish to run authentication servers itself, but 1743 instead delegates that functionality, say to an identity provider 1744 (IdP). The delegated functionality may be operated by an 1745 organization which handles "authentication as a service" for multiple 1746 customers. 1748 A current solution is for the IdP system to present a server 1749 certificate which contains a list all of the domain names which it 1750 services. The problem is that this list can change often, which 1751 means that the old certificate must be revoked, and a new one issued. 1752 If these changes happen regularly, then this "churning" of 1753 certificates can cause problems for clients which cache the server 1754 certificate. There is also the management overhead of updating the 1755 certificate. Over all, this process is not scalable. 1757 The processes outlined here allow for simple discovery and 1758 configuration of TLS-based EAP methods, but they do not entirely 1759 solve this problem. 1761 The problem can be solved, however, by noting that the public EAP 1762 Response Identity used should be in the form "@realm", as per 1763 [EAPTLS] Section 2.1.7. An EAP server will receive this identity in 1764 the first EAP packet, at which point the server can select and 1765 present a certificate which is appropriate for that realm. 1767 The result is that an IdP needs to be configured only with one server 1768 certificate for each NAI realm that it manages. When an NAI realm is 1769 added, deleted, or updated, those changes affect only the 1770 configuration for the modified realm. Any other organization or NAI 1771 realm is not affected. 1773 This solution is simple and scalable. 1775 7.3.5. Identification of Networks 1777 While the examples above used an SSID to identify a network, there 1778 are other ways of network identification. 1780 One is the Roaming Consortium Organisation Identifiers (RCOI), which 1781 are organizational identifiers which are assigned by the IEEE (REF 1782 TBD). They can be 24 or 36 bits. These organizations are global, and 1783 can identify a vendor, operator, consortium, or other organization. 1785 This section defines the RCOIdentifier name as a form of otherName 1786 from the GeneralName structure in subjectAltName defined in 1787 [RFC5280]. 1789 id-on-RCOIdentifier OBJECT IDENTIFIER ::= { id-on TBD } 1791 ub-RCOIdentifier-length INTEGER ::= 255 1793 RCOIdentifier ::= OCTET String (SIZE (1..ub-RCOIdentifier-length)) 1795 This field can be used in either a client certificate or a server 1796 certificate. With either usage, it indicates to the client which 1797 RCOI should be used for accessing network services. 1799 7.4. Anti-solutions 1801 In this section, we explain why a number of existing technologies do 1802 not solve the problems which are addressed by this specification. 1804 7.4.1. MDM Products Are not the Solution 1806 MDM products are not the solution. Solutions like Eduroam CAT [CAT] 1807 are simple and easy to use, but they are only one of many possible 1808 products. In the extreme case, each end user has to download one MDM 1809 product for each network being accessed, and then repeat that process 1810 across each of many devices being used to access those networks. 1812 These solutions are not just expensive, and non-standard, they are 1813 not scalable. It is difficult to scale the solutions to millions of 1814 disparate devices, as software has to be written and verified for 1815 each vendor, and often for each firmware version supplied by a 1816 vendor. 1818 In addition, MDM prodicts do not scale for an individual device. 1819 Each MDM product usually assumes that it is in complete control of 1820 the device, which makes it difficult or impossible to install 1821 multiple products. For example, a contractor who works for multiple 1822 companies may need multiple conflicting MDM products. Or, an 1823 employee may be required to install an MDM product on a personal 1824 device, which makes it difficult to say who actually owns that 1825 device. 1827 These MDM products typically also are capable of remotely wiping the 1828 device, such as when a contractor or employee leaves an organization. 1829 If the device was bought for personal use, there are ethical and may 1830 also be legal implicatations. Other issues are the loss of critical 1831 data such as documents or personal photographs. 1833 Or perhaps even worse, when an MDM product is in complete control of 1834 a device, then there is plausible deniability for a user, for any 1835 action taken on that device. It is likely defensible to claim that 1836 the user is not responsible, because "the remote admin had full 1837 control", or perhaps "the remote admin is running software which 1838 controls my device". 1840 There are serious security issues with a user not being in control of 1841 their own device. 1843 In contrast, a standard discovery and configuration method, run by 1844 devices at the edge, which leverages DNS and HTTP is proven to work 1845 at Internet scales. They are implemented once by each vendor, and 1846 then maintained afterwards. As the configuration for each 1847 organization (NAI realm) is separate, there are minimal issues with 1848 installing multiple configurations on the same machine. 1850 However, in the interest of enabling multiple solutions, we also 1851 define an [RFC8552] URI record. This record points to a location 1852 where a client device can download an MDM solution which is specific 1853 to a particular organization. 1855 The format of the URI record is as follows: 1857 _install._mdm. 1859 This record SHOULD NOT be visible on the public Internet, i.e. the 1860 public DNS servers for that NAI Realm. Doing so would permit 1861 malicious actors to download and examine the MDM software. Instead, 1862 this record SHOULD be available only inside of the organizations 1863 private network. Either to devices which have used 802.1X in order 1864 to authenticate themselves to the organization, or to devices which 1865 are using private IP address ranges. 1867 The server which hosts the URI SHOULD use device fingerprinting in 1868 order to provide a system-dependent MDM solution. 1870 As with the requirements on certificates above, the URI MUST be 1871 within same domain (NAI realm) as the CERT resource record. The URI 1872 MUST be secured with TLS transport. The certificate presented at 1873 that URI MUST be issued by a root CA which is generally already known 1874 to the device. The certificate presented at the URI MUST pass all 1875 normal HTTPS validation, including that for id-ce-subjectAltName. 1877 If any of these validation steps fail, then the client MUST NOT 1878 download or use any further data presented by that server. 1880 If the validation steps succeed, then the client device can download 1881 and run the MDM software which has been provided at that URI. 1883 Where possible, the client MUST inform any human user that these 1884 steps are being taken, and MUST give the user the ability to prevent 1885 this download from happening. There are many situations where the 1886 client device is owned by the end user, and not the organization 1887 which is being accessed. As such, it is inappropriate to mandate 1888 that software be automatically installed. 1890 However, there is also no requirement that an organization grant 1891 access to devices which do not follow the organizations policy. The 1892 organization is free to deny the device network access until such 1893 time as the MDM software has been installed. 1895 7.4.2. EST and similar protocols do not solve all of the problem 1897 Certificate provisioning solutions like EST [RFC7030] or Simple 1898 Certificate Enrolment Protocol (SCEP) [RFC8894] are useful, but they 1899 do not solve the underlying problem we solve here. 1901 EST and SCEP are useful for provisioning CA certificates to end 1902 devices, and for end devices to request and provision client 1903 certificates. However, these processes generally configuration on 1904 the client device, and also an unrestricted network connection. 1906 Part of the problem we are trying to solve here is supplicant 1907 configuration, and EST / SCEP do not help. 1909 Further, EST can require complex bootstrapping. Section 2 of 1910 [RFC7030] says: 1912 Both the EST clients and server are configured with information 1913 that provides the basis for mutual authentication and for 1914 authorization. The specific initialization data depends on the 1915 methods available in the client and server, but it can include 1916 shared secrets, network service names and locations (e.g., a 1917 Uniform Resource Identifier (URI) ...), trust anchor information 1918 (e.g., a CA certificate or a hash of a TA's certificate), and 1919 enrollment keys and certificates. 1921 In contrast, the method proposed here requires that the client device 1922 have a known root CA from the web PKI, and the ability to do DNS and 1923 HTTPS. This capability is available on essentially all systems which 1924 can access the public internet. 1926 The reason for this simplification is that the problem we are trying 1927 to solve for EAP is substantially smaller than the problem that EST 1928 is trying to solve. 1930 We conclude by noting that our solution is entirely compatible with 1931 EST, in that the DNS query for "_ca._cert._eap.example.com" could 1932 return a CERT record which points to the URL of the EST server, for 1933 example "https://example.com/.well-known/est/cacerts", as described 1934 in [RFC7030] Section 4.1.2. 1936 7.4.3. Captive Portals and Hotspots 1938 Captive portals and hotspots have been traditionally used as a method 1939 of controlling network access, as with EAP. The use-case for captive 1940 portals is that the client devices can do DNS and HTTP, but that they 1941 do not have credentials already provisioned. The captive portal is a 1942 way to introduce humans into the process, by displaying information, 1943 and asking for credentials such as credit cards, etc. 1945 There are, of course, a number of issues with captive portals. It 1946 may take the client device some time to determine that it is in a 1947 captive portal. The information displayed on a captive portal page 1948 may be confusing to the end user, or may even be in a language which 1949 the user does not understand. 1951 Automating the onboarding process means that almost all of these 1952 issues are resolved. 1954 7.5. id-kp-eapOverLAN May not be sufficient 1956 While [RFC4334] Section 2 defines id-kp-eapOverLAN, it gives no 1957 explicit use-case for that EKU. That document suggests that the EKU 1958 is intended for use in client certificates. However, it also can be 1959 read to suggest that the EKU could also be used in server 1960 certificates. 1962 As such, we define a new EKU, id-kp-eapClient. If it is determined 1963 that this new EKU is not needed, this document can be updated before 1964 final publication to use id-kp-eapOverLAN instead of id-kp-eapClient. 1966 7.6. Guest Networks 1968 For EAP-TLS, [EAPTLS] Section 2.1.5 provides for the protocol to be 1969 used without peer authentication. The methods outlined here can be 1970 extended to perform provisioning within guest networks. That is, the 1971 device suspects the identity of the network, but also knows that it 1972 does not yet have credentials for use within that network. 1974 Where an EAP peer wishes to connection to the network, but does not 1975 know the identity of the network, it SHOULD use EAP-TLS without peer 1976 authentication. That is, it should obtain the server certificate 1977 without providing a client certificate. 1979 This server certificate can be examined for identification fields, 1980 such as id-on-naiRealm. The supplicant SHOULD query the network for 1981 the expected server certificate, using the DNS discovery process 1982 outlined above. 1984 Thee certificates and related network configuration which are 1985 discovered this way SHOULD NOT be cached for more than one day. 1987 While on the provisioning network, the device can use almost any 1988 method to authenticate and authorize the end user. For example, 1989 having a "self service" registration page, obtaining temporary 1990 credentials, etc. 1992 It is RECOMMENDED that the guest network permit the device to obtain 1993 email from anywhere on the Internet, via standard email reception 1994 protocols. It is RECOMMENDED that all other ports be blocked. Port 1995 25 (SMTP) MUST be blocked. All DNS ports MUST either be blocked, or 1996 be forwarded to a DNS server controlled by the administrator of the 1997 guest network. 1999 Network access SHOULD be restricted in both time and usage. There is 2000 no reason to allow unauthenticated guest access for more than about 2001 30 minutes. There is no reason to allow unauthenticated guests to 2002 transfer gigabytes of data. 2004 These requirements allow the provisioning process to be simple. A 2005 device uses EAP-TLS without peer authentication to connect to a 2006 network. The user enters an email address in a "self service" 2007 registration page. The visited network determines whether or not the 2008 person using that email address is authorized. If so, it sends a 2009 message to that address with a unique URL. 2011 The user obtains the email, clicks on the URL, and downloads 2012 credentials for the visited network. These credentials could be an 2013 EAP-TLS client certificate, which has the following properties: 2015 * issued by the visited network * containing information identifying 2016 the end user * ideally also contains information identifying the 2017 device * has a limited lifetime, ideally one day * lifetime MUST be 2018 less than 30 days. 2020 The device then provisions the credentials as above. 2022 This process could also be extended by leveraging DNS even more. The 2023 client device could look up a CERT record based on the user's 2024 identifying information, e.g. for a user with identifier 2025 "user@example.com", visiting a particular naiRalm it could look up a 2026 CERT RR of: 2028 user.example.com._guest._cert._eap. 2030 The local network could return a custom CERT RR, pointing to a URL 2031 for a page which contains a custom client certificate for use with 2032 EAP-TLS. 2034 As most DNS servers have limited policy capabilities, this 2035 functionality is likely difficult to implement in practice. 2037 7.7. Using TLS with protocols other than EAP 2039 While the discussion so far has been about EAP, there is no reason to 2040 limit this process to EAP. However, we do note that the methods 2041 defined here are intended for bootstrapping access to secure 2042 networks. They are not intended for use with generic web browsing. 2044 For example, it is possible to use similar methods (though with 2045 different DNS names and EKU fields) in order to configure clients for 2046 other protocols such as RADIUS/TLS [RFC6614] or RADIUS/DTLS 2047 [RFC7360]. 2049 These methods are not limited to RADIUS and EAP. For example, 2050 discovery of an IMAP server could be done via looking up a SRV record 2051 for "_imap._tcp.", while discovery of an email submission 2052 server could be done via looking up "_submit._tcp.". If a 2053 private CA is used for those services, it could be discovered via 2054 looking up a CERT record for "_ca._imap._tcp.". 2056 Similarly, the issue of intermediate CAs discussed earlier is also 2057 applicable to other protocols, and therefore requires similar 2058 solutions. We also note that there are issues with many other non- 2059 WWW protocols which appear to (mis)-use the id-kp-serverAuth field. 2060 We offer no solution here to that problem. 2062 It may be possible to use these processes in many other situations, 2063 but we do not discuss those use-cases in detail here. We only 2064 discuss them as a side note, to demonstrate that automatic 2065 provisioning of a client system can be done simply, securely, and 2066 with minimal intervention by an end user. 2068 8. Moving to the new methods 2070 The methods given herein are intended to give parties in an EAP 2071 conversation more, and better information about what should be 2072 happening, and about what is happening. If all of the recommended 2073 information is available, then all parties in an EAP conversation 2074 have strong, positive indications that the system is secure. If any 2075 information is missing or conflicting information is seen, then the 2076 system may or may not be secure. 2078 That is, following the recommendations is a positive signal of 2079 security. Lack of positive signals does not necessarily indicate 2080 insecurity. 2082 It is RECOMMENDED that EAP peers and authenticators which implement 2083 these processes add configurable flags which allow the 2084 recommendations to be made mandatory. These configurable flags 2085 SHOULD permit the recommendations to be enforced in a wide range of 2086 conditions, such as per SSID, per realm, per CA, etc. Doing so will 2087 allow administrators to make and enforce site-local policies. 2089 For example, a company might mandate that all devices which connect 2090 to WiFi use EAP with client certificates, that those client 2091 certificates contain the fields defined above, and that those devices 2092 only send authentication credentials to EAP authenticators which also 2093 satisfy the recommendations above. When an EAP peer follows these 2094 mandates, it will not be vulnerable to any of the attacks outlined 2095 earlier. 2097 These guidelines allows existing systems to operate unchanged. They 2098 also allow updated systems to gain the benefit of increased, and 2099 mandated, security. 2101 8.1. Using the new OIDs 2103 In general, we recommend using private CAs for EAP. Such uses avoid 2104 the issue of certificate misuse under the [CAB] guidelines. 2106 We also have to address how systems which are unaware of this 2107 specification will interact with certificates containing the new 2108 OIDs. 2110 Happily, the requirements of [RFC5216] and [EAPTLS] are requirements 2111 on what should exist, and not on what should not exist. Tests with 2112 implementations, and (where possible) checks of publicly available 2113 source code lead us to conclude that these requirements are 2114 accurately followed. 2116 The solution then is for server certificates to contain both id-kp- 2117 serverAuth, in order to satisfy [RFC5280], and also to contain id-kp- 2118 eapServer, in order to satisfy this document. The result is that 2119 both old, and new behavior is supported, and that the transition path 2120 from one to the other is seamless. 2122 8.2. Recommendations for EAP peers and authenticators 2124 It is RECOMMENDED that EAP peers use a dedicated certificate store 2125 for EAP. Where a dedicate certificate store cannot be used, each 2126 certificate MUST have additional metadata stored with it, which 2127 indicates its permitted uses. This metadata serves as a way of 2128 creating "per-use-case" certificate stores. 2130 It is RECOMMENDED that no CAs are enabled by default for EAP. User 2131 credentials are provisioned from a known authentication source. If 2132 there are no local user credentials configured, then by definition 2133 there are no known sources. When credentials are configured, known 2134 sources can be enabled at the same time. 2136 It is RECOMMENDED that "web" CAs are not used for EAP. The two use- 2137 cases are different, and misuse of certificates opens both EAP and 2138 WWW systems to attacks. 2140 It is RECOMMENDED that EAP peers do not perform TLS resumption across 2141 different media. 2143 It is RECOMMENDED that when EAP peers use any TLS-based EAP method 2144 with a client certificate, that the client certificate contains id- 2145 kp-eapClient in order to indicate that the certificate is intended to 2146 be used by an EAP peer. 2148 it is RECOMMENDED that EAP peers expose configuration settings which 2149 allow the user to permit this new behavior, or require it, on a per- 2150 NAI realm basis. 2152 It is RECOMMENDED that EAP servers which permit the use of client 2153 certificates mark one or more CAs as being permitted to issue client 2154 certificates. These CAs SHOULD be the one which is the "lowest" in 2155 the certificate chain. That is, the one which is closest to the 2156 client certificate. EAP servers SHOULD NOT mark a global "root" CA 2157 as being permitted to issue client certificates, as that root CA may 2158 sign many intermediate CAs, each of which could then issue client 2159 certificates. 2161 It is RECOMMENDED to use id-pe-wlanSSID [RFC4334] in client and 2162 server certificates. When used in a client certificate, it informs 2163 the client that this certificate should be used when the given SSID 2164 is seen. When used in a server certificate, it informs the client 2165 that the server is intended to be reachable from this particular 2166 SSID. Note that a mismatch is not necessarily an error. 2168 It is RECOMMENDED that when EAP authenticators use any TLS-based EAP 2169 method with a server certificate, that the server certificate 2170 contains id-kp-eapServer in order to indicate that the certificate is 2171 intended to be used by an EAP authenticator. 2173 It is RECOMMENDED that when EAP authenticators use any TLS-based EAP 2174 method with a server certificate, that the server certificate 2175 contains one or more naiRealm, to indicate that the EAP authenticator 2176 is authorized to accept authentication requests for users in those 2177 realms. 2179 The requirements of [RFC7585] Section 2.2 on the definition, number, 2180 and format of naiRealm are included here by reference. 2182 It is RECOMMENDED that when EAP peers use any TLS-based EAP method, 2183 that the EAP peer verify that the server certificate presented 2184 contains id-kp-eapServer, and an naiRealm which matches the NAI (if 2185 used) in the EAP Identity Response. Any mismatch indicates to the 2186 client that the server is not trusted to authenticate users for that 2187 realm. Therefore user credentials for that NAI realm should not be 2188 sent to the server. 2190 It is RECOMMENDED that when EAP authenticators use any TLS-based EAP 2191 method and a client certificate is presented, that the EAP 2192 authenticator verify that the client certificate contains id-kp- 2193 eapClient, and that the NAI (if used) given in the EAP Identity 2194 Response field matches one of the naiRealm fields in the server 2195 certificate. Any mismatch indicates to the server that the client is 2196 either misconfigured, or is acting maliciously. The server should 2197 therefore treat this mismatch as an authentication failure. 2199 As noted above, the use of the label "*" in id-on-naiRealm is 2200 forbidden for this specification. 2202 Where the server certificates do not contain naiRealm, but do contain 2203 one or more subjectAltName field of type dNSname, clients SHOULD 2204 verify that the NAI realm used by the client is an exact suffix of 2205 the dNSname field. 2207 8.3. Principles and Guidelines 2209 After analysis of the historical practices and standards for EAP, we 2210 came to a set of guidelines which are outlined in this section. 2211 Application of these guidelines drove the rest of the specification 2212 which we define herein. 2214 It is RECOMMENDED that the guidelines given below are followed when 2215 developing new network configuration standards and methods: 2217 * Automated provisioning is strongly preferred to manual 2218 provisioning. We define "automated provisioning" as provisioning 2219 which is performed via software, with little or no user 2220 intervention. Automation minimizes the possibility for end users 2221 to create broken or insecure configurations. 2223 * Manual provisioning should be limited to "Trust on first use" 2224 (ToFU), and cached or "pinned" after that. That is, manual 2225 provisioning should be limited to allowing a user to approve 2226 validation decisions which have been made by the system. 2228 * Relying on end users to manually configure complex systems 2229 is strongly discouraged. Complex systems are difficult to 2230 configure, and improperly configured systems create many issues 2231 related to security, usability, and network access. 2233 * Configuration should be "pinned" in order to permit systems to 2234 detect and prevent unauthorized changes, and to detect malicious 2235 networks which claim to be updated versions of the true network. 2237 * The identity and role of both parties should be exchanged, and 2238 verified. In practice, this suggestion often means that TLS-based 2239 EAP methods are preferred to ones which only do name / password 2240 credential verification. 2242 * The previous requirement usually means that the both parties know 2243 which RFC 7542 NAI realm is being used. This realm serves a 2244 similar purpose to the the DNS host name used in other TLS-based 2245 protocols such as HTTPS. As such, similar methods can be used to 2246 validate certificate authenticity. This NAI realm is contained in 2247 an id-on-naiRealm field, as defined in [RFC7585] Section 2.2 2249 * For TLS-based EAP methods, trust should be based on a 2250 certification authority (CA), which signs certificates for a 2251 particular realm. If the CA is trusted, then everything derived 2252 from that CA can be trusted. If the CA is not trusted, then it is 2253 impossible to trust anything derived from an untrusted CA. 2255 * CAs should also be associated with permitted uses. For example, a 2256 root CA which is trusted for web surfing is not necessarily trusted 2257 for use with EAP authentication. In practice this means either 2258 having separate certificate stores for different purposes, or 2259 annotating root certificates with their permitted uses. 2261 We believe that these recommendations are correct, simple, practical, 2262 and will improve security and usability for all participants in EAP. 2263 We show that there is a clear upgrade path from current behavior to 2264 better behavior. Each step of that upgrade path is simple, and 2265 involves minimal change for end users or administrators. 2267 9. Security Considerations 2269 There are a large number of security issues with current practices. 2270 This document attempts to give both fixes, and a transition path to a 2271 better system. As such, the entire document is discussing security 2272 issues. 2274 One of the main points of this document is that systems which are 2275 difficult to configure are likely to be insecure. 2277 This document also highlights problems with misuse of certificates 2278 containing id-kp-serverAuth, and id-kp-clientAuth. If such misused 2279 certificates were to be widely reported, then large parts of the 2280 Internet could be taken offline. 2282 We note that distribution of these certificates MUST NOT be done via 2283 email. There is just too much possibility for forgery and user 2284 mistakes for that process to be secure. We instead rely on secure 2285 transport layers and cryptographically signed data in order to 2286 bootstrap authenticated network access. 2288 9.1. On Identities and Service Discovery 2290 All the user needs is on identity (e.g. "user@example.com"), and a 2291 password. Essentially everything else required for network access 2292 can be derived automatically, and provisioned with no additional user 2293 input. This process is significantly more secure than manual 2294 provisioning. 2296 9.2. Password Hashing and Storage 2298 In some situations, using client certificates with EAP is preferable 2299 to using password-based methods. Password-based EAP methods often 2300 hash the password along with a salt or a challenge, and then send the 2301 hashed version of the password. However, this hashing can conflict 2302 with the desire of administrators to store hashed passwords in their 2303 user databases. The two different hashing methods are almost always 2304 incompatible, which means that the administrator has to choose either 2305 to send passwords via a method such as PAP inside of TTLS, or to 2306 store clear-text passwords in their local user database. 2308 Neither choice is optimal. Where there is a trade-off, it is 2309 RECOMMENDED that systems use a method such as TTLS with PAP, and then 2310 store hashed or encrypted passwords in the local user database. The 2311 "clear-text" password which is sent in TTLS is, in fact, secured via 2312 TLS when it is sent "over the wire". So there is minimal security 2313 risk with this approach. 2315 While some would argue that exposing the users clear-text password to 2316 an EAP Server is a security risk, it is in practice irrelevant. The 2317 EAP server is almost always co-located with an AAA server (e.g. 2318 RADIUS or Diameter). Those servers control network access for entire 2319 organizations, including setting complex policies. Any attacker who 2320 gains control of an AAA server can take many more, and worse actions 2321 than simply observe peoples passwords. 2323 In contrast, history shows that exposure of user databases (with 2324 names and passwords) is not uncommon. In fact, as the EAP or AAA 2325 server usually has complete access to the user database (including 2326 passwords), compromise of the AAA server almost by definition leads 2327 to compromise of the local user password database. 2329 We therefore make the trade-off which has the lowest possible 2330 security impact, for all failure cases. Passwords SHOULD be stored 2331 hashed or encrypted in a user database. TLS-based EAP methods which 2332 rely on passwords SHOULD use authentication methods which are 2333 compatible with such password storage methods, which generally means 2334 that the passwords are sent by the user in clear-text, but protected 2335 by TLS. 2337 10. IANA Considerations 2339 This section this specification requests from Internet Assigned 2340 Numbers Authority (IANA) registration of the following items. 2342 10.1. Key Purpose OIDs 2344 We request registration of values related to the certificate key 2345 purpose OIDs in accordance with [RFC8126]. 2347 * id-kp-eapServer 2349 * id-kp-eapClient 2351 10.2. Underscored and Globally Scoped DNS Node Names 2353 Per RFC 8552, please add the following entry to the "Underscored and 2354 Globally Scoped DNS Node Names" registry: 2356 +---------+----------------------+---------------------------------+ 2357 | RR Type | _NODE NAME | Reference | 2358 +---------+----------------------+---------------------------------+ 2359 | CERT | _ca._cert._eap | | 2360 | CERT | _client._cert._eap | | 2361 | CERT | _server._cert._eap | | 2362 | SRV | _est._eap | | 2363 | URI | _install._mdm | | 2364 +---------+----------------------+---------------------------------+ 2366 We note that [RFC8552] does not provide for "sub" registries, as we 2367 have defined above. However, we believe that these definitions fall 2368 within both the intent of [RFC8552], and common practice. 2370 11. References 2372 11.1. Normative References 2374 [RFC2119] 2375 Bradner, S., "Key words for use in RFCs to Indicate Requirement 2376 Levels", RFC 2119, March, 1997, . 2379 [RFC3748] 2380 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2381 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 2382 June 2004. 2384 [RFC4334] 2385 Housley, R., and Moore, T., "Certificate Extensions and Attributes 2386 Supporting Authentication in Point-to-Point Protocol (PPP) and 2387 Wireless Local Area Networks (WLAN)", RFC 4334, February 2006 2389 [RFC4398] 2390 Josefsson, S., "Storing Certificates in the Domain Name System 2391 (DNS)", RFC 4398, March 2006. 2393 [RFC5216] 2394 Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication 2395 Protocol", RFC 5216, March 2008 2397 [RFC7170] 2398 Zhou, H., et al., "Tunnel Extensible Authentication Protocol (TEAP) 2399 Version 1", RFC 7170, May 2014. 2401 [RFC7234] 2402 Fielding, Ed., et al, "Hypertext Transfer Protocol (HTTP/1.1): 2403 Caching", RFC 7234, June 2014 2405 [RFC7542] 2406 DeKok, A., "The Network Access Identifier", RFC 7542, May 2015. 2408 [RFC8126] 2409 Cotton, M., et al, "Guidelines for Writing an IANA Considerations 2410 Section in RFCs", RC 8126, June 2017. 2412 [RFC8174] 2413 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key 2414 Words", RFC 8174, May 2017, . 2417 [RFC8552] 2418 Crocker, D., "Scoped Interpretation of DNS Resource Records through 2419 "Underscored" Naming of Attribute Leaves", RFC 8552, March 2019. 2421 [EAPTLS] 2422 Mattsson, J., and Sethi, M., "Using EAP-TLS with TLS 1.3", draft- 2423 ietf-emu-eap-tls13-15, May 2021. 2425 11.2. Informative References 2427 [CAT] 2428 https://cat.eduroam.org/ 2430 [EDUROAM] 2431 https://eduroam.org/ 2433 [MSPEAP] 2434 https://msdn.microsoft.com/en-us/library/cc238354.aspx 2436 [PEAP] 2437 Palekar, A. et al, "Protected EAP Protocol (PEAP)", draft- 2438 josefsson-pppext-eap-tls-eap-06.txt, March 2003. 2440 [CAB] 2441 CA/Browser Forum, "Baseline Requirements for the Issuance and 2442 Management of Publicly-Trusted Certificates" Version 1.7.4, 5 April 2443 2021 https://cabforum.org/wp-content/uploads/CA-Browser-Forum- 2444 BR-1.7.4.pdf 2446 [RFC2716] 2447 Aboba, B., and Simon, D., "PPP EAP TLS Authentication Protocol", 2448 RFC 2716, October 1999. 2450 [RFC2865] 2451 Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 2452 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 2454 [RFC2818] 2455 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2457 [RFC4851] 2458 Cam-Winget, N., et al, "The Flexible Authentication via Secure 2459 Tunneling Extensible Authentication Protocol Method (EAP-FAST)", 2460 RFC 4851, May 2007. 2462 [RFC5280] 2463 Cooper, D., et al., "Internet X.509 Public Key Infrastructure 2464 Certificate and Certificate Revocation List (CRL) Profile", RFC 2465 5280, May 2008. 2467 [RFC5281] 2468 Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol 2469 Tunneled Transport Layer Security Authenticated Protocol Version 0 2470 (EAP-TTLSv0)", RFC 5281, August 2008. 2472 [RFC5785] 2473 Nottingham, M. and Hammer-Lahav, E., "Defining Well-Known Uniform 2474 Resource Identifiers (URIs)", April 2010. 2476 [RFC5931] 2477 Harkins, D., and Zorn, G., "Extensible Authentication Protocol 2478 (EAP) Authentication Using Only a Password", RFC 5931, August 2010. 2480 [RFC6614] 2481 Winter, S., et al., "Transport Layer Security (TLS) Encryption for 2482 RADIUS", RFC 6614, May 2012. 2484 [RFC6677] 2485 Hartman, S. (ed), et al., "Channel-Binding Support for Extensible 2486 Authentication Protocol (EAP) Methods", RFC 6677, July 2012. 2488 [RFC7030], 2489 Pritikin, M. (Ed), Et al, "Enrollment over Secure Transport", 2490 October 2013 2492 [RFC7360] 2493 DeKok, A., "Datagram Transport Layer Security (DTLS) as a Transport 2494 Layer for RADIUS", RFC 7360, September 2014. 2496 [RFC7585] 2497 Winter, S, and McCauley, M., "Dynamic Peer Discovery for RADIUS/TLS 2498 and RADIUS/DTLS Based on the Network Access Identifier (NAI)", RFC 2499 7585, October 2015. 2501 [RFC7593] 2502 Weiringa, K. et al, "The eduroam Architecture for Network Roaming", 2503 RFC 7593, September 2015. 2505 [RFC8446] 2506 Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 2507 1.3", August 2018. 2509 [RFC8894] 2510 Gutmann, P., "Simple Certificate Enrolment Protocol", RFC 8894, 2511 September 2020. 2513 Acknowledgments 2515 This document would not be possible without the input of many people. 2517 Jorge Vergara provided reviews of previous documents which led to a 2518 clearer articulation of the problem described here, and which 2519 therefore motivated this document. He has also provided reviews for 2520 early versions of this document. 2522 Tom Rixom provided a significant amount of information on issues seen 2523 by supplicants, which motivated much of the text in Section 3.1. 2525 Arran Cudbard-Bell suggested using DNS for the "out of band" 2526 provisioning of certificates in Section 3. He also provided detailed 2527 reviews of multiple versions of this document. 2529 Stefan Winter provided feedback on a number of issues related to 2530 certificates, roaming, and provisioning. 2532 Karri Huhtanen raised issues related to purpose-specific CAs, and 2533 provided suggestions to help address those issues. 2535 Authors' Addresses 2537 Alan DeKok 2538 Network RADIUS SAS 2539 26 rue Colonel Dumont 2540 38000 Grenoble 2541 FRANCE 2542 Email: aland@networkradius.com