idnits 2.17.1 draft-mahy-eap-enrollment-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 894. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 871. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 878. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 884. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 350 has weird spacing: '... word cert...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2006) is 6625 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '7' is defined on line 773, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 789, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 794, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 807, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 835, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. '3') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2716 (ref. '5') (Obsoleted by RFC 5216) ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. '6') ** Obsolete normative reference: RFC 2511 (ref. '7') (Obsoleted by RFC 4211) ** Downref: Normative reference to an Informational RFC: RFC 2986 (ref. '8') ** Obsolete normative reference: RFC 3268 (ref. '9') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 3280 (ref. '11') (Obsoleted by RFC 5280) -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' == Outdated reference: A later version (-01) exists of draft-funk-eap-ttls-v1-00 -- Possible downref: Normative reference to a draft: ref. '16' == Outdated reference: A later version (-11) exists of draft-clancy-eap-pax-06 Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 EAP WG R. Mahy 3 Internet-Draft Plantronics 4 Expires: September 6, 2006 March 5, 2006 6 An Extensible Authentication Protocol (EAP) Enrollment Method 7 draft-mahy-eap-enrollment-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 6, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document introduces a new EAP Method intended to automatically 41 enroll clients with minimal user interaction in a wireless LAN 42 environment. The enrollment process involves the client providing 43 weak possibly temporary credentials and the server providing stronger 44 persistent credentials, both stages over a TLS-protected channel. 46 Table of Contents 48 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Introduction and Motivation . . . . . . . . . . . . . . . . 3 50 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 4 51 4. Establishing a Secure Channel . . . . . . . . . . . . . . . 5 52 5. EAP Enroll Protocol Definition . . . . . . . . . . . . . . . 6 53 6. Description of Specific Elements . . . . . . . . . . . . . . 11 54 7. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 55 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 14 56 9. Security Considerations . . . . . . . . . . . . . . . . . . 16 57 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 58 11. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 59 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 17 60 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 61 13.1 Normative References . . . . . . . . . . . . . . . . . . 18 62 13.2 Informational References . . . . . . . . . . . . . . . . 19 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . 20 64 Intellectual Property and Copyright Statements . . . . . . . 21 66 1. Conventions 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in RFC-2119 [2]. 72 2. Introduction and Motivation 74 Wireless LANs are increasingly popular for portable devices such as 75 phones, PDAs, projectors, equipment carts, and factory equipment, 76 many of which have minimal user interface capabilities. 77 Authentication on wireless LAN networks today requires either a 78 human-brokered web-based enrollment process, entering a shared secret 79 key and optionally a username, or via a preprovisioned X.509 80 certificate [11]. The user experience of this type of manual 81 enrollment is burdensome even on a device such as a laptop, but 82 becomes even more problematic on devices with minimal user interface 83 capabilities. For example, many wireless LAN phones require entry of 84 pre-shared keys using mutiple taps per character on the phone keypad. 85 Furthermore, many of the traditional techniques for automatic 86 configuration such as DHCP [19] and SLP [20] cannot be used in a 87 wireless LAN environment until layer 2 or layer 3 connectivity is 88 fully established. 90 What is required is an enrollment mechanism that can bootstrap using 91 whatever credentials are available from these devices (for example: a 92 numeric PIN or a manufacturer's certificate) and provide them with 93 strong credentials such as certificates rooted in the local domain or 94 machine generated username/password pairs. Since EAP [1] is already 95 part of the recommended method of authenticating stations in a 96 wireless LAN network such as 802.11 [17], an EAP extension is the 97 logical way to exchange these credentials. The mechanism takes 98 advantage of TLS [3] to setup a secure channel over which to perform 99 the enrollment exchange. 101 Since it is desirable to offer enrollment as widely as possible, it 102 should be possible to enroll a client with credentials for a separate 103 wireless LAN than the one used for enrollment. Since many existing 104 wireless LANs are deployed using username/password authentication, 105 this document describes an enrollment mechanism that can provide both 106 certificates and strong username/password combinations. 107 Specifically, this mechanism was designed to provide persistent 108 credentials suitable for authentication using WiFi Protected Access 109 (WPA) and 802.11i [18] (WPA2) authentication: WPA Personal (which 110 requires a machine generated key), WPA Enterprise (which needs a 111 "username" and machine generated password), and EAP-TLS [5] with 112 mutual certificate-based authentication (which requires a certificate 113 and possibly the corresponding private key). 115 The certificates provided during this enrollment phase could 116 correspond to a private key already in use on the client 117 corresponding to an already existing certificate, a new private key 118 generated by the client (if the server does not trust the 119 distribution of the previous key), or a new private key generated by 120 the server (if the server does not trust that the client can generate 121 keys with sufficient entropy). 123 3. Protocol Overview 125 A client that wants to enroll, first tries to discover wireless LANs 126 which support automatic enrollment. The client can attempt to 127 discover this through a variety of mechanisms, including probing. 128 For example, the author has proposed a mechanism [24] for 802.11 129 networks that a wireless access point can use to advertise support 130 for this automatic enrollment protocol in beacons. 132 Once a client associates with a wireless LAN, the client should be 133 able to indicate to the server that it wishes to perform automatic 134 enrollment. In this proposal, the EAP Enrollment process can be 135 triggered in the initial EAP Identity response by sending the 136 following URN (Uniform Resource Name) as the identity string: 138 urn:ietf:params:eap:enroll 140 The server then starts a TLS session to protect the enrollment 141 exchange. The TLS handshake does not require a client certificate 142 and expects the server to present a certificate rooted in an 143 authority trusted by the client. The client is also expected to 144 present the domain name from the certificate to the user for 145 confirmation if at all practical. 147 Once the TLS channel is setup, the actual enrollment consists of two- 148 stages. During the first roundtrip, the Provide phase, the server 149 indicates what combinations of weak credentials are acceptable for 150 enrollment and what types of strong credentials it can provide. The 151 client responds by providing a combination of weak credentials from 152 the server's list of acceptable weak credentials and indicates which 153 of the offered strong credentials it can use. If the client cannot 154 provide the weak credentials or cannot use credentials that the 155 server would provide, the client can send an EAP Response/Nak to end 156 the enrollment process. 158 During the second roundtrip, the Store phase, the server asks the 159 client to store the credentials the client requested. The client 160 response merely indicates it successfully stored them. It may be 161 desirable for the server to also provide a usage policy document that 162 indicate how these credentials are used. For example the document 163 could indicate which SSIDs and which authentication mechanisms are 164 valid when used with the provided credentials. This policy 165 information is left for future work. 167 <------- EAP Request/Identity 168 -------> EAP Response/Identity: urn:ietf:params:eap:enroll 170 <------- EAP Request/EAP-TTLS (Start) 171 -------> EAP Response/EAP-TTLS: ClientHello... 172 <------- EAP Request/EAP-TTLS: ServerHello, Certificate... 173 -------> EAP Response/EAP-TTLS: ClientKeyExchange... 174 <------- EAP Request/EAP-TTLS: ChangeCipherSuite... 175 # <----- EAP Request/EAP-Enroll: Provide (list ok weak 176 # credentials, strong 177 # credentials offered) 178 # -----> EAP Response/EAP-Enroll: Provide (weak credentials) 179 # <----- EAP Request/EAP-Enroll: Store (strong credentials) 180 # -----> EAP Response/EAP-Enroll: Store (Done) 181 # <----- EAP Success 182 EAP authentication optionally continues with new credentials... 184 # These exchanges occur inside a TLS-protected channel. 185 The first EAP-Enroll Request is inside the same EAP-TTLS Request 186 as the ChangeCipherSuite message which completes the TLS handshake 188 The client can now save the strong credentials provided during 189 enrollment into persistent storage and use them to authenticate with 190 the target wireless LAN. At this point the server can start a new 191 EAP exchange to authenticate the client using the new credentials. 192 Once IP connectivity is established, any additional configuration can 193 proceed using already defined mechanisms. Alternatively the server 194 can terminate the outermost EAP method with an EAP Request/Failure. 196 4. Establishing a Secure Channel 198 EAP clients that wish to use enrollment during an EAP exchange SHOULD 199 respond to the first EAP Identity request from the server by 200 providing the following URN as the client identity. 202 urn:ietf:params:eap:enroll 204 A server that receives this string in an Identity request SHOULD 205 immediately start a TLS connecting using EAP-TTLS according to the 206 rules defined there (this could be replaced with any other EAP method 207 that creates an tunnel which provided confidentiality , integrity, 208 and server authentication, for example PEAP, but we should select a 209 single mechanism). 211 The TLS handshake MAY request a client certificate but MUST NOT 212 require the client to have a valid certificate to continue the TLS 213 handshake. The TLS client SHOULD provide a certificate if it has 214 one, even if the certificate is self-signed. The TLS server MUST 215 have a certificate which SHOULD be rooted in a certificate authority 216 that is likely to be trusted by the client. If possible, the client 217 SHOULD render to the user the CommonName (CN) in the Subject of the 218 server's certificate and prompt the user of the device to authorize 219 enrollment with the target domain. The CN SHOULD be a domainName 220 choice type which is a fully-qualified domain name. The CN should 221 also be the same CN presented when authenticating to any wireless LAN 222 with the strong credentials provided during enrollment. If the 223 server certificate contains a wlanSSID certificate extension as 224 defined in [15], it SHOULD be ignored. 225 If present, the wlanSSID extension implies a restriction on the 226 SSID of the target SSID used after enrollment, not during 227 enrollment. The domain name associated with both the enrollment 228 wireless LAN and the target wireless LAN SHOULD be the same and 229 are likely to use the same AAA server. Administrators should be 230 able to use the same certificate for both enrollment and target 231 WLANs. Since this enrollment method is designed to enroll devices 232 on other wireless LANs, the SSID on the enrollment WLAN could be 233 different. If the wlanSSID extension is present, this restriction 234 should apply to the target LAN. 236 If the TLS handshake completes successfully, the EAP Enroll two-phase 237 process begins. 239 5. EAP Enroll Protocol Definition 241 The document defines a new EAP Method Type "EAP-Enroll". It requires 242 a new EAP Method Type number assigned by IANA. The EAP-Enroll 243 process consists of a Provide phase (Request/Response) followed by a 244 Store phase (Request/Response). The Phase field is set to 0x01 245 during the Provide phase and 0x02 during the Store phase. Each EAP- 246 Enroll messages is followed by zero or more Enroll Elements. Each 247 Enroll Element has an Element Type (1 octet), a 2-octet length which 248 counts the number of octets in the Element Data field (starting 249 immediately after the length), and the data itself. EAP-Enroll MUST 250 only be used inside a tunnel which provides confidentiality, message 251 integrity, and server authentication. 253 A summary of the packet format is shown below. The fields are 254 transmitted from left to right. 256 General Format of an EAP Enroll message 258 0 1 2 3 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Code | Identifier | Overall Length | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | EAP Enroll | Phase | Enroll Elements... 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Format of Enroll Elements 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Element Type | Length | Data... 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Below is a summary of Enroll Element Types. The majority of these 275 element types are parts of the credentials that are either provided 276 to the server to bootstrap the enrollment process, or sent to the 277 client to store persistently. 279 Element 280 Code Semantics 281 ------- ---------------------------------- 282 0x00 RESERVED 283 0x01 Identity or Username 284 0x02 Plain-text Secret or PIN or Password 285 0x03 Digested Password 286 0x04 Nonce 287 0x05 Rooted Certificate 288 0x06 Self-Signed Certificate 289 0x07 Certificate Signing Request using existing private key 290 0x08 Certificate Signing Request using a newly generated key 291 0x09 Private Key in PKCS8 Format 292 0x0A Signed Digest rsa 293 0x0B CA Certificate 294 0x0C CSR Signed Digest rsa 296 0x80 BootstrapCombinations: 297 List of element combinations acceptable to server 298 abrreviated the "bootcomb" in the diagrams. 299 0x81 GeneratedCombinations: 300 Element combinations provided by the server or 301 requested by the client from the server. 302 abbreviated the "gencomb" in the diagrams. 304 0xFF RESERVED 306 The EAP-Enroll process consists of a Provide request and response and 307 a Store request and response. The server provides a Nonce element 308 (0x04) with at least 16 octets of data in the Provide request. The 309 Provide request MUST also contain the BootstrapCombinations Element 310 (0x80) and the GeneratedCombinations Element (0x81). 312 EAP Request/EAP-Enroll (Provide Phase) 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Code=1 (Req) | Identifier | Overall Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | EAP Enroll | Phase=1 (Prov)| 0x80 bootcomb | Length.. 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 .. | Acceptable element combinations c->s ... 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 ... | 0x81 gencomb | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | List of acceptable element combinations s->c .... 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 Both element lists have the same format. The data field in each 329 element list contains a list of element types (1 octet each) or the 330 octets 0x00 or 0xFF which have special semantics. Each list is 331 organized as an ordered list of alternative combinations in 332 preference order (the left-most combinations are more preferred). 333 Each alternative is separated by the octet 0xFF. The octet 0x00 MAY 334 be offered among alternatives, but it MUST NOT be combined with other 335 elements inside a single alternative. Combinations are simply an 336 unordered list of elements that MUST appear together in the same EAP 337 message. The octet 0x00 indicates that satisfactory authentication 338 was already performed and no additional credentials need to be 339 provided. 341 Meaning of non-element octects in element lists 342 0x00 No additional credentials are required 343 0xFF Indicates an alternative in an element list 345 For example, the following BootstrapCombinations means that the 346 client can provide the server either with a password and a self- 347 signed certificate, OR a username and password. 349 pass + self OR user + digested 350 word cert name password 351 0x02 0x06 0xFF 0x01 0x03 353 The client uses the BootstrapCombinations so it knows what type of 354 elements it needs to include in its response (the bootstrap 355 credentials). The client also examines the GeneratedCombinations to 356 select a combination of elements the client would like to receive 357 from the server in the Store phase (the persistent credentials). 359 After receiving an EAP Enroll Provide phase request, the client 360 selects one combination of elements from the BootstrapCombinations 361 that it can provide to bootstrap the enrollment process. The client 362 responds by sending each element from that combination plus a Nonce 363 element of its own. This client-side nonce MUST be different from 364 the server-side nonce and must be at least 16 octets in length. The 365 client also includes an GeneratedCombinations. The 366 GeneratedCombinations includes a subset of the GeneratedCombinations 367 from the request which MUST consist of only one of the originally 368 provided combinations with no alternatives. If the client cannot 369 respond with a set of credentials or a GeneratedCombinations list 370 which is compatible with the server, the client MUST send an EAP Nak 371 to terminate the enrollment. 373 EAP Response/EAP-Enroll (Provide Phase) 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Code=2 (Rsp) | Identifier | Overall Length | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | EAP Enroll | Phase=1 (Prov)| 0x81 gencomb | Length.. 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 .. | Acceptable element combinations c->s ... 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 ... | Other elements indicated in Request 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 After receiving an EAP Enroll Provide response, the server tries to 388 authenticate and authorize the client using the elements it provided. 389 If the client is authorized, the server examines the 390 GeneratedCombinations provided by the client and verifies that it is 391 willing to generate the requested elements for the client. If so, 392 the server generates these elements and returns them to the client in 393 an EAP Enroll Store request (shown below). 395 If the client did not authenticate or authorize or asked for a list 396 of elements the server was unwilling to provide, the server SHOULD 397 terminate the EAP exchange with an EAP-Failure message. The server 398 MAY instead attempt another round of EAP requests if it believes this 399 will fix the error. 401 The EAP Enroll Store request contains the elements which contain the 402 credentials the client needs to store for later access to the 403 enrolled network. 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Code=1 (Req) | Identifier | Overall Length | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | EAP Enroll | Phase=2 (Stor)| Credential Elements... 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 If the client sucessfully receives and saves the credentials in the 414 EAP Enroll Store request, it send an EAP Enroll Store response. The 415 EAP Enroll Store response contains no elements. 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Code=2 (Rsp) | Identifier | Overall Length = 2 | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | EAP Enroll | Phase=1 (Stor)| 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 6. Description of Specific Elements 427 Element 428 Code Semantics 429 ------- ---------------------------------- 430 0x00 RESERVED 431 0x01 Identity or Username 432 0x02 Plain-text Secret or PIN or Password 433 0x03 Digested Password 434 0x04 Nonce 435 0x05 Rooted Certificate 436 0x06 Self-Signed Certificate 437 0x07 Certificate Signing Request using existing private key 438 0x08 Certificate Signing Request using a newly generated key 439 0x09 Private Key in PKCS8 Format 440 0x0A Signed Digest rsa 441 0x0B CA Certificate 442 0x0C CSR Signed Digest rs 444 0x80 BootstrapCombinations: 445 List of element combinations acceptable to server 446 abrreviated the "bootcomb" in the diagrams. 447 0x81 GeneratedCombinations: 448 Element combinations provided by the server or 449 requested by the client from the server. 450 abbreviated the "gencomb" in the diagrams. 452 0xFF RESERVED 454 0x01 is an identity or username. The data is a UTF-8 string which is 455 not null-terminated and MUST NOT contain any NULL characters. In a 456 Provide response, this element MUST be accompanied by a Digested 457 Password Element (0x03). In a Store request, this element MUST be 458 accompanied by a Plain-Text Password element (0x02). 460 0x02 is a raw binary password, PIN, or other shared secret. 462 0x03 is a SHA-1 [6] digest of the username and password mixed with 463 client and server nonces. The digest is 20 octets of raw data which 464 is formed using the function: SHA( nonce + cnonce + user + 465 SHA(password)). This element can only be included in a Provide 466 response. 468 0x04 is a cryptographically secure nonce of at least 16 octets. 470 0x05 is a DER-encoded X.509v3 certificate which is rooted in a well- 471 known authority. If the client wants to receive a rooted certificate 472 from the EAP server that uses a private key generated by the client, 473 the client needs to provide a Certificate Signing Request (CSR) in 474 either Element 0x07 or 0x08 in the EAP Enroll Provide response. When 475 included in a Provide response it MUST be accompanied by a Signed 476 Digest Element (0x0A). When included in a Store request it MUST be 477 accompanied by a CA Certificate element (0x0B). 479 0x06 is a DER-encoded X.509v3 certificate which is self-signed. When 480 this element is a listed in a BootstrapCombinations element, the 481 client can safely imply that a rooted certificate would also be 482 acceptable. This element can only be included in a Provide response 483 and MUST be accompanied by a Signed Digest Element (0x0A). 485 0x07 is a DER-encoded PKCS#10 Certificate Signing Request [8] which 486 uses the same public key as a certificate presented in the EAP Enroll 487 Provide response. This element can only be included in a Provide 488 response. 490 0x08 is a DER-encoded PKCS#10 Certificate Signing Request which uses 491 a new key pair freshly generated specifically for the requested 492 certificate. This element can only be included in a Provide 493 response. 495 0x09 is a DER-encoded private key in PKCS#8 [14] format. This 496 element can only be included in a Store request and MUST be 497 accompanied by a rooted certificate (0x05). 499 0x0A is a signed digest used to insure the peer has possesion of a 500 private key. It is formed by signing (nonce + cnonce) with 501 sha1WithRSAEncryption as described in RFC 3370 [4] using the private 502 key from the corresponding provided certificate (0x05 or 0x06). This 503 element can only be included in a Provide response. 505 0x0B is a DER-encoded X.509v3 certificate of the authority which 506 issued the accompanying rooted certificate. This element can only be 507 included in a Store request and MUST be accompanied by a rooted 508 certificate (0x05). 510 0x0C is a signed digest used to insure the peer has possesion of a 511 newly generated private key. It is formed in the same way as the 512 Signed Digest (0x0A) except that it is signed with the private key 513 generated for a new CSR. This element can only be included in a 514 Provide response and MUST be accompanied by a new key CSR (0x08). 516 7. Usage 518 This EAP method offer a large array of elements. The purpose of this 519 section is to explain valid combinations of these elements and to 520 motivate the need for these combinations. 522 EAP-Enroll can be used to generate three types of credentials which 523 are of practical use: a certificate rooted in the local domain, a 524 username/password combination, and a pre-shared key. These 525 correspond respectively to EAP-TLS, WPA Enterprise, and WPA Personal 526 in 802.11 networks. While using a certificate infrastructure is 527 desirable from a security perspective, many organizations do not have 528 a deployed certificate authority. Username/password pairs are still 529 the norm for the majority of large organizations. When passwords are 530 machine-generated, this style of authentication is still quite 531 reasonable. Unfortunately, there is still also a need for EAP 532 authentication using a pre-shared key, although this usage is 533 discouraged. However, until a mechanism for secure fast roaming is 534 standardized, implemented, and widely deployed, there will still be a 535 number of deployments in wireless networks which authenticate using a 536 pre-shared key. Also, shared-key authentication is still very 537 popular for home access points. 539 When using a pre-shared key, the key is likely to be shared by a 540 large community, so this key is naturally provided by the server. 541 When using a username/password combination, this document provides a 542 mechanism to deliver a server-derived password. (The potential for 543 using a mutually-derived password is discussed in the To Do Section.) 544 When generating a certificate, there are a number of administrative 545 policy issues around how the key was generated for the client. The 546 client could generate a new private key for this certificate, the 547 client could reuse an existing private (possibly provided during 548 manufacturing), or the server could generate the corresponding 549 private key. Client generation of a new key is generally 550 RECOMMENDED, but there are some circumstances that justify using one 551 of the other two methods. For example, a wireless client can 552 associate with potentially dozens of wireless LANs. If the client 553 enrolls in each network using a separate certificate and key pair, 554 the storage requirements on the wireless device become non-trivial. 555 In addition, some devices may not generate sufficient entropy to 556 generate a good quality private key or may generate entropy very 557 slowly. One solution is to use an existing key or to generate the 558 key on the server. These two choices have different tradeoffs, so 559 this protocol allows the server to choose. 561 Valid combinations of optional elements returned in a Store Request 562 are listed below. Note (*) that the CA Certificate element (0x0B) 563 MUST always accompany a rooted certificate in the Store request. 565 Valid Credentials in an EAP-Enroll Store Request 567 Code(s) Element Names Example Usage 568 ----------- -------------------------------- -------------- 569 0x02 Plaintext Password WPA Personal 570 0x01 + 0x03 Username + Digest Password WPA Enterprise 571 * 0x05 Rooted Certificate EAP-TLS 572 * 0x05 + 0x09 Rooted Certificate + Private Key EAP-TLS 574 In order to authenticate the client, the server can accept several 575 different types of bootstrap credentials. The following is a list of 576 valid combinations of the elements defined in this document for use 577 in the Provide response. The client could include a CSR using a new 578 key, and its signed digest (0x08 + 0x0C) in any of these listed 579 combinations, or a CSR using an existing key (0x07) in any of the 580 starred combinations. 582 Valid Boostrap Credential Combos in EAP-Enroll Provide Response 584 Code(s) Elements 585 ------------------------- -------------------------------------- 586 none No Further Authentication Needed 587 0x02 Plaintext Password 588 0x01 + 0x03 Username + Password 589 * 0x05 + 0x0A Rooted Cert 590 * 0x06 + 0x0A Self-Signed Cert 591 * 0x05 + 0x0A + 0x02 Rooted Cert + Password 592 * 0x06 + 0x0A + 0x02 Self-Signed Cert + Password 593 * 0x05 + 0x0A + 0x01 + 0x03 Rooted Cert + Username + Password 594 * 0x06 + 0x0A + 0x01 + 0x03 Self-Signed Cert + Username + Password 596 Note that new elements could be defined (for example an element for 597 authentication partially via credit card information) and these 598 elements will need to define valid combinations with respect to the 599 elements defined in this document. 601 8. Example 603 In the example below, the Provide Request indicates that the server 604 will accept either a username and password; or a password, self- 605 signed certificate, and a certificate request as the credentials used 606 to bootstrap the enrollment process. The server is prepared to offer 607 either a rooted certificate and private key, or a machine generated 608 username and password. 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Code=1 (Req) | Identifier | Overall Length = 38 | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | EAP Enroll | Phase=1 (Prov)| 0x80 bootcomb | Length.. 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 .. = 6 | 0x02 passwd | 0x06 self cert| 0x08 CSR | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | 0xFF alt | 0x01 username | 0x03 digest | 0x81 gencomb | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Length = 5 | 0x05 cert | 0x09 privkey | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | 0xFF alt | 0x01 username | 0x02 passwd | 0x04 nonce | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Length = 16 | nonce data.... 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | 0xea9c8e88df84f1cec4341ae6cbe5a359 | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+ 630 In the Provide Response, the client sends a username "bob" and a 631 digest which uses the password "sh!", and asks for a rooted 632 certificate and the corresponding private key. 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Code=1 (Rsp) | Identifier | Overall Length = 68 | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | EAP Enroll | Phase=1 (Prov)| 0x01 username | Length .. 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 .. = 16 | "mac:00032a006486" | 0x04 nonce | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Length = 16 | nonce data.... 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | 0xf1cec4341ae6ca9c8e88df84be55a359 | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+ 647 ! 0x03 digest | Length = 20 | ... 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 .. sha( nonce + cnonce + user + sha(password) ) | 0x81 gencomb | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Length = 2 | 0x03 cert | 0x05 privkey | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 The server authenticates and authorizes the client and returns an 655 X.509 certificate and a private key in PKCS#8 format in an EAP Enroll 656 Store request. 658 0 1 2 3 659 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 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Code=1 (Req) | Identifier | Overall Length | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | EAP Enroll | Phase=2 (Stor)| 0x03 cert | Length .. 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 .. = 944 | X.509 Certificate in DER format .... | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+ 667 | 0x05 privkey | Length = 677 | Private Key.. 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 .. in PKCS#8 format (DER encoded) .... | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+-+ 672 The EAP Enroll Store response just acknowledges the successful 673 receipt of the persistent credentials 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Code=2 (Rsp) | Identifier | Overall Length = 2 | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | EAP Enroll | Phase=1 (Stor)| 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 9. Security Considerations 685 This mechanism relies on a TLS channel to provide confidentiality, 686 message integrity, and server authentication. If the TLS server is 687 not authenticated, this mechanism is open to a variety of active 688 attacks and can reveal cleartext passwords. The mechanism currently 689 includes only a very basic way to perform mutual authentication using 690 a shared secret. Since the passwords used during the bootstrapping 691 process are likely to be weak, this authentication is vulnerable to 692 dictionary attacks, but due to the incorporation of nonces, it is not 693 vulnerable to dictionary pre-computation. 695 Similarly, this mechanism assumes transitive trust between the AAA 696 server (the TLS server) and the certificate authority. It does not 697 attempt to prevent active attacks by an attacker introduced between a 698 AAA server and a certificate authority for example. 700 This mechanism allows the server to generate a username/password pair 701 for the client. It is desirable to mutually derive this password. A 702 possible approach to mutually deriving passwords is dicsussed in the 703 To Do section. Likewise, the server can generate a private key for 704 the client in one mode. However, the server can refuse to offer a 705 private key and the client can refuse to enroll with a server that 706 provides a private key. 708 EAP servers which implement this mechanism MUST implement Rooted 709 Certificate and Username/Plaintext Password storage. EAP servers 710 which implement this mechanism MUST implement Self-Signed Certificate 711 plus Plaintext Password and Username/Digested Password for 712 bootstrapping. EAP servers which implement this mechanism MUST 713 implement EAP-TTLS and the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite 714 defined in RFC 3268 [9]. 716 Much more to do here. 718 10. IANA Considerations 720 Need a new EAP Method assignment. Need a new URN assignment 721 following rules in RFC3688 [10]. Should probably setup a registry of 722 Enroll Element Types. 724 11. To Do 726 This draft has several layering violations. EAP Enroll mechanism 727 should be as independent as possible of other layers. 729 This EAP method defines a way to configure an EAP client with a 730 username and password using a server generated key. It is desirable 731 to develop a mechanism for the server to generate a username and 732 provide a mutually derived key. One possible solution is to start 733 the EAP-Enroll Provide phase, then use EAP-PAX [22] to derive a 734 mutual key, finally ending with an EAP-Enroll Store phase which 735 references the derived key. This may aggravate the layering problems 736 with the proposal however. 738 Need to describe how this relates to the SACRED framework [23]. 740 Missing a normative discussion about how to verify that the client is 741 in possession of the private key that corresponds to a certificate or 742 CSR. (how to use the Signed Digest and CSR Signed Digest elements). 744 12. Acknowledgments 746 Many thanks to Max Pritikin for his discussions about this idea, and 747 to Charles Clancy who provided a security review and many helpful 748 comments. Thanks also to Russ Housley and Benard Aboba for their 749 support of this idea. 751 13. References 752 13.1 Normative References 754 [1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 755 Levkowetz, "Extensible Authentication Protocol (EAP)", 756 RFC 3748, June 2004. 758 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 759 Levels", BCP 14, RFC 2119, March 1997. 761 [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 762 RFC 2246, January 1999. 764 [4] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", 765 RFC 3370, August 2002. 767 [5] Aboba, B. and D. Simon, "PPP EAP TLS Authentication Protocol", 768 RFC 2716, October 1999. 770 [6] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", 771 RFC 3174, September 2001. 773 [7] Myers, M., Adams, C., Solo, D., and D. Kemp, "Internet X.509 774 Certificate Request Message Format", RFC 2511, March 1999. 776 [8] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request 777 Syntax Specification Version 1.7", RFC 2986, November 2000. 779 [9] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 780 Transport Layer Security (TLS)", RFC 3268, June 2002. 782 [10] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 783 January 2004. 785 [11] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 786 Public Key Infrastructure Certificate and Certificate 787 Revocation List (CRL) Profile", RFC 3280, April 2002. 789 [12] International Telecommunications Union, "Information technology 790 - Open Systems Interconnection - The Directory: Public-key and 791 attribute certificate frameworks", ITU-T Recommendation X.509, 792 ISO Standard 9594-8, March 2000. 794 [13] International Telecommunications Union, "Information Technology 795 - ASN.1 encoding rules: Specification of Basic Encoding Rules 796 (BER), Canonical Encoding Rules (CER) and Distinguished 797 Encoding Rules (DER)", ITU-T Recommendation X.690, 1994. 799 [14] RSA Laboratories, "Private-Key Information Syntax Standard, 800 Version 1.2", PKCS 8, November 1993. 802 [15] Housley, R. and T. Moore, "Certificate Extensions and 803 Attributes Supporting Authentication in Point-to-Point 804 Protocol (PPP) and Wireless Local Area Networks (WLAN)", 805 draft-ietf-pkix-rfc3770bis-03 (work in progress), June 2005. 807 [16] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication 808 Protocol Version 1 (EAP-TTLSv1)", draft-funk-eap-ttls-v1-00 809 (work in progress), February 2005. 811 13.2 Informational References 813 [17] "Information technology - Telecommunications and information 814 exchange between systems - Local and metropolitan area networks 815 - Specific requirements - Part 11: Wireless LAN Medium Access 816 Control (MAC) and Physical Layer (PHY) specifications", 817 IEEE Standard 802.11, 1999, 818 . 821 [18] "Information technology - Telecommunications and information 822 exchange between systems - Local and metropolitan area networks 823 - Specific requirements - Part 11: Wireless LAN Medium Access 824 Control (MAC) and Physical Layer (PHY) specifications Amendment 825 6: Medium Access Control (MAC) Security Enhancements", 826 IEEE Standard 802.11i, July 2004, . 829 [19] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 830 March 1997. 832 [20] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan, "Service 833 Location Protocol", RFC 2165, June 1997. 835 [21] Stanley, D., Walker, J., and B. Aboba, "Extensible 836 Authentication Protocol (EAP) Method Requirements for Wireless 837 LANs", RFC 4017, March 2005. 839 [22] Clancy, C. and W. Arbaugh, "EAP Password Authenticated 840 Exchange", draft-clancy-eap-pax-06 (work in progress), 841 January 2006. 843 [23] Gustafson, D., Just, M., and M. Nystrom, "Securely Available 844 Credentials (SACRED) - Credential Server Framework", RFC 3760, 845 April 2004. 847 URIs 849 [24] 852 Author's Address 854 Rohan Mahy 855 Plantronics 856 345 Encincal Street 857 Santa Cruz, CA 858 USA 860 Email: rohan@ekabal.com 862 Intellectual Property Statement 864 The IETF takes no position regarding the validity or scope of any 865 Intellectual Property Rights or other rights that might be claimed to 866 pertain to the implementation or use of the technology described in 867 this document or the extent to which any license under such rights 868 might or might not be available; nor does it represent that it has 869 made any independent effort to identify any such rights. Information 870 on the procedures with respect to rights in RFC documents can be 871 found in BCP 78 and BCP 79. 873 Copies of IPR disclosures made to the IETF Secretariat and any 874 assurances of licenses to be made available, or the result of an 875 attempt made to obtain a general license or permission for the use of 876 such proprietary rights by implementers or users of this 877 specification can be obtained from the IETF on-line IPR repository at 878 http://www.ietf.org/ipr. 880 The IETF invites any interested party to bring to its attention any 881 copyrights, patents or patent applications, or other proprietary 882 rights that may cover technology that may be required to implement 883 this standard. Please address the information to the IETF at 884 ietf-ipr@ietf.org. 886 Disclaimer of Validity 888 This document and the information contained herein are provided on an 889 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 890 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 891 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 892 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 893 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 894 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 896 Copyright Statement 898 Copyright (C) The Internet Society (2006). This document is subject 899 to the rights, licenses and restrictions contained in BCP 78, and 900 except as set forth therein, the authors retain all their rights. 902 Acknowledgment 904 Funding for the RFC Editor function is currently provided by the 905 Internet Society.