idnits 2.17.1 draft-dekok-emu-eap-usability-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 RFC5, 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 rfc5 - is the name correct? -- The document date (5 March 2022) is 782 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 5 March 2022 5 Category: Standards Track 6 Expires: September 05, 2022 8 EAP Usability 9 draft-dekok-emu-eap-usability-01.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) 2022 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 .......................... 36 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 ..................... 42 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.4.4. Fully Anonymous Network Access and Provisioning 45 119 7.5. id-kp-eapOverLAN May not be sufficient .............. 46 120 7.6. Guest Networks ...................................... 46 121 7.7. Using TLS with protocols other than EAP ............. 48 122 8. Moving to the new methods ................................ 49 123 8.1. Using the new OIDs .................................. 49 124 8.2. Recommendations for EAP peers and authenticators .... 50 125 8.3. Principles and Guidelines ........................... 52 126 9. Security Considerations .................................. 53 127 9.1. On Identities and Service Discovery ................. 53 128 9.2. Password Hashing and Storage ........................ 53 129 10. IANA Considerations ..................................... 54 130 10.1. Key Purpose OIDs ................................... 55 131 10.2. Underscored and Globally Scoped DNS Node Names ..... 55 132 11. References .............................................. 55 133 11.1. Normative References ............................... 55 134 11.2. Informative References ............................. 56 136 1. Introduction 138 TLS [RFC8446] has been widely deployed, and is used with EAP 139 [RFC3748] and with RADIUS [RFC2865]. Historically, these 140 specifications have been written to define the protocols "on the 141 wire", with minimal description of use-cases and usability. The 142 success of these specifications has been that perhaps a billion 143 devices use EAP. The failure of these specifications is that EAP can 144 be still difficult to use, both for administrators and for end users. 146 Even with a clear standard, implementations do not always follow the 147 specifications exactly. In some cases implementations do less than 148 what is recommended, which can cause security and inter-operability 149 issues. In other cases, implementors do more than what is 150 recommended, as they have found the specifications insufficient to 151 address practical requirements. In other cases, there is no 152 standard, so implementators make individual choices as to how their 153 implementations work. Even worse, implementors change their 154 implementations over time, to solve problems which are not addressed 155 in the standards. 157 All of these issues lead to confusion for end users and 158 administrators. These issues lead to decreased security of the 159 protocols, and decreased trust in the protocols. 161 The result of the above problems is software where many critical 162 aspects of its operation are vendor-defined. This wide variation 163 gives a poor experience for all parties involved, and contributes to 164 decreased security. 166 This document therefore defines method to enable the simple and easy 167 deployment of TLS-based EAP methods. It defines new certificate 168 fields, and describes how those fields can be used to gain network 169 access easily and securely. The processes it defines are clear and 170 straightforward. The end user experience is understandable, and 171 difficult to get wrong. 173 That is, this specification removes the need to rely on end users to 174 make security decisions. History shows us that such reliance is 175 misplaced. Instead, we rely on the global certificate system which 176 has proven to work well, along with a few changes to the behavior of 177 EAP systems. 179 These ideas are not new. [RFC4334] Section 1 says: 181 Automated selection of client certificates for use with PPP and 182 IEEE 802.1X is highly desirable. By using certificate extensions 183 to identify the intended environment for a particular certificate, 184 the need for user input is minimized. 186 We extend the above statements to include server certificates, and to 187 further define automated processes by which TLS-based EAP methods can 188 be configured. In addition, where [RFC4334] describes the "automated 189 selection of client certificates", we invert that use-case to show 190 how certificates can be used to automate network configuration, via a 191 set of simple and clearly defined processes. 193 The requirements on the client device are simple: 195 * it has some kind of network connectivity, * it has a root 196 certificates for the web, * it knows the domain for which it wishes 197 to authenticate 198 e.g. "example.com", * it knows a username and password at that 199 domain. 201 With that information, the configuration process can be automated, 202 with essentially zero user input. 204 The document begins with an overview of the current situation. We 205 describe the problems which have motivated this document. First by 206 showing how the behavior of multiple vendor implementations has 207 changed over time. We then discuss problems with the ways that 208 certificate are handled. We discuss how the standards contradict 209 each other, and how current practices contradict, ignore, or extend 210 the standards in incompatible ways. 212 The document begins with a worked example, initially just for EAP- 213 TLS, and then showing how the processes described for EAP-TLS can be 214 easily applied to other EAP methods. 216 We extend the given solution by using DNS and HTTPS to perform 217 initial bootstrapping of the supplicant configuration. We show how 218 supplicants can be configured securely by leveraging the existing 219 trust in the web PKI. This bootstrapping requires no changes to 220 supplicant code or behavior. 222 We finally summarize the work by giving a set of specific 223 recommendations. 225 1.1. Requirements Language 227 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 228 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 229 "OPTIONAL" in this document are to be interpreted as described in BCP 230 14 [RFC2119] [RFC8174] when, and only when, they appear in all 231 capitals, as shown here. 233 2. Historical Problems 235 There have historically been a number of issues with configuring 236 devices for EAP authentication. The overly positive description of 237 this history is that it has resulted in a wide variety of tools and 238 products available to configure EAP on end-user devices. In addition 239 to the wide variety of configuration products, the behavior of native 240 supplicants has also varied widely over time. 242 These issues point to an underlying problem which has, as yet, been 243 unresolved. Each vendor of configuration products or devices to be 244 configured has largely been performing searches by "trial and error" 245 in order to find the best user experience. The result, of course, 246 has been a frustrating experience for both users and for vendors. 248 We do not discuss Mobile Device Management (MDM) vendors or vendors 249 of other supplicant configuration products here. Their products are 250 largely tools which use the APIs presented by supplicant vendors, and 251 attempt to hide the complexity from end users. 253 We also do not discuss the behavior of EAP servers (authenticators) 254 or RADIUS servers. The issues seen by supplicants are largely 255 related to user experience, and have little effect on the "on the 256 wire" protocol. As such, RADIUS servers have been required to make 257 correspondingly fewer changes to their implementations. In addition, 258 RADIUS servers are generally designed to be complex, with complex 259 policies. These policies enable their administrators to change the 260 behavior of the software without resorting to product upgrades. 262 As a result, we focus initially on supplicants, how their behavior 263 has changed over time, and the publicly visible effects of those 264 changes. 266 2.1. Supplicant Changes over Time 268 In this section we discuss how the behavior of multiple supplicants 269 has changed over time. We do not name the vendors of these 270 supplicants, as there is no need to blame them for being unable to 271 solve an industry-wide problem. 273 2.1.1. Phone Vendor One 275 This vendor has been gradually disabling the supplicant 276 configuraration API. Instead, configuration product vendors are able 277 to influence the user interface with suggested prompts at different 278 points in the authentication framework. 280 It appears that the goal is to give the user control over the 281 network. A related goal is to require the user's consent before 282 making changes to the network. 284 The system also treats SSIDs as defining a location, even though 285 SSIDs are not inherently location-specific. This mislabelling means 286 that users' are shown prompts about location, when in fact the 287 operation being performed is connecting to an SSID. 289 The effect of these issues is that the user is unable to meaningfully 290 consent. There may insufficient information available, the available 291 information may be meaningless to the end user, or the information 292 given to the end user is simply wrong. 294 This vendor has changed how manual connections are managed over time. 295 The user is not always prompted, but the systems behavior has gone 296 through the following changes to connection requirements: 298 * do not perform certificate validation * validate that the root CA 299 is in the system certificate store * validate that the root CA is in 300 the WiFi certificate store * require a DNS name for the RADIUS 301 server. 303 None of these solutions are optimal. 305 2.1.2. Phone Vendor Two 307 This vendor has a standard format for WiFi configuration files. The 308 user can manually install the configuration, but that configuration 309 is not active until an additional manual step is performed to enable 310 it. 312 A standard configuration is useful, but the configuration file is not 313 typically signed, even though that is supported. It appears that the 314 the manual enablement step is an attempt to work around the lack of 315 authentication for the configuration files. 317 As was seen in the previous section, the end user has no meaningful 318 information about the configuration. This lack of information means 319 that the user is conditioned to simply accept the configuration and 320 enable it, without paying attention to its contents. 322 This vendor does, however, provide a robust API. This API permits a 323 rich ecosystem of MDM products which automate the configuration of 324 end-user devices. 326 2.1.3. Operating System Vendor One 328 This vendor has been gradually disabling their WLAN API. The 329 remaining APIs permit MDM solutions to associate a user identity with 330 a particular network. However, there is no ability to set a root CA 331 or a RADIUS server DNS host name. 333 When the user connects to the network, a prompt is shown which asks 334 the user if the server is valid. The server certificate is presented 335 to the user, but the user has no information about which root CA is 336 acceptable or not. Instead, the user is shown fields from an unknown 337 certificate, and is asked to validate that the certificate is 338 acceptable. 340 Again, the user has insufficient information to meaningfully consent. 341 Which again means that the only course of action is to mindlessly 342 click on "accept". 344 2.1.4. Operating System Vendor Two 346 This vendor retains a rich WLAN API, but has removed the ability to 347 configure specific users. Instead, only system-wide profiles can be 348 set. 350 This vendor provides for easy installation of additional root CAs, 351 but those root CAs are permitted to be used for any purpose. Which 352 means that a malicious private CA can issue HTTPS certificates for 353 any domain. These fake certificates will be silently accepted by the 354 systems browser as being valid. The user will be unable to 355 distinguish malicious sites presenting those fake certificates from 356 the genuine domains. 358 It is difficult to overstate the negative security impact of that 359 process. 361 An MDM product adding a private CA generally requires a privileged 362 account to install the CA. A user can install a CA manually, but the 363 operating system will show the user large amounts of text in order to 364 warn the user about the security issues of this process. The user, 365 of course, has no way of understanding many of these warnings, and is 366 left again to mindlessly click on "accept". 368 2.1.5. Operating System Vendor Three 370 This vendor retains a rich WLAN API, and a number of tools by which 371 network configuration can be performed. These tools are widely used 372 by MDM vendors to automate the configuration of networks. 374 However, the end user experience is still complex. The user still 375 must manually select each individual parameter from multiple options. 376 This capability gives the user a substantial amount of control over 377 the process, but does not provide any more information than is 378 available in other operating systems. 380 This process of allowing the end user to configure everything is 381 useful for experienced and knowledgable users. However, it leaves 382 the average user with a bewildering set of choices, most of which are 383 meaningless or opaque. The user is then left to mindlessly follow 384 online guides, which may or may not work, and which do not give the 385 user enough information to give informed consent for the actions that 386 are being taken. 388 2.2. Problems with Certificates 389 The widely (and wildly) changing behavior of supplicant software is 390 not the end of the story, however. There are a large number of 391 problems related to the use and abuse of certificates. These issues 392 are discussed in more detail in this section. 394 2.2.1. Problematic Use of Certificate Stores 396 Some EAP peers use a different certificate store for EAP than for 397 other (e.g. web) applications. In practice, the use-case of 398 "downloading video from a known source" is substantially different 399 from the use-case of "sending authentication credentials to a known 400 destination". As such, the certificate stores should be different 401 for these two use-cases. 403 When a CA is allowed to be used for EAP, then the implication is that 404 all certificates signed by that CA are allowed to be used for EAP. 405 This result is not secure. It permits attackers to get a valid 406 server certificate from a public CA, and then to set up an EAP 407 server. Naive EAP peers will then send user credentials to the 408 malicious server. Worse, there is no general way for any third-party 409 to detect that this impersonation has happened. It is only visible 410 to EAP peers who are in a small geographic area. 412 Tests have shown that in a university environment, up to fifty 413 percent of EAP peers will connect to a malicious SSID without 414 checking the CA or server certificate. In effect, these peers will 415 send authentication credentials to anyone who asks. 417 The security problems associated with such behavior cannot be 418 overstated. 420 However, not all EAP peers uses separate certificate stores. Using 421 one certificate store is less of an issue when "self signed" or 422 "private" CAs are used. The use of private CAs for EAP means that 423 the EAP system is now more secure. However, the addition of private 424 CAs to a global certificate store means that those private CAs can 425 now issue certificates for well-known public web sites. The 426 possibility of such forgery has made it difficult for MDM vendors or 427 site administrators to create and use private CAs. 429 As such, we reiterate that the certificate stores SHOULD be different 430 for these each application or use-case. Where the system cannot 431 tolerate multiple different stores, it SHOULD at least mark each CA 432 certificate with an annotation as to its intended purpose. While 433 there is a "key purpose" field defined for certificates, we will see 434 that this field is not always suitable for differentiating 435 certificate purposes. 437 2.2.2. Problematic use of key purpose fields 439 [RFC5216] Section 5.3 makes the following recommendations about the 440 certificate used by the EAP-TLS server: 442 In the case of the EAP-TLS peer, this involves ensuring that the 443 certificate presented by the EAP-TLS server was intended to be 444 used as a server certificate. Implementations SHOULD use the 445 Extended Key Usage (see Section 4.2.1.13 of RFC3280) extension and 446 ensure that at least one of the following is true: 447 1) The certificate issuer included no Extended Key Usage 448 identifiers in the certificate. 449 2) The issuer included the anyExtendedKeyUsage identifier in the 450 certificate ... 451 3) The issuer included the id-kp-serverAuth identifier in the 452 certificate ... 454 These recommendations have also been used in EAP-TLS [EAPTLS], EAP- 455 TTLS [RFC5281], PEAP [PEAP] and [MSPEAP], EAP-FAST [RFC4851], and 456 TEAP [RFC7170]. 458 We first note that this document extends and strengthens the 459 suggestion that systems ensure "that the certificate presented by the 460 EAP-TLS server was intended to be used as a server certificate." We 461 also extend this recommendation to client certificates, further 462 strengthening the security around TLS-based EAP methods. 464 However there is an issue with the [RFC5216] recommendations. These 465 recommendations appear to be in direct conflict with the definition 466 of id-kp-serverAuth from [RFC5280] 4.2.1.12, and of the requirements 467 for its usage: 469 If the extension is present, then the certificate MUST only be 470 used for one of the purposes indicated. If multiple purposes are 471 indicated the application need not recognize all purposes 472 indicated, as long as the intended purpose is present. 473 ... If a certificate contains both a key usage extension and an 474 extended key usage extension, then both extensions MUST be 475 processed independently and the certificate MUST only be used for 476 a purpose consistent with both extensions. If there is no purpose 477 consistent with both extensions, then the certificate MUST NOT be 478 used for any purpose. 479 ... 480 id-kp-serverAuth OBJECT IDENTIFIER ::= { id-kp 1 } 481 -- TLS WWW server authentication 483 This definition shows that id-kp-serverAuth is intended for "WWW 484 server" usage, which is in conflict with how it is defined in 485 [RFC5216]. Similar issues exist for the id-kp-clientAuth OID, in 486 that it is intended for "WWW client", which is not correct for EAP. 488 It appears that the recommendations made in [RFC5216] were taken from 489 [RFC2716], and were made for entirely practical reasons. The desire 490 was for users of EAP to be able to obtain certificates from public 491 root CAs. However, those root CAs could not (or would not) issue 492 certificates which contained OIDs other than id-kp-serverAuth. 493 Therefore as work around, [RFC5216] Section 5.3 allowed for a wide 494 variety of EKUs to be used in server certificates. These 495 certificates could then come from private CAs, or from publicly known 496 root CAs. 498 We believe that the long-term correct solution is to define and use 499 additional key purpose OIDs. These key purpose OIDs can initially be 500 used by EAP implementations along with private CAs. As support for 501 these OIDs becomes more widely available, it may be possible for 502 public CAs to issue purpose-specific certificates. 504 The problematic use of id-kp-serverAuth has had a number of impacts, 505 past the issue of contradictory specifications. These impacts result 506 in certificates being used in problematic ways, which we discuss 507 below. 509 2.2.3. Problematic Use of Certificates 511 The current workarounds to the contradictions in the specifications 512 are two-fold. One, is simply to get certificates with id-kp- 513 serverAuth from a public CA, and hope that using it for EAP either is 514 acceptable, or that it is not noticed. Another is to use a self- 515 signed CA. Both work-arounds have problems. 517 Many people prefer to use public CAs, as they are seen as "better" 518 than self-signed CAs. However, using a public CA likely means 519 violating the terms of use of that CA. Which means that the network 520 continues to work so long as this mis-use is not reported. 522 It can be useful instead to use private CA. A private CA can add id- 523 kp-serverAuth without violating any terms of use, or it can omit the 524 key purpose OIDs, or it can add custom key purpose OIDs. 526 However, in addition to the problems noted in the earlier section, 527 private CAs are not installed by default in client devices. This 528 limitation means that these CAs must be provisioned somehow. As seen 529 above, these provisioning methods can be complex and prone to 530 failure. 532 As such, there is no simple, easy, way for administrators to both 533 obtain and provision certificates for use with EAP. 535 We also note that these OIDs are used not only for EAP, but that they 536 are also used for other public-facing TLS services such as XMPP, 537 SMTPS, LDAPS, etc. Those protocols may have similar issues with 538 alleged mis-use of these OIDs. If these use-cases are forbidden user 539 CAB guidelines, then this would seem to be a serious problem with the 540 global certificate framework. 542 We leave the solution of these issues as a point of discussion for 543 the wider Internet community. 545 2.2.4. Obtaining Certificates with the new OIDs 547 Most CAs currently offer limited support for non-"WWW" OIDs in 548 certificates. In many cases, the Certificate Signing Request (CSR) 549 supplied by the customer is (in practice) used only as a vague 550 suggestion. While the CA generally does not add any fields, it may 551 drop fields that it does not recognize or support. Or, the CA may 552 discard the CSR entirely. 554 [CAB] Section 7.1.2.3 makes it difficult for existing CAs to issue 555 client certificates which contain the new OIDs: 557 Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth 558 [RFC5280] or both values MUST be present. id-kp-emailProtection 559 [RFC5280] MAY be present. Other values SHOULD NOT be present. The 560 value anyExtendedKeyUsage MUST NOT be present. 562 Further, the requirements of [CAB] Section 7.1.2.4 essentially 563 forbids CAs from signing certificates which are intended for use with 564 EAP: 566 CAs SHALL NOT issue a Certificate with: 568 a. Extensions that do not apply in the context of the public 569 Internet (such as an extKeyUsage value for a service that is only 570 valid in the context of a privately managed network), unless: 572 None of the reasons listed after "unless" allow for CAs to issue 573 certificates for use with EAP in a privately managed network. 575 This behavior by CAs makes it difficult in practice, if not 576 impossible, to obtain non-"WWW" certificates from a public CA. 578 The suggestion given here is to simply use self-signed CAs. This 579 suggestion is not always practical. 581 It is possible to define CAs for "walled gardens" with a private CA. 582 One example is certificates used internally in an organization, or in 583 a group such as Eduroam [RFC7593] and [EDUROAM]. In those 584 situations, the members requesting certificates have already 585 validated, and there is already a legal framework in place to protect 586 the parties. 588 Other suggestions have been that it is relatively simple to set up a 589 new CA, with new procedures and requirements. Given the regulatory 590 requirements around CAs, it appears that new public-facing CAs have 591 to be well funded. i.e. requiring many millions of dollars. It is 592 therefore difficult, if not impossible, for small public-facing CAs 593 to be created. 595 The goal of this document is to permit better behavior for EAP peers 596 and authenticators. If this specification is widely deployed, then 597 there may be sufficient demand for CAs to offer new certificates 598 which are marked as fit for their intended purpose. 600 3. Principles and Guidelines 602 After analysis of the historical practices and standards for EAP, we 603 came to a set of guidelines which are outlined in this section. 604 Application of these guidelines drove the rest of the specification 605 which we define herein. 607 3.1. Network Configuration Guidelines 609 It is RECOMMENDED that the guidelines given below are followed when 610 developing new network configuration standards and methods: 612 * Automated provisioning is strongly preferred to manual 613 provisioning. We define "automated provisioning" as provisioning 614 which is performed via software, with little or no user 615 intervention. i.e. "zero touch" for end users. Automation 616 minimizes the possibility for end users to create broken or 617 insecure configurations. 619 * Manual provisioning should be limited to "Trust on first use" 620 (ToFU), and cached or "pinned" after that. That is, manual 621 provisioning should be limited to allowing a user to approve 622 validation decisions which have been made by the system. 624 * Relying on end users to manually configure complex systems 625 is strongly discouraged. Complex systems are difficult to 626 configure, and improperly configured systems create many issues 627 related to security, usability, and network access. 629 * Configuration should be "pinned" in order to permit systems to 630 detect and prevent unauthorized changes, and to detect malicious 631 networks which claim to be updated versions of the true network. 633 * The identity and role of both parties should be exchanged, and 634 verified. In practice, this suggestion often means that TLS-based 635 EAP methods are preferred to ones which only do name / password 636 credential verification. TLS allows both parties to exchange 637 certificates which demonstrate their identities, 639 * The previous requirement usually means that the both parties know 640 which RFC 7542 NAI realm is being used. This realm serves a 641 similar purpose to the the DNS host name used in other TLS-based 642 protocols such as HTTPS. As such, similar methods can be used to 643 validate certificate authenticity. This NAI realm is contained in 644 an id-on-naiRealm field, as defined in [RFC7585] Section 2.2 646 * For TLS-based EAP methods, trust should be based on a 647 certification authority (CA), which signs certificates for a 648 particular realm. If the CA is trusted, then everything derived 649 from that CA can be trusted. If the CA is not trusted, then it is 650 impossible to trust anything derived from an untrusted CA. 652 * CAs should also be associated with permitted uses. For example, a 653 root CA which is trusted for web surfing is not necessarily trusted 654 for use with EAP authentication. In practice this means either 655 having separate certificate stores for different purposes, or 656 annotating root certificates with their permitted uses. Again, 657 this process should be automated, because end users have no way to 658 verify which CA is valid for what purpose. 660 We believe that these recommendations are correct, simple, practical, 661 and will improve security and usability for all participants in EAP. 662 We show that there is a clear upgrade path from current behavior to 663 better behavior. Each step of that upgrade path is simple, and 664 involves minimal change for end users or administrators. 666 4. New Recommendations for Certificates with EAP 668 The first step towards a complete solution is to define new OIDs. 669 These OIDs indicate that certificates are intended for use with an 670 EAP server, or an EAP peer. 672 The following key usage purposes are defined within id-kp: 674 id-kp OBJECT IDENTIFIER ::= { id-pkix 3 } 676 id-kp-eapServer OBJECT IDENTIFIER ::= { id-kp TBD-1 } 677 -- TLS EAP server authentication 678 -- Key usage bits that may be consistent: digitalSignature, 679 -- keyEncipherment or keyAgreement 681 id-kp-eapClient OBJECT IDENTIFIER ::= { id-kp TBD-2 } 682 -- TLS EAP peer authentication 683 -- Key usage bits that may be consistent: digitalSignature, 684 -- and/or keyAgreement 686 These EKU fields mirror id-kp-serverAuth, and id-kp-clientAuth, 687 respectively. 689 We also rely on id-on-naiRealm, as defined in [RFC7585] Section 2.2. 690 This field contains the NAI realm [RFC7542] in which the user has an 691 identity, and for which the EAP server is performing authentication. 693 4.1. Comparison to HTTPS 695 We can further explain how these fields help EAP by comparison with 696 how certificates are used for HTTPS [RFC2818]: 698 * HTTPS uses id-kp-serverAuth to indicate that a certificate 699 is permitted to be used with an HTTPS server. We 700 define id-kp-eapServer which indicates that a 701 certificate is permitted to be used with an EAP 702 server. 704 * HTTPS uses id-kp-clientAuth to indicate that a certificate 705 is permitted to be used with an HTTPS client. We 706 define id-kp-eapClient which indicates that a 707 certificate is permitted to be used with an EAP 708 client. 710 * HTTPS uses id-ce-subjectAltName with dNSName [RFC5280] to contain 711 the DNS name of the server to which the client is 712 connecting. We use id-on-naiRealm [RFC7585] to 713 indicate the NAI realm of the server to which the 714 client is authenticating. 716 4.2. Additional Information Required 718 When combined with a clearly defined process, the above definitions 719 allow devices to use TLS-based EAP methods with no more complexity 720 than is seen when browsing the web. That is, in many situations, all 721 the end device needs is the following: 723 * network access (trusted or not) * an account in a domain, e.g. 724 "user@example.com" * one or more trusted root CAs from the web PKI. 726 This information can be used to securely obtain network access. The 727 procedures outlined here work with both public CAs and private CAs. 729 We will first describe how these fields can be used to make EAP 730 authentication easier to use. Once we have described a worked 731 example using these fields, we will show how to extend the solution 732 to solve the remaining open issues. 734 5. How It Works in Practice 736 In this section we provide a worked example for EAP-TLS. This 737 discussion uses EAP-TLS as an example, but the methods discussed here 738 are not limited to that use-case. Describing a specific EAP method 739 allows us to discuss every aspect of the proposal, without worrying 740 about how similar methods are applicable to different situations. 742 We expand the discussion later in this section to show how these 743 methods are applicable to other TLS-based EAP methods. 745 5.1. A worked example for EAP-TLS 747 We explain how this specification works via an example using EAP-TLS. 748 We start off with the problem statement, then how the certificates 749 might be obtained, then how the EAP peer is configured using 750 information in the certificates, and finally how the device obtains 751 network access. 753 5.1.1. The Problem Statement 755 For the initial worked example, we assume that we are trying to solve 756 the limited problem of an end user who has a WiFi enabled device such 757 as a laptop. The user wishes to use that device to get online, via 758 the simplest possible method. There is an administrator who also 759 wishes to get that user online, and wishes to configure the end user 760 device to do EAP-TLS. 762 We also presume that there are some additional pieces of the 763 solution, as follows: 765 * There may be a Wireless LAN (WLAN) System Service identifier 766 (SSID) which is used for WiFI authentication. This information can 767 be realized in the certificate field id-pe-wlanSSID, as defined in 768 [RFC4334] Section 3. 770 * All parties know which NAI realm [RFC7542] is being being used. 771 For example, an individual may work for a company "example.com". 772 This information is placed into the certificate field id-on- 773 naiRealm, as defined in [RFC7585] Section 2.2. 775 * We use the new EKU field id-kp-eapServer. This field indicates 776 that a certificate is intended to be used as a server certificate 777 within EAP. 779 * We use the new EKU field id-kp-eapClient. This field indicates 780 that a certificate is intended to be used as a client certificate 781 within EAP. 783 Knowing the name of the SSID is necessary, but perhaps not 784 sufficient. Some environments may have additional security 785 requirements, such as mandating that only WPA3-192-bit connections 786 may be used. This information should likely go into another field of 787 the certificate. For the purposes of this document, we will assume 788 that knowing the SSID name is acceptable. 790 EAP methods are also used to authenticate users when SSIDs are not 791 available (e.g. wired 802.1X), the use of id-pe-wlanSSID is 792 recommended, but is not required. For the purpose of this section, 793 we assume that WiFi access is being configured. Later discussion 794 will show how the methods outlined here can be applied to other forms 795 of network access. 797 As we will see below, this information is sufficient to configure 798 EAP-TLS securely, and with minimal effort by the end user. 800 5.1.2. Obtaining the Certificates 802 The administrator begins by obtaining a server certificate from a 803 root CA. This CA can be public or private. The only requirement is 804 that the CA is willing to sign certificates which contain an id-on- 805 naiRealm field, and which also contain the id-kp-eapServer field 806 which indicates that this certificate is suitable for use with EAP. 807 The rest of the fields, and the validation process for those fields, 808 can be identical to the processes used today. 810 The use of the new EKU fields here is intended to illustrate the end 811 goal of simplifying deployments. As we will see later, there are 812 intermediate steps which do not require the new EKU fields. 814 The administrator also obtains a client certificate, which will be 815 given to the end user for installation on the device. This client 816 certificate is issued via a hierarchy which ends in a known root CA. 817 The rest of the certificate hierachy here is not important to this 818 example. We only presume that it exists; that it is valid; and 819 therefore that it is trusted. 821 The client certificate contains an id-on-naiRealm field, which has 822 the same NAI realm as seen in the server certificate. The client 823 certificate also contains the id-kp-eapClient field which indicates 824 that this certificate is suitable for use with EAP. The client 825 certificate may also contain a id-pe-wlanSSID field, though this is 826 not required. 828 We presume that the client certificate also has an associated private 829 key, and that this key is encrypted using a password. 831 We now have enough information to configure the end user device. 833 5.1.3. Configuring the end user device 835 The administrator configures the end device with the client 836 certificate, along with its associated private key and password. For 837 the purposes of this example, it is not important how the device 838 obtains that information. As noted earlier, the distribution problem 839 will be solved later in this document by extending the solution. 841 The configuration may also include the entire certificate chain up 842 to, and including, the root CA. Not all of these certificates are 843 always required, as they can be exchanged in the initial EAP-TLS 844 session. 846 We note here that the configuration of the end user device is not 847 embodied in a downloadable executable, or in a vendor-specific 848 configuration file. Instead, the configuration is given in the form 849 of standardized certificates which have been marked up to express 850 their intended usage. 852 When the end user receives the client certificate (and possibly 853 certificate chain), it can be installed on the device immediately. 854 When the certificate is installed, it causes a number of additional 855 steps to be taken by the device which is using that certificate. 856 These steps are new to EAP peers, and are not performed today. 858 First, the device determines that this certificate contains id-kp- 859 eapClient, which indicates that this certificate is intended to be 860 used for EAP. If there is a certificate chain, then those 861 certificates can be saved. If the client certificate contains id-pe- 862 wlanSSID, then the device uses that information to configure itself 863 so that it will connect to the named SSID, and to perform EAP-TLS 864 authentication using this client certificate. 866 This process is similar to that outlined in [RFC4334]. The changes 867 we make over that specification are new extensions to the 868 certificates, and additional steps which mandate new behavior. 870 Finally, if there is a root CA in the certificate chain, that the 871 root CA is installed. The device also annotates this root CA (pre- 872 existing or otherwise) as being trusted to issue certificates for use 873 with EAP. As we will see, the device can also require the EAP server 874 certificate to contain id-kp-eapServer, along with an id-on-naiRealm 875 value which matches the id-on-naiRealm which is in the client 876 certificate. 878 At this point, the end user device is fully configured for using EAP- 879 TLS with a particular SSID. 881 5.1.4. Obtaining Network Access 883 When the end user device wishes to obtain network access, it can for 884 the most part follow the methods used prior to the publication of 885 this specification. There are, of course, a few changes which 886 simplify the process and make it more secure. 888 For privacy, the device uses an anonymous identifier in the EAP 889 Response Identity field. This identifier is the NAI realm which is 890 taken from the id-on-naiRealm field of the client certificate. 891 Taking the NAI realm from the client certificate means that there is 892 no need for the user to configure the publicly visible EAP Response 893 Identity. This usage also provides for the anonymity required in 894 [EAPTLS]. 896 In order to provide for privacy of the client certificate, TLS 1.3 is 897 used. Older versions of TLS are NOT RECOMMENDED. 899 When the EAP-TLS connection is established, the device verifies that 900 the server certificate which is presented also contains a id-on- 901 naiRealm field, which matches the value in the client certificate. 902 This validation is similar to the validation of DNS names performed 903 by web browsers when accessing HTTPS sites. However, as DNS is not 904 available during EAP authentication, the id-on-naiRealm field is used 905 instead to validate the server certificate. 907 For clarity, we repeat the instructions in [RFC7585] Section 2.2, for 908 matching the NAI realm: 910 The comparison of an NAIRealm to the NAI realm as derived from 911 user input with this algorithm is a byte-by-byte comparison, 912 except for the optional leftmost dot-separated part of the value 913 whose content is a single "*" character; such labels match all 914 strings in the same dot-separated part of the NAI realm. If at 915 least one of the sAN:otherName:NAIRealm values match the NAI 916 realm, the server is considered authorized; if none match, the 917 server is considered unauthorized. 919 Since multiple names and multiple name forms may occur in the 920 subjectAltName extension, an arbitrary number of NAIRealms can be 921 specified in a certificate. 923 The device also verifies that the server certificate also contains 924 the id-kp-eapServer field. It verifies that the certificate is 925 signed by a root CA which is annotated as being permitted for use 926 with an EAP server. If these verification steps fail, then the 927 client stops the authentication process, as it has determined that 928 the network is not trusted. 930 If all of these verification steps pass, then the end user device can 931 trust the EAP server, and be authenticated to the network. 933 We note here that from the perspective of the end user, the only 934 actions which have performed have been (1) to install a certificate, 935 and (2) to enter a password for that certificate. This process is 936 substantially simpler than most WiFi configuration processes used 937 today. This process is also likely to be easy to follow for most 938 users. 940 5.2. Other TLS-based EAP methods 942 While the above example discusses EAP-TLS, it is easily extensible to 943 any other TLS-based EAP methods. Instead of distributing a client 944 certificate to end users, the administrator can distribute a server 945 certificate and/or a root CA which is intended for use with EAP. For 946 simplicity, the server certificate should also contain id-pe- 947 wlanSSID, which informs the client as to which SSID(s) should be used 948 for authentication. 950 We reiterate that the public EAP Response Identity used should always 951 be in the form "@realm", as per [EAPTLS] Section 2.1.7. The user's 952 full identity should only be sent inside of the TLS tunnel. We also 953 recommend that the inner authentication methods use the full identity 954 of "user@realm", and not just the "user" portion. 956 The end device then follows the same process to configure the SSID 957 for authentication, to mark up the SSID as being used with a 958 particular NAI realm, and to annotate the root CA as being permitted 959 for use with EAP. Again, having an SSID here simply makes this 960 example clearer, this specification does not mandate its use, and 961 this specification is applicable to any type of network access which 962 uses EAP. 964 When the device connects, it does not need to verify that the server 965 certificate being presented is the same as was used for 966 configuration. Instead, the device simply has to "pin" the 967 combination of SSID, NAI realm, and root CA. This pinning allows for 968 flexibility in accepting other server certificates, while preventing 969 down-grade attacks which attempt to supply different root CAs for 970 that NAI realm. This pinning means that the device associates the 971 SSID and NAI realm with a particular root CA, and then does not 972 permit that NAI realm to authenticate to an EAP server which does not 973 use the same permitted root CA. 975 The only requirement on the new server certificate is that it has to 976 match the same criteria as outlined in the previous section. That 977 is, the certificate must contain id-kp-eapServer, it must have a 978 matching id-on-naiRealm, and it must be be signed by a root CA which 979 the supplicant has permitted to be used with EAP. 981 The device can then safely send authentication credentials inside of 982 the TLS tunnel. This process is substantially similar to that used to 983 log into an HTTPS enabled web site. The only difference here is that 984 the device must associate the user's credentials with EAP and an NAI 985 realm, instead of with the web and a DNS host name. 987 5.3. EAP methods which do not use TLS 989 Unfortunately, the methods outlined here apply only to TLS-based EAP 990 methods. This limitation is because we are leveraging the TLS 991 certificate format in order to both define additional permitted uses 992 for those certificates, and to inform devices how non-TLS systems 993 should be configured. 995 This extra information is simply not possible to add to other EAP 996 methods such as EAP-PWD [RFC5931]. Those methods typically 997 authenticate users, but do not provide for carrying additional 998 information. Those methods also generally do not provide for the 999 mutual exchange of identities, and for mutual authentication. 1001 Authentication protocols such as EAP-PWD are simple enough that it is 1002 both impossible, and generally unnecessary, for them to use the 1003 methods outlined in this specification. That is, the cryptographic 1004 guarantees in EAP-PWD ensure that it is always safe to perform EAP- 1005 PWD with unknown EAP servers, as there is no possibility for leakage 1006 of user credentials. As such, there is less need to verify the 1007 identity of the EAP-PWD server. 1009 5.4. Other Methods of Provisioning 1011 The EAP-TLS example described how provisioning was done via an 1012 administrator sending certificates to an end user. This process is 1013 not always necessary. 1015 For EAP-TLS, [EAPTLS] Section 2.1.5 provides for the protocol to be 1016 used without peer authentication. This capability can be leveraged 1017 to perform provisioning. All that is needed on the device is for the 1018 EAP peer to have a pre-configured root CA, and to know the NAI realm 1019 which it belongs to, and which is being used for provisioning. 1021 For the purposes of this section, we assume that the root CA known to 1022 the device is willing to issue and sign server certificates which 1023 contain the id-kp-eapServer and id-on-naiRealm fields. As we will 1024 see below, this assumption may be difficult to achieve in practice. 1026 When the device connects to a network, it can perform the 1027 verification steps outlined above. That is, the server certificate 1028 presented has a matching id-on-naiRealm field; the server certificate 1029 contains id-kp-eapServer; and that the server certificate is signed 1030 by a known root CA. The root CA does not necessarily have to be 1031 annotated as being permitted for EAP. 1033 If all of those requirements are satisfied, then the device can 1034 obtain limited network access. The device can then leverage normal 1035 networking protocols to download provisioning information, which is 1036 then used to configure the device. As noted above, this provisioning 1037 information needs to be little more than a client certificate. 1039 For example, the device could use Enrolment over Secure Transport 1040 (EST) [RFC7030]. It could also use vendor-specific methods. 1042 This process works because every device capable of doing TLS is 1043 shipped with a set of known root CAs, which are intended for use with 1044 the web. In addition, every end user wishing to connect to a known 1045 network is aware of the identity of that network (e.g. 1046 "example.com"), and their their identity in that network (e.g. 1047 "user@example.com"). 1049 If the device does not have a root CA configured, as we will see 1050 below, it can use the limited authorization network with other 1051 protocols such as DNS. The device could use DNS to query a pre- 1052 defined SRV record (as with [RFC7585] Section 3). The results of 1053 that record could be a "self signed" root CA. Certificates can 1054 therefore be obtained over DNS, such as via the methods outlined in 1055 [RFC4398]. 1057 The only requirement here is that the DNS record be obtained securely 1058 (DNSSec or DNS over TLS), otherwise an attacker could forge the 1059 response, or replace the root CA in transit. 1061 Other methods are also possible, though not discussed here. 1063 5.5. Trust on First Use Can be Secure 1065 Similar provisioning methods can be be used for other TLS-based EAP 1066 methods. In those methods, when a device connects to the network, it 1067 could prompt the user for a username (with an NAI realm) and 1068 password. Then, it could use that information to derive the NAI 1069 Realm, and perform the verification steps described previously. The 1070 device simply needs to know that it is trying to authenticate to a 1071 specific NAI Realm before verifying the server certificate, and needs 1072 to verify that server certificate prior to sending any user identity 1073 or authentication credentials to the EAP server. 1075 That is, a device which knows that it is trying to authenticate to a 1076 realm "example.com", can then verify that the server certificate 1077 contains id-on-naiRealm which matches "example.com". This process is 1078 similar to a web browser that wishes to connect to a web site for 1079 "example.com". The client already knows that "example.com" is the 1080 desired destination, which then means that the client must verify 1081 that the site which it connects to has a certificate matching 1082 "example.com". 1084 If the device is not configured with any realm, then it has no way of 1085 determining whether or not it should trust any EAP server. As such, 1086 the use of the NAI realm is a critical component of this 1087 specification. 1089 This process is close to "Trust on First Use" (ToFU) provisioning, 1090 with minimal knowledge required, and with a high degree of security. 1091 From the point of view of the end user, the only actions which have 1092 been taken are to select an SSID, and then to enter a name and 1093 password. The process outlined here ensures that the user is 1094 authenticated to a known and trusted network, and that the EAP peer 1095 sends the identity and authentication credentials only to known and 1096 trusted networks. 1098 Some EAP methods such as TEAP [RFC7170] support provisioning of end 1099 user devices. Since this provisioning information is automatic, it 1100 can include additional information not discussed here. The process, 1101 however, remains substantially similar. The client can download one 1102 or more certificates, and then perform the validation and 1103 configuration steps outlined above. 1105 5.6. Additional Considerations 1107 Note that there is no requirement that the device use only the SSID 1108 given in the id-pe-wlanSSID field of a certificate. If the device 1109 sees an authorized server certificate on a different SSID, then it 1110 should proceed with authentication as discussed previously. 1112 However, the EAP server may not permit the client to be authenticated 1113 via other SSIDs. It is therefore RECOMMENDED that channel bindings 1114 [RFC6677] are used in all EAP methods, in order to inform the server 1115 about the clients local environment. Channel bindings also solve 1116 problems with supplicants that do MAC address randomization: The real 1117 MAC address is sent inside of the TLS tunnel, as part of the channel 1118 binding exchange. 1120 Similarly, there is no requirement for the device to "pin" a 1121 particular server certificate. If the presented server certificate 1122 meets the criteria of known root CA; containing id-kp-eapServer; and 1123 matching id-on-naiRealm, then the connection can be trusted. In 1124 fact, there is no need to cache the server certificate at all. 1126 6. Extending the Solution 1128 The process described above greatly simplifies the usability of EAP, 1129 and its security. We can, however, do better. 1131 The process described above requires changes to both supplicants, and 1132 to the systems which issue certificates. These changes are useful, 1133 but are not always trivial. Further, the processes still have a 1134 bootstrapping problem, which was waved away in Section 2.2.3 during 1135 the discussion of the worked example. The bootstrapping problem was 1136 somewhat addressed by the use of ToFU provisioning in Section 2.6, 1137 but there are still open issues with respect to security and 1138 provisioning. 1140 In this section, we describe a few ways in which the remaining issues 1141 may be addressed, in order to come up with a complete solution to the 1142 problem. We first describe protocols such as EST [RFC7030], and then 1143 later how DNS may also be used. 1145 6.1. Bootstrapping via EST 1147 EST [RFC7030] can be used to distribute previously created 1148 certificates for CAs and servers. It can also be used by clients to 1149 request new client certificates. As there is no distinction in EST 1150 between public CAs and private CAs, either can be used. This feature 1151 enables EST-capable systems to use the new OIDs defined here. 1153 The use of EST therefore solves the certificate distribution problem 1154 which was described earlier in the worked example for EAP-TLS. 1156 However, the requirement here is that the client implements EST, and 1157 not all currently do. Another requirement is that EST uses the 1158 ".well-known" relative URL from [RFC5785], and both specifications 1159 assume implicitely that the base domain is rooted both in the web, 1160 and in the top-level subdomain. For example the base URL for 1161 "example.com" is given as "www.example.com". While the ".well-known" 1162 prefix is capable of being used with other portions of the domain 1163 name tree, there is no standard way for a client and server to agree 1164 on its location. The location is simply implicit in the protocol. 1166 This limitation is an issue mainly because we wish to use automatic 1167 enrollment schemes in "captive portal" or "walled gardens", which 1168 have limited network access. It may be possible for a system with 1169 limited network access to reach a URI such as 1170 "https://www.example.com/.well-known/". However, there is no 1171 guarantee that the administrator of the main web server system for a 1172 domain is the same as the administrator of the captive portal system. 1174 As a result, we need a way for both the client to discover the URI to 1175 use, and for that URI to point to a web sever which is controlled by 1176 the administrator of the captive portal system. The solution here is 1177 to use DNS. 1179 We define a DNS SRV record which points to the EST server for this 1180 NAI realm. In order to provide for the separation of 1181 responsibilities, we make this record specific to EAP. 1183 The format of the SRV record is as follows: 1185 _est._eap. 1187 An EAP client system can query for this record, and then connect to 1188 the ".well-known" service at the provided host, in order to perform 1189 EST. This record may point to the main EST server for a domain, or 1190 it may point to a separate EST server which is specifically used for 1191 EAP. We believe that it is important to make provisions for 1192 separation of services such as these, even if this separation is not 1193 always used. 1195 We note that the DNS resource record type here is SRV and not URI, as 1196 we only need to define the hostname and port for the EST server. The 1197 rest of the URI is defined by EST. 1199 We discuss the use of DNS in more detail in the next section. 1201 6.1.1. Closing the loop 1203 An EAP peer which has a username, password, and NAI realm can 1204 leverage EST to securely provision client certificates for use with 1205 TLS-based EAP methods. 1207 The device first discovers the location of the EST server via the DNS 1208 lookup above. It can then download any necessary CAs, using the 1209 methods outlined in [RFC7030] Section 4.1 The device then uses the 1210 username and password with HTTP basic authentication in order to 1211 authenticate itself to the EST server. Finally, the device can 1212 request that the EST server create and sign a client certificate, 1213 using the methods outlined in [RFC7030] Section 4.2. 1215 One benefit of this method is that the key associated with the client 1216 certificate can be generated automatically by the client device, and 1217 to some extent hidden from the user. This secrecy ensures that the 1218 client certificate is associated with a particular device, and that 1219 the user is prevented from copying the certificate to multiple 1220 devices. 1222 6.2. Bootstrapping via DNS 1224 We have seen above that the EAP configuration problem can be largely 1225 reduced to getting a properly formed certificate onto the device. We 1226 show here how to use DNS to bootstrap the certificate installation. 1227 This bootstrapping process requires no changes to supplicants or to 1228 systems which certificates. Instead, it requires only that: 1230 * certificates be placed at a well-known URI, 1232 * this URI is found DNS CERT records [RFC4398], 1234 * an independent tool downloads the certificates and uses them 1235 to configure EAP as described above, 1237 * the end user or device knows the NAIRealm to which it is 1238 supposed to connect. 1240 This process leverages both DNS, and the existing "web" root CA 1241 infrastructure in order to securely configure EAP, with minimal 1242 manual intervention. 1244 6.2.1. CERT records 1246 The process begins with the administrator obtaining one or more 1247 server certificates as described above, and then placing them at a 1248 well-known URI. The administrator then adds records to DNS which 1249 point to the certificates. The client can then download these server 1250 certificates, and configure its EAP system to use these certificates 1251 when authenticating to the relevant NAI realm. 1253 For the purpose of this section, we assume that the server 1254 certificates are signed by a CA which is already known to the client 1255 system. In the next section, we extend this process to downloading 1256 new CA certificates. 1258 The information stored in DNS is a CERT record as described in 1259 [RFC4398] Section 2. If the DNS record is served over a secure 1260 transport such as DNSSec, DNS over HTTPS, or DNS over TLS, then the 1261 record can directly contain the certificate. If the DNS record is 1262 served over an insecure transport, then the "type" field MUST be one 1263 which contains a URI. These requirements typically mean that value 1264 of the "type" field will be (4), for IPKIX, which points to the URL 1265 of an X.509 data object. 1267 In order for this process to be secure, the URL MUST be within same 1268 domain (NAI realm) as the CERT resource record. The URL MUST be 1269 secured with TLS transport. The certificate presented at that URL 1270 MUST be issued by a root CA which is generally already known to the 1271 device. The certificate presented at the URL MUST pass all normal 1272 HTTPS validation, including that for id-ce-subjectAltName. 1274 That is, when the client accesses a URL pointed to by a CERT record, 1275 certificate validation for that access MUST be performed as per 1276 [RFC5280]. If any of these validation steps fail, then the client 1277 MUST NOT download or use any further data presented by that server. 1279 Further, the contents of the data at that URL MUST be a X.509 1280 certificate. 1282 The downloaded certificate MUST be one with is suitable for TLS-based 1283 EAP methods, as described in [EAPTLS]. The client system MUST verify 1284 that the server certificate matches the NAI realm which is being 1285 used, either via the steps defined here, or via the host name 1286 matching defined in [EAPTLS]. If the certificate does not match the 1287 NAI realm, then it is discarded and not used for EAP. 1289 An issue is that [EAPTLS] provides for host name matching, but not 1290 for NAI realm matching. The two are similar, but not identical. If 1291 we recall [RFC7542] Section 2.5, the NAI realm is defined as: 1293 * Realms MUST be of the form that can be registered as a Fully 1294 Qualified Domain Name (FQDN) within the DNS. 1296 Certificates of the form supported by [EAPTLS] therefore may still 1297 match the given NAI realm. 1299 The downloaded certificate SHOULD also contain id-pe-wlanSSID, in 1300 order to inform the device as to which SSID is suggested for network 1301 access. 1303 Note that there is no requirement for this server certificate to 1304 contain the id-kp-eapServer OID defined here. It is RECOMMENDED to 1305 include that OID, but it is not required. 1307 These requirements ensure that devices can leverage the existing web 1308 framework to securely download certificates which are to be used for 1309 EAP. 1311 The use of insecure transport for DNS is acceptable, as it is only 1312 being used to transport a URL, which is itself protected by TLS. The 1313 URL validation requirements above ensure that an attacker can only 1314 point the device to pre-existing URIs within the given domain, which 1315 contain information not under the control of the attacker. 1317 6.2.2. CERT record labels for Server Certificates 1319 The next problem is to define a well-known name for this record. We 1320 leverage the [RFC8552] "Underscored" naming of attribute leaves in 1321 order to provide for well-known names. We define a series of names, 1322 which are all rooted from the NAI realm given by the user. 1324 We note here that the insecurity of plain UDP DNS may, in fact, be of 1325 use here. For example, the administrator of a captive portal can 1326 modify the captive portal DNS server in order to serve records for 1327 the "top level" domain, which not normally be permitted. Since this 1328 use of DNS names is only visible from within the captive portal, 1329 there is no security impact outside of this limited network. 1331 The format of the CERT record is as follows: 1333 _server._cert._eap. 1335 It can be beneficial to use a DNS CERT record instead of Enrolment 1336 over Secure Transport (EST) [RFC7030], as our goal here is to simply 1337 obtain a pre-existing certificate, and not to generate new 1338 certificates. In some cases, the URL provided by DNS can just be the 1339 URL of a certificate hosted by an EST server. 1341 In some cases, the downloaded certificate may be from a CA which is 1342 not known to the device. For example, when the CA is a "private CA" 1343 which is not in the root CA list for web PKI. The next section 1344 addresses this issue. 1346 6.2.3. CERT record labels for CA Certificates 1348 This CA certificate may be obtained via EST, as described in 1349 [RFC7030] Sections 2.1 and 4.1.2. The device can also look up the CA 1350 certificate via a similar process to obtaining the server 1351 certificate, by querying for a CERT record at the following name: 1353 _ca._cert._eap. 1355 Again, the URL presented here MUST match all of the requirements 1356 given earlier for the certificate obtained from the 1357 "_server._cert._eap." record. The only restriction on the 1358 contents and/or format of the downloaded CA certificate is that it 1359 MUST permit the previously downloaded server certificate to be 1360 verified. If the server certificate cannot be verified using this CA 1361 certificate, then both certificates MUST be discarded. 1363 Since this new CA has been downloaded from a trusted source, the CA 1364 can also be given limited trust. That is, the downloaded CA SHOULD 1365 be trusted to issue certificates for use with EAP, but only for the 1366 NA realm in question. The downloaded CA MUST NOT be trusted for any 1367 other use-cases or purposes. This limitation ensures that private 1368 CAs cannot be used to spoof public web sites from unrelated 1369 organizations. 1371 This requirement in effect mandates implementations to create 1372 multiple certificate stores. This limitation is the minimal change 1373 required to supplicant implementations in order to support the core 1374 of this specification. Every other change suggested here can either 1375 be pushed to an auxiliary tool, or can be delayed until a later step. 1377 That is, the user-visible workflow here can be implemented with 1378 minimal changes to the supplicant software which implements EAP. 1380 7. Related issues 1382 We discuss related issues in this section. The items discussed here 1383 are individually useful to discuss, but do not follow a clear 1384 developmental flow. As such, they are placed into a separate 1385 section. 1387 7.1. Provisioning Issues 1389 There are a number of issues related to provisioning. We show that 1390 there is no need to use a single network for all of the above 1391 discovery and configuration. We show that configuration updates are 1392 simple, and are no more difficult than repeating the initial 1393 provisioning. Finally, we describe why the methods defined herein 1394 are significantly more secure than ToFU. 1396 7.1.1. Bootstrapping via a Separate Network 1398 There is no requirement that a particular network provide all of the 1399 bootstrapping outlined above via a "guest network". It is also 1400 possible to leverage the public Internet in order to bootstrap 1401 authentication to a private network which requires EAP 1402 authentication. 1404 For example, a mobile phone may be trying to connect to a WiFi SSID, 1405 while it also has additional network access via 3G or LTE. There is 1406 no requirement here for the WiFi network to provide a guest network 1407 with full provisioning capabilities. Instead, the phone can simply 1408 try to do unauthenticated EAP-TLS. During the EAP-TLS negotiation, 1409 the device will obtain a copy of the server certificate. This 1410 certificate should contain id-on-naiRealm. 1412 The device can then use the LTE connection, and the process outlined 1413 above (DNS, EST, etc.) in order to verify that the server certificate 1414 is the one which meets all of the criteria necessary for full 1415 authentication. Once the server certificate is validated and the 1416 device has updated its configuration, it can drop the EAP-TLS 1417 connection, and re-authenticate using any TLS-based EAP method. 1419 With this process, the experience for the end user would be little 1420 more than: 1422 * select an SSID, 1424 * be informed that this is a network associated with a particular NAI 1425 realm (i.e. domain), 1427 * be informed that the network is secure and is trusted, 1429 * be requested to enter an identity and password within that domain, 1431 * enter that identity and password, and obtain network access. 1433 This process is little different from using a web browser to navigate 1434 to a web site, and ensuring that the green "lock" icon is set for 1435 that site. 1437 7.1.2. Configuration Change is just Refresh 1439 Any automatic provisioning scheme has the problem of performing 1440 change control. In our case, updating the configuration which a new 1441 set of data is largely just repeating the bootstrapping process. The 1442 questions then become how often to check for updates, how long to 1443 cache configuration, etc. 1445 It is RECOMMENDED that HTTPS servers which provide the certificates 1446 described in the previous section set the Cache-Control [RFC7234] 1447 directive in the response. It is RECOMMENDED that the "max-age" 1448 directive ([RFC7234] Section 5.2.2.8) be used. The value returned 1449 SHOULD NOT be less than one day (86400 seconds), and MUST NOT go past 1450 the expiry date of the certificate which is being returned. 1452 The supplicant which is retrieiving the certificate SHOULD annotate 1453 the certificate with the value of the "max-age" directive. The 1454 supplicant SHOULD perform the bootstrapping checks again prior to the 1455 "max-age" time limit being reached. 1457 Where "max-age" is not returned, the supplicant SHOULD refresh the 1458 bootstrapping checks again no more than once per day. It SHOULD 1459 track when the certificate was downloaded, and then perform these 1460 checks no later than when the certificate is halfway to expiry, taken 1461 from when the supplicant first downloaded the certificate. 1463 When either the root CA or server CA has expired, the supplicant MUST 1464 NOT use them to obtain network access. It SHOULD refresh the 1465 certificates at that time. If the certificates are not refreshed, 1466 then the relevant configuration SHOULD be deleted. 1468 If the refreshed certificate is identical to the previously 1469 downloaded certificate, then the supplicant makes no configuration 1470 changes other than to update its refresh timers. The supplicant 1471 SHOULD still perform other certificate validation checks, such as 1472 checking for certificate revocation. 1474 If the refreshed certificate has changed, then the supplicant 1475 performs all of the validation checks described above. If the tests 1476 pass, the new certificate can be used in place of the previous one. 1477 Note that there is no need to "tear down" the current network 1478 connection if the current certificate is still valid. The new 1479 configuration should be used only when the device next requests 1480 network access. 1482 As the old credentials are usually still valid, device SHOULD keep 1483 the old credentials around until such time as it has verified that 1484 the new credentials work. If the new credentials do not obtain 1485 satisfactory network access, then they should be discarded, and the 1486 device should try again not sooner than one day later. 1488 TBD: There should also be fine-grained methods to control when a new 1489 configuration is downloaded, and separately when it is applied. For 1490 client certificates, we can use the "notBefore" field, which 1491 indicates that the certificate is not valid before a particular time. 1493 7.1.3. Secure versus Insecure Provisioning 1495 We now revisit the discussion of ToFU first mentioned above. We note 1496 that the process defined here isn't even "trust on first use". 1497 Instead, it is leveraging the web PKI in order to get secure, 1498 authenticated downloads of non-web certificates. ToFU provision such 1499 as used in TEAP is essentially a standardized way to download 1500 security configuration from an insecure source. 1502 Our proposal here begins with the naiRealm, and then uses trusted 1503 roots and secure protocols to download security configuration from a 1504 known and trusted source. While this process is more complex than 1505 TEAP, in that it requires DNS and HTTPS, it is also more secure. 1507 7.2. Issues related to Security 1509 We explain why id-on-naiRealm was chosen. We describe some issues 1510 related to resumption, and the use of certificates in a multi-server 1511 environment. We explain how this solution can be extended to 1512 configure individual EAP types. We explain how this solution is 1513 applicable when either private or public CAs are used. We conclude 1514 by explaining how the user experience offered by this solution 1515 creates a simple and clear user experience. 1517 7.2.1. Why id-on-naiRealm 1519 Server certificates used with EAP have historically contained DNS 1520 names. This practice is largely because the certificates are "TLS 1521 web server" certificates. However, [RFC7585] Section 2.2 explains 1522 why DNS names are not appropriate: 1524 Current subjectAltName fields do not semantically allow an NAI 1525 realm to be expressed; the field subjectAltName:dNSName is 1526 syntactically a good match but would inappropriately conflate DNS 1527 names and NAI realm names. Thus, this specification defines a new 1528 subjectAltName field to hold either a single NAI realm name or a 1529 wildcard name matching a set of NAI realms. 1531 We extend the above requirement to say that the wildcard name MUST be 1532 limited to a subset of one realm. That is, a wildcard of 1533 "*.example.com" is permitted, but a wildcard of "*", or "*.com", is 1534 forbidden. 1536 Although this recommendation was done in the context of RADIUS, this 1537 field is exactly what is needed for EAP. The definition is the same 1538 (NAI), and the use-cases are the same. 1540 7.2.2. Resumption 1542 [RFC8446] Section 4.6.1 discusses resumption: 1544 Clients MUST only resume if the new SNI value is valid for the 1545 server certificate presented in the original session and SHOULD 1546 only resume if the SNI value matches the one used in the original 1547 session. The latter is a performance optimization: normally, 1548 there is no reason to expect that different servers covered by a 1549 single certificate would be able to accept each other's tickets; 1550 hence, attempting resumption in that case would waste a single-use 1551 ticket. If such an indication is provided (externally or by any 1552 other means), clients MAY resume with a different SNI value. 1553 -0.3i 1554 Similar requirements apply for EAP, except that clients check id- 1555 on-naiRealm instead of using SNI. 1557 Where multiple servers are in an high availability or load-balance 1558 group, they SHOULD use the same certificate. Where the same 1559 certificate is used, then either the resumption master secret MUST 1560 be shared among all systems, or the tickets MUST be accessible to 1561 all systems. Preferably by putting them into an external data 1562 store. 1564 7.2.3. Choosing EAP Types 1566 We note that this specification does not define which EAP type is 1567 used by the supplicant, except implicitly. That is, if the 1568 supplicant is given a client certificate, then it is presumed that 1569 EAP-TLS is being used. Otherwise, the supplicant should choose some 1570 other TLS-based EAP type. 1572 It would be possbile define new OIDs which define a list of EAP types 1573 that the EAP server will accept. These OIDs can then be placed in a 1574 server certificate, where they can inform the supplicant as to which 1575 EAP types should be used. 1577 7.2.4. User Experience 1579 It is RECOMMENDED that the system notify any end user of the 1580 configuration changes being performed. It is RECOMMENDED that these 1581 notifications give sufficient information to the end user, so that an 1582 informed decision can be made. It is RECOMMENDED that these 1583 notifications allow the user to stop or cancel the process at any 1584 time. 1586 The goal of the user experience described that it should be little 1587 different from using a web browser to navigate to a web site, and 1588 ensuring that the green "lock" icon is set for that site. 1590 Is is therefore RECOMMENDED that supplicant vendors update their user 1591 interfaces to clearly distinguish between "trusted" and "untrusted" 1592 network access. A "trusted" network is one which satisfies all of 1593 the criteria outlined herein. An "untrusted" network is one which 1594 satisfies only some, or none of the criteria outlined here. 1596 It is likely a good idea to update the graphical user interface (GUI) 1597 for as supplicant with a green lock / red unlocked icon, similar to 1598 that used in web browsers. Further, the GUI should also include the 1599 naiRealm which has been verified, as web browsers show the domain 1600 name which has been verified. This information is enough to give the 1601 user enough information to meaningfully consent to obtaining network 1602 access, and to enter credentials. 1604 That is, if the user sees that the operating-system GUI window says 1605 "this site is trusted", and also "you are accessing the example.com 1606 domain", then the user can safely enter credentials for that domain. 1608 This workflow is familiar to end users, and has been proven to be at 1609 least moderately successful in the web. 1611 7.3. Issues related to Certificates 1613 There are a number of other issues related to certificates, in 1614 addition to those which have been raised above. 1616 TBD: more explanation of the trailing sections. 1618 7.3.1. Public CA versus Private CA 1620 Nothing in this specification requires the use of either a public or 1621 private CA. Both are possible, and both have issues. 1623 The main issue with using a private CA is that it is not already on 1624 the device, and has to be provisioned. While there are many possible 1625 methods of provisioning this information, we define here only a few 1626 straightforward methods. We hope that the method proposed here (DNS 1627 + HTTPS) is clear, and simple for administrators to implement. 1629 There is still the requirement that the client device have new 1630 software to obtain this information and call the supplicant API. 1631 However, this process is no different than installing custom MDM 1632 software. 1634 Private CAs have the benefit of being able to sign certificates with 1635 any EKU they desire. These certificates can then be marked with an 1636 EKU as being intended for a particular use, and supplicant software 1637 can verify these EKU fields. 1639 The issues with public CAs are described above. Public CAs are 1640 likely to refuse to sign certificates which contain the EKUs proposed 1641 here, and appear to be uninterested in offering a different product 1642 which would sign such certificates. Further, using these 1643 certificates for EAP appears to be against their intended purpose, 1644 and is therefore misuse. 1646 However, the benefit of using public CAs is that they are already 1647 configured on most devices, and it is relatively simple to obtain 1648 certificates from them. 1650 In the end, local administrators can choose whatever CA is best for 1651 them. Our goal here is to simplify the process of using a CA and 1652 server certificate for EAP. It is best to give administrators and 1653 implementors a few simple options which meet their needs, rather than 1654 mandating one particular solution which is likely to not meet the 1655 needs of a large set of users. 1657 7.3.2. Limitations of public CAs 1659 Recent changes to the CAB guidelines limit certificate validity 1660 periods to 397 days. While this change may be good for the larger 1661 WWW framework, it is not clear how it benefits other protocols such 1662 as EAP. Additional changes include limiting the kind of domain 1663 validation methods permitted, and forbidding file-based validation 1664 for wildcard certificates. 1666 Part of EAP "best practices" is to ensure that EAP (or AAA) servers 1667 have minimal exposure to the public Internet. In order to use 1668 certificates from a public CA therefore, administators must choose 1669 between either exposing their EAP server via WWW (in order to perform 1670 validation), or to expose a different WWW server, and then also 1671 simultaneously install the same certificate on the EAP system. 1672 Neither option is a good one. 1674 In addition, limiting the certificate validity period means that 1675 clients see the server certificate change much more often than has 1676 been previously the case. This higher volume of changes was 1677 historically perhaps not an issue, as we have seen above that some 1678 systems perform limited checks on server certificates. 1680 The benefit of the process outlined here is that the server 1681 certificate either becomes trivially verifiable (even if it changes), 1682 or installing a new server certificate becomes a trivial and secure 1683 process. 1685 On the other hand, if there is no automated process to update the EAP 1686 client configuration, then users will simply be trained to mindlessly 1687 click "accept" when they are presented with a new certificate. As 1688 this process will happen much more often than has historically been 1689 the case, this maladaptive behavior by users will be even more 1690 strongly enforced. 1692 Another issue with public CAs is that intermediate CA certificates 1693 are significantly more expensive than a server certificate. The 1694 reason here appears to be economic: if intermediate CA certs were 1695 cheap, then an organization would simply purchase one, and then use 1696 that CA cert to issue many server certificates. 1698 This limitations means that EAP-TLS is significantly more difficult 1699 to deploy in practice and PEAP or TTLS. The administrator has to 1700 choose between either purchasing an extremely expensive intermediate 1701 CA certificate, or using a private CA. 1703 The use of intermediate CAs has other issues, as we will see in the 1704 next section. 1706 7.3.3. CA Chains 1708 Some administrators wish to use multiple CAs for security. For 1709 example, a large organization could have one CA which is controlled 1710 by a security group. That CA could issue intermediate CA 1711 certificates to other groups with the organization. These CAs could 1712 be issued on multiple grounds, such as geographic location, or 1713 function units. 1715 In practice, this process could result in there being one CA which is 1716 used for EAP / AAA, another CA which is used for internal web sites, 1717 and another CA for organizational Virtual Private Network (VPN) 1718 usage. 1720 We have worked through all of the examples and discussion above by 1721 largely assuming that there was one "root" CA. Now that we see this 1722 assumption is insufficient, we must then discuss, and solve, the 1723 issue of intermediate CAs. 1725 If an application were to simply trust the "root" CA, then by 1726 inference it would also trust all intermediate CAs. This trust means 1727 that an EAP administrator who can issue client certificates could 1728 potentially configure that client certificate for use in another 1729 protocol, such as with a VPN. Such misuse could lead to unauthorized 1730 users obtaining access to resources. 1732 The solution here is two-fold. One, applications which accept client 1733 certificates SHOULD be configured to trust a particular issuing CA, 1734 which may not be the "root" CA. That is, simply having a certificate 1735 store of root CAs is insufficient. Instead, the application needs to 1736 track a particular intermediate CA. 1738 Another solution is to simply move to purpose-specific EKU fields. 1739 An EAP client which follows this specification can require that the 1740 EAP server contain an id-kp-eapServer field. The EAP client can then 1741 rely on policy within the issuing framework to ensure that all 1742 relevant certificates also have an id-kp-eapServer field. Similarly, 1743 and EAP server which follows this specification can ensure that EAP 1744 clients are presenting certificates which contain id-kp-eapClient. 1746 That is, the use of id-kp-serverAuth for all possible applications 1747 means that it is impossible to limit the use of certificates to one 1748 particular application. An administrator or end user is free to 1749 (mis-)use any certificate for almost any purpose. 1751 We would suggest that having purpose-specific key usage fields is 1752 preferable. Such fields would make it simpler for both clients and 1753 servers to have more fine-grained control over certificate usage. 1755 7.3.4. Delegated Authentication 1757 In some cases an organization may delegate EAP / AAA functionality to 1758 another organization. This can happen for example, when an 1759 organization does not wish to run authentication servers itself, but 1760 instead delegates that functionality, say to an identity provider 1761 (IdP). The delegated functionality may be operated by an 1762 organization which handles "authentication as a service" for multiple 1763 customers. 1765 A current solution is for the IdP system to present a server 1766 certificate which contains a list all of the domain names which it 1767 services. The problem is that this list can change often, which 1768 means that the old certificate must be revoked, and a new one issued. 1769 If these changes happen regularly, then this "churning" of 1770 certificates can cause problems for clients which cache the server 1771 certificate. There is also the management overhead of updating the 1772 certificate. Over all, this process is not scalable. 1774 The processes outlined here allow for simple discovery and 1775 configuration of TLS-based EAP methods, but they do not entirely 1776 solve this problem. 1778 The problem can be solved, however, by noting that the public EAP 1779 Response Identity used should be in the form "@realm", as per 1780 [EAPTLS] Section 2.1.7. An EAP server will receive this identity in 1781 the first EAP packet, at which point the server can select and 1782 present a certificate which is appropriate for that realm. 1784 The result is that an IdP needs to be configured only with one server 1785 certificate for each NAI realm that it manages. When an NAI realm is 1786 added, deleted, or updated, those changes affect only the 1787 configuration for the modified realm. Any other organization or NAI 1788 realm is not affected. 1790 This solution is simple and scalable. 1792 7.3.5. Identification of Networks 1794 While the examples above used an SSID to identify a network, there 1795 are other ways of network identification. 1797 One is the Roaming Consortium Organisation Identifiers (RCOI), which 1798 are organizational identifiers which are assigned by the IEEE (REF 1799 TBD). They can be 24 or 36 bits. These organizations are global, and 1800 can identify a vendor, operator, consortium, or other organization. 1802 This section defines the RCOIdentifier name as a form of otherName 1803 from the GeneralName structure in subjectAltName defined in 1804 [RFC5280]. 1806 id-on-RCOIdentifier OBJECT IDENTIFIER ::= { id-on TBD } 1808 ub-RCOIdentifier-length INTEGER ::= 255 1810 RCOIdentifier ::= OCTET String (SIZE (1..ub-RCOIdentifier-length)) 1812 This field can be used in either a client certificate or a server 1813 certificate. With either usage, it indicates to the client which 1814 RCOI should be used for accessing network services. 1816 7.4. Anti-solutions 1818 In this section, we explain why a number of existing technologies do 1819 not solve the problems which are addressed by this specification. 1821 7.4.1. MDM Products Are not the Solution 1823 MDM products are not the solution. Solutions like Eduroam CAT [CAT] 1824 are simple and easy to use, but they are only one of many possible 1825 products. In the extreme case, each end user has to download one MDM 1826 product for each network being accessed, and then repeat that process 1827 across each of many devices being used to access those networks. 1829 These solutions are not just expensive, and non-standard, they are 1830 not scalable. It is difficult to scale the solutions to millions of 1831 disparate devices, as software has to be written and verified for 1832 each vendor, and often for each firmware version supplied by a 1833 vendor. 1835 In addition, MDM prodicts do not scale for an individual device. 1836 Each MDM product usually assumes that it is in complete control of 1837 the device, which makes it difficult or impossible to install 1838 multiple products. For example, a contractor who works for multiple 1839 companies may need multiple conflicting MDM products. Or, an 1840 employee may be required to install an MDM product on a personal 1841 device, which makes it difficult to say who actually owns that 1842 device. 1844 These MDM products typically also are capable of remotely wiping the 1845 device, such as when a contractor or employee leaves an organization. 1846 If the device was bought for personal use, there are ethical and may 1847 also be legal implicatations. Other issues are the loss of critical 1848 data such as documents or personal photographs. 1850 Or perhaps even worse, when an MDM product is in complete control of 1851 a device, then there is plausible deniability for a user, for any 1852 action taken on that device. It is likely defensible to claim that 1853 the user is not responsible, because "the remote admin had full 1854 control", or perhaps "the remote admin is running software which 1855 controls my device". 1857 There are serious security issues with a user not being in control of 1858 their own device. 1860 In contrast, a standard discovery and configuration method, run by 1861 devices at the edge, which leverages DNS and HTTP is proven to work 1862 at Internet scales. They are implemented once by each vendor, and 1863 then maintained afterwards. As the configuration for each 1864 organization (NAI realm) is separate, there are minimal issues with 1865 installing multiple configurations on the same machine. 1867 However, in the interest of enabling multiple solutions, we also 1868 define an [RFC8552] URI record. This record points to a location 1869 where a client device can download an MDM solution which is specific 1870 to a particular organization. 1872 The format of the URI record is as follows: 1874 _install._mdm. 1876 This record SHOULD NOT be visible on the public Internet, i.e. the 1877 public DNS servers for that NAI Realm. Doing so would permit 1878 malicious actors to download and examine the MDM software. Instead, 1879 this record SHOULD be available only inside of the organizations 1880 private network. Either to devices which have used 802.1X in order 1881 to authenticate themselves to the organization, or to devices which 1882 are using private IP address ranges. 1884 The server which hosts the URI SHOULD use device fingerprinting in 1885 order to provide a system-dependent MDM solution. 1887 As with the requirements on certificates above, the URI MUST be 1888 within same domain (NAI realm) as the CERT resource record. The URI 1889 MUST be secured with TLS transport. The certificate presented at 1890 that URI MUST be issued by a root CA which is generally already known 1891 to the device. The certificate presented at the URI MUST pass all 1892 normal HTTPS validation, including that for id-ce-subjectAltName. 1894 If any of these validation steps fail, then the client MUST NOT 1895 download or use any further data presented by that server. 1897 If the validation steps succeed, then the client device can download 1898 and run the MDM software which has been provided at that URI. 1900 Where possible, the client MUST inform any human user that these 1901 steps are being taken, and MUST give the user the ability to prevent 1902 this download from happening. There are many situations where the 1903 client device is owned by the end user, and not the organization 1904 which is being accessed. As such, it is inappropriate to mandate 1905 that software be automatically installed. 1907 However, there is also no requirement that an organization grant 1908 access to devices which do not follow the organizations policy. The 1909 organization is free to deny the device network access until such 1910 time as the MDM software has been installed. 1912 7.4.2. EST and similar protocols do not solve all of the problem 1914 Certificate provisioning solutions like EST [RFC7030] or Simple 1915 Certificate Enrolment Protocol (SCEP) [RFC8894] are useful, but they 1916 do not solve the underlying problem we solve here. 1918 EST and SCEP are useful for provisioning CA certificates to end 1919 devices, and for end devices to request and provision client 1920 certificates. However, these processes generally require additional 1921 configuration on the client device, and also an unrestricted network 1922 connection. 1924 Part of the problem we are trying to solve here is supplicant 1925 configuration, and EST / SCEP do not help. 1927 Further, EST can require complex bootstrapping. Section 2 of 1928 [RFC7030] says: 1930 Both the EST clients and server are configured with information 1931 that provides the basis for mutual authentication and for 1932 authorization. The specific initialization data depends on the 1933 methods available in the client and server, but it can include 1934 shared secrets, network service names and locations (e.g., a 1935 Uniform Resource Identifier (URI) ...), trust anchor information 1936 (e.g., a CA certificate or a hash of a TA's certificate), and 1937 enrollment keys and certificates. 1939 In contrast, the method proposed here requires that the client device 1940 have a known root CA from the web PKI, and the ability to do DNS and 1941 HTTPS. This capability is available on essentially all systems which 1942 can access the public internet. 1944 The reason for this simplification is that the problem we are trying 1945 to solve for EAP is substantially smaller than the problem that EST 1946 is trying to solve. 1948 We conclude by noting that our solution is entirely compatible with 1949 EST, in that the DNS query for "_ca._cert._eap.example.com" could 1950 return a CERT record which points to the URL of the EST server, for 1951 example "https://example.com/.well-known/est/cacerts", as described 1952 in [RFC7030] Section 4.1.2. 1954 7.4.3. Captive Portals and Hotspots 1956 Captive portals and hotspots have been traditionally used as a method 1957 of controlling network access, as with EAP. The use-case for captive 1958 portals is that the client devices can do DNS and HTTP, but that they 1959 do not have credentials already provisioned. The captive portal is 1960 usually a way to introduce humans into the process, by displaying 1961 information about the network, and asking the user for credentials 1962 such as credit cards, etc. 1964 There are, of course, a number of issues with captive portals. It 1965 may take the client device some time to determine that it is in a 1966 captive portal. The information displayed on a captive portal page 1967 may be confusing to the end user, or may even be in a language which 1968 the user does not understand. 1970 Automating the onboarding process means that almost all of these 1971 issues are resolved. 1973 7.4.4. Fully Anonymous Network Access and Provisioning 1975 In some situations, the device may have minimal authentication 1976 credentials. There is still, however, a need to provision the 1977 device. 1979 Existing solutions such as [RFC7170] Section 3.8 rely on exchanging 1980 data inside of a tunneled EAP method. This process is useful, but 1981 does not permit either device to use the full suite of protocols 1982 available on the wider Internet. We therefore define a different 1983 provisioning method here. 1985 When devices need to provision themselves, they SHOULD attempt to 1986 authenticate using EAP-TLS, with no client certificate, and an NAI 1987 realm of "@eap.arpa". This realm indicates to the server that the 1988 device wishes to perform provisioning. 1990 In some situations, the client device can authenticate the server 1991 certificate presented by the EAP server. More generally, however, it 1992 cannot. The client device therefore SHOULD NOT attempt to verify the 1993 server certificate when using this provisioning method. The device 1994 MUST treat the network as untrusted, and the server MUST ensure that 1995 the device is placed into a "captive portal" network as per [EAPTLS] 1996 Section 2.1.5. 1998 Further discussion of such provisioning is outside of the scope of 1999 this document. 2001 7.5. id-kp-eapOverLAN May not be sufficient 2003 While [RFC4334] Section 2 defines id-kp-eapOverLAN, it gives no 2004 explicit use-case for that EKU. That document suggests that the EKU 2005 is intended for use in client certificates. However, it also can be 2006 read to suggest that the EKU could also be used in server 2007 certificates. 2009 As such, we define a new EKU, id-kp-eapClient. If it is determined 2010 that this new EKU is not needed, this document can be updated before 2011 final publication to use id-kp-eapOverLAN instead of id-kp-eapClient. 2013 7.6. Guest Networks 2015 For EAP-TLS, [EAPTLS] Section 2.1.5 provides for the protocol to be 2016 used without peer authentication. The methods outlined here can be 2017 extended to perform provisioning within guest networks. That is, the 2018 device suspects the identity of the network, but also knows that it 2019 does not yet have credentials for use within that network. 2021 Where an EAP peer wishes to connection to the network, but does not 2022 know the identity of the network, it SHOULD use EAP-TLS without peer 2023 authentication. That is, it should obtain the server certificate 2024 without providing a client certificate. 2026 This server certificate can be examined for identification fields, 2027 such as id-on-naiRealm. The supplicant SHOULD query the network for 2028 the expected server certificate, using the DNS discovery process 2029 outlined above. 2031 Thee certificates and related network configuration which are 2032 discovered this way SHOULD NOT be cached for more than one day. 2034 While on the provisioning network, the device can use almost any 2035 method to authenticate and authorize the end user. For example, 2036 having a "self service" registration page, obtaining temporary 2037 credentials, etc. 2039 It is RECOMMENDED that the guest network permit the device to obtain 2040 email from anywhere on the Internet, via standard email reception 2041 protocols. It is RECOMMENDED that all other ports be blocked. Port 2042 25 (SMTP) MUST be blocked. All DNS ports MUST either be blocked, or 2043 be forwarded to a DNS server controlled by the administrator of the 2044 guest network. 2046 Network access SHOULD be restricted in both time and usage. There is 2047 no reason to allow unauthenticated guest access for more than about 2048 30 minutes. There is no reason to allow unauthenticated guests to 2049 transfer gigabytes of data. 2051 These requirements allow the provisioning process to be simple. A 2052 device uses EAP-TLS without peer authentication to connect to a 2053 network. The user enters an email address in a "self service" 2054 registration page. The visited network determines whether or not the 2055 person using that email address is authorized. If so, it sends a 2056 message to that address with a unique URL. 2058 The user obtains the email, clicks on the URL, and downloads 2059 credentials for the visited network. These credentials could be an 2060 EAP-TLS client certificate, which has the following properties: 2062 * issued by the visited network * containing information identifying 2063 the end user * ideally also contains information identifying the 2064 device * has a limited lifetime, ideally one day * lifetime MUST be 2065 less than 30 days. 2067 The device then provisions the credentials as above. 2069 This process could also be extended by leveraging DNS even more. The 2070 client device could look up a CERT record based on the user's 2071 identifying information, e.g. for a user with identifier 2072 "user@example.com", visiting a particular naiRalm it could look up a 2073 CERT RR of: 2075 user.example.com._guest._cert._eap. 2077 The local network could return a custom CERT RR, pointing to a URL 2078 for a page which contains a custom client certificate for use with 2079 EAP-TLS. 2081 As most DNS servers have limited policy capabilities, this 2082 functionality is likely difficult to implement in practice. 2084 7.7. Using TLS with protocols other than EAP 2086 While the discussion so far has been about EAP, there is no reason to 2087 limit this process to EAP. However, we do note that the methods 2088 defined here are intended for bootstrapping access to secure 2089 networks. They are not intended for use with generic web browsing. 2091 For example, it is possible to use similar methods (though with 2092 different DNS names and EKU fields) in order to configure clients for 2093 other protocols such as RADIUS/TLS [RFC6614] or RADIUS/DTLS 2094 [RFC7360]. 2096 These methods are not limited to RADIUS and EAP. For example, 2097 discovery of an IMAP server could be done via looking up a SRV record 2098 for "_imap._tcp.", while discovery of an email submission 2099 server could be done via looking up "_submit._tcp.". If a 2100 private CA is used for those services, it could be discovered via 2101 looking up a CERT record for "_ca._imap._tcp.". 2103 Similarly, the issue of intermediate CAs discussed earlier is also 2104 applicable to other protocols, and therefore requires similar 2105 solutions. We also note that there are issues with many other non- 2106 WWW protocols which appear to (mis)-use the id-kp-serverAuth field. 2107 We offer no solution here to that problem. 2109 It may be possible to use these processes in many other situations, 2110 but we do not discuss those use-cases in detail here. We only 2111 discuss them as a side note, to demonstrate that automatic 2112 provisioning of a client system can be done simply, securely, and 2113 with minimal intervention by an end user. 2115 8. Moving to the new methods 2117 The methods given herein are intended to give parties in an EAP 2118 conversation more, and better information about what should be 2119 happening, and about what is happening. If all of the recommended 2120 information is available, then all parties in an EAP conversation 2121 have strong, positive indications that the system is secure. If any 2122 information is missing or conflicting information is seen, then the 2123 system may or may not be secure. 2125 That is, following the recommendations is a positive signal of 2126 security. Lack of positive signals does not necessarily indicate 2127 insecurity. 2129 It is RECOMMENDED that EAP peers and authenticators which implement 2130 these processes add configurable flags which allow the 2131 recommendations to be made mandatory. These configurable flags 2132 SHOULD permit the recommendations to be enforced in a wide range of 2133 conditions, such as per SSID, per realm, per CA, etc. Doing so will 2134 allow administrators to make and enforce site-local policies. 2136 For example, a company might mandate that all devices which connect 2137 to WiFi use EAP with client certificates, that those client 2138 certificates contain the fields defined above, and that those devices 2139 only send authentication credentials to EAP authenticators which also 2140 satisfy the recommendations above. When an EAP peer follows these 2141 mandates, it will not be vulnerable to any of the attacks outlined 2142 earlier. 2144 These guidelines allows existing systems to operate unchanged. They 2145 also allow updated systems to gain the benefit of increased, and 2146 mandated, security. 2148 8.1. Using the new OIDs 2150 In general, we recommend using private CAs for EAP. Such uses avoid 2151 the issue of certificate misuse under the [CAB] guidelines. 2153 We also have to address how systems which are unaware of this 2154 specification will interact with certificates containing the new 2155 OIDs. 2157 Happily, the requirements of [RFC5216] and [EAPTLS] are requirements 2158 on what should exist, and not on what should not exist. Tests with 2159 implementations, and (where possible) checks of publicly available 2160 source code lead us to conclude that these requirements are 2161 accurately followed. 2163 The solution then is for server certificates to contain both id-kp- 2164 serverAuth, in order to satisfy [RFC5280], and also to contain id-kp- 2165 eapServer, in order to satisfy this document. The result is that 2166 both old, and new behavior is supported, and that the transition path 2167 from one to the other is seamless. 2169 8.2. Recommendations for EAP peers and authenticators 2171 It is RECOMMENDED that EAP peers use a dedicated certificate store 2172 for EAP. Where a dedicate certificate store cannot be used, each 2173 certificate MUST have additional metadata stored with it, which 2174 indicates its permitted uses. This metadata serves as a way of 2175 creating "per-use-case" certificate stores. 2177 It is RECOMMENDED that no CAs are enabled by default for EAP. User 2178 credentials are provisioned from a known authentication source. If 2179 there are no local user credentials configured, then by definition 2180 there are no known sources. When credentials are configured, known 2181 sources can be enabled at the same time. 2183 It is RECOMMENDED that "web" CAs are not used for EAP. The two use- 2184 cases are different, and misuse of certificates opens both EAP and 2185 WWW systems to attacks. 2187 It is RECOMMENDED that EAP peers do not perform TLS resumption across 2188 different media. 2190 It is RECOMMENDED that when EAP peers use any TLS-based EAP method 2191 with a client certificate, that the client certificate contains id- 2192 kp-eapClient in order to indicate that the certificate is intended to 2193 be used by an EAP peer. 2195 it is RECOMMENDED that EAP peers expose configuration settings which 2196 allow the user to permit this new behavior, or require it, on a per- 2197 NAI realm basis. 2199 It is RECOMMENDED that EAP servers which permit the use of client 2200 certificates mark one or more CAs as being permitted to issue client 2201 certificates. These CAs SHOULD be the one which is the "lowest" in 2202 the certificate chain. That is, the one which is closest to the 2203 client certificate. EAP servers SHOULD NOT mark a global "root" CA 2204 as being permitted to issue client certificates, as that root CA may 2205 sign many intermediate CAs, each of which could then issue client 2206 certificates. 2208 It is RECOMMENDED to use id-pe-wlanSSID [RFC4334] in client and 2209 server certificates. When used in a client certificate, it informs 2210 the client that this certificate should be used when the given SSID 2211 is seen. When used in a server certificate, it informs the client 2212 that the server is intended to be reachable from this particular 2213 SSID. Note that a mismatch is not necessarily an error. 2215 It is RECOMMENDED that when EAP authenticators use any TLS-based EAP 2216 method with a server certificate, that the server certificate 2217 contains id-kp-eapServer in order to indicate that the certificate is 2218 intended to be used by an EAP authenticator. 2220 It is RECOMMENDED that when EAP authenticators use any TLS-based EAP 2221 method with a server certificate, that the server certificate 2222 contains one or more naiRealm, to indicate that the EAP authenticator 2223 is authorized to accept authentication requests for users in those 2224 realms. 2226 The requirements of [RFC7585] Section 2.2 on the definition, number, 2227 and format of naiRealm are included here by reference. 2229 It is RECOMMENDED that when EAP peers use any TLS-based EAP method, 2230 that the EAP peer verify that the server certificate presented 2231 contains id-kp-eapServer, and an naiRealm which matches the NAI (if 2232 used) in the EAP Identity Response. Any mismatch indicates to the 2233 client that the server is not trusted to authenticate users for that 2234 realm. Therefore user credentials for that NAI realm should not be 2235 sent to the server. 2237 It is RECOMMENDED that when EAP authenticators use any TLS-based EAP 2238 method and a client certificate is presented, that the EAP 2239 authenticator verify that the client certificate contains id-kp- 2240 eapClient, and that the NAI (if used) given in the EAP Identity 2241 Response field matches one of the naiRealm fields in the server 2242 certificate. Any mismatch indicates to the server that the client is 2243 either misconfigured, or is acting maliciously. The server should 2244 therefore treat this mismatch as an authentication failure. 2246 As noted above, the use of the label "*" in id-on-naiRealm is 2247 forbidden for this specification. 2249 Where the server certificates do not contain naiRealm, but do contain 2250 one or more subjectAltName field of type dNSname, clients SHOULD 2251 verify that the NAI realm used by the client is an exact suffix of 2252 the dNSname field. 2254 8.3. Principles and Guidelines 2256 After analysis of the historical practices and standards for EAP, we 2257 came to a set of guidelines which are outlined in this section. 2258 Application of these guidelines drove the rest of the specification 2259 which we define herein. 2261 It is RECOMMENDED that the guidelines given below are followed when 2262 developing new network configuration standards and methods: 2264 * Automated provisioning is strongly preferred to manual 2265 provisioning. We define "automated provisioning" as provisioning 2266 which is performed via software, with little or no user 2267 intervention. Automation minimizes the possibility for end users 2268 to create broken or insecure configurations. 2270 * Manual provisioning should be limited to "Trust on first use" 2271 (ToFU), and cached or "pinned" after that. That is, manual 2272 provisioning should be limited to allowing a user to approve 2273 validation decisions which have been made by the system. 2275 * Relying on end users to manually configure complex systems 2276 is strongly discouraged. Complex systems are difficult to 2277 configure, and improperly configured systems create many issues 2278 related to security, usability, and network access. 2280 * Configuration should be "pinned" in order to permit systems to 2281 detect and prevent unauthorized changes, and to detect malicious 2282 networks which claim to be updated versions of the true network. 2284 * The identity and role of both parties should be exchanged, and 2285 verified. In practice, this suggestion often means that TLS-based 2286 EAP methods are preferred to ones which only do name / password 2287 credential verification. 2289 * The previous requirement usually means that the both parties know 2290 which RFC 7542 NAI realm is being used. This realm serves a 2291 similar purpose to the the DNS host name used in other TLS-based 2292 protocols such as HTTPS. As such, similar methods can be used to 2293 validate certificate authenticity. This NAI realm is contained in 2294 an id-on-naiRealm field, as defined in [RFC7585] Section 2.2 2296 * For TLS-based EAP methods, trust should be based on a 2297 certification authority (CA), which signs certificates for a 2298 particular realm. If the CA is trusted, then everything derived 2299 from that CA can be trusted. If the CA is not trusted, then it is 2300 impossible to trust anything derived from an untrusted CA. 2302 * CAs should also be associated with permitted uses. For example, a 2303 root CA which is trusted for web surfing is not necessarily trusted 2304 for use with EAP authentication. In practice this means either 2305 having separate certificate stores for different purposes, or 2306 annotating root certificates with their permitted uses. 2308 We believe that these recommendations are correct, simple, practical, 2309 and will improve security and usability for all participants in EAP. 2310 We show that there is a clear upgrade path from current behavior to 2311 better behavior. Each step of that upgrade path is simple, and 2312 involves minimal change for end users or administrators. 2314 9. Security Considerations 2316 There are a large number of security issues with current practices. 2317 This document attempts to give both fixes, and a transition path to a 2318 better system. As such, the entire document is discussing security 2319 issues. 2321 One of the main points of this document is that systems which are 2322 difficult to configure are likely to be insecure. 2324 This document also highlights problems with misuse of certificates 2325 containing id-kp-serverAuth, and id-kp-clientAuth. If such misused 2326 certificates were to be widely reported, then large parts of the 2327 Internet could be taken offline. 2329 We note that distribution of these certificates MUST NOT be done via 2330 email. There is just too much possibility for forgery and user 2331 mistakes for that process to be secure. We instead rely on secure 2332 transport layers and cryptographically signed data in order to 2333 bootstrap authenticated network access. 2335 9.1. On Identities and Service Discovery 2337 All the user needs is on identity (e.g. "user@example.com"), and a 2338 password. Essentially everything else required for network access 2339 can be derived automatically, and provisioned with no additional user 2340 input. This process is significantly more secure than manual 2341 provisioning. 2343 9.2. Password Hashing and Storage 2345 In some situations, using client certificates with EAP is preferable 2346 to using password-based methods. Password-based EAP methods often 2347 hash the password along with a salt or a challenge, and then send the 2348 hashed version of the password. However, this hashing can conflict 2349 with the desire of administrators to store hashed passwords in their 2350 user databases. The two different hashing methods are almost always 2351 incompatible, which means that the administrator has to choose either 2352 to send passwords via a method such as PAP inside of TTLS, or to 2353 store clear-text passwords in their local user database. 2355 Neither choice is optimal. Where there is a trade-off, it is 2356 RECOMMENDED that systems use a method such as TTLS with PAP, and then 2357 store hashed or encrypted passwords in the local user database. The 2358 "clear-text" password which is sent in TTLS is, in fact, secured via 2359 TLS when it is sent "over the wire". So it is incorrect to claim 2360 that EAP is sending passwords "in the clear". 2362 The caveat here is that supplicants must verify the identity of the 2363 server certificate before sending the password to the EAP server. As 2364 we have seen in Section 2 above, many supplicants skipped this step. 2365 As a result, it has been common practice to recommend that 2366 supplicants use EAP methods which do not send clear-text passwords. 2367 However, all this recommendation does is to move the security risk 2368 from the supplicant to the database, which is now required to store 2369 clear-text passwords for all users. 2371 While some would argue that exposing the users clear-text password to 2372 an EAP Server is a security risk, it is in practice irrelevant. The 2373 EAP server is almost always co-located with an AAA server (e.g. 2374 RADIUS or Diameter). Those servers control network access for entire 2375 organizations, including setting complex policies. Any attacker who 2376 gains control of an AAA server can take many more, and worse actions 2377 than to simply observe peoples passwords. 2379 In contrast, history shows that exposure of user databases (with 2380 names and passwords) is not uncommon. In fact, as the EAP or AAA 2381 server usually has complete access to the user database (including 2382 passwords), compromise of the AAA server almost by definition leads 2383 to compromise of the local user password database. 2385 We therefore make the trade-off which has the lowest possible 2386 security impact, for all failure cases. Passwords SHOULD be stored 2387 hashed or encrypted in a user database. TLS-based EAP methods which 2388 rely on passwords SHOULD use authentication methods which are 2389 compatible with such password storage methods, which generally means 2390 that the passwords are sent by the user in clear-text, but are 2391 protected by TLS. 2393 10. IANA Considerations 2395 This section this specification requests from Internet Assigned 2396 Numbers Authority (IANA) registration of the following items. 2398 10.1. Key Purpose OIDs 2400 We request registration of values related to the certificate key 2401 purpose OIDs in accordance with [RFC8126]. 2403 * id-kp-eapServer 2405 * id-kp-eapClient 2407 10.2. Underscored and Globally Scoped DNS Node Names 2409 Per RFC 8552, please add the following entry to the "Underscored and 2410 Globally Scoped DNS Node Names" registry: 2412 +---------+----------------------+---------------------------------+ 2413 | RR Type | _NODE NAME | Reference | 2414 +---------+----------------------+---------------------------------+ 2415 | CERT | _ca._cert._eap | | 2416 | CERT | _client._cert._eap | | 2417 | CERT | _server._cert._eap | | 2418 | SRV | _est._eap | | 2419 | URI | _install._mdm | | 2420 +---------+----------------------+---------------------------------+ 2422 We note that [RFC8552] does not provide for "sub" registries, as we 2423 have defined above. However, we believe that these definitions fall 2424 within both the intent of [RFC8552], and common practice. 2426 11. References 2428 11.1. Normative References 2430 [RFC2119] 2431 Bradner, S., "Key words for use in RFCs to Indicate Requirement 2432 Levels", RFC 2119, March, 1997, . 2435 [RFC3748] 2436 Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 2437 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, 2438 June 2004. 2440 [RFC4334] 2441 Housley, R., and Moore, T., "Certificate Extensions and Attributes 2442 Supporting Authentication in Point-to-Point Protocol (PPP) and 2443 Wireless Local Area Networks (WLAN)", RFC 4334, February 2006 2445 [RFC4398] 2446 Josefsson, S., "Storing Certificates in the Domain Name System 2447 (DNS)", RFC 4398, March 2006. 2449 [RFC5216] 2450 Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication 2451 Protocol", RFC 5216, March 2008 2453 [RFC7170] 2454 Zhou, H., et al., "Tunnel Extensible Authentication Protocol (TEAP) 2455 Version 1", RFC 7170, May 2014. 2457 [RFC7234] 2458 Fielding, Ed., et al, "Hypertext Transfer Protocol (HTTP/1.1): 2459 Caching", RFC 7234, June 2014 2461 [RFC7542] 2462 DeKok, A., "The Network Access Identifier", RFC 7542, May 2015. 2464 [RFC8126] 2465 Cotton, M., et al, "Guidelines for Writing an IANA Considerations 2466 Section in RFCs", RC 8126, June 2017. 2468 [RFC8174] 2469 Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key 2470 Words", RFC 8174, May 2017, . 2473 [RFC8552] 2474 Crocker, D., "Scoped Interpretation of DNS Resource Records through 2475 "Underscored" Naming of Attribute Leaves", RFC 8552, March 2019. 2477 [EAPTLS] 2478 Mattsson, J., and Sethi, M., "Using EAP-TLS with TLS 1.3", draft- 2479 ietf-emu-eap-tls13-15, May 2021. 2481 11.2. Informative References 2483 [CAT] 2484 https://cat.eduroam.org/ 2486 [EDUROAM] 2487 https://eduroam.org/ 2489 [MSPEAP] 2490 https://msdn.microsoft.com/en-us/library/cc238354.aspx 2492 [PEAP] 2493 Palekar, A. et al, "Protected EAP Protocol (PEAP)", draft- 2494 josefsson-pppext-eap-tls-eap-06.txt, March 2003. 2496 [CAB] 2497 CA/Browser Forum, "Baseline Requirements for the Issuance and 2498 Management of Publicly-Trusted Certificates" Version 1.7.4, 5 April 2499 2021 https://cabforum.org/wp-content/uploads/CA-Browser-Forum- 2500 BR-1.7.4.pdf 2502 [RFC2716] 2503 Aboba, B., and Simon, D., "PPP EAP TLS Authentication Protocol", 2504 RFC 2716, October 1999. 2506 [RFC2865] 2507 Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote 2508 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 2510 [RFC2818] 2511 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2513 [RFC4851] 2514 Cam-Winget, N., et al, "The Flexible Authentication via Secure 2515 Tunneling Extensible Authentication Protocol Method (EAP-FAST)", 2516 RFC 4851, May 2007. 2518 [RFC5280] 2519 Cooper, D., et al., "Internet X.509 Public Key Infrastructure 2520 Certificate and Certificate Revocation List (CRL) Profile", RFC 2521 5280, May 2008. 2523 [RFC5281] 2524 Funk, P., and Blake-Wilson, S., "Extensible Authentication Protocol 2525 Tunneled Transport Layer Security Authenticated Protocol Version 0 2526 (EAP-TTLSv0)", RFC 5281, August 2008. 2528 [RFC5785] 2529 Nottingham, M. and Hammer-Lahav, E., "Defining Well-Known Uniform 2530 Resource Identifiers (URIs)", April 2010. 2532 [RFC5931] 2533 Harkins, D., and Zorn, G., "Extensible Authentication Protocol 2534 (EAP) Authentication Using Only a Password", RFC 5931, August 2010. 2536 [RFC6614] 2537 Winter, S., et al., "Transport Layer Security (TLS) Encryption for 2538 RADIUS", RFC 6614, May 2012. 2540 [RFC6677] 2541 Hartman, S. (ed), et al., "Channel-Binding Support for Extensible 2542 Authentication Protocol (EAP) Methods", RFC 6677, July 2012. 2544 [RFC7030], 2545 Pritikin, M. (Ed), Et al, "Enrollment over Secure Transport", 2546 October 2013 2548 [RFC7360] 2549 DeKok, A., "Datagram Transport Layer Security (DTLS) as a Transport 2550 Layer for RADIUS", RFC 7360, September 2014. 2552 [RFC7585] 2553 Winter, S, and McCauley, M., "Dynamic Peer Discovery for RADIUS/TLS 2554 and RADIUS/DTLS Based on the Network Access Identifier (NAI)", RFC 2555 7585, October 2015. 2557 [RFC7593] 2558 Weiringa, K. et al, "The eduroam Architecture for Network Roaming", 2559 RFC 7593, September 2015. 2561 [RFC8446] 2562 Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 2563 1.3", August 2018. 2565 [RFC8894] 2566 Gutmann, P., "Simple Certificate Enrolment Protocol", RFC 8894, 2567 September 2020. 2569 Acknowledgments 2571 This document would not be possible without the input of many people. 2573 Jorge Vergara provided reviews of previous documents which led to a 2574 clearer articulation of the problem described here, and which 2575 therefore motivated this document. He has also provided reviews for 2576 early versions of this document. 2578 Tom Rixom provided a significant amount of information on issues seen 2579 by supplicants, which motivated much of the text in Section 3.1. 2581 Arran Cudbard-Bell suggested using DNS for the "out of band" 2582 provisioning of certificates in Section 3. He also provided detailed 2583 reviews of multiple versions of this document. 2585 Stefan Winter provided feedback on a number of issues related to 2586 certificates, roaming, and provisioning. 2588 Karri Huhtanen raised issues related to purpose-specific CAs, and 2589 provided suggestions to help address those issues. 2591 Authors' Addresses 2593 Alan DeKok 2594 Network RADIUS SAS 2595 26 rue Colonel Dumont 2596 38000 Grenoble 2597 FRANCE 2599 Email: aland@networkradius.com