idnits 2.17.1 draft-hartman-webauth-00.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 533. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 523. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (June 14, 2006) is 6524 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) == Unused Reference: 'RFC2818' is defined on line 486, but no explicit reference was found in the text == Unused Reference: 'RFC4346' is defined on line 488, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'LAWS' ** Downref: Normative reference to an Informational draft: draft-jaganathan-kerberos-http (ref. 'MSNEGOTIATE') -- Possible downref: Non-RFC (?) normative reference: ref. 'PHISHING' ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) == Outdated reference: A later version (-07) exists of draft-iab-auth-mech-05 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hartman 3 Internet-Draft MIT 4 Expires: December 16, 2006 June 14, 2006 6 Distributed Identity for the Web 7 draft-hartman-webauth-00.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 December 16, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 It is often useful to be able to use distributed identity--an 41 identity from one organization for accessing resources from another. 42 for example it would be useful to use an identifier corresponding to 43 your work identity when accessing business partners' websites. 44 Similarly collaborative projects can benefit from distributed 45 identity. This memo proposes a scheme for distributed identity that 46 meets requirements to minimize the risk of phishing attacks for HTTP- 47 based applications including websites. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. User Experience . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Roaming and Local State . . . . . . . . . . . . . . . . . 5 55 3.2. Webdav and other HTTP Applications . . . . . . . . . . . . 6 56 4. Website Author Experience . . . . . . . . . . . . . . . . . . 7 57 5. A Proposed Solution . . . . . . . . . . . . . . . . . . . . . 8 58 5.1. Negotiate Authentication . . . . . . . . . . . . . . . . . 8 59 5.2. Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 5.3. Security Assertion Markup Language . . . . . . . . . . . . 11 61 5.4. Local Browser UI . . . . . . . . . . . . . . . . . . . . . 11 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 14 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 67 Intellectual Property and Copyright Statements . . . . . . . . . . 17 69 1. Introduction 71 It is often useful to be able to use distributed identity--an 72 identity from one organization for accessing resources from another. 73 for example it would be useful to use an identifier corresponding to 74 your work identity when accessing business partners' websites. 75 Similarly collaborative projects can benefit from distributed 76 identity. This memo proposes a scheme for distributed identity that 77 meets requirements to minimize the risk of phishing attacks 78 [PHISHING]. 80 Distributed identity solutions will never achieve the goal of having 81 a single identity used for all websites. Some websites will only 82 accept a limited number of identity providers. For example financial 83 sites typically want high degrees of assurance that identity 84 providers will not allow the wrong user to use an identity that has 85 access to a financial account. Similarly users will not always wish 86 to link their identities together. However distributed identity can 87 minimize the number of identities that are in use. 89 This proposal uses existing technology with incremental improvements 90 to achieve the goal of distributed identity. This document is 91 organized into two parts. The first part (sections 3 and 4) 92 describes the intended user experience for the distributed identity 93 system. The second part describes a specific proposal for realizing 94 distributed identity. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 The terms identity, subject, relying party, and claim are used as 103 defined in [LAWS]. 105 3. User Experience 107 This section describes what Alice, a HTTP user is hoping to get from 108 distributed identity. 110 Alice wants to go to a website. She's remembered the name of the 111 website from an ad, received a link in email, or is following a link 112 from another site. 114 The website wishes Alice to log in. It presents an HTML page which 115 includes a login button. Alice pushes this button and her local 116 identity management UI appears. This UI includes some branding from 117 the website, but it also includes branding Alice chose when she 118 installed her computer. 120 Alice selects an identity she wants to present to the website. Since 121 she has not recently used this identity either on the web or anywhere 122 else, she must enter the password associated with the identity. 124 Alice is logged into the website. If the website uses TLS, she knows 125 that the page she sees was created by the same party to whom she 126 authenticated. If her identity is designed to be accepted only by a 127 small number of relying parties, then she knows that she is talking 128 to one of these parties even if she was not careful to check to make 129 sure the URL was not spoofed. 131 If Alice didn't have an existing identity she wanted to use and if 132 the website she's going to is not somehow restricted to existing 133 users, then her identity management UI will provide the option to 134 create a new identity. 136 The primary benefit from distributed identity is that if the website 137 allows, Alice can choose whatever identity she wishes to use. For 138 example if a business partner has granted her access to some 139 collaboration site, she can use her work identity even if the site is 140 in a completely different organization. Alice can choose to use the 141 same personal identity for many of the sites she shops at, or she can 142 choose to use different identities in order to minimize sites' 143 ability to correlate what she is doing. She can even choose to use 144 multiple identities within a single site if she wants that level of 145 privacy. 147 3.1. Roaming and Local State 149 Alice's computer may store information on which identity is typically 150 used with which website. However it is important that Alice be able 151 to use her identities from any computer she finds herself at, without 152 needing to bring special hardware or to configure the computer with 153 her identities. Alice should be able to use an identity by knowing 154 the name of the identity, the identity provider and of course the 155 password. 157 Special consideration needs to be given to how Alice knows that the 158 local identity management UI is displayed on a computer that she is 159 visiting. On her local computer she has branded the identity 160 management UI. 162 3.2. Webdav and other HTTP Applications 164 Alice needs to get the same experience when she uses HTTP 165 applications besides websites. Generally the identity management UI 166 will be invoked when the server requires authentication instead of 167 when she selects a login button, but besides that the experience will 168 be the same. 170 4. Website Author Experience 172 This section describes how distributed identity works for Bob, an 173 author of a website. 175 Bob wants to add support for distributed identity to his website. 176 His server software does already support distributed identity. 178 Bob adds a new form control to his login page. He can choose one of 179 three ways to select which identities users may use: 181 1. Any identity 183 2. Any identity from a set of identity providers specified by Bob 185 3. Any identity from a single identity provider that Bob specifies 187 Bob can also specify branding for his site to be included in the 188 local identity management UI. In the interests of extensibility Bob 189 can specify which distributed identity management mechanisms he 190 supports. 192 In the interests of incremental deployment, Bob needs to be able to 193 use Javascript or some other mechanism to provide a page that works 194 both with traditional authentication and with distributed identity. 196 If Bob runs a webdav server or some other HTTP application, he sends 197 the same information but it is carried in the HTTP response 198 requesting authentication instead of in an HTML page. It is 199 important that future extensions to distributed identity keep the 200 parameters that can be specified in HTTP and HTML in sync. 202 5. A Proposed Solution 204 This section proposes a concrete way to achieve distributed identity. 205 The goals of this proposal are as follows: 207 1. Demonstrate that distributed identity can be achieved with 208 incremental improvements to existing protocols and technology. 210 2. Establish a minimum level of detail that needs to be specified to 211 propose a solution and show that it is workable. 213 3. Propose a solution the author believes is the best compromise 214 between deployability and meeting the requirements. 216 The solution is comprised of four related components. HTTP negotiate 217 [MSNEGOTIATE] (GSS-API [RFC2743]) authentication is used to carry 218 security data from the browser or client application to the server 219 and to carry security response information back. Kerberos [RFC4120] 220 [RFC4121] is used as a way to separate the interactions with the 221 identity provider from the interactions with the HTTP server. In 222 effect, Kerberos provides the distributed identity. Security 223 Assertion Markup Language (SAML) is used to carry assertions (claims) 224 about the identity. The browser or client UI is used to let the user 225 know in a trusted manner that their password is being given to an 226 identity manager on their local system rather than sent in the clear 227 to the remote server. 229 5.1. Negotiate Authentication 231 HTTP negotiate [MSNEGOTIATE] authentication has been very successful 232 at providing enterprise websites with a limited form of distributed 233 identity. Enterprise users can log into their operating system and 234 then are authenticated to websites with no additional work. While 235 this protocol was originally introduced for Microsoft it has been 236 adopted by several major browsers, Webdav libraries, web servers and 237 operating systems. Negotiate authentication has enjoyed wide 238 deployment in enterprises--possibly greater than digest 239 authentication [RFC2617]. The negotiate authentication method 240 typically provides a better user experience than the digest method 241 because except in error cases, no dialogue or user interaction is 242 required. One significant problem with basic and digest HTTP 243 authentication is that at least today, they provide a interface very 244 different from the rest of the website by popping up a local 245 dialogue; options for forgotten passwords, new accounts or help are 246 not typically available. 248 In the optimal case, the negotiate method will not add any round 249 trips to the HTTP exchange. If the client knows that negotiate 250 authentication is needed (for example via an HTML extension like the 251 one contemplated in Section 4), then the client can include the first 252 negotiate message in the with its HTTP request. For the case of 253 Kerberos [RFC4121], only one round trip is required so no round trips 254 are added. Additional round trips may be required if other 255 mechanisms are used. 257 While negotiate exists today, incremental improvements are required 258 to get an ideal user experience. The following improvements would be 259 needed: 261 1. Create a standards track version of the negotiate protocol. It 262 is likely necessary to change the name used in the HTTP 263 authentication request in order to gain change control and to add 264 extensibility. Work is already under way to do this as an 265 individual submission. 267 2. Currently negotiate assumes that servers maintain context if more 268 than one round trip is required. This is unacceptable for some 269 HTTP deployments. Add support for the client to return an opaque 270 context to the server for multi-round-trip negotiation. 272 3. Currently there is not a well defined way in HTTP to authenticate 273 before sending a request. In the case of PUT requests or other 274 requests with confidential data it would be desirable to 275 authenticate first. Add support for this. 277 4. Provide some mechanism for carrying hints about the identity that 278 is used. As discussed in Section 5.2, servers may have many 279 identities. Some GSS-API implementations will be much easier to 280 use if the server's identity is made available to the server as 281 part of the HTTP request. 283 5.2. Kerberos 285 Kerberos provides separation between the identity provider and the 286 relying party. In effect, Kerberos allows the identity to be 287 distributed. Kerberos deployments have scaled to sizes comparable to 288 those anticipated for Internet identity providers. 290 Kerberos has two exchanges that are relevant to distributed identity. 291 The first exchange is the authentication server (AS) exchange 292 [RFC4120] which is an exchange between the identity provider and 293 client. This exchange has a mode described in RFC 4120 that is a 294 traditional challenge/response authentication system [IABAUTH]. 295 Authentication based on public key certificates [RFC4556] can also be 296 performed using the AS exchange. Modes of the AS exchange for token 297 cards and for zero-knowledge password protocols have been implemented 298 but not standardized. 300 The second exchange is the ap-req exchange used to authenticate to 301 the relying party. This exchange is carried in HTTP authentication 302 using the negotiate mechanism. 304 A feature of Kerberos called authorization data can be used to carry 305 Security Assertion Markup Language (SAML) assertions. Since the 306 assertions are carried in the ticket, Kerberos' existing mechanisms 307 can be used to protect and authenticate the assertions when the 308 Kerberos server (KDC) is the SAML Authority. This will be much 309 easier to deploy than XML signatures. Of course XML signature can 310 still be used for assertions made by parties other than the KDC. 312 Kerberos authenticates a client to a given server. Kerberos has 313 mechanisms for cross-realm authentication where a client in one realm 314 (Kerberos namespace) can authenticate to a server in another realm. 315 While this mechanism can be used with distributed identity when the 316 necessary cross-realm relationships exist, distributed identity 317 cannot depend on being able to establish cross-realm relationships. 318 A cross-realm relationship implies that the client realm believes 319 that the KDC of the server realm is responsible for authentication to 320 any server in that realm's namespace. Unfortunately, there is no 321 easy way to know which servers belong to a given realm's namespace. 322 So, it will generally be easier to deploy systems where servers have 323 multiple Kerberos principals--one for each identity provider they 324 accept. Since servers only accept identity providers when they have 325 a relationship with someone using that identity provider, then this 326 will not typically involve more than constant increase in state 327 servers already maintain for each user. In several important 328 situations including servers that accept a specified set of identity 329 providers, significantly less state is required. 331 Kerberos is a good match for many of distributed identity's needs. 332 However incremental improvement is required in the following ways: 334 1. Provide a standardized mechanism for enrolling an identity in a 335 Kerberos realm. This is needed so Alice's local identity 336 management UI can create identities. 338 2. Develop a mechanism for enrolling a Kerberos server into a realm 339 based on a public-key credential or other non-Kerberos 340 credential. This is needed so that servers can start accepting 341 identities from a particular identity provider. In cases where 342 the identity provider is willing to register any server and the 343 server is willing to accept any identity provider, this operation 344 needs to be something Alice's browser can do automatically. 346 3. Kerberos in the enterprise is focused on single sign-on. Users 347 should type their password or present a smart card at login and 348 then should have network credentials cached. This is desirable 349 from a usability standpoint. However security policies of some 350 sites--particularly financial sites--require that the user has 351 recently authenticated. Such sites will often time out a session 352 after a few minutes to avoid problems where a user has left a 353 computer unattended. Kerberos has an integrity-protected 354 mechanism to report when the user actually authenticated to the 355 KDC but no standardized mechanism to allow a server to request a 356 new authentication be performed without using cached tickets. 358 4. An authorization data element needs to be defined to carry SAML 359 assertions. 361 5. An HTTP transport for Kerberos should be defined. Currently, 362 Kerberos runs over TCP and UDP. If Kerberos is going to be used 363 for web authentication and HTTP transport is required so that 364 Kerberos has the same firewall traversal properties as HTTP. 366 5.3. Security Assertion Markup Language 368 People often desire to use distributed identity systems to convey 369 information such as name and age about a subject to the relying 370 party. SAML is proposed as a mechanism to do this. In order to use 371 SAML, a profile of SAML for this application needs to be created. 372 Such a profile would need to specify: 374 1. What claims need to be supported 376 2. How third-party and KDC-issued claims are mixed 378 3. How clients request particular claims 380 An alternative that has been proposed is a SAML GSS-API mechanism 381 that wraps the Kerberos mechanism. The problem with this approach is 382 that only the KDC and server share the service key ticket. So, 383 unless the SAML is inside the Kerberos ticket, then the client is 384 responsible for binding the SAML assertions to the Kerberos exchange 385 and proving that the assertions apply to the client. This would 386 typically require XML digital signatures be used for all assertions-- 387 not just third-party claims. That would increase code complexity and 388 deployment complexity. 390 5.4. Local Browser UI 392 The local browser UI is critical to the security of any web 393 authentication system. The primary purpose of browser UI extensions 394 is to let a user know whether they are typing a password into a local 395 system or sending the password over the network. The phishing 396 requirements document [PHISHING] discusses UI requirements in more 397 detail. 399 Specification of the UI is outside the scope of the IETF. However 400 the IETF should be involved in discussing security requirements for 401 the UI, such as the need to distinguish between passwords entered 402 locally and passwords sent over the net. The IETF also needs to be 403 involved in discussing abstract requirements for the inputs and 404 output of the UI such as those discussed in Section 4. 406 6. Security Considerations 408 All the security considerations discussed in [PHISHING] apply to the 409 specific proposal in this document. 411 The security of HTML extensions proposed in Section 4 needs to be 412 carefully considered. IN particular, any concrete set of extensions 413 needs to be analyzed for possible vulnerabilities when an attacker 414 can modify the HTML elements used to signal distributed identity. 416 As discussed in Section 5.2, Kerberos needs to be extended to support 417 enrollment of new identities. The security of these extensions will 418 be critical to the security of the entire system. Often, identity 419 providers will allow new identities to be enrolled without 420 authentication. This allows the identity provider to confirm that 421 subsequent uses of the identity correspond to the same subject but 422 not to confirm that the identity corresponds to some particular real- 423 world subject. This is reasonable provided that relying parties do 424 not place inappropriate trust in information claimed about the 425 subject. IN particular, relying parties need to make sure that they 426 have sufficient confidence the identity corresponds to the intended 427 subject before granting access to that identity. Similarly the 428 relying party needs to confirm that it has sufficient confidence in 429 policies and procedures used to run an identity provider. 431 Similar concerns exist for enrollment of servers into a Kerberos 432 realm. A denial of service condition exists if servers are weakly 433 authenticated before being allowed to join a realm and an attacker is 434 able to prevent the real server from joining by joining a spoofed 435 server. In addition, if users connect to a spoofed server expecting 436 to be connecting to the real server, they may disclose confidential 437 information to that server. However the server authentication 438 provided by TLS will tend to mitigate this attack when distributed 439 identity is used in conjunction with HTTP over TLS. Also, identity 440 providers wishing to provide a high degree of trust should not weakly 441 authenticate servers before allowing those servers to accept 442 identities. 444 7. References 446 7.1. Normative References 448 [LAWS] "Laws of Identity", 2006. 450 [MSNEGOTIATE] 451 Jaganathan, K., Zhu, L., and J. Brezak, "Kerberos Based 452 HTTP Authentication in Windows", 453 draft-jaganathan-kerberos-http-01.txt (work in progress), 454 July 2005. 456 [PHISHING] 457 Hartman, S., "Requirements for Web Authentication 458 Resistant to Phishing", May 2006. 460 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, March 1997. 463 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 464 Leach, P., Luotonen, A., and L. Stewart, "HTTP 465 Authentication: Basic and Digest Access Authentication", 466 RFC 2617, June 1999. 468 [RFC2743] Linn, J., "Generic Security Service Application Program 469 Interface Version 2, Update 1", RFC 2743, January 2000. 471 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 472 Kerberos Network Authentication Service (V5)", RFC 4120, 473 July 2005. 475 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 476 Version 5 Generic Security Service Application Program 477 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 478 July 2005. 480 7.2. Informative References 482 [IABAUTH] Rescorla, E., "A Survey of Authentication Mechanisms", 483 draft-iab-auth-mech-05.txt (work in progress), 484 February 2006. 486 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 488 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 489 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 491 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 492 Authentication in Kerberos", rfc 4556, June 2006. 494 Author's Address 496 Sam Hartman 497 Massachusetts Institute of Technology 499 Email: hartmans-ietf@mit.edu 501 Intellectual Property Statement 503 The IETF takes no position regarding the validity or scope of any 504 Intellectual Property Rights or other rights that might be claimed to 505 pertain to the implementation or use of the technology described in 506 this document or the extent to which any license under such rights 507 might or might not be available; nor does it represent that it has 508 made any independent effort to identify any such rights. Information 509 on the procedures with respect to rights in RFC documents can be 510 found in BCP 78 and BCP 79. 512 Copies of IPR disclosures made to the IETF Secretariat and any 513 assurances of licenses to be made available, or the result of an 514 attempt made to obtain a general license or permission for the use of 515 such proprietary rights by implementers or users of this 516 specification can be obtained from the IETF on-line IPR repository at 517 http://www.ietf.org/ipr. 519 The IETF invites any interested party to bring to its attention any 520 copyrights, patents or patent applications, or other proprietary 521 rights that may cover technology that may be required to implement 522 this standard. Please address the information to the IETF at 523 ietf-ipr@ietf.org. 525 Disclaimer of Validity 527 This document and the information contained herein are provided on an 528 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 529 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 530 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 531 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 532 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 533 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 535 Copyright Statement 537 Copyright (C) The Internet Society (2006). This document is subject 538 to the rights, licenses and restrictions contained in BCP 78, and 539 except as set forth therein, the authors retain all their rights. 541 Acknowledgment 543 Funding for the RFC Editor function is currently provided by the 544 Internet Society.