idnits 2.17.00 (12 Aug 2021) /tmp/idnits50715/draft-ietf-httpbis-security-properties-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 11, 2010) is 4447 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2145 (Obsoleted by RFC 7230) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265) -- Obsolete informational reference (is this intentional?): RFC 2109 (Obsoleted by RFC 2965) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hodges 3 Internet-Draft PayPal 4 Intended status: Informational B. Leiba 5 Expires: September 12, 2010 Huawei Technologies 6 March 11, 2010 8 Security Requirements for HTTP 9 draft-ietf-httpbis-security-properties-05 11 Abstract 13 Recent IESG practice dictates that IETF protocols must specify 14 mandatory-to-implement (MTI) security mechanisms, so that all 15 conformant implementations share a common baseline. This document 16 examines all widely deployed HTTP security technologies, and analyzes 17 the trade-offs of each. 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on September 12, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Existing HTTP Security Mechanisms . . . . . . . . . . . . . . 3 73 2.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 4 74 2.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 5 75 2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 6 76 2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 6 77 2.2.3. Authentication Using Certificates in TLS . . . . . . . 7 78 2.2.4. Other Access Authentication Schemes . . . . . . . . . 7 79 2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 8 80 2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 8 81 2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 9 82 3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 9 83 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 85 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 87 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 88 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 89 Appendix B. Document History . . . . . . . . . . . . . . . . . . 11 90 B.1. Changes between draft-sayre-http-security-variance-00 91 and draft-ietf-httpbis-security-properties-00 . . . . . . 11 92 B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 11 93 B.3. Changes between -01 and -02 . . . . . . . . . . . . . . . 12 94 B.4. Changes between -02 and -03 . . . . . . . . . . . . . . . 12 95 B.5. Changes between -03 and -04 . . . . . . . . . . . . . . . 12 96 B.6. Changes between -04 and -05 . . . . . . . . . . . . . . . 13 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 99 1. Introduction 101 Recent IESG practice dictates that IETF protocols be required to 102 specify mandatory-to-implement (MTI) security mechanisms. "The IETF 103 Standards Process" [RFC2026] does not require that protocols specify 104 mandatory security mechanisms. "Strong Security Requirements for 105 IETF Standard Protocols" [RFC3365] requires that all IETF protocols 106 provide a mechanism for implementers to provide strong security. RFC 107 3365 does not define the term "strong security". 109 "Security Mechanisms for the Internet" [RFC3631] is not an IETF 110 procedural RFC, but it is perhaps most relevant. Section 2.2 states: 112 We have evolved in the IETF the notion of "mandatory to implement" 113 mechanisms. This philosophy evolves from our primary desire to 114 ensure interoperability between different implementations of a 115 protocol. If a protocol offers many options for how to perform a 116 particular task, but fails to provide for at least one that all 117 must implement, it may be possible that multiple, non-interoperable 118 implementations may result. This is the consequence of the 119 selection of non-overlapping mechanisms being deployed in the 120 different implementations. 122 This document examines the effects of applying security constraints 123 to Web applications, documents the properties that result from each 124 method, and will make Best Current Practice recommendations for HTTP 125 security in a later document version. At the moment, it is mostly a 126 laundry list of security technologies and tradeoffs. 128 [[ OVERALL ISSUE: It isn't entirely clear to the present editors what 129 the purpose of this document is. On one hand it could be a 130 compendium of peer-entity authentication mechanisms (as it is 131 presently) and make MTI recommendations thereof, or it could be a 132 place for various security considerations (either coalesced here from 133 the other httpbis specs, or reserved for the more gnarly cross-spec 134 composite ones), or both. This needs to be clarified. ]] 136 2. Existing HTTP Security Mechanisms 138 For HTTP, the IETF generally defines "security mechanisms" as some 139 combination of access authentication and/or a secure transport. 141 [[ There is a suggestion that this section be split into "browser- 142 like" and "automation-like" subsections. See: 144 http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/ 145 0180.html 146 http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/ 147 0183.html 149 ]] 151 [[ NTLM (shudder) was brought up in the WG a few times in the 152 discussion of the -00 draft. Should we add a section on it? See.. 154 http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/ 155 0132.html 157 http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/ 158 0135.html 160 ]] 162 2.1. Forms And Cookies 164 [[ JH: I am not convinced that this subsection properly belongs in 165 this overall section in that "HTTP+HTML Form based authentication" 166 167 is not properly a part of HTTP itself. Rather, it is a piece of 168 applications layered on top of HTTP. Use of cookies for state 169 management (e.g. session maintanence) can be considered such, however 170 (although there is no overall specification for HTTP user agents 171 stipulating that they must implement cookies (nominally [RFC2109])). 172 Perhaps this section should be should be retitled "HTTP 173 Authentication". 175 Note: The httpstate WG was recently chartered to develop a successor 176 to [RFC2109]. See.. 178 http://www.ietf.org/dyn/wg/charter/httpstate-charter.html 180 ]] 182 Almost all HTTP authentication that involves a human using a web 183 browser is accomplished through HTML forms, with session identifiers 184 stored in cookies. For cookies, most implementations rely on the 185 "Netscape specification", which is described loosely in section 10 of 186 "HTTP State Management Mechanism" [RFC2109]. The protocol in RFC 187 2109 is relatively widely implemented, but most clients don't 188 advertise support for it. RFC 2109 was later updated [RFC2965], but 189 the newer version is not widely implemented. 191 Forms and cookies have many properties that make them an excellent 192 solution for some implementers. However, many of those properties 193 introduce serious security trade-offs. 195 HTML forms provide a large degree of control over presentation, which 196 is an imperative for many websites. However, this increases user 197 reliance on the appearance of the interface. Many users do not 198 understand the construction of URIs [RFC3986], or their presentation 199 in common clients [PhishingHOWTO]. As a result, forms are extremely 200 vulnerable to spoofing. 202 HTML forms provide acceptable internationalization if used carefully, 203 at the cost of being transmitted as normal HTTP content in all cases 204 (credentials are not differentiated in the protocol). 206 Many Web browsers have an auto-complete feature that stores a user's 207 information and pre-populates fields in forms. This is considered to 208 be a convenience mechanism, and convenience mechanisms often have 209 negative security properties. The security concerns with auto- 210 completion are particularly poignant for web browsers that reside on 211 computers with multiple users. HTML forms provide a facility for 212 sites to indicate that a field, such as a password, should never be 213 pre-populated. However, it is clear that some form creators do not 214 use this facility when they should. 216 The cookies that result from a successful form submission make it 217 unnecessary to validate credentials with each HTTP request; this 218 makes cookies an excellent property for scalability. Cookies are 219 susceptible to a large variety of XSS (cross-site scripting) attacks, 220 and measures to prevent such attacks will never be as stringent as 221 necessary for authentication credentials because cookies are used for 222 many purposes. Cookies are also susceptible to a wide variety of 223 attacks from malicious intermediaries and observers. The possible 224 attacks depend on the contents of the cookie data. There is no 225 standard format for most of the data. 227 HTML forms and cookies provide flexible ways of ending a session from 228 the client. 230 HTML forms require an HTML rendering engine for which many protocols 231 have no use. 233 2.2. HTTP Access Authentication 235 HTTP 1.1 provides a simple authentication framework, "HTTP 236 Authentication: Basic and Digest Access Authentication" [RFC2617], 237 which defines two optional mechanisms. Both of these mechanisms are 238 extremely rarely used in comparison to forms and cookies, but some 239 degree of support for one or both is available in many 240 implementations. Neither scheme provides presentation control, 241 logout capabilities, or interoperable internationalization. 243 2.2.1. Basic Authentication 245 Basic Authentication (normally called just "Basic") transmits 246 usernames and passwords in the clear. It is very easy to implement, 247 but not at all secure unless used over a secure transport. 249 Basic has very poor scalability properties because credentials must 250 be revalidated with every request, and because secure transports 251 negate many of HTTP's caching mechanisms. Some implementations use 252 cookies in combination with Basic credentials, but there is no 253 standard method of doing so. 255 Since Basic credentials are clear text, they are reusable by any 256 party. This makes them compatible with any authentication database, 257 at the cost of making the user vulnerable to mismanaged or malicious 258 servers, even over a secure channel. 260 Basic is not interoperable when used with credentials that contain 261 characters outside of the ISO 8859-1 repertoire. 263 2.2.2. Digest Authentication 265 In Digest Authentication, the client transmits the results of hashing 266 user credentials with properties of the request and values from the 267 server challenge. Digest is susceptible to man-in-the-middle attacks 268 when not used over a secure transport. 270 Digest has some properties that are preferable to Basic and Cookies. 271 Credentials are not immediately reusable by parties that observe or 272 receive them, and session data can be transmitted alongside 273 credentials with each request, allowing servers to validate 274 credentials only when absolutely necessary. Authentication data 275 session keys are distinct from other protocol traffic. 277 Digest includes many modes of operation, but only the simplest modes 278 enjoy any degree of interoperability. For example, most 279 implementations do not implement the mode that provides full message 280 integrity. Perhaps one reason is that implementation experience has 281 shown that in some cases, especially those involving large requests 282 or responses such as streams, the message integrity mode is 283 impractical because it requires servers to analyze the full request 284 before determining whether the client knows the shared secret or 285 whether message-body integrity has been violated and hence whether 286 the request can be processed. 288 Digest is extremely susceptible to offline dictionary attacks, making 289 it practical for attackers to perform a namespace walk consisting of 290 a few million passwords for most users. 292 Many of the most widely-deployed HTTP/1.1 clients are not compliant 293 when GET requests include a query string [Apache_Digest]. 295 Digest either requires that authentication databases be expressly 296 designed to accommodate it, or requires access to cleartext 297 passwords. As a result, many authentication databases that chose to 298 do the former are incompatible, including the most common method of 299 storing passwords for use with Forms and Cookies. 301 Many Digest capabilities included to prevent replay attacks expose 302 the server to Denial of Service attacks. 304 Digest is not interoperable when used with credentials that contain 305 characters outside of the ISO 8859-1 repertoire. 307 2.2.3. Authentication Using Certificates in TLS 309 Running HTTP over TLS provides authentication of the HTTP server to 310 the client. HTTP over TLS can also provides authentication of the 311 client to the server using certificates. Although forms are a much 312 more common way to authenticate users to HTTP servers, TLS client 313 certificates are widely used in some environments. The public key 314 infrastructure (PKI) used to validate certificates in TLS can be 315 rooted in public trust anchors or can be based on local trust 316 anchors. 318 2.2.4. Other Access Authentication Schemes 320 There are many niche schemes that make use of the HTTP Authentication 321 framework, but very few are well documented. Some are bound to 322 transport layer connections. 324 2.2.4.1. Negotiate (GSS-API) Authentication 326 Microsoft has designed an HTTP authentication mechanism that utilizes 327 SPNEGO [RFC4178] GSSAPI [RFC4559]. In Microsoft's implementation, 328 SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan 329 Manager protocols). 331 In Kerberos, clients and servers rely on a trusted third-party 332 authentication service which maintains its own authentication 333 database. Kerberos is typically used with shared secret key 334 cryptography, but extensions for use of other authentication 335 mechnanisms such as PKIX certificates and two-factor tokens are also 336 common. Kerberos was designed to work under the assumption that 337 packets traveling along the network can be read, modified, and 338 inserted at will. 340 Unlike Digest, Negotiate authentication can take multiple round trips 341 (client sending authentication data in Authorization, server sending 342 authentication data in WWW-Authenticate) to complete. 344 Kerberos authentication is generally more secure than Digest. 345 However the requirement for having a separate network authentication 346 service might be a barrier to deployment. 348 2.2.4.2. OAuth 350 [[ See.. 352 http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt 354 http://www.ietf.org/id/draft-hammer-oauth-10.txt 356 ]] 358 2.3. Centrally-Issued Tickets 360 Many large Internet services rely on authentication schemes that 361 center on clients consulting a single service for a time-limited 362 ticket that is validated with undocumented heuristics. Centralized 363 ticket issuing has the advantage that users may employ one set of 364 credentials for many services, and clients don't send credentials to 365 many servers. This approach is often no more than a sophisticated 366 application of forms and cookies. 368 All of the schemes in wide use are proprietary and non-standard, and 369 usually are undocumented. There are many standardization efforts in 370 progress, as usual. 372 2.4. Web Services 374 Many security properties mentioned in this document have been recast 375 in XML-based protocols, using HTTP as a substitute for TCP. Like the 376 amalgam of HTTP technologies mentioned above, the XML-based protocols 377 are defined by an ever-changing combination of standard and vendor- 378 produced specifications, some of which may be obsoleted at any time 379 [WS-Pagecount] without any documented change control procedures. 380 These protocols usually don't have much in common with the 381 Architecture of the World Wide Web. It's not clear why the term "Web" 382 is used to group them, but they are obviously out of scope for HTTP- 383 based application protocols. 385 [[ This section could really use a good definition of "Web Services" 386 to differentiate it from REST. See.. 388 http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/ 389 0536.html 391 ]] 393 2.5. Transport Layer Security 395 In addition to using TLS for client and/or server authentication, it 396 is also very commonly used to protect the confidentiality and 397 integrity of the HTTP session. For instance, both HTTP Basic 398 authentication and Cookies are often protected against snooping by 399 TLS. 401 It should be noted that, in that case, TLS does not protect against a 402 breach of the credential store at the server or against a keylogger 403 or phishing interface at the client. TLS does not change the fact 404 that Basic Authentication passwords are reusable and does not address 405 that weakness. 407 3. Revisions To HTTP 409 Is is possible that HTTP will be revised in the future. "HTTP/1.1" 410 [RFC2616] and "Use and Interpretation of HTTP Version Numbers" 411 [RFC2145] define conformance requirements in relation to version 412 numbers. In HTTP 1.1, all authentication mechanisms are optional, 413 and no single transport substrate is specified. Any HTTP revision 414 that adds a mandatory security mechanism or transport substrate will 415 have to increment the HTTP version number appropriately. All widely 416 used schemes are non-standard and/or proprietary. 418 4. IANA Considerations 420 This document has no actions for IANA. 422 5. Security Considerations 424 This entire document is about security considerations. 426 6. References 428 6.1. Normative References 430 [Apache_Digest] 431 Apache Software Foundation, "Apache HTTP Server - 432 mod_auth_digest", . 435 [PhishingHOWTO] 436 Gutmann, P., "Phishing Tips and Techniques", 437 February 2008, 438 . 440 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 441 3", BCP 9, RFC 2026, October 1996. 443 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use 444 and Interpretation of HTTP Version Numbers", RFC 2145, 445 May 1997. 447 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 448 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 449 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 451 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 452 Leach, P., Luotonen, A., and L. Stewart, "HTTP 453 Authentication: Basic and Digest Access Authentication", 454 RFC 2617, June 1999. 456 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 457 Mechanism", RFC 2965, October 2000. 459 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 460 Engineering Task Force Standard Protocols", BCP 61, 461 RFC 3365, August 2002. 463 [RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security 464 Mechanisms for the Internet", RFC 3631, December 2003. 466 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 467 Resource Identifier (URI): Generic Syntax", STD 66, 468 RFC 3986, January 2005. 470 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 471 Simple and Protected Generic Security Service Application 472 Program Interface (GSS-API) Negotiation Mechanism", 473 RFC 4178, October 2005. 475 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 476 Kerberos and NTLM HTTP Authentication in Microsoft 477 Windows", RFC 4559, June 2006. 479 [WS-Pagecount] 480 Bray, T., "WS-Pagecount", September 2004, . 483 6.2. Informative References 485 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 486 Mechanism", RFC 2109, February 1997. 488 Appendix A. Acknowledgements 490 Much of the material in this document was written by Rob Sayre, who 491 first promoted the topic. Many others on the HTTPbis Working Group 492 have contributed to this document in the discussion. 494 Appendix B. Document History 496 [This entire section is to be removed when published as an RFC.] 498 B.1. Changes between draft-sayre-http-security-variance-00 and 499 draft-ietf-httpbis-security-properties-00 501 Changed the authors to Paul Hoffman and Alexey Melnikov, with 502 permission of Rob Sayre. 504 Made lots of minor editorial changes. 506 Removed what was section 2 (Requirements Notation), the reference to 507 RFC 2119, and any use of 2119ish all-caps words. 509 In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 510 repertoire" to match the definition of "TEXT" in RFC 2616. 512 Added minor text to the Security Considerations section. 514 Added URLs to the two non-RFC references. 516 B.2. Changes between -00 and -01 518 Fixed some editorial nits reported by Iain Calder. 520 Added the suggestions about splitting for browsers and automation, 521 and about adding NTLM, to be beginning of 2. 523 In 2.1, added "that involves a human using a web browser" in the 524 first sentence. 526 In 2.1, changed "session key" to "session identifier". 528 In 2.2.2, changed 530 Digest includes many modes of operation, but only the simplest modes 531 enjoy any degree of interoperability. For example, most 532 implementations do not implement the mode that provides full message 533 integrity. Additionally, implementation experience has shown that 534 the message integrity mode is impractical because it requires servers 535 to analyze the full request before determining whether the client 536 knows the shared secret. 538 to 540 Digest includes many modes of operation, but only the simplest 541 modes enjoy any degree of interoperability. For example, most 542 implementations do not implement the mode that provides full message 543 integrity. Perhaps one reason is that implementation experience has 544 shown that in some cases, especially those involving large requests 545 or responses such as streams, the message integrity mode is 546 impractical because it requires servers to analyze the full request 547 before determining whether the client knows the shared secret or 548 whether message-body integrity has been violated and hence whether 549 the request can be processed. 551 In 2.4, asked for a definition of "Web Services". 553 In A, added the WG. 555 B.3. Changes between -01 and -02 557 In section 2.1, added more to the paragraph on auto-completion of 558 HTML forms. 560 Added the section on TLS for authentication. 562 Filled in section 2.5. 564 B.4. Changes between -02 and -03 566 Changed IPR licensing from "full3978" to "pre5378Trust200902". 568 B.5. Changes between -03 and -04 570 Changed authors to be Jeff Hodges (JH) and Barry Leiba (BL) with 571 permission of Paul Hoffman, Alexey Melnikov, and Mark Nottingham 572 (httpbis chair). 574 Added "OVERALL ISSUE" to introduction. 576 Added links to email messages on mailing list(s) where various 577 suggestions for this document were brought up. I.e. added various 578 links to those comments herein delimited by "[[...]]" braces. 580 Noted JH's belief that "HTTP+HTML Form based authentication" aka 581 "Forms And Cookies" doesn't properly belong in the section where it 582 presently resides. Added link to httpstate WG. 584 Added references to OAuth. Section needs to be filled-in as yet. 586 Moved ref to RFC2109 to new "Informative References" section, and 587 added a placeholder "IANA Considerations" section in order to satisfy 588 IDnits checking. 590 B.6. Changes between -04 and -05 592 Fixed incorrect year from 2009 to 2010. mea culpa. 594 Authors' Addresses 596 Jeff Hodges 597 PayPal 599 Email: Jeff.Hodges@PayPal.com 601 Barry Leiba 602 Huawei Technologies 604 Phone: +1 646 827 0648 605 Email: barryleiba@computer.org 606 URI: http://internetmessagingtechnology.org/