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