EAP WG R. Mahy Internet-Draft Plantronics Expires: September 6, 2006 March 5, 2006 An Extensible Authentication Protocol (EAP) Enrollment Method draft-mahy-eap-enrollment-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 6, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document introduces a new EAP Method intended to automatically enroll clients with minimal user interaction in a wireless LAN environment. The enrollment process involves the client providing weak possibly temporary credentials and the server providing stronger persistent credentials, both stages over a TLS-protected channel. Mahy Expires September 6, 2006 [Page 1] Internet-Draft EAP Enrollment March 2006 Table of Contents 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction and Motivation . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4 4. Establishing a Secure Channel . . . . . . . . . . . . . . . 5 5. EAP Enroll Protocol Definition . . . . . . . . . . . . . . . 6 6. Description of Specific Elements . . . . . . . . . . . . . . 11 7. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 11. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 13.1 Normative References . . . . . . . . . . . . . . . . . . 18 13.2 Informational References . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . 21 Mahy Expires September 6, 2006 [Page 2] Internet-Draft EAP Enrollment March 2006 1. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. 2. Introduction and Motivation Wireless LANs are increasingly popular for portable devices such as phones, PDAs, projectors, equipment carts, and factory equipment, many of which have minimal user interface capabilities. Authentication on wireless LAN networks today requires either a human-brokered web-based enrollment process, entering a shared secret key and optionally a username, or via a preprovisioned X.509 certificate [11]. The user experience of this type of manual enrollment is burdensome even on a device such as a laptop, but becomes even more problematic on devices with minimal user interface capabilities. For example, many wireless LAN phones require entry of pre-shared keys using mutiple taps per character on the phone keypad. Furthermore, many of the traditional techniques for automatic configuration such as DHCP [19] and SLP [20] cannot be used in a wireless LAN environment until layer 2 or layer 3 connectivity is fully established. What is required is an enrollment mechanism that can bootstrap using whatever credentials are available from these devices (for example: a numeric PIN or a manufacturer's certificate) and provide them with strong credentials such as certificates rooted in the local domain or machine generated username/password pairs. Since EAP [1] is already part of the recommended method of authenticating stations in a wireless LAN network such as 802.11 [17], an EAP extension is the logical way to exchange these credentials. The mechanism takes advantage of TLS [3] to setup a secure channel over which to perform the enrollment exchange. Since it is desirable to offer enrollment as widely as possible, it should be possible to enroll a client with credentials for a separate wireless LAN than the one used for enrollment. Since many existing wireless LANs are deployed using username/password authentication, this document describes an enrollment mechanism that can provide both certificates and strong username/password combinations. Specifically, this mechanism was designed to provide persistent credentials suitable for authentication using WiFi Protected Access (WPA) and 802.11i [18] (WPA2) authentication: WPA Personal (which requires a machine generated key), WPA Enterprise (which needs a "username" and machine generated password), and EAP-TLS [5] with mutual certificate-based authentication (which requires a certificate and possibly the corresponding private key). Mahy Expires September 6, 2006 [Page 3] Internet-Draft EAP Enrollment March 2006 The certificates provided during this enrollment phase could correspond to a private key already in use on the client corresponding to an already existing certificate, a new private key generated by the client (if the server does not trust the distribution of the previous key), or a new private key generated by the server (if the server does not trust that the client can generate keys with sufficient entropy). 3. Protocol Overview A client that wants to enroll, first tries to discover wireless LANs which support automatic enrollment. The client can attempt to discover this through a variety of mechanisms, including probing. For example, the author has proposed a mechanism [24] for 802.11 networks that a wireless access point can use to advertise support for this automatic enrollment protocol in beacons. Once a client associates with a wireless LAN, the client should be able to indicate to the server that it wishes to perform automatic enrollment. In this proposal, the EAP Enrollment process can be triggered in the initial EAP Identity response by sending the following URN (Uniform Resource Name) as the identity string: urn:ietf:params:eap:enroll The server then starts a TLS session to protect the enrollment exchange. The TLS handshake does not require a client certificate and expects the server to present a certificate rooted in an authority trusted by the client. The client is also expected to present the domain name from the certificate to the user for confirmation if at all practical. Once the TLS channel is setup, the actual enrollment consists of two- stages. During the first roundtrip, the Provide phase, the server indicates what combinations of weak credentials are acceptable for enrollment and what types of strong credentials it can provide. The client responds by providing a combination of weak credentials from the server's list of acceptable weak credentials and indicates which of the offered strong credentials it can use. If the client cannot provide the weak credentials or cannot use credentials that the server would provide, the client can send an EAP Response/Nak to end the enrollment process. During the second roundtrip, the Store phase, the server asks the client to store the credentials the client requested. The client response merely indicates it successfully stored them. It may be desirable for the server to also provide a usage policy document that indicate how these credentials are used. For example the document Mahy Expires September 6, 2006 [Page 4] Internet-Draft EAP Enrollment March 2006 could indicate which SSIDs and which authentication mechanisms are valid when used with the provided credentials. This policy information is left for future work. <------- EAP Request/Identity -------> EAP Response/Identity: urn:ietf:params:eap:enroll <------- EAP Request/EAP-TTLS (Start) -------> EAP Response/EAP-TTLS: ClientHello... <------- EAP Request/EAP-TTLS: ServerHello, Certificate... -------> EAP Response/EAP-TTLS: ClientKeyExchange... <------- EAP Request/EAP-TTLS: ChangeCipherSuite... # <----- EAP Request/EAP-Enroll: Provide (list ok weak # credentials, strong # credentials offered) # -----> EAP Response/EAP-Enroll: Provide (weak credentials) # <----- EAP Request/EAP-Enroll: Store (strong credentials) # -----> EAP Response/EAP-Enroll: Store (Done) # <----- EAP Success EAP authentication optionally continues with new credentials... # These exchanges occur inside a TLS-protected channel. The first EAP-Enroll Request is inside the same EAP-TTLS Request as the ChangeCipherSuite message which completes the TLS handshake The client can now save the strong credentials provided during enrollment into persistent storage and use them to authenticate with the target wireless LAN. At this point the server can start a new EAP exchange to authenticate the client using the new credentials. Once IP connectivity is established, any additional configuration can proceed using already defined mechanisms. Alternatively the server can terminate the outermost EAP method with an EAP Request/Failure. 4. Establishing a Secure Channel EAP clients that wish to use enrollment during an EAP exchange SHOULD respond to the first EAP Identity request from the server by providing the following URN as the client identity. urn:ietf:params:eap:enroll A server that receives this string in an Identity request SHOULD immediately start a TLS connecting using EAP-TTLS according to the rules defined there (this could be replaced with any other EAP method that creates an tunnel which provided confidentiality , integrity, and server authentication, for example PEAP, but we should select a single mechanism). Mahy Expires September 6, 2006 [Page 5] Internet-Draft EAP Enrollment March 2006 The TLS handshake MAY request a client certificate but MUST NOT require the client to have a valid certificate to continue the TLS handshake. The TLS client SHOULD provide a certificate if it has one, even if the certificate is self-signed. The TLS server MUST have a certificate which SHOULD be rooted in a certificate authority that is likely to be trusted by the client. If possible, the client SHOULD render to the user the CommonName (CN) in the Subject of the server's certificate and prompt the user of the device to authorize enrollment with the target domain. The CN SHOULD be a domainName choice type which is a fully-qualified domain name. The CN should also be the same CN presented when authenticating to any wireless LAN with the strong credentials provided during enrollment. If the server certificate contains a wlanSSID certificate extension as defined in [15], it SHOULD be ignored. If present, the wlanSSID extension implies a restriction on the SSID of the target SSID used after enrollment, not during enrollment. The domain name associated with both the enrollment wireless LAN and the target wireless LAN SHOULD be the same and are likely to use the same AAA server. Administrators should be able to use the same certificate for both enrollment and target WLANs. Since this enrollment method is designed to enroll devices on other wireless LANs, the SSID on the enrollment WLAN could be different. If the wlanSSID extension is present, this restriction should apply to the target LAN. If the TLS handshake completes successfully, the EAP Enroll two-phase process begins. 5. EAP Enroll Protocol Definition The document defines a new EAP Method Type "EAP-Enroll". It requires a new EAP Method Type number assigned by IANA. The EAP-Enroll process consists of a Provide phase (Request/Response) followed by a Store phase (Request/Response). The Phase field is set to 0x01 during the Provide phase and 0x02 during the Store phase. Each EAP- Enroll messages is followed by zero or more Enroll Elements. Each Enroll Element has an Element Type (1 octet), a 2-octet length which counts the number of octets in the Element Data field (starting immediately after the length), and the data itself. EAP-Enroll MUST only be used inside a tunnel which provides confidentiality, message integrity, and server authentication. A summary of the packet format is shown below. The fields are transmitted from left to right. Mahy Expires September 6, 2006 [Page 6] Internet-Draft EAP Enrollment March 2006 General Format of an EAP Enroll message 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Overall Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Enroll | Phase | Enroll Elements... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Format of Enroll Elements 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Element Type | Length | Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Below is a summary of Enroll Element Types. The majority of these element types are parts of the credentials that are either provided to the server to bootstrap the enrollment process, or sent to the client to store persistently. Element Code Semantics ------- ---------------------------------- 0x00 RESERVED 0x01 Identity or Username 0x02 Plain-text Secret or PIN or Password 0x03 Digested Password 0x04 Nonce 0x05 Rooted Certificate 0x06 Self-Signed Certificate 0x07 Certificate Signing Request using existing private key 0x08 Certificate Signing Request using a newly generated key 0x09 Private Key in PKCS8 Format 0x0A Signed Digest rsa 0x0B CA Certificate 0x0C CSR Signed Digest rsa 0x80 BootstrapCombinations: List of element combinations acceptable to server abrreviated the "bootcomb" in the diagrams. 0x81 GeneratedCombinations: Element combinations provided by the server or requested by the client from the server. abbreviated the "gencomb" in the diagrams. Mahy Expires September 6, 2006 [Page 7] Internet-Draft EAP Enrollment March 2006 0xFF RESERVED The EAP-Enroll process consists of a Provide request and response and a Store request and response. The server provides a Nonce element (0x04) with at least 16 octets of data in the Provide request. The Provide request MUST also contain the BootstrapCombinations Element (0x80) and the GeneratedCombinations Element (0x81). EAP Request/EAP-Enroll (Provide Phase) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=1 (Req) | Identifier | Overall Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Enroll | Phase=1 (Prov)| 0x80 bootcomb | Length.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. | Acceptable element combinations c->s ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | 0x81 gencomb | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List of acceptable element combinations s->c .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Both element lists have the same format. The data field in each element list contains a list of element types (1 octet each) or the octets 0x00 or 0xFF which have special semantics. Each list is organized as an ordered list of alternative combinations in preference order (the left-most combinations are more preferred). Each alternative is separated by the octet 0xFF. The octet 0x00 MAY be offered among alternatives, but it MUST NOT be combined with other elements inside a single alternative. Combinations are simply an unordered list of elements that MUST appear together in the same EAP message. The octet 0x00 indicates that satisfactory authentication was already performed and no additional credentials need to be provided. Meaning of non-element octects in element lists 0x00 No additional credentials are required 0xFF Indicates an alternative in an element list For example, the following BootstrapCombinations means that the client can provide the server either with a password and a self- signed certificate, OR a username and password. pass + self OR user + digested word cert name password 0x02 0x06 0xFF 0x01 0x03 Mahy Expires September 6, 2006 [Page 8] Internet-Draft EAP Enrollment March 2006 The client uses the BootstrapCombinations so it knows what type of elements it needs to include in its response (the bootstrap credentials). The client also examines the GeneratedCombinations to select a combination of elements the client would like to receive from the server in the Store phase (the persistent credentials). After receiving an EAP Enroll Provide phase request, the client selects one combination of elements from the BootstrapCombinations that it can provide to bootstrap the enrollment process. The client responds by sending each element from that combination plus a Nonce element of its own. This client-side nonce MUST be different from the server-side nonce and must be at least 16 octets in length. The client also includes an GeneratedCombinations. The GeneratedCombinations includes a subset of the GeneratedCombinations from the request which MUST consist of only one of the originally provided combinations with no alternatives. If the client cannot respond with a set of credentials or a GeneratedCombinations list which is compatible with the server, the client MUST send an EAP Nak to terminate the enrollment. EAP Response/EAP-Enroll (Provide Phase) 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=2 (Rsp) | Identifier | Overall Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Enroll | Phase=1 (Prov)| 0x81 gencomb | Length.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. | Acceptable element combinations c->s ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | Other elements indicated in Request +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ After receiving an EAP Enroll Provide response, the server tries to authenticate and authorize the client using the elements it provided. If the client is authorized, the server examines the GeneratedCombinations provided by the client and verifies that it is willing to generate the requested elements for the client. If so, the server generates these elements and returns them to the client in an EAP Enroll Store request (shown below). If the client did not authenticate or authorize or asked for a list of elements the server was unwilling to provide, the server SHOULD terminate the EAP exchange with an EAP-Failure message. The server MAY instead attempt another round of EAP requests if it believes this will fix the error. Mahy Expires September 6, 2006 [Page 9] Internet-Draft EAP Enrollment March 2006 The EAP Enroll Store request contains the elements which contain the credentials the client needs to store for later access to the enrolled network. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=1 (Req) | Identifier | Overall Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Enroll | Phase=2 (Stor)| Credential Elements... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If the client sucessfully receives and saves the credentials in the EAP Enroll Store request, it send an EAP Enroll Store response. The EAP Enroll Store response contains no elements. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=2 (Rsp) | Identifier | Overall Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Enroll | Phase=1 (Stor)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Mahy Expires September 6, 2006 [Page 10] Internet-Draft EAP Enrollment March 2006 6. Description of Specific Elements Element Code Semantics ------- ---------------------------------- 0x00 RESERVED 0x01 Identity or Username 0x02 Plain-text Secret or PIN or Password 0x03 Digested Password 0x04 Nonce 0x05 Rooted Certificate 0x06 Self-Signed Certificate 0x07 Certificate Signing Request using existing private key 0x08 Certificate Signing Request using a newly generated key 0x09 Private Key in PKCS8 Format 0x0A Signed Digest rsa 0x0B CA Certificate 0x0C CSR Signed Digest rs 0x80 BootstrapCombinations: List of element combinations acceptable to server abrreviated the "bootcomb" in the diagrams. 0x81 GeneratedCombinations: Element combinations provided by the server or requested by the client from the server. abbreviated the "gencomb" in the diagrams. 0xFF RESERVED 0x01 is an identity or username. The data is a UTF-8 string which is not null-terminated and MUST NOT contain any NULL characters. In a Provide response, this element MUST be accompanied by a Digested Password Element (0x03). In a Store request, this element MUST be accompanied by a Plain-Text Password element (0x02). 0x02 is a raw binary password, PIN, or other shared secret. 0x03 is a SHA-1 [6] digest of the username and password mixed with client and server nonces. The digest is 20 octets of raw data which is formed using the function: SHA( nonce + cnonce + user + SHA(password)). This element can only be included in a Provide response. 0x04 is a cryptographically secure nonce of at least 16 octets. 0x05 is a DER-encoded X.509v3 certificate which is rooted in a well- known authority. If the client wants to receive a rooted certificate from the EAP server that uses a private key generated by the client, Mahy Expires September 6, 2006 [Page 11] Internet-Draft EAP Enrollment March 2006 the client needs to provide a Certificate Signing Request (CSR) in either Element 0x07 or 0x08 in the EAP Enroll Provide response. When included in a Provide response it MUST be accompanied by a Signed Digest Element (0x0A). When included in a Store request it MUST be accompanied by a CA Certificate element (0x0B). 0x06 is a DER-encoded X.509v3 certificate which is self-signed. When this element is a listed in a BootstrapCombinations element, the client can safely imply that a rooted certificate would also be acceptable. This element can only be included in a Provide response and MUST be accompanied by a Signed Digest Element (0x0A). 0x07 is a DER-encoded PKCS#10 Certificate Signing Request [8] which uses the same public key as a certificate presented in the EAP Enroll Provide response. This element can only be included in a Provide response. 0x08 is a DER-encoded PKCS#10 Certificate Signing Request which uses a new key pair freshly generated specifically for the requested certificate. This element can only be included in a Provide response. 0x09 is a DER-encoded private key in PKCS#8 [14] format. This element can only be included in a Store request and MUST be accompanied by a rooted certificate (0x05). 0x0A is a signed digest used to insure the peer has possesion of a private key. It is formed by signing (nonce + cnonce) with sha1WithRSAEncryption as described in RFC 3370 [4] using the private key from the corresponding provided certificate (0x05 or 0x06). This element can only be included in a Provide response. 0x0B is a DER-encoded X.509v3 certificate of the authority which issued the accompanying rooted certificate. This element can only be included in a Store request and MUST be accompanied by a rooted certificate (0x05). 0x0C is a signed digest used to insure the peer has possesion of a newly generated private key. It is formed in the same way as the Signed Digest (0x0A) except that it is signed with the private key generated for a new CSR. This element can only be included in a Provide response and MUST be accompanied by a new key CSR (0x08). 7. Usage This EAP method offer a large array of elements. The purpose of this section is to explain valid combinations of these elements and to motivate the need for these combinations. Mahy Expires September 6, 2006 [Page 12] Internet-Draft EAP Enrollment March 2006 EAP-Enroll can be used to generate three types of credentials which are of practical use: a certificate rooted in the local domain, a username/password combination, and a pre-shared key. These correspond respectively to EAP-TLS, WPA Enterprise, and WPA Personal in 802.11 networks. While using a certificate infrastructure is desirable from a security perspective, many organizations do not have a deployed certificate authority. Username/password pairs are still the norm for the majority of large organizations. When passwords are machine-generated, this style of authentication is still quite reasonable. Unfortunately, there is still also a need for EAP authentication using a pre-shared key, although this usage is discouraged. However, until a mechanism for secure fast roaming is standardized, implemented, and widely deployed, there will still be a number of deployments in wireless networks which authenticate using a pre-shared key. Also, shared-key authentication is still very popular for home access points. When using a pre-shared key, the key is likely to be shared by a large community, so this key is naturally provided by the server. When using a username/password combination, this document provides a mechanism to deliver a server-derived password. (The potential for using a mutually-derived password is discussed in the To Do Section.) When generating a certificate, there are a number of administrative policy issues around how the key was generated for the client. The client could generate a new private key for this certificate, the client could reuse an existing private (possibly provided during manufacturing), or the server could generate the corresponding private key. Client generation of a new key is generally RECOMMENDED, but there are some circumstances that justify using one of the other two methods. For example, a wireless client can associate with potentially dozens of wireless LANs. If the client enrolls in each network using a separate certificate and key pair, the storage requirements on the wireless device become non-trivial. In addition, some devices may not generate sufficient entropy to generate a good quality private key or may generate entropy very slowly. One solution is to use an existing key or to generate the key on the server. These two choices have different tradeoffs, so this protocol allows the server to choose. Valid combinations of optional elements returned in a Store Request are listed below. Note (*) that the CA Certificate element (0x0B) MUST always accompany a rooted certificate in the Store request. Mahy Expires September 6, 2006 [Page 13] Internet-Draft EAP Enrollment March 2006 Valid Credentials in an EAP-Enroll Store Request Code(s) Element Names Example Usage ----------- -------------------------------- -------------- 0x02 Plaintext Password WPA Personal 0x01 + 0x03 Username + Digest Password WPA Enterprise * 0x05 Rooted Certificate EAP-TLS * 0x05 + 0x09 Rooted Certificate + Private Key EAP-TLS In order to authenticate the client, the server can accept several different types of bootstrap credentials. The following is a list of valid combinations of the elements defined in this document for use in the Provide response. The client could include a CSR using a new key, and its signed digest (0x08 + 0x0C) in any of these listed combinations, or a CSR using an existing key (0x07) in any of the starred combinations. Valid Boostrap Credential Combos in EAP-Enroll Provide Response Code(s) Elements ------------------------- -------------------------------------- none No Further Authentication Needed 0x02 Plaintext Password 0x01 + 0x03 Username + Password * 0x05 + 0x0A Rooted Cert * 0x06 + 0x0A Self-Signed Cert * 0x05 + 0x0A + 0x02 Rooted Cert + Password * 0x06 + 0x0A + 0x02 Self-Signed Cert + Password * 0x05 + 0x0A + 0x01 + 0x03 Rooted Cert + Username + Password * 0x06 + 0x0A + 0x01 + 0x03 Self-Signed Cert + Username + Password Note that new elements could be defined (for example an element for authentication partially via credit card information) and these elements will need to define valid combinations with respect to the elements defined in this document. 8. Example In the example below, the Provide Request indicates that the server will accept either a username and password; or a password, self- signed certificate, and a certificate request as the credentials used to bootstrap the enrollment process. The server is prepared to offer either a rooted certificate and private key, or a machine generated username and password. Mahy Expires September 6, 2006 [Page 14] Internet-Draft EAP Enrollment March 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=1 (Req) | Identifier | Overall Length = 38 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Enroll | Phase=1 (Prov)| 0x80 bootcomb | Length.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. = 6 | 0x02 passwd | 0x06 self cert| 0x08 CSR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF alt | 0x01 username | 0x03 digest | 0x81 gencomb | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 5 | 0x05 cert | 0x09 privkey | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xFF alt | 0x01 username | 0x02 passwd | 0x04 nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 16 | nonce data.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xea9c8e88df84f1cec4341ae6cbe5a359 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+ In the Provide Response, the client sends a username "bob" and a digest which uses the password "sh!", and asks for a rooted certificate and the corresponding private key. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=1 (Rsp) | Identifier | Overall Length = 68 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Enroll | Phase=1 (Prov)| 0x01 username | Length .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. = 16 | "mac:00032a006486" | 0x04 nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 16 | nonce data.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xf1cec4341ae6ca9c8e88df84be55a359 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+ ! 0x03 digest | Length = 20 | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. sha( nonce + cnonce + user + sha(password) ) | 0x81 gencomb | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length = 2 | 0x03 cert | 0x05 privkey | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The server authenticates and authorizes the client and returns an X.509 certificate and a private key in PKCS#8 format in an EAP Enroll Store request. Mahy Expires September 6, 2006 [Page 15] Internet-Draft EAP Enrollment March 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=1 (Req) | Identifier | Overall Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Enroll | Phase=2 (Stor)| 0x03 cert | Length .. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. = 944 | X.509 Certificate in DER format .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+ | 0x05 privkey | Length = 677 | Private Key.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .. in PKCS#8 format (DER encoded) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+ The EAP Enroll Store response just acknowledges the successful receipt of the persistent credentials 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code=2 (Rsp) | Identifier | Overall Length = 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EAP Enroll | Phase=1 (Stor)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 9. Security Considerations This mechanism relies on a TLS channel to provide confidentiality, message integrity, and server authentication. If the TLS server is not authenticated, this mechanism is open to a variety of active attacks and can reveal cleartext passwords. The mechanism currently includes only a very basic way to perform mutual authentication using a shared secret. Since the passwords used during the bootstrapping process are likely to be weak, this authentication is vulnerable to dictionary attacks, but due to the incorporation of nonces, it is not vulnerable to dictionary pre-computation. Similarly, this mechanism assumes transitive trust between the AAA server (the TLS server) and the certificate authority. It does not attempt to prevent active attacks by an attacker introduced between a AAA server and a certificate authority for example. This mechanism allows the server to generate a username/password pair for the client. It is desirable to mutually derive this password. A possible approach to mutually deriving passwords is dicsussed in the To Do section. Likewise, the server can generate a private key for the client in one mode. However, the server can refuse to offer a Mahy Expires September 6, 2006 [Page 16] Internet-Draft EAP Enrollment March 2006 private key and the client can refuse to enroll with a server that provides a private key. EAP servers which implement this mechanism MUST implement Rooted Certificate and Username/Plaintext Password storage. EAP servers which implement this mechanism MUST implement Self-Signed Certificate plus Plaintext Password and Username/Digested Password for bootstrapping. EAP servers which implement this mechanism MUST implement EAP-TTLS and the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite defined in RFC 3268 [9]. Much more to do here. 10. IANA Considerations Need a new EAP Method assignment. Need a new URN assignment following rules in RFC3688 [10]. Should probably setup a registry of Enroll Element Types. 11. To Do This draft has several layering violations. EAP Enroll mechanism should be as independent as possible of other layers. This EAP method defines a way to configure an EAP client with a username and password using a server generated key. It is desirable to develop a mechanism for the server to generate a username and provide a mutually derived key. One possible solution is to start the EAP-Enroll Provide phase, then use EAP-PAX [22] to derive a mutual key, finally ending with an EAP-Enroll Store phase which references the derived key. This may aggravate the layering problems with the proposal however. Need to describe how this relates to the SACRED framework [23]. Missing a normative discussion about how to verify that the client is in possession of the private key that corresponds to a certificate or CSR. (how to use the Signed Digest and CSR Signed Digest elements). 12. Acknowledgments Many thanks to Max Pritikin for his discussions about this idea, and to Charles Clancy who provided a security review and many helpful comments. Thanks also to Russ Housley and Benard Aboba for their support of this idea. 13. References Mahy Expires September 6, 2006 [Page 17] Internet-Draft EAP Enrollment March 2006 13.1 Normative References [1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [4] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002. [5] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", RFC 2716, October 1999. [6] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [7] Myers, M., Adams, C., Solo, D., and D. Kemp, "Internet X.509 Certificate Request Message Format", RFC 2511, March 1999. [8] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000. [9] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. [10] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [11] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [12] International Telecommunications Union, "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks", ITU-T Recommendation X.509, ISO Standard 9594-8, March 2000. [13] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 1994. [14] RSA Laboratories, "Private-Key Information Syntax Standard, Mahy Expires September 6, 2006 [Page 18] Internet-Draft EAP Enrollment March 2006 Version 1.2", PKCS 8, November 1993. [15] Housley, R. and T. Moore, "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)", draft-ietf-pkix-rfc3770bis-03 (work in progress), June 2005. [16] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication Protocol Version 1 (EAP-TTLSv1)", draft-funk-eap-ttls-v1-00 (work in progress), February 2005. 13.2 Informational References [17] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", IEEE Standard 802.11, 1999, . [18] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications Amendment 6: Medium Access Control (MAC) Security Enhancements", IEEE Standard 802.11i, July 2004, . [19] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [20] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan, "Service Location Protocol", RFC 2165, June 1997. [21] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005. [22] Clancy, C. and W. Arbaugh, "EAP Password Authenticated Exchange", draft-clancy-eap-pax-06 (work in progress), January 2006. [23] Gustafson, D., Just, M., and M. Nystrom, "Securely Available Credentials (SACRED) - Credential Server Framework", RFC 3760, April 2004. URIs Mahy Expires September 6, 2006 [Page 19] Internet-Draft EAP Enrollment March 2006 [24] Author's Address Rohan Mahy Plantronics 345 Encincal Street Santa Cruz, CA USA Email: rohan@ekabal.com Mahy Expires September 6, 2006 [Page 20] Internet-Draft EAP Enrollment March 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Mahy Expires September 6, 2006 [Page 21]