idnits 2.17.1 draft-ietf-httpbis-p7-auth-05.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 30. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 597. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2617, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC2617, updated by this document, for RFC5378 checks: 1997-12-01) -- 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 (November 16, 2008) is 5602 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) == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-05 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p6-cache-05 ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Fielding, Ed. 3 Internet-Draft Day Software 4 Obsoletes: 2616 (if approved) J. Gettys 5 Updates: 2617 (if approved) One Laptop per Child 6 Intended status: Standards Track J. Mogul 7 Expires: May 20, 2009 HP 8 H. Frystyk 9 Microsoft 10 L. Masinter 11 Adobe Systems 12 P. Leach 13 Microsoft 14 T. Berners-Lee 15 W3C/MIT 16 Y. Lafon, Ed. 17 W3C 18 J. Reschke, Ed. 19 greenbytes 20 November 16, 2008 22 HTTP/1.1, part 7: Authentication 23 draft-ietf-httpbis-p7-auth-05 25 Status of this Memo 27 By submitting this Internet-Draft, each author represents that any 28 applicable patent or other IPR claims of which he or she is aware 29 have been or will be disclosed, and any of which he or she becomes 30 aware will be disclosed, in accordance with Section 6 of BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on May 20, 2009. 50 Abstract 52 The Hypertext Transfer Protocol (HTTP) is an application-level 53 protocol for distributed, collaborative, hypermedia information 54 systems. HTTP has been in use by the World Wide Web global 55 information initiative since 1990. This document is Part 7 of the 56 seven-part specification that defines the protocol referred to as 57 "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines 58 HTTP Authentication. 60 Editorial Note (To be removed by RFC Editor) 62 Discussion of this draft should take place on the HTTPBIS working 63 group mailing list (ietf-http-wg@w3.org). The current issues list is 64 at and related 65 documents (including fancy diffs) can be found at 66 . 68 The changes in this draft are summarized in Appendix B.6. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Notational Conventions and Generic Grammar . . . . . . . . . . 4 75 3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5 76 3.1. 401 Unauthorized . . . . . . . . . . . . . . . . . . . . . 5 77 3.2. 407 Proxy Authentication Required . . . . . . . . . . . . 5 78 4. Header Field Definitions . . . . . . . . . . . . . . . . . . . 5 79 4.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 5 80 4.2. Proxy-Authenticate . . . . . . . . . . . . . . . . . . . . 6 81 4.3. Proxy-Authorization . . . . . . . . . . . . . . . . . . . 7 82 4.4. WWW-Authenticate . . . . . . . . . . . . . . . . . . . . . 7 83 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 84 5.1. Message Header Registration . . . . . . . . . . . . . . . 8 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 86 6.1. Authentication Credentials and Idle Clients . . . . . . . 8 87 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 91 Appendix A. Compatibility with Previous Versions . . . . . . . . 10 92 A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 10 93 Appendix B. Change Log (to be removed by RFC Editor before 94 publication) . . . . . . . . . . . . . . . . . . . . 10 95 B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 10 96 B.2. Since draft-ietf-httpbis-p7-auth-00 . . . . . . . . . . . 10 97 B.3. Since draft-ietf-httpbis-p7-auth-01 . . . . . . . . . . . 10 98 B.4. Since draft-ietf-httpbis-p7-auth-02 . . . . . . . . . . . 10 99 B.5. Since draft-ietf-httpbis-p7-auth-03 . . . . . . . . . . . 10 100 B.6. Since draft-ietf-httpbis-p7-auth-04 . . . . . . . . . . . 10 101 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 103 Intellectual Property and Copyright Statements . . . . . . . . . . 15 105 1. Introduction 107 This document defines HTTP/1.1 access control and authentication. 108 Right now it includes the extracted relevant sections of RFC 2616 109 with only minor changes. The intention is to move the general 110 framework for HTTP authentication here, as currently specified in 111 [RFC2617], and allow the individual authentication mechanisms to be 112 defined elsewhere. This introduction will be rewritten when that 113 occurs. 115 HTTP provides several OPTIONAL challenge-response authentication 116 mechanisms which can be used by a server to challenge a client 117 request and by a client to provide authentication information. The 118 general framework for access authentication, and the specification of 119 "basic" and "digest" authentication, are specified in "HTTP 120 Authentication: Basic and Digest Access Authentication" [RFC2617]. 121 This specification adopts the definitions of "challenge" and 122 "credentials" from that specification. 124 1.1. Requirements 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 An implementation is not compliant if it fails to satisfy one or more 131 of the MUST or REQUIRED level requirements for the protocols it 132 implements. An implementation that satisfies all the MUST or 133 REQUIRED level and all the SHOULD level requirements for its 134 protocols is said to be "unconditionally compliant"; one that 135 satisfies all the MUST level requirements but not all the SHOULD 136 level requirements for its protocols is said to be "conditionally 137 compliant." 139 2. Notational Conventions and Generic Grammar 141 This specification uses the ABNF syntax defined in Section 2.1 of 142 [Part1]. 144 The ABNF rules below are defined in other specifications: 146 OWS = 148 challenge = 149 credentials = 151 3. Status Code Definitions 153 3.1. 401 Unauthorized 155 The request requires user authentication. The response MUST include 156 a WWW-Authenticate header field (Section 4.4) containing a challenge 157 applicable to the requested resource. The client MAY repeat the 158 request with a suitable Authorization header field (Section 4.1). If 159 the request already included Authorization credentials, then the 401 160 response indicates that authorization has been refused for those 161 credentials. If the 401 response contains the same challenge as the 162 prior response, and the user agent has already attempted 163 authentication at least once, then the user SHOULD be presented the 164 entity that was given in the response, since that entity might 165 include relevant diagnostic information. HTTP access authentication 166 is explained in "HTTP Authentication: Basic and Digest Access 167 Authentication" [RFC2617]. 169 3.2. 407 Proxy Authentication Required 171 This code is similar to 401 (Unauthorized), but indicates that the 172 client must first authenticate itself with the proxy. The proxy MUST 173 return a Proxy-Authenticate header field (Section 4.2) containing a 174 challenge applicable to the proxy for the requested resource. The 175 client MAY repeat the request with a suitable Proxy-Authorization 176 header field (Section 4.3). HTTP access authentication is explained 177 in "HTTP Authentication: Basic and Digest Access Authentication" 178 [RFC2617]. 180 4. Header Field Definitions 182 This section defines the syntax and semantics of HTTP/1.1 header 183 fields related to authentication. 185 4.1. Authorization 187 A user agent that wishes to authenticate itself with a server-- 188 usually, but not necessarily, after receiving a 401 response--does so 189 by including an Authorization request-header field with the request. 190 The field "Authorization" consists of credentials containing the 191 authentication information of the user agent for the realm of the 192 resource being requested. 194 Authorization = "Authorization" ":" OWS Authorization-v 195 Authorization-v = credentials 197 HTTP access authentication is described in "HTTP Authentication: 199 Basic and Digest Access Authentication" [RFC2617]. If a request is 200 authenticated and a realm specified, the same credentials SHOULD be 201 valid for all other requests within this realm (assuming that the 202 authentication scheme itself does not require otherwise, such as 203 credentials that vary according to a challenge value or using 204 synchronized clocks). 206 When a shared cache (see Section 9 of [Part6]) receives a request 207 containing an Authorization field, it MUST NOT return the 208 corresponding response as a reply to any other request, unless one of 209 the following specific exceptions holds: 211 1. If the response includes the "s-maxage" cache-control directive, 212 the cache MAY use that response in replying to a subsequent 213 request. But (if the specified maximum age has passed) a proxy 214 cache MUST first revalidate it with the origin server, using the 215 request-headers from the new request to allow the origin server 216 to authenticate the new request. (This is the defined behavior 217 for s-maxage.) If the response includes "s-maxage=0", the proxy 218 MUST always revalidate it before re-using it. 220 2. If the response includes the "must-revalidate" cache-control 221 directive, the cache MAY use that response in replying to a 222 subsequent request. But if the response is stale, all caches 223 MUST first revalidate it with the origin server, using the 224 request-headers from the new request to allow the origin server 225 to authenticate the new request. 227 3. If the response includes the "public" cache-control directive, it 228 MAY be returned in reply to any subsequent request. 230 4.2. Proxy-Authenticate 232 The response-header field "Proxy-Authenticate" MUST be included as 233 part of a 407 (Proxy Authentication Required) response. The field 234 value consists of a challenge that indicates the authentication 235 scheme and parameters applicable to the proxy for this Request-URI. 237 Proxy-Authenticate = "Proxy-Authenticate" ":" OWS 238 Proxy-Authenticate-v 239 Proxy-Authenticate-v = 1#challenge 241 The HTTP access authentication process is described in "HTTP 242 Authentication: Basic and Digest Access Authentication" [RFC2617]. 243 Unlike WWW-Authenticate, the Proxy-Authenticate header field applies 244 only to the current connection and SHOULD NOT be passed on to 245 downstream clients. However, an intermediate proxy might need to 246 obtain its own credentials by requesting them from the downstream 247 client, which in some circumstances will appear as if the proxy is 248 forwarding the Proxy-Authenticate header field. 250 4.3. Proxy-Authorization 252 The request-header field "Proxy-Authorization" allows the client to 253 identify itself (or its user) to a proxy which requires 254 authentication. The Proxy-Authorization field value consists of 255 credentials containing the authentication information of the user 256 agent for the proxy and/or realm of the resource being requested. 258 Proxy-Authorization = "Proxy-Authorization" ":" OWS 259 Proxy-Authorization-v 260 Proxy-Authorization-v = credentials 262 The HTTP access authentication process is described in "HTTP 263 Authentication: Basic and Digest Access Authentication" [RFC2617]. 264 Unlike Authorization, the Proxy-Authorization header field applies 265 only to the next outbound proxy that demanded authentication using 266 the Proxy-Authenticate field. When multiple proxies are used in a 267 chain, the Proxy-Authorization header field is consumed by the first 268 outbound proxy that was expecting to receive credentials. A proxy 269 MAY relay the credentials from the client request to the next proxy 270 if that is the mechanism by which the proxies cooperatively 271 authenticate a given request. 273 4.4. WWW-Authenticate 275 The WWW-Authenticate response-header field MUST be included in 401 276 (Unauthorized) response messages. The field value consists of at 277 least one challenge that indicates the authentication scheme(s) and 278 parameters applicable to the Request-URI. 280 WWW-Authenticate = "WWW-Authenticate" ":" OWS WWW-Authenticate-v 281 WWW-Authenticate-v = 1#challenge 283 The HTTP access authentication process is described in "HTTP 284 Authentication: Basic and Digest Access Authentication" [RFC2617]. 285 User agents are advised to take special care in parsing the WWW- 286 Authenticate field value as it might contain more than one challenge, 287 or if more than one WWW-Authenticate header field is provided, the 288 contents of a challenge itself can contain a comma-separated list of 289 authentication parameters. 291 5. IANA Considerations 292 5.1. Message Header Registration 294 The Message Header Registry located at should be 296 updated with the permanent registrations below (see [RFC3864]): 298 +---------------------+----------+----------+-------------+ 299 | Header Field Name | Protocol | Status | Reference | 300 +---------------------+----------+----------+-------------+ 301 | Authorization | http | standard | Section 4.1 | 302 | Proxy-Authenticate | http | standard | Section 4.2 | 303 | Proxy-Authorization | http | standard | Section 4.3 | 304 | WWW-Authenticate | http | standard | Section 4.4 | 305 +---------------------+----------+----------+-------------+ 307 The change controller is: "IETF (iesg@ietf.org) - Internet 308 Engineering Task Force". 310 6. Security Considerations 312 This section is meant to inform application developers, information 313 providers, and users of the security limitations in HTTP/1.1 as 314 described by this document. The discussion does not include 315 definitive solutions to the problems revealed, though it does make 316 some suggestions for reducing security risks. 318 6.1. Authentication Credentials and Idle Clients 320 Existing HTTP clients and user agents typically retain authentication 321 information indefinitely. HTTP/1.1 does not provide a method for a 322 server to direct clients to discard these cached credentials. This 323 is a significant defect that requires further extensions to HTTP. 324 Circumstances under which credential caching can interfere with the 325 application's security model include but are not limited to: 327 o Clients which have been idle for an extended period following 328 which the server might wish to cause the client to reprompt the 329 user for credentials. 331 o Applications which include a session termination indication (such 332 as a `logout' or `commit' button on a page) after which the server 333 side of the application `knows' that there is no further reason 334 for the client to retain the credentials. 336 This is currently under separate study. There are a number of work- 337 arounds to parts of this problem, and we encourage the use of 338 password protection in screen savers, idle time-outs, and other 339 methods which mitigate the security problems inherent in this 340 problem. In particular, user agents which cache credentials are 341 encouraged to provide a readily accessible mechanism for discarding 342 cached credentials under user control. 344 7. Acknowledgments 346 [[anchor2: TBD.]] 348 8. References 350 8.1. Normative References 352 [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 353 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 354 and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, 355 and Message Parsing", draft-ietf-httpbis-p1-messaging-05 356 (work in progress), November 2008. 358 [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., 359 Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., 360 and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", 361 draft-ietf-httpbis-p6-cache-05 (work in progress), 362 November 2008. 364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 365 Requirement Levels", BCP 14, RFC 2119, March 1997. 367 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 368 Leach, P., Luotonen, A., and L. Stewart, "HTTP 369 Authentication: Basic and Digest Access Authentication", 370 RFC 2617, June 1999. 372 8.2. Informative References 374 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 375 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 376 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 378 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 379 Procedures for Message Header Fields", BCP 90, RFC 3864, 380 September 2004. 382 Appendix A. Compatibility with Previous Versions 384 A.1. Changes from RFC 2616 386 Appendix B. Change Log (to be removed by RFC Editor before publication) 388 B.1. Since RFC2616 390 Extracted relevant partitions from [RFC2616]. 392 B.2. Since draft-ietf-httpbis-p7-auth-00 394 Closed issues: 396 o : "Normative and 397 Informative references" 399 B.3. Since draft-ietf-httpbis-p7-auth-01 401 Ongoing work on ABNF conversion 402 (): 404 o Explicitly import BNF rules for "challenge" and "credentials" from 405 RFC2617. 407 o Add explicit references to BNF syntax and rules imported from 408 other parts of the specification. 410 B.4. Since draft-ietf-httpbis-p7-auth-02 412 Ongoing work on IANA Message Header Registration 413 (): 415 o Reference RFC 3984, and update header registrations for headers 416 defined in this document. 418 B.5. Since draft-ietf-httpbis-p7-auth-03 420 B.6. Since draft-ietf-httpbis-p7-auth-04 422 Ongoing work on ABNF conversion 423 (): 425 o Use "/" instead of "|" for alternatives. 427 o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional 428 whitespace ("OWS") and required whitespace ("RWS"). 430 o Rewrite ABNFs to spell out whitespace rules, factor out header 431 value format definitions. 433 Index 435 4 436 401 Unauthorized (status code) 5 437 407 Proxy Authentication Required (status code) 5 439 A 440 Authorization header 5 442 G 443 Grammar 444 Authorization 5 445 Authorization-v 5 446 challenge 4 447 credentials 4 448 Proxy-Authenticate 6 449 Proxy-Authenticate-v 6 450 Proxy-Authorization 7 451 Proxy-Authorization-v 7 452 WWW-Authenticate 7 453 WWW-Authenticate-v 7 455 H 456 Headers 457 Authorization 5 458 Proxy-Authenticate 6 459 Proxy-Authorization 7 460 WWW-Authenticate 7 462 P 463 Proxy-Authenticate header 6 464 Proxy-Authorization header 7 466 S 467 Status Codes 468 401 Unauthorized 5 469 407 Proxy Authentication Required 5 471 W 472 WWW-Authenticate header 7 474 Authors' Addresses 476 Roy T. Fielding (editor) 477 Day Software 478 23 Corporate Plaza DR, Suite 280 479 Newport Beach, CA 92660 480 USA 482 Phone: +1-949-706-5300 483 Fax: +1-949-706-5305 484 Email: fielding@gbiv.com 485 URI: http://roy.gbiv.com/ 487 Jim Gettys 488 One Laptop per Child 489 21 Oak Knoll Road 490 Carlisle, MA 01741 491 USA 493 Email: jg@laptop.org 494 URI: http://www.laptop.org/ 496 Jeffrey C. Mogul 497 Hewlett-Packard Company 498 HP Labs, Large Scale Systems Group 499 1501 Page Mill Road, MS 1177 500 Palo Alto, CA 94304 501 USA 503 Email: JeffMogul@acm.org 505 Henrik Frystyk Nielsen 506 Microsoft Corporation 507 1 Microsoft Way 508 Redmond, WA 98052 509 USA 511 Email: henrikn@microsoft.com 512 Larry Masinter 513 Adobe Systems, Incorporated 514 345 Park Ave 515 San Jose, CA 95110 516 USA 518 Email: LMM@acm.org 519 URI: http://larry.masinter.net/ 521 Paul J. Leach 522 Microsoft Corporation 523 1 Microsoft Way 524 Redmond, WA 98052 526 Email: paulle@microsoft.com 528 Tim Berners-Lee 529 World Wide Web Consortium 530 MIT Computer Science and Artificial Intelligence Laboratory 531 The Stata Center, Building 32 532 32 Vassar Street 533 Cambridge, MA 02139 534 USA 536 Email: timbl@w3.org 537 URI: http://www.w3.org/People/Berners-Lee/ 539 Yves Lafon (editor) 540 World Wide Web Consortium 541 W3C / ERCIM 542 2004, rte des Lucioles 543 Sophia-Antipolis, AM 06902 544 France 546 Email: ylafon@w3.org 547 URI: http://www.raubacapeu.net/people/yves/ 548 Julian F. Reschke (editor) 549 greenbytes GmbH 550 Hafenweg 16 551 Muenster, NW 48155 552 Germany 554 Phone: +49 251 2807760 555 Fax: +49 251 2807761 556 Email: julian.reschke@greenbytes.de 557 URI: http://greenbytes.de/tech/webdav/ 559 Full Copyright Statement 561 Copyright (C) The IETF Trust (2008). 563 This document is subject to the rights, licenses and restrictions 564 contained in BCP 78, and except as set forth therein, the authors 565 retain all their rights. 567 This document and the information contained herein are provided on an 568 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 569 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 570 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 571 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 572 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 573 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 575 Intellectual Property 577 The IETF takes no position regarding the validity or scope of any 578 Intellectual Property Rights or other rights that might be claimed to 579 pertain to the implementation or use of the technology described in 580 this document or the extent to which any license under such rights 581 might or might not be available; nor does it represent that it has 582 made any independent effort to identify any such rights. Information 583 on the procedures with respect to rights in RFC documents can be 584 found in BCP 78 and BCP 79. 586 Copies of IPR disclosures made to the IETF Secretariat and any 587 assurances of licenses to be made available, or the result of an 588 attempt made to obtain a general license or permission for the use of 589 such proprietary rights by implementers or users of this 590 specification can be obtained from the IETF on-line IPR repository at 591 http://www.ietf.org/ipr. 593 The IETF invites any interested party to bring to its attention any 594 copyrights, patents or patent applications, or other proprietary 595 rights that may cover technology that may be required to implement 596 this standard. Please address the information to the IETF at 597 ietf-ipr@ietf.org.