idnits 2.17.1 draft-winter-opsawg-eap-metadata-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 06, 2015) is 3211 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 informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Operations Area Working Group S. Winter 3 Internet-Draft RESTENA 4 Intended status: Standards Track July 06, 2015 5 Expires: January 7, 2016 7 A Configuration File Format for Extensible Authentication Protocol (EAP) 8 Deployments 9 draft-winter-opsawg-eap-metadata-02 11 Abstract 13 This document specifies a YANG module and derived XML and JSON file 14 formats for transfering configuration information of deployments of 15 the Extensible Authentication Protocol (EAP). Such configuration 16 files are meant to be discovered, consumed and used by EAP supplicant 17 software to achieve secure and automatic EAP configuration on the 18 consuming device. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 7, 2016. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 2 53 1.2. Other Approaches . . . . . . . . . . . . . . . . . . . . 4 54 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 55 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. YANG module for EAP Metadata . . . . . . . . . . . . . . . . 4 57 2.1. Location of the YANG module and derived XML Schema . . . 4 58 2.2. Description of YANG Module Elements . . . . . . . . . . . 4 59 2.2.1. Overall structure . . . . . . . . . . . . . . . . . . 4 60 2.2.2. The 'AuthenticationMethods' container . . . . . . . . 5 61 2.2.3. The 'ProviderInfo' container . . . . . . . . . . . . 9 62 2.3. Internationalisation / Multi-language support . . . . . . 10 63 3. Derivation of formats from YANG source . . . . . . . . . . . 11 64 4. Issuer Authentication, Integrity Protection and Encryption of 65 EAP Metadata configuration files . . . . . . . . . . . . . . 11 66 5. XML Farget Format: File Discovery . . . . . . . . . . . . . . 11 67 5.1. By MIME-Type: application/eap-config-xml . . . . . . . . 11 68 5.2. By filename extension: .eap-config-xml . . . . . . . . . 11 69 5.3. By network location: SCAD . . . . . . . . . . . . . . . . 12 70 6. Design Decisions . . . . . . . . . . . . . . . . . . . . . . 12 71 6.1. Why YANG and not directly XML, JSON or $FOO? . . . . . . 12 72 6.2. Shallow vs. Deep definition of EAP method properties . . 12 73 6.3. EAP tunneling inside EAP tunnels . . . . . . . . . . . . 12 74 6.4. Placement of 'OuterIdentity' inside 75 'AuthenticationMethod' . . . . . . . . . . . . . . . . . 12 76 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 77 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 80 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 11.1. Normative References . . . . . . . . . . . . . . . . . . 16 82 11.2. Informative References . . . . . . . . . . . . . . . . . 16 83 Appendix A. Appendix A: MIME Type Registration Template . . . . 18 85 1. Introduction 87 1.1. Problem Statement 89 The IETF has produced the Extensible Authentication Protocol (EAP, 90 [RFC3748] and numerous EAP methods (for example EAP-TTLS [RFC5281], 91 EAP-TLS [RFC5216] and EAP-pwd [RFC5931]); the methods have many 92 properties which need to be setup on the EAP server and matched as 93 configuration items on the EAP peer for a secure EAP deployment. 95 Setting up these configuration items is comparatively easy if the 96 end-user devices which implement the EAP peer functionality are under 97 central administrative control, e.g. in closed enterprise 98 environments. Group policies or device provisioning by the IT 99 department can push the settings to user devices. 101 In other environments, for example "BYOD" scenarios where users bring 102 their own devices which are not under enterprise control, or in EAP- 103 based WISP environments (see e.g. [HS20] and 104 [I-D.wierenga-ietf-eduroam]) where it is not desired neither for the 105 ISP nor for his user that the device control is in the ISPs hands, 106 configuration of EAP is significantly harder as it has to be done by 107 potentially very non-technical end users. 109 Correct configuration of all EAP deployment parameters is required to 110 make the resulting authentications 112 o functional (i.e. the end user can authenticate to an EAP server at 113 all) 115 o secure (i.e. the end user device can unambiguously authenticate 116 the EAP server prior to releasing any sensitive client-side 117 credentials) 119 o privacy-preserving (i.e. the end user is able to conceal his 120 username from the EAP authenticator) 122 It would be desirable to be able to convey the EAP configuration 123 information of a deployment in a machine parseable way to the end- 124 user device, so that all the gory details need not be known/ 125 understood by the user. Instead, the EAP peer software on the device 126 could consume the configuration information and set up all EAP 127 authentication details automatically. 129 However, there is currently no standard way of communicating 130 configuration parameters about an EAP setup to the EAP peer. 132 This specification defines such file formats for EAP configuration 133 metadata. The source definition is a YANG module which allows for 134 automatic derivation of XML and JSON formats. 136 The specification allows for unique identification of an EAP identity 137 provider by scoping it into a namespace and giving it a unique name 138 inside that namespace. Using this unique identification, other 139 configuration files (which e.g. detail the wireless media properties 140 of an Enterprise Wi-Fi setup) can then refer to this particular 141 instance of EAP identity information as authentication source. The 142 contents of the EAP configuration file may also be an embedded part 143 of those other configuration files. 145 1.2. Other Approaches 147 Device manufacturers sometimes have developed their own proprietary 148 configuration formats, examples include Apple's "mobileconfig" (MIME 149 type application/x-apple-aspen-config), Microsoft's XML schemata for 150 EAP methods for use with the command-line "netsh" tool, or Intel's 151 "PRO/Set Wireless" binary configuration files. The multitude of 152 proprietary file formats and their different levels of richness in 153 expression of EAP details create a very heterogenous and non- 154 interoperable landscape. 156 New devices which would like to benefit from machine-parseable EAP 157 configuration currently either have to choose to follow a 158 competitor's approach and use that competitor's file format or have 159 to develop their own. This situation is very unsatisfactory. 161 1.3. Requirements Language 163 In this document, several words are used to signify the requirements 164 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 165 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 166 and "OPTIONAL" in this document are to be interpreted as described in 167 RFC 2119. [RFC2119] 169 1.4. Terminology 171 2. YANG module for EAP Metadata 173 2.1. Location of the YANG module and derived XML Schema 175 The schema files are currently hosted on this location: 177 o YANG module: https://www.supplicants.net/site/standardisation/eap- 178 metadata-02.yang 180 o XML Schema: https://www.supplicants.net/site/standardisation/eap- 181 metadata-02.xml 183 2.2. Description of YANG Module Elements 185 2.2.1. Overall structure 187 The root element is the container 'EAPIdentityProviderList', which 188 contains a list of 'EAPIdentityProvider' elements; these carry the 189 actual EAP configuration information for this identity provider. In 190 most practical applications, the 'EAPIdentityProviderList' will 191 contain only a single element; a longer list can be used for metadata 192 transfers between systems or to allow users to select from a set of 193 providers in one file. 195 The global uniqueness of each 'EAPIdentityProvider' is ensured by the 196 combination of the two leafs 'NameIDFormat' which provides a 197 namespace identifier, and 'ID' which specifies the unique name inside 198 the namespace. The other leafs and containers in the 199 'EAPIdentityProvider' list are: 201 o zero or one 'ValidUntil' date-and-time timestamp with an 202 indication of possible expiry of the information in the 203 configuration file. EAP peers importing the configuration file 204 can use this information for example to re-assess whether the 205 account is still valid (e.g. if the ValidUntil timestamp has 206 passed, and authentication attempts consistently fail, the 207 supplicant should consider the information stale and ask the user 208 to verify his access authorisation with the EAP identity provider) 210 o exactly one 'AuthenticationMethods' container with a list of EAP 211 methods which the EAPIdentityProvider supports. This container is 212 described in more detail in section Section 2.2.2 214 o zero or one 'ProviderInfo' container can provide additional 215 information about the EAPIdentityProvider, e.g. a logo to allow 216 visual identification of the provider to the user in a user 217 interface, or Acceptable Use Policies pertaining to the use of 218 this EAP identity. This element is described in more detail in 219 section Section 2.2.3 221 2.2.2. The 'AuthenticationMethods' container 223 'AuthenticationMethods' contains a sequence of 'AuthenticationMethod' 224 groupings. Each such grouping specifies the properties of one 225 supported authentication method of an EAPIdentityProvider. The 226 content of this grouping is enumerated in section Section 2.2.2.1 The 227 set of configuration parameters specified in the grouping depends on 228 the particular EAP method to be configured. 230 For instance, EAP-PWD [RFC5931] does not require any server 231 certificate parameters; EAP-FAST and TEAP are the only ones making 232 use of Protected Access Credential (PAC) provisioning. On the other 233 hand, properties such as outer ("anonymous") identity or the need for 234 a trusted root Certification Authority are common to several EAP 235 methods. The server- and client-side credential types of EAP methods 236 are defined as a flat list of elements to choose from (see 237 'ServerSideCredential' and 'ClientSideCredential' below); see section 238 Section 6.2 for a rationale. 240 Where the sequence of 'AuthenticationMethod' groupings contains more 241 than one element, the order of appearance in the file indicates the 242 server operator's preference for the supported EAP types; occurences 243 earlier in the file indicate a more preferred authentication method. 245 When a consuming device receives multiple 'AuthenticationMethod' 246 groupings inside 'AuthenticationMethods', it should attempt to 247 install more preferred methods first. During interactive 248 provisioning of EAP properties, if the configuration information for 249 a preferred method is insufficient (e.g. the 'AuthenticationMethod' 250 is EAP-TLS, but the configuration file does not contain the client 251 certificate/private key and the device's credential store is not pre- 252 loaded with the client's certificate), the device should query 253 whether this more preferred method should be used (requiring the user 254 to supplement the missing data) or whether a less-preferred method 255 should be configured instead. In non-interactive provisioning 256 scenarios, all methods should be tried non-interactively in order 257 until one method can be installed; if no method can be installed in a 258 fully automated way, provisioning is aborted. 260 2.2.2.1. Authentication Method Properties 262 The 'AuthenticationMethod' grouping contains 264 o exactly one 'EAPMethod' leaf, which is an enumerated integer of 265 the EAP method identifier as assigned by IANA (typedef eap-method) 267 o zero or one container 'ServerSideCredential' which defines means 268 to authenticate the EAP server to the EAP peer (for a list of the 269 elements comprising this container, see section Section 2.2.2.2) 271 o zero or one container 'ClientSideCredential' which defines means 272 to authenticate the EAP peer to the EAP server (for a list of the 273 elements comprising this container, see section Section 2.2.2.3) 275 o zero or more 'InnerAuthenticationMethod' lists. Occurence of this 276 list indicates that a tunneled EAP method is in use, and that 277 further server-side and/or client-side credentials are defined 278 inside the tunnel. The presence of more than one 279 'InnerAuthenticationMethod' indicates that EAP Method Chaining is 280 in use, i.e. that several inner EAP methods are to be executed in 281 sequence inside the tunnel. The order of occurence of the inner 282 EAP methods defines the chaining order of the methods. 284 The 'InnerAuthenticationMethod' list itself contains the same 285 'EAPMethod', 'ServerSideCredentials' and 'ClientSideCredentials' 286 elements as described in the preceding list, but differs in two 287 points: 289 o It can optionally contain the leaf 'NonEAPAuthMethod' (an 290 enumerated integer of authentication methods not based on EAP) 291 instead of 'EAPMethod' because some tunneled EAP types do not 292 necessarily contain EAP inside the tunnel (e.g. TTLS-PAP, TEAP). 293 The YANG definition ensures that EAPMethod and NonEAPAuthMethod 294 are mutually exclusive in instantiations of the YANG module. 296 o It can NOT contain a further 'InnerAuthenticationMethod' because 297 establishing a secure tunnel inside an already established secure 298 tunnel is considered a pathological case which needs not be 299 considered. See section Section 6.3 for a rationale. 301 2.2.2.2. The 'ServerSideCredential' container 303 The server-side authentication of a mutually authenticating EAP 304 method is typically based on X.509 certificates, which requires the 305 EAP peer to be pre-provisioned with one or more trusted root 306 Certification Authority (CA) prior to authenticating. A server is 307 uniquely identified by presenting a certificate which is signed by 308 these trusted CAs, and by the EAP peer verifying that the name of the 309 server matches the expected one. Consequently, a (set of) CAs and a 310 (set of) server names make up the ServerSideCredentials block. 312 Note that different EAP methods use different terminology when 313 referring to trusted CA roots, server certificates, and server name 314 identification. They also differ or have inherent ambiguity in their 315 interpretation on where to extract the server name from (e.g. is the 316 server name the CN part of the DistinguishedName, or is the server 317 name one of the subjectAltName:DNS entries; what to do if there is a 318 mismatch?). This specification introduces one single element for CA 319 trust roots and naming; these notions map into the naming of the 320 particular EAP methods very naturally. This specification can not 321 remove the CN vs. sAN:DNS ambiguity in many EAP methods. 323 o zero or more 'CA' lists: a Certification Authority which is 324 trusted to sign the expected server certificate. The set of 'CA' 325 occurences SHOULD contain self-signed root certificates to 326 establish trust, and MAY contain additional intermediate CA 327 certificates which ultimately root in these self-signed root CAs. 328 A configuration file can, but SHOULD NOT include only an 329 intermediate CA certificate (i.e. without also including the 330 corresponding self-signed root) because trusting only an 331 intermediate CA without being able to verify to a self-signed root 332 is an unsupported notion in many EAP peers. 334 o zero or more 'ServerID' leafs: these leafs contain the expected 335 server names in incoming X.509 EAP server certificates. For EAP 336 methods not using X.509 certificates for their mutual 337 authentication, these elements contain other string-based handles 338 which identify the server (Example: EAP-pwd). 340 2.2.2.3. The 'ClientSideCredential' container 342 There is a variety of means to identify the EAP peer to the EAP 343 server. EAP methods use a subset of these criteria. As with server- 344 side credentials, the terminology for the credential type may differ 345 slightly between EAP types. The naming convention in this 346 specification maps nicely into the method-specific terminology. Not 347 all the criteria make sense in all contexts; for EAP methods which do 348 not support a criterion, configuration files SHOULD NOT contain the 349 corresponding elements, and consumers of the file MUST ignore these 350 elements. 352 Specifying any one of these elements is optional and they can occur 353 at most once. Consumers of configuration files MUST be able to fall 354 back to user-interactive configuration for these parts if they are 355 not specified (e.g. ask for the username and password for an EAP 356 method during import of the EAP configuration data). Configuration 357 files which contain sensitive elements such as 'Password' MUST be 358 handled with due care after the import on the device (e.g. ensure 359 minimal file permissions, or delete the source file after 360 installing). See also the leaf 'allow-save' below. 362 The leaf 'allow-save' specifies whether consumers should allow the 363 user to save the credential persistently; if it is set to false, 364 sensitive parts of the client-side credentials MUST NOT be 365 persistently saved on the device. See also section Section 4 for 366 transport security considerations. 368 Leaf 'AnonymousIdentity' is typically used on the outside of a 369 tunneled EAP method and allows to specify which user identity 370 should be used outside the tunnel. This string is not used for 371 actual user authentication, but may contain routing hints to send 372 the request to the right EAP server. 374 'UserName' contains the actual username to be used for user 375 authentication. For tunneled EAP methods, this element SHOULD 376 only occur in the 'InnerAuthenticationMethod's 377 'ClientSideCredentials' - if differing outer identities are not 378 desired in the deployment, the 'OuterIdentity' element should be 379 populated for the 'AuthenticationMethod' element but be populated 380 with the actual username then. 382 The 'ClientCertificate' container holds a X.509 certificate and 383 private key; if the key is protected, the 'Passphrase' leaf MAY be 384 used to indicate the passphrase, see below 385 'Passphrase' contains the passphrase needed to unlock a 386 cryptographic credential internally on the device (i.e. it is not 387 used itself for the actual authentication during the EAP 388 conversation) 390 'Password' contains the user's password, or an otherwise secret 391 string which the user needs to authenticate to the EAP server 393 'PAC' contains the Protected Access Credential, typically used in 394 EAP-FAST and TEAP. 396 'ProvisionPAC' is a boolean which indicates whether a PAC should 397 be provisioned on the first connection. Note that this 398 specification allows to use 'ProvisionPAC' without a CA nor 399 ServerID in 'ServerSideCredential'. While this allows the 400 operation mode of "Anonymous PAC Provisioning" as used in many 401 field deployments of EAP-FAST (and is thus supported here), due to 402 the known security vulnerabilities of anonymous PAC provisioning, 403 this combination SHOULD NOT be used. 405 2.2.3. The 'ProviderInfo' container 407 This specification needs to consider that user interaction during the 408 installation time may be required; the user at the very least must be 409 empowered to decide whether the configuration file was issued by a 410 provider he has an account with; the provider may have hints for the 411 user (e.g. which password to use for the login), or may want to 412 display links to helpdesk pages in case the user has problems with 413 the setup or use of his identity. 415 The 'ProviderInfo' container allows to specify a range of potentially 416 useful information for display to the user (some of which is relevant 417 only during installation time, other pieces of information could be 418 retained by the EAP peer implementation and displayed e.g. in case of 419 failed authentication): 421 o 'DisplayName' specifies a user-friendly name for the EAP Identity 422 Provider. Consumers of this specification should be aware that 423 this is simple text, and self-asserted by the producer of the 424 configuration file. If more authoritative information about the 425 issuer is available (e.g. if the file is signed with S/MIME and 426 carries an Organisation name (O attribute) in the signing 427 certificate) then the more authoritative information should be 428 displayed with more prominence than the self-asserted one. 430 o 'Description' specifies a generic descriptive text which should be 431 displayed to the user prior to the installation of the 432 configuration data. 434 o 'ProviderLocation' specifies the approximate geographic 435 location(s) of the EAP Identity Provider and/or his Points of 436 Presence. This can be useful if the configuration file contains 437 multiple 'EAPIdentityProvider' elements; the user device can then 438 make an informed guess which of the Identity Providers could be a 439 good match to suggest to the user. 441 o 'ProviderLogo' specifies the logo of the EAP Identity Provider. 442 The same self-assertion considerations as for 'DisplayName' above 443 apply. 445 o 'TermsOfUse' contains terms of use to be displayed to and 446 acknowledged by the user prior to the installation of the 447 configuration on the user's system 449 o 'Helpdesk' is a container with three possible sub-elements: 450 'EmailAddress', 'WebAddress' and 'Phone', all of which can be 451 displayed to the user and possibly retained for future debugging 452 hints. 454 2.3. Internationalisation / Multi-language support 456 Some elements in this specification contain text to be displayed in 457 User Interfaces; depending on the user's language preferences, it 458 would be desirable to present the information in a local language. 459 Other elements contain contact information, and those contact points 460 may only be able to handle requests in a number of languages; it may 461 be desirable to present only contact points to the user which are 462 compatible with his language capabilities. 464 All elements which either contain localisable text, or which point to 465 external resources in localised languages, use the grouping 466 'localized-non-interactive' or 'localized-interactive'. These 467 groupings can occur more than once in the specification, which 468 enables an iteration of all applicable languages. If the grouping is 469 omitted or its 'lang' leaf is set to "C", the instance of the element 470 is considered a default choice which is to be displayed if no other 471 language is a better match. 473 If the entire file content consistently uses only one language set, 474 e.g. all the elements are to be treated as "default" choices, the 475 language can also be set for the entire 'EAPIdentityProvider' element 476 in its own 'lang-tag' leaf. 478 3. Derivation of formats from YANG source 480 The utility 'pyang' is used to derive XML Schema (XSD) from the YANG 481 source. The Schema for this Internet-Draft was generated with pyang 482 1.4.1. 484 4. Issuer Authentication, Integrity Protection and Encryption of EAP 485 Metadata configuration files 487 S/MIME or underlying transport security. Nuff said :-) 489 5. XML Farget Format: File Discovery 491 5.1. By MIME-Type: application/eap-config-xml 493 For transports where the categorisation of file types via MIME types 494 is possible (e.g. HTTP, E-Mail), this document assigns the MIME type 496 application/eap-config-xml 498 Edge devices can associate this MIME type to incoming files on such 499 transports, and register the application which can consume the EAP 500 Metadata in XML format as the default handler for this file type. By 501 doing so, for example a single click or tap on a link to the file in 502 the device's browser will invoke the configuration process. 504 This method of discovery is analogous to the Apple "mobileconfig" 505 discovery on recent versions of Mac OS and iOS. 507 5.2. By filename extension: .eap-config-xml 509 In situations where file types can not be determined by MIME type 510 meta-information (e.g. when the file gets stored on a local 511 filesystem), this document RECOMMENDs that EAP Metadata in XML format 512 files be stored with the extension 514 .eap-config-xml 516 to identify the file as containing EAP Metadata configuration 517 information in XML format. Edge devices can register the application 518 which can consume the EAP Metadata with this file extension. By 519 doing so, for example a single click or tap on the filename in the 520 device's User Interface will invoke the configuration process. 522 5.3. By network location: SCAD 524 6. Design Decisions 526 6.1. Why YANG and not directly XML, JSON or $FOO? 528 XML is a popular choice for EAP configurations: Microsoft's "netsh" 529 files, Apple's "mobileconfig" files, the Wi-Fi Alliance's 530 "PerProviderSubscription Managed Object", and other vendor/SDO 531 definitions are all using XML. 533 JSON file formats for EAP configuration exist as well; most notable 534 are Google's most recent efforts for their Chromebook Operating 535 system. 537 YANG has a very rich feature set, and can codify restrictions on 538 which element is allowed when in a much more fine-grained way than 539 XML Schema could. Since YANG modules can be converted to XML Schema 540 and be instantiated as XML or JSON, they can serve as an abstract 541 notion of EAP configuration which can be deployed on consumer devices 542 in either of those two more popular formats as needed by the device 543 in question. 545 6.2. Shallow vs. Deep definition of EAP method properties 547 6.3. EAP tunneling inside EAP tunnels 549 6.4. Placement of 'OuterIdentity' inside 'AuthenticationMethod' 551 7. Implementation Status 553 RFC Editor Note: Please remove this section and the reference to 554 [RFC6982] prior to publication. 556 This section records the status of known implementations of the 557 protocol defined by this specification at the time of posting of this 558 Internet-Draft, and is based on a proposal described in [RFC6982]. 559 The description of implementations in this section is intended to 560 assist the IETF in its decision processes in progressing drafts to 561 RFCs. Please note that the listing of any individual implementation 562 here does not imply endorsement by the IETF. Furthermore, no effort 563 has been spent to verify the information presented here that was 564 supplied by IETF contributors. This is not intended as, and must not 565 be construed to be, a catalog of available implementations or their 566 features. Readers are advised to note that other implementations may 567 exist. 569 According to [RFC6982], "this will allow reviewers and working groups 570 to assign due consideration to documents that have the benefit of 571 running code, which may serve as evidence of valuable experimentation 572 and feedback that have made the implemented protocols more mature. 573 It is up to the individual working groups to use this information as 574 they see fit". 576 All of the implementations listed below interoperate from producer- 577 to consumer-side of the EAP metadata specification. 579 Producers of the configuration files 581 o eduroam Configuration Assistant Tool 583 Organisation: Nicolaus Copernicus University, Torun, Poland 585 Implementation Name: eduroam Configuration Assistant Tool 587 This existing tool already produces EAP configuration files in 588 various proprietary formats for hundreds of EAP Identity 589 Providers. A module which produces configuration files in the 590 XML variant as specified in an eralier revision of this draft 591 (-00) is in production deployment. 593 Link to production version: https://cat.eduroam.org 595 Maturity: production 597 Coverage: entire specification; XML structure aligns with 598 version -00 of this draft 600 Licensing: freely distributable with acknowledgement (BSD 601 style) 603 Implementation experience: given that the specification is XML, 604 it is easy to produce a configuration file with common XML 605 libraries. The CAT Framework is written in PHP, which provides 606 ample procedures to produce well-formed XML. 608 Contact Information: Tomasz Wolniewicz (see Section 10); the 609 CAT software homepage at http://forge.geant.net/CAT/ 611 Consumers of the configuration files 613 o Android 615 Organisation: Swansea University, Swansea, Wales, U.K. 617 Implementation Name: eduroam CAT app 619 An Android app, compatible with API level 18 of Android (i.e. 620 version 4.3 and above); the app consumes the -00 revision of 621 this specification. The information in the config files is 622 used to push settings to the SSID 'eduroam' (hard-coded) via 623 the WifiEnterpriseConfig API. The app is in production 624 deployment, with a 4-four digit amount of downloads one month 625 after launch. 627 Link to production version: https://play.google.com/store/apps/ 628 details?id=uk.ac.swansea.eduroamcat 630 Maturity: production 632 Coverage: entire specification; XML structure aligns with 633 version -00 of this draft 635 Licensing: Apache 2.0 637 Implementation experience: parsing XML is rather 638 straightfoward. The ability to verify signatures on XML files 639 (S/MIME vs. XMLDSIG as discussed in Section 4) remains unclear 640 at this point. 642 Contact Information: eduroam CAT Play Store app contact address 643 ( playstore@eduroam.org ) 645 o Windows 647 Organisation: Amebis, d.o.o.i, Kamnik, Slovenia 649 Implementation Name: ArnesLink 651 A Windows supplicant/Enterprise WiFi installer/debugging 652 assistant. The application consumes the -02 revision of this 653 specification. The information from the XML variant of this 654 specification is embedded in a larger XML file. The additional 655 parts of the overall configuration file include information 656 regarding the SSID to configure and other useful, but not EAP- 657 specific information. The complete set of information is used 658 to push settings into the Windows Wi-Fi configuration via the 659 'netsh' tool. The app is in production deployment. 661 Link to production version: http://ftp.arnes.si/software/ 662 eduroam/ArnesLink/ 664 Maturity: production 665 Coverage: entire specification; XML structure aligns with 666 version -02 of this draft 668 Licensing: GPL 670 Implementation experience: parsing XML is rather 671 straightfoward. For Wi-Fi configuration use, the lack of 672 802.11 specific details in the config file is an issue. 674 Contact Information: info@amebis.si 676 o Linux: the authors of this specification are currently developing 677 an application for UNIX-like operating systems which configure 678 enterprise networks via the NetworkManager daemon; the application 679 can consume the file format as defined in this draft specification 680 (XML format) and configure the settings via Networkmanager's D-BUS 681 interface. 683 8. Security Considerations 685 9. IANA Considerations 687 IANA is requested to allocate the MIME type "application/eap-config- 688 xml" in the MIME Media Types / application registry (see section 689 Section 5.1). The allocation should contain the following values: 691 o Name: eap-config-xml 693 o Template: see Appendix A (RFC editor note: remove this appendix 694 prior to publication; replace this line with the URL to the 695 application as posted online) 697 o Reference: RFCabcd (RFC editor note: replace with the RFC number 698 of this document) 700 IANA is requested to allocate the location "TBD" in the "well-known 701 URIs" registry. The allocation should contain the following values: 703 o URI Suffix: TBD 705 o Change Controller: IETF 707 o Reference: RFCabcd (RFC editor note: replace with the RFC number 708 of this document) 710 o Related Information: none 711 IANA is requested to register the XML namespace 712 "urn:ietf:params:xml:ns:eap-config-xml" in the "IETF XML Registry / 713 ns". The allocation should contain the following values: 715 o ID: eap-config-xml 717 o URI: urn:ietf:params:xml:ns:eap-config-xml 719 o Filename: https://www.iana.org/assignments/xml-registry/ns/eap- 720 config-xml.txt (to be created by IANA) 722 o Reference: RFCabcd (RFC editor note: replace with the RFC number 723 of this document) 725 IANA is requested to register the XML schema 726 "urn:ietf:params:xml:schema:eap-config-xml" in the "IETF XML Registry 727 / schema". The allocation should contain the following values: 729 o ID: eap-config-xml 731 o URI: urn:ietf:params:xml:schema:eap-config-xml 733 o Filename: https://www.iana.org/assignments/xml-registry/schema/ 734 eap-config-xml.xsd (to be created by IANA; current XSD file is 735 linked to in section Section 2.1) 737 o Reference: RFCabcd (RFC editor note: replace with the RFC number 738 of this document) 740 10. Contributors 742 Tomasz Wolniewicz of Nicolaus Copernicus University in Torun, Poland, 743 provided significant input into this specification. 745 11. References 747 11.1. Normative References 749 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 750 Requirement Levels", BCP 14, RFC 2119, March 1997. 752 11.2. Informative References 754 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 755 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 756 3748, June 2004. 758 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 759 Authentication Protocol", RFC 5216, March 2008. 761 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 762 Protocol Tunneled Transport Layer Security Authenticated 763 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 765 [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication 766 Protocol (EAP) Authentication Using Only a Password", RFC 767 5931, August 2010. 769 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 770 Code: The Implementation Status Section", RFC 6982, July 771 2013. 773 [I-D.wierenga-ietf-eduroam] 774 Wierenga, K., Winter, S., and T. Wolniewicz, "The eduroam 775 architecture for network roaming", draft-wierenga-ietf- 776 eduroam-05 (work in progress), March 2015. 778 [HS20] Wi-Fi Alliance, "Hotspot 2.0 Technical Specification", 779 2012, . 782 Appendix A. Appendix A: MIME Type Registration Template 784 The following values will be used for the online MIME type 785 registration at https://www.iana.org/form/media-types 787 Your Name: Stefan Winter 789 Your Email Address: stefan.winter@restena.lu 791 Media Type Name: Application 793 Subtype name: (Standards tree) eap-config-xml 795 Required parameters: (none) 797 Optional parameters: (none) 799 Encoding Considerations: 8-Bit text 801 Security Considerations: This file type carries configuration 802 information for consumer devices. It has the potential to 803 substantially alter the consumer's device; particularly to install 804 a new trusted Certification Authority. Applications consuming 805 files of this type need to be cautious to explain to the end user 806 what is being altered, so that they understand the consequences. 807 For further explanations, see Section 8 of draft-winter-opsawg- 808 eap-metadata. (Note to RFC Editor: replace this reference with 809 the RFC number of this document once known) 811 Interoperability Considerations: The file content is XML version 812 1.0 or later. The encoding SHOULD be UTF-8, but implementations 813 consuming the file SHOULD be prepared to encounter different 814 encodings. 816 Published Specification: draft-winter-opsawg-eap-metadata (Note to 817 RFC Editor: replace this reference with the RFC number of this 818 document once known) 820 Applications which use this media type: files of this type are 821 intended for consumption by sortware on edge devices; they consume 822 the information therein to configure authentication parameters 823 (EAP protocol and EAP method payload configurations) which are 824 then applied to network or application authentication scenarios. 826 Fragment Identifier Considerations: files of this type are 827 expected to be transmitted in their entirety. If a reference to a 828 specific part of the content is to be made, XML XPath expressions 829 are to be used. I.e. fragment identifier formats are not expected 830 to be used. 832 Restrictions on Usage: none 834 Provisional registration: initial submission of this form will be 835 executed after adoption in the IETF; it will be a provisional 836 registration. Final registration will be done after IESG review. 838 Additional information: 840 Deprecated alias types for this name: none 842 Magic numbers: none 844 File extensions: eap-config-xml 846 Macintosh File Type Codes: TBD 848 Object Identifiers or OIDs: none 850 Intended Usage: Common (no further provisions) 852 Other Information/General Comment: none 854 Person to contact for further information: 856 Name: Stefan Winter 858 E-Mail: stefan.winter@restena.lu 860 Author/Change controller: IETF 862 DATA 864 Author's Address 865 Stefan Winter 866 Fondation RESTENA 867 6, rue Richard Coudenhove-Kalergi 868 Luxembourg 1359 869 LUXEMBOURG 871 Phone: +352 424409 1 872 Fax: +352 422473 873 EMail: stefan.winter@restena.lu 874 URI: http://www.restena.lu.