Changeset 2726 for draft-ietf-httpbis-security-properties/04
- Timestamp:
- 14/06/14 11:20:37 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis-security-properties/04/draft-ietf-httpbis-security-properties-04.html
r788 r2726 2 2 PUBLIC "-//W3C//DTD HTML 4.01//EN"> 3 3 <html lang="en"> 4 <head profile="http:// www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">4 <head profile="http://dublincore.org/documents/2008/08/04/dc-html/"> 5 5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> 6 6 <title>Security Requirements for HTTP</title><style type="text/css" title="Xml2Rfc (sans serif)"> … … 24 24 body { 25 25 color: black; 26 font-family: verdana, helvetica, arial, sans-serif; 27 font-size: 10pt; 26 font-family: cambria, helvetica, arial, sans-serif; 27 font-size: 11pt; 28 margin-right: 2em; 28 29 } 29 30 cite { 30 31 font-style: normal; 31 32 } 32 dd {33 margin-right: 2em;34 }35 33 dl { 36 34 margin-left: 2em; 37 35 } 38 39 36 ul.empty { 40 37 list-style-type: none; … … 50 47 } 51 48 h1 { 52 font-size: 1 4pt;49 font-size: 130%; 53 50 line-height: 21pt; 54 51 page-break-after: avoid; … … 57 54 page-break-before: always; 58 55 } 59 h1 a {60 color: #333333;61 }62 56 h2 { 63 font-size: 12 pt;57 font-size: 120%; 64 58 line-height: 15pt; 65 59 page-break-after: avoid; 66 60 } 67 h3 , h4, h5, h6{68 font-size: 1 0pt;61 h3 { 62 font-size: 110%; 69 63 page-break-after: avoid; 70 64 } 71 h2 a, h3 a, h4 a, h5 a, h6 a { 65 h4, h5, h6 { 66 page-break-after: avoid; 67 } 68 h1 a, h2 a, h3 a, h4 a, h5 a, h6 a { 72 69 color: black; 73 70 } … … 77 74 li { 78 75 margin-left: 2em; 79 margin-right: 2em;80 76 } 81 77 ol { 82 78 margin-left: 2em; 83 margin-right: 2em; 79 } 80 ol.la { 81 list-style-type: lower-alpha; 82 } 83 ol.ua { 84 list-style-type: upper-alpha; 84 85 } 85 86 ol p { … … 88 89 p { 89 90 margin-left: 2em; 90 margin-right: 2em;91 91 } 92 92 pre { … … 94 94 background-color: lightyellow; 95 95 padding: .25em; 96 page-break-inside: avoid; 96 97 } 97 98 pre.text2 { … … 123 124 border-spacing: 1px; 124 125 width: 95%; 125 font-size: 1 0pt;126 font-size: 11pt; 126 127 color: white; 127 128 } … … 131 132 td.topnowrap { 132 133 vertical-align: top; 133 white-space: nowrap; 134 white-space: nowrap; 134 135 } 135 136 table.header td { … … 145 146 display:table-header-group; 146 147 } 147 ul.toc {148 ul.toc, ul.toc ul { 148 149 list-style: none; 149 150 margin-left: 1.5em; 150 margin-right: 0em;151 151 padding-left: 0em; 152 152 } 153 li.tocline0{153 ul.toc li { 154 154 line-height: 150%; 155 155 font-weight: bold; 156 margin-left: 0em; 157 } 158 ul.toc li li { 159 line-height: normal; 160 font-weight: normal; 156 161 font-size: 10pt; 157 162 margin-left: 0em; 158 margin-right: 0em; 159 } 160 li.tocline1 { 161 line-height: normal; 162 font-weight: normal; 163 font-size: 9pt; 164 margin-left: 0em; 165 margin-right: 0em; 166 } 167 li.tocline2 { 163 } 164 li.excluded { 168 165 font-size: 0pt; 169 166 } 170 167 ul p { 171 168 margin-left: 0em; 169 } 170 .title, .filename, h1, h2, h3, h4 { 171 font-family: candara, helvetica, arial, sans-serif; 172 } 173 samp, tt, code, pre { 174 font: consolas, monospace; 172 175 } 173 176 … … 186 189 font-weight: bold; 187 190 text-align: center; 188 font-size: 9pt;191 font-size: 10pt; 189 192 } 190 193 .filename { 191 194 color: #333333; 195 font-size: 75%; 192 196 font-weight: bold; 193 font-size: 12pt;194 197 line-height: 21pt; 195 198 text-align: center; … … 198 201 font-weight: bold; 199 202 } 200 .hidden {201 display: none;202 }203 203 .left { 204 204 text-align: left; … … 208 208 } 209 209 .title { 210 color: #990000;211 font-size: 1 8pt;210 color: green; 211 font-size: 150%; 212 212 line-height: 18pt; 213 213 font-weight: bold; … … 215 215 margin-top: 36pt; 216 216 } 217 .vcardline {218 display: block;219 }220 217 .warning { 221 font-size: 1 4pt;218 font-size: 130%; 222 219 background-color: yellow; 223 220 } … … 228 225 display: none; 229 226 } 230 227 231 228 a { 232 229 color: black; … … 243 240 background-color: white; 244 241 vertical-align: top; 245 font-size: 1 2pt;246 } 247 248 ul.toc a: :after {242 font-size: 110%; 243 } 244 245 ul.toc a:nth-child(2)::after { 249 246 content: leader('.') target-counter(attr(href), page); 250 247 } 251 252 a.iref{248 249 ul.ind li li a { 253 250 content: target-counter(attr(href), page); 254 251 } 255 252 256 253 .print2col { 257 254 column-count: 2; … … 263 260 @page { 264 261 @top-left { 265 content: "Internet-Draft"; 266 } 262 content: "Internet-Draft"; 263 } 267 264 @top-right { 268 content: "March 2009"; 269 } 265 content: "March 2009"; 266 } 270 267 @top-center { 271 content: "Security Requirements for HTTP"; 272 } 268 content: "Security Requirements for HTTP"; 269 } 273 270 @bottom-left { 274 content: "Hodges & Leiba"; 275 } 271 content: "Hodges & Leiba"; 272 } 276 273 @bottom-center { 277 content: " Informational";278 } 274 content: "Expires September 2009"; 275 } 279 276 @bottom-right { 280 content: "[Page " counter(page) "]"; 281 } 282 } 283 284 @page:first { 277 content: "[Page " counter(page) "]"; 278 } 279 } 280 281 @page:first { 285 282 @top-left { 286 283 content: normal; … … 303 300 <link rel="Appendix" title="A Acknowledgements" href="#rfc.section.A"> 304 301 <link rel="Appendix" title="B Document History" href="#rfc.section.B"> 305 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1. 510, 2010-02-20 17:14:25, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">302 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.640, 2014/06/13 12:42:58, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 306 303 <link rel="schema.dct" href="http://purl.org/dc/terms/"> 307 304 <meta name="dct.creator" content="Hodges, J."> … … 338 335 </table> 339 336 <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-04</span></p> 340 <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1> 341 <p>This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain 342 material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) 343 controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of 344 such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the 345 copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of 346 it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it 347 into languages other than English. 348 </p> 349 <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note 350 that other groups may also distribute working documents as Internet-Drafts. 351 </p> 352 <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other 353 documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work 354 in progress”. 355 </p> 356 <p>The list of current Internet-Drafts can be accessed at <a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>. 357 </p> 358 <p>The list of Internet-Draft Shadow Directories can be accessed at <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>. 359 </p> 360 <p>This Internet-Draft will expire in September 2009.</p> 361 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 362 <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 363 <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date 364 of publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 365 </p> 366 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 337 <div id="rfc.status"> 338 <h1><a href="#rfc.status">Status of this Memo</a></h1> 339 <p>This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain 340 material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) 341 controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of 342 such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the 343 copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of 344 it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it 345 into languages other than English. 346 </p> 347 <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note 348 that other groups may also distribute working documents as Internet-Drafts. 349 </p> 350 <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other 351 documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work 352 in progress”. 353 </p> 354 <p>The list of current Internet-Drafts can be accessed at <a href="http://www.ietf.org/ietf/1id-abstracts.txt">http://www.ietf.org/ietf/1id-abstracts.txt</a>. 355 </p> 356 <p>The list of Internet-Draft Shadow Directories can be accessed at <a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>. 357 </p> 358 <p>This Internet-Draft will expire in September 2009.</p> 359 </div> 360 <div id="rfc.copyrightnotice"> 361 <h1><a href="#rfc.copyrightnotice">Copyright Notice</a></h1> 362 <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p> 363 <p>This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date 364 of publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 365 </p> 366 </div> 367 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 367 368 <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement (MTI) security mechanisms, so that all 368 369 conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, 369 370 and analyzes the trade-offs of each. 370 </p>371 <hr class="noprint">372 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> Introduction373 </h1>374 <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols be required to specify mandatory-to-implement (MTI) security mechanisms.375 "The IETF Standards Process" <a href="#RFC2026"><cite title="The Internet Standards Process -- Revision 3">[RFC2026]</cite></a> does not require that protocols specify mandatory security mechanisms. "Strong Security Requirements for IETF Standard Protocols" <a href="#RFC3365"><cite title="Strong Security Requirements for Internet Engineering Task Force Standard Protocols">[RFC3365]</cite></a> requires that all IETF protocols provide a mechanism for implementers to provide strong security. RFC 3365 does not define376 the term "strong security".377 371 </p> 378 <p id="rfc.section.1.p.2">"Security Mechanisms for the Internet" <a href="#RFC3631"><cite title="Security Mechanisms for the Internet">[RFC3631]</cite></a> is not an IETF procedural RFC, but it is perhaps most relevant. Section 2.2 states: 379 </p> 380 <div id="rfc.figure.u.1"></div> <pre> 372 <hr class="noprint"> 373 <div> 374 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> Introduction 375 </h1> 376 <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols be required to specify mandatory-to-implement (MTI) security mechanisms. 377 "The IETF Standards Process" <a href="#RFC2026"><cite title="The Internet Standards Process -- Revision 3">[RFC2026]</cite></a> does not require that protocols specify mandatory security mechanisms. "Strong Security Requirements for IETF Standard Protocols" <a href="#RFC3365"><cite title="Strong Security Requirements for Internet Engineering Task Force Standard Protocols">[RFC3365]</cite></a> requires that all IETF protocols provide a mechanism for implementers to provide strong security. RFC 3365 does not define 378 the term "strong security". 379 </p> 380 <p id="rfc.section.1.p.2">"Security Mechanisms for the Internet" <a href="#RFC3631"><cite title="Security Mechanisms for the Internet">[RFC3631]</cite></a> is not an IETF procedural RFC, but it is perhaps most relevant. Section 2.2 states: 381 </p> 382 <div id="rfc.figure.u.1"></div><pre> 381 383 We have evolved in the IETF the notion of "mandatory to implement" 382 384 mechanisms. This philosophy evolves from our primary desire to … … 388 390 selection of non-overlapping mechanisms being deployed in the 389 391 different implementations. 390 </pre> <p id="rfc.section.1.p.4">This document examines the effects of applying security constraints to Web applications, documents the properties that result 391 from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the 392 moment, it is mostly a laundry list of security technologies and tradeoffs. 393 </p> 394 <p id="rfc.section.1.p.5">[[ OVERALL ISSUE: It isn't entirely clear to the present editors what the purpose of this document is. On one hand it could 395 be a compendium of peer-entity authentication mechanisms (as it is presently) and make MTI recommendations thereof, or it 396 could be a place for various security considerations (either coalesced here from the other httpbis specs, or reserved for 397 the more gnarly cross-spec composite ones), or both. This needs to be clarified. ]] 398 </p> 399 <hr class="noprint"> 400 <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a> Existing HTTP Security Mechanisms 401 </h1> 402 <p id="rfc.section.2.p.1">For HTTP, the IETF generally defines "security mechanisms" as some combination of access authentication and/or a secure transport.</p> 403 <p id="rfc.section.2.p.2">[[ There is a suggestion that this section be split into "browser-like" and "automation-like" subsections. See: </p> 404 <ul class="empty"> 405 <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0180.html</li> 406 <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0183.html</li> 407 </ul> 408 <p> ]]</p> 409 <p id="rfc.section.2.p.3">[[ NTLM (shudder) was brought up in the WG a few times in the discussion of the -00 draft. Should we add a section on it? 410 See.. 411 </p> 412 <ul class="empty"> 413 <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0132.html</li> 414 <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0135.html</li> 415 </ul> 416 <p> ]]</p> 417 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> Forms And Cookies 418 </h2> 419 <p id="rfc.section.2.1.p.1">[[ JH: I am not convinced that this subsection properly belongs in this overall section in that "HTTP+HTML Form based authentication" 420 <http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication> is not properly a part of HTTP itself. Rather, it is 421 a piece of applications layered on top of HTTP. Use of cookies for state management (e.g. session maintanence) can be considered 422 such, however (although there is no overall specification for HTTP user agents stipulating that they must implement cookies 423 (nominally <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>)). Perhaps this section should be should be retitled "HTTP Authentication". 424 </p> 425 <p id="rfc.section.2.1.p.2">Note: The httpstate WG was recently chartered to develop a successor to <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>. See.. 426 </p> 427 <ul class="empty"> 428 <li>http://www.ietf.org/dyn/wg/charter/httpstate-charter.html</li> 429 </ul> 430 <p id="rfc.section.2.1.p.3">]]</p> 431 <p id="rfc.section.2.1.p.4">Almost all HTTP authentication that involves a human using a web browser is accomplished through HTML forms, with session 432 identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described 433 loosely in section 10 of "HTTP State Management Mechanism" <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>. The protocol in RFC 2109 is relatively widely implemented, but most clients don't advertise support for it. RFC 2109 was 434 later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented. 435 </p> 436 <p id="rfc.section.2.1.p.5">Forms and cookies have many properties that make them an excellent solution for some implementers. However, many of those 437 properties introduce serious security trade-offs. 438 </p> 439 <p id="rfc.section.2.1.p.6">HTML forms provide a large degree of control over presentation, which is an imperative for many websites. However, this increases 440 user reliance on the appearance of the interface. Many users do not understand the construction of URIs <a href="#RFC3986"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, or their presentation in common clients <a href="#PhishingHOWTO"><cite title="Phishing Tips and Techniques">[PhishingHOWTO]</cite></a>. As a result, forms are extremely vulnerable to spoofing. 441 </p> 442 <p id="rfc.section.2.1.p.7">HTML forms provide acceptable internationalization if used carefully, at the cost of being transmitted as normal HTTP content 443 in all cases (credentials are not differentiated in the protocol). 444 </p> 445 <p id="rfc.section.2.1.p.8">Many Web browsers have an auto-complete feature that stores a user's information and pre-populates fields in forms. This is 446 considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security 447 concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML 448 forms provide a facility for sites to indicate that a field, such as a password, should never be pre-populated. However, it 449 is clear that some form creators do not use this facility when they should. 450 </p> 451 <p id="rfc.section.2.1.p.9">The cookies that result from a successful form submission make it unnecessary to validate credentials with each HTTP request; 452 this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting) 453 attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because 454 cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries 455 and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the 456 data. 457 </p> 458 <p id="rfc.section.2.1.p.10">HTML forms and cookies provide flexible ways of ending a session from the client.</p> 459 <p id="rfc.section.2.1.p.11">HTML forms require an HTML rendering engine for which many protocols have no use.</p> 460 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> HTTP Access Authentication 461 </h2> 462 <p id="rfc.section.2.2.p.1">HTTP 1.1 provides a simple authentication framework, "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, which defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies, 463 but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control, 464 logout capabilities, or interoperable internationalization. 465 </p> 466 <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a> Basic Authentication 467 </h3> 468 <p id="rfc.section.2.2.1.p.1">Basic Authentication (normally called just "Basic") transmits usernames and passwords in the clear. It is very easy to implement, 469 but not at all secure unless used over a secure transport. 470 </p> 471 <p id="rfc.section.2.2.1.p.2">Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure 472 transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials, 473 but there is no standard method of doing so. 474 </p> 475 <p id="rfc.section.2.2.1.p.3">Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication 476 database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel. 477 </p> 478 <p id="rfc.section.2.2.1.p.4">Basic is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p> 479 <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a> Digest Authentication 480 </h3> 481 <p id="rfc.section.2.2.2.p.1">In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and 482 values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport. 483 </p> 484 <p id="rfc.section.2.2.2.p.2">Digest has some properties that are preferable to Basic and Cookies. Credentials are not immediately reusable by parties that 485 observe or receive them, and session data can be transmitted alongside credentials with each request, allowing servers to 486 validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic. 487 </p> 488 <p id="rfc.section.2.2.2.p.3">Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most 489 implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation 490 experience has shown that in some cases, especially those involving large requests or responses such as streams, the message 491 integrity mode is impractical because it requires servers to analyze the full request before determining whether the client 492 knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed. 493 </p> 494 <p id="rfc.section.2.2.2.p.4">Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk 495 consisting of a few million passwords for most users. 496 </p> 497 <p id="rfc.section.2.2.2.p.5">Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string <a href="#Apache_Digest"><cite title="Apache HTTP Server - mod_auth_digest">[Apache_Digest]</cite></a>. 498 </p> 499 <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accommodate it, or requires access to cleartext 500 passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common 501 method of storing passwords for use with Forms and Cookies. 502 </p> 503 <p id="rfc.section.2.2.2.p.7">Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks.</p> 504 <p id="rfc.section.2.2.2.p.8">Digest is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p> 505 <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a> Authentication Using Certificates in TLS 506 </h3> 507 <p id="rfc.section.2.2.3.p.1">Running HTTP over TLS provides authentication of the HTTP server to the client. HTTP over TLS can also provides authentication 508 of the client to the server using certificates. Although forms are a much more common way to authenticate users to HTTP servers, 509 TLS client certificates are widely used in some environments. The public key infrastructure (PKI) used to validate certificates 510 in TLS can be rooted in public trust anchors or can be based on local trust anchors. 511 </p> 512 <h3 id="rfc.section.2.2.4"><a href="#rfc.section.2.2.4">2.2.4</a> Other Access Authentication Schemes 513 </h3> 514 <p id="rfc.section.2.2.4.p.1">There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are 515 bound to transport layer connections. 516 </p> 517 <h4 id="rfc.section.2.2.4.1"><a href="#rfc.section.2.2.4.1">2.2.4.1</a> Negotiate (GSS-API) Authentication 518 </h4> 519 <p id="rfc.section.2.2.4.1.p.1">Microsoft has designed an HTTP authentication mechanism that utilizes SPNEGO <a href="#RFC4178"><cite title="The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism">[RFC4178]</cite></a> GSSAPI <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>. In Microsoft's implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan Manager protocols). 520 </p> 521 <p id="rfc.section.2.2.4.1.p.2">In Kerberos, clients and servers rely on a trusted third-party authentication service which maintains its own authentication 522 database. Kerberos is typically used with shared secret key cryptography, but extensions for use of other authentication mechnanisms 523 such as PKIX certificates and two-factor tokens are also common. Kerberos was designed to work under the assumption that packets 524 traveling along the network can be read, modified, and inserted at will. 525 </p> 526 <p id="rfc.section.2.2.4.1.p.3">Unlike Digest, Negotiate authentication can take multiple round trips (client sending authentication data in Authorization, 527 server sending authentication data in WWW-Authenticate) to complete. 528 </p> 529 <p id="rfc.section.2.2.4.1.p.4">Kerberos authentication is generally more secure than Digest. However the requirement for having a separate network authentication 530 service might be a barrier to deployment. 531 </p> 532 <h4 id="rfc.section.2.2.4.2"><a href="#rfc.section.2.2.4.2">2.2.4.2</a> OAuth 533 </h4> 534 <p id="rfc.section.2.2.4.2.p.1">[[ See.. </p> 535 <ul class="empty"> 536 <li>http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt</li> 537 <li>http://www.ietf.org/id/draft-hammer-oauth-10.txt</li> 538 </ul> 539 <p> ]]</p> 540 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> Centrally-Issued Tickets 541 </h2> 542 <p id="rfc.section.2.3.p.1">Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited 543 ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ 544 one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more 545 than a sophisticated application of forms and cookies. 546 </p> 547 <p id="rfc.section.2.3.p.2">All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization 548 efforts in progress, as usual. 549 </p> 550 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> Web Services 551 </h2> 552 <p id="rfc.section.2.4.p.1">Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for 553 TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination 554 of standard and vendor-produced specifications, some of which may be obsoleted at any time <a href="#WS-Pagecount"><cite title="WS-Pagecount">[WS-Pagecount]</cite></a> without any documented change control procedures. These protocols usually don't have much in common with the Architecture 555 of the World Wide Web. It's not clear why the term "Web" is used to group them, but they are obviously out of scope for HTTP-based 556 application protocols. 557 </p> 558 <p id="rfc.section.2.4.p.2">[[ This section could really use a good definition of "Web Services" to differentiate it from REST. See.. </p> 559 <ul class="empty"> 560 <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0536.html</li> 561 </ul> 562 <p> ]]</p> 563 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> Transport Layer Security 564 </h2> 565 <p id="rfc.section.2.5.p.1">In addition to using TLS for client and/or server authentication, it is also very commonly used to protect the confidentiality 566 and integrity of the HTTP session. For instance, both HTTP Basic authentication and Cookies are often protected against snooping 567 by TLS. 568 </p> 569 <p id="rfc.section.2.5.p.2">It should be noted that, in that case, TLS does not protect against a breach of the credential store at the server or against 570 a keylogger or phishing interface at the client. TLS does not change the fact that Basic Authentication passwords are reusable 571 and does not address that weakness. 572 </p> 573 <hr class="noprint"> 574 <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a> Revisions To HTTP 575 </h1> 576 <p id="rfc.section.3.p.1">Is is possible that HTTP will be revised in the future. "HTTP/1.1" <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and "Use and Interpretation of HTTP Version Numbers" <a href="#RFC2145"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and 577 no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate 578 will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary. 579 </p> 580 <hr class="noprint"> 581 <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a> IANA Considerations 582 </h1> 583 <p id="rfc.section.4.p.1">This document has no actions for IANA.</p> 584 <hr class="noprint"> 585 <h1 id="rfc.section.5" class="np"><a href="#rfc.section.5">5.</a> Security Considerations 586 </h1> 587 <p id="rfc.section.5.p.1">This entire document is about security considerations.</p> 392 </pre><p id="rfc.section.1.p.4">This document examines the effects of applying security constraints to Web applications, documents the properties that result 393 from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the 394 moment, it is mostly a laundry list of security technologies and tradeoffs. 395 </p> 396 <p id="rfc.section.1.p.5">[[ OVERALL ISSUE: It isn't entirely clear to the present editors what the purpose of this document is. On one hand it could 397 be a compendium of peer-entity authentication mechanisms (as it is presently) and make MTI recommendations thereof, or it 398 could be a place for various security considerations (either coalesced here from the other httpbis specs, or reserved for 399 the more gnarly cross-spec composite ones), or both. This needs to be clarified. ]] 400 </p> 401 </div> 402 <hr class="noprint"> 403 <div> 404 <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a> Existing HTTP Security Mechanisms 405 </h1> 406 <p id="rfc.section.2.p.1">For HTTP, the IETF generally defines "security mechanisms" as some combination of access authentication and/or a secure transport.</p> 407 <p id="rfc.section.2.p.2">[[ There is a suggestion that this section be split into "browser-like" and "automation-like" subsections. See: </p> 408 <ul class="empty"> 409 <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0180.html</li> 410 <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0183.html</li> 411 </ul> 412 <p> ]]</p> 413 <p id="rfc.section.2.p.3">[[ NTLM (shudder) was brought up in the WG a few times in the discussion of the -00 draft. Should we add a section on it? 414 See.. 415 </p> 416 <ul class="empty"> 417 <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0132.html</li> 418 <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0135.html</li> 419 </ul> 420 <p> ]]</p> 421 <div> 422 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> Forms And Cookies 423 </h2> 424 <p id="rfc.section.2.1.p.1">[[ JH: I am not convinced that this subsection properly belongs in this overall section in that "HTTP+HTML Form based authentication" 425 <http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication> is not properly a part of HTTP itself. Rather, it is 426 a piece of applications layered on top of HTTP. Use of cookies for state management (e.g. session maintanence) can be considered 427 such, however (although there is no overall specification for HTTP user agents stipulating that they must implement cookies 428 (nominally <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>)). Perhaps this section should be should be retitled "HTTP Authentication". 429 </p> 430 <p id="rfc.section.2.1.p.2">Note: The httpstate WG was recently chartered to develop a successor to <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>. See.. 431 </p> 432 <ul class="empty"> 433 <li>http://www.ietf.org/dyn/wg/charter/httpstate-charter.html</li> 434 </ul> 435 <p id="rfc.section.2.1.p.3">]]</p> 436 <p id="rfc.section.2.1.p.4">Almost all HTTP authentication that involves a human using a web browser is accomplished through HTML forms, with session 437 identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described 438 loosely in section 10 of "HTTP State Management Mechanism" <a href="#RFC2109"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>. The protocol in RFC 2109 is relatively widely implemented, but most clients don't advertise support for it. RFC 2109 was 439 later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented. 440 </p> 441 <p id="rfc.section.2.1.p.5">Forms and cookies have many properties that make them an excellent solution for some implementers. However, many of those 442 properties introduce serious security trade-offs. 443 </p> 444 <p id="rfc.section.2.1.p.6">HTML forms provide a large degree of control over presentation, which is an imperative for many websites. However, this increases 445 user reliance on the appearance of the interface. Many users do not understand the construction of URIs <a href="#RFC3986"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, or their presentation in common clients <a href="#PhishingHOWTO"><cite title="Phishing Tips and Techniques">[PhishingHOWTO]</cite></a>. As a result, forms are extremely vulnerable to spoofing. 446 </p> 447 <p id="rfc.section.2.1.p.7">HTML forms provide acceptable internationalization if used carefully, at the cost of being transmitted as normal HTTP content 448 in all cases (credentials are not differentiated in the protocol). 449 </p> 450 <p id="rfc.section.2.1.p.8">Many Web browsers have an auto-complete feature that stores a user's information and pre-populates fields in forms. This is 451 considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security 452 concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML 453 forms provide a facility for sites to indicate that a field, such as a password, should never be pre-populated. However, it 454 is clear that some form creators do not use this facility when they should. 455 </p> 456 <p id="rfc.section.2.1.p.9">The cookies that result from a successful form submission make it unnecessary to validate credentials with each HTTP request; 457 this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting) 458 attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because 459 cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries 460 and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the 461 data. 462 </p> 463 <p id="rfc.section.2.1.p.10">HTML forms and cookies provide flexible ways of ending a session from the client.</p> 464 <p id="rfc.section.2.1.p.11">HTML forms require an HTML rendering engine for which many protocols have no use.</p> 465 </div> 466 <div> 467 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> HTTP Access Authentication 468 </h2> 469 <p id="rfc.section.2.2.p.1">HTTP 1.1 provides a simple authentication framework, "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, which defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies, 470 but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control, 471 logout capabilities, or interoperable internationalization. 472 </p> 473 <div> 474 <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a> Basic Authentication 475 </h3> 476 <p id="rfc.section.2.2.1.p.1">Basic Authentication (normally called just "Basic") transmits usernames and passwords in the clear. It is very easy to implement, 477 but not at all secure unless used over a secure transport. 478 </p> 479 <p id="rfc.section.2.2.1.p.2">Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure 480 transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials, 481 but there is no standard method of doing so. 482 </p> 483 <p id="rfc.section.2.2.1.p.3">Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication 484 database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel. 485 </p> 486 <p id="rfc.section.2.2.1.p.4">Basic is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p> 487 </div> 488 <div> 489 <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a> Digest Authentication 490 </h3> 491 <p id="rfc.section.2.2.2.p.1">In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and 492 values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport. 493 </p> 494 <p id="rfc.section.2.2.2.p.2">Digest has some properties that are preferable to Basic and Cookies. Credentials are not immediately reusable by parties that 495 observe or receive them, and session data can be transmitted alongside credentials with each request, allowing servers to 496 validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic. 497 </p> 498 <p id="rfc.section.2.2.2.p.3">Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most 499 implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation 500 experience has shown that in some cases, especially those involving large requests or responses such as streams, the message 501 integrity mode is impractical because it requires servers to analyze the full request before determining whether the client 502 knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed. 503 </p> 504 <p id="rfc.section.2.2.2.p.4">Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk 505 consisting of a few million passwords for most users. 506 </p> 507 <p id="rfc.section.2.2.2.p.5">Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string <a href="#Apache_Digest"><cite title="Apache HTTP Server - mod_auth_digest">[Apache_Digest]</cite></a>. 508 </p> 509 <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accommodate it, or requires access to cleartext 510 passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common 511 method of storing passwords for use with Forms and Cookies. 512 </p> 513 <p id="rfc.section.2.2.2.p.7">Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks.</p> 514 <p id="rfc.section.2.2.2.p.8">Digest is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p> 515 </div> 516 <div> 517 <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a> Authentication Using Certificates in TLS 518 </h3> 519 <p id="rfc.section.2.2.3.p.1">Running HTTP over TLS provides authentication of the HTTP server to the client. HTTP over TLS can also provides authentication 520 of the client to the server using certificates. Although forms are a much more common way to authenticate users to HTTP servers, 521 TLS client certificates are widely used in some environments. The public key infrastructure (PKI) used to validate certificates 522 in TLS can be rooted in public trust anchors or can be based on local trust anchors. 523 </p> 524 </div> 525 <div> 526 <h3 id="rfc.section.2.2.4"><a href="#rfc.section.2.2.4">2.2.4</a> Other Access Authentication Schemes 527 </h3> 528 <p id="rfc.section.2.2.4.p.1">There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are 529 bound to transport layer connections. 530 </p> 531 <div> 532 <h4 id="rfc.section.2.2.4.1"><a href="#rfc.section.2.2.4.1">2.2.4.1</a> Negotiate (GSS-API) Authentication 533 </h4> 534 <p id="rfc.section.2.2.4.1.p.1">Microsoft has designed an HTTP authentication mechanism that utilizes SPNEGO <a href="#RFC4178"><cite title="The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism">[RFC4178]</cite></a> GSSAPI <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>. In Microsoft's implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan Manager protocols). 535 </p> 536 <p id="rfc.section.2.2.4.1.p.2">In Kerberos, clients and servers rely on a trusted third-party authentication service which maintains its own authentication 537 database. Kerberos is typically used with shared secret key cryptography, but extensions for use of other authentication mechnanisms 538 such as PKIX certificates and two-factor tokens are also common. Kerberos was designed to work under the assumption that packets 539 traveling along the network can be read, modified, and inserted at will. 540 </p> 541 <p id="rfc.section.2.2.4.1.p.3">Unlike Digest, Negotiate authentication can take multiple round trips (client sending authentication data in Authorization, 542 server sending authentication data in WWW-Authenticate) to complete. 543 </p> 544 <p id="rfc.section.2.2.4.1.p.4">Kerberos authentication is generally more secure than Digest. However the requirement for having a separate network authentication 545 service might be a barrier to deployment. 546 </p> 547 </div> 548 <div> 549 <h4 id="rfc.section.2.2.4.2"><a href="#rfc.section.2.2.4.2">2.2.4.2</a> OAuth 550 </h4> 551 <p id="rfc.section.2.2.4.2.p.1">[[ See.. </p> 552 <ul class="empty"> 553 <li>http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt</li> 554 <li>http://www.ietf.org/id/draft-hammer-oauth-10.txt</li> 555 </ul> 556 <p> ]]</p> 557 </div> 558 </div> 559 </div> 560 <div> 561 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> Centrally-Issued Tickets 562 </h2> 563 <p id="rfc.section.2.3.p.1">Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited 564 ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ 565 one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more 566 than a sophisticated application of forms and cookies. 567 </p> 568 <p id="rfc.section.2.3.p.2">All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization 569 efforts in progress, as usual. 570 </p> 571 </div> 572 <div> 573 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> Web Services 574 </h2> 575 <p id="rfc.section.2.4.p.1">Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for 576 TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination 577 of standard and vendor-produced specifications, some of which may be obsoleted at any time <a href="#WS-Pagecount"><cite title="WS-Pagecount">[WS-Pagecount]</cite></a> without any documented change control procedures. These protocols usually don't have much in common with the Architecture 578 of the World Wide Web. It's not clear why the term "Web" is used to group them, but they are obviously out of scope for HTTP-based 579 application protocols. 580 </p> 581 <p id="rfc.section.2.4.p.2">[[ This section could really use a good definition of "Web Services" to differentiate it from REST. See.. </p> 582 <ul class="empty"> 583 <li>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0536.html</li> 584 </ul> 585 <p> ]]</p> 586 </div> 587 <div> 588 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> Transport Layer Security 589 </h2> 590 <p id="rfc.section.2.5.p.1">In addition to using TLS for client and/or server authentication, it is also very commonly used to protect the confidentiality 591 and integrity of the HTTP session. For instance, both HTTP Basic authentication and Cookies are often protected against snooping 592 by TLS. 593 </p> 594 <p id="rfc.section.2.5.p.2">It should be noted that, in that case, TLS does not protect against a breach of the credential store at the server or against 595 a keylogger or phishing interface at the client. TLS does not change the fact that Basic Authentication passwords are reusable 596 and does not address that weakness. 597 </p> 598 </div> 599 </div> 600 <hr class="noprint"> 601 <div> 602 <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a> Revisions To HTTP 603 </h1> 604 <p id="rfc.section.3.p.1">Is is possible that HTTP will be revised in the future. "HTTP/1.1" <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and "Use and Interpretation of HTTP Version Numbers" <a href="#RFC2145"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and 605 no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate 606 will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary. 607 </p> 608 </div> 609 <hr class="noprint"> 610 <div> 611 <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a> IANA Considerations 612 </h1> 613 <p id="rfc.section.4.p.1">This document has no actions for IANA.</p> 614 </div> 615 <hr class="noprint"> 616 <div> 617 <h1 id="rfc.section.5" class="np"><a href="#rfc.section.5">5.</a> Security Considerations 618 </h1> 619 <p id="rfc.section.5.p.1">This entire document is about security considerations.</p> 620 </div> 588 621 <hr class="noprint"> 589 622 <h1 id="rfc.references" class="np"><a id="rfc.section.6" href="#rfc.section.6">6.</a> References … … 591 624 <h2 class="np" id="rfc.references.1"><a href="#rfc.section.6.1" id="rfc.section.6.1">6.1</a> Normative References 592 625 </h2> 593 <table> 626 <table> 594 627 <tr> 595 628 <td class="reference"><b id="RFC2026">[RFC2026]</b></td> 596 <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http ://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP 9, RFC 2026, October 1996.597 </td> 598 </tr> 629 <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="https://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP 9, RFC 2026, October 1996. 630 </td> 631 </tr> 599 632 <tr> 600 633 <td class="reference"><b id="RFC2145">[RFC2145]</b></td> 601 <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J. C.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.T.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC 2145, May 1997.602 </td> 603 </tr> 634 <td class="top"><a href="mailto:mogul@wrl.dec.com" title="Western Research Laboratory">Mogul, J.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="MIT Laboratory for Computer Science">Gettys, J.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium">H. Nielsen</a>, “<a href="https://tools.ietf.org/html/rfc2145">Use and Interpretation of HTTP Version Numbers</a>”, RFC 2145, May 1997. 635 </td> 636 </tr> 604 637 <tr> 605 638 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> 606 <td class="top"><a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="World Wide Web Consortium">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="World Wide Web Consortium">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">T. Berners-Lee</a>, “<a href="http ://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999.607 </td> 608 </tr> 639 <td class="top"><a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="World Wide Web Consortium">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="World Wide Web Consortium">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="World Wide Web Consortium">T. Berners-Lee</a>, “<a href="https://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. 640 </td> 641 </tr> 609 642 <tr> 610 643 <td class="reference"><b id="RFC2617">[RFC2617]</b></td> 611 <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P. M.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.L.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.D.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.J.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC 2617, June 1999.612 </td> 613 </tr> 644 <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="https://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC 2617, June 1999. 645 </td> 646 </tr> 614 647 <tr> 615 648 <td class="reference"><b id="RFC2965">[RFC2965]</b></td> 616 <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D. M.</a> and <a href="mailto:lou@montulli.org" title="Epinions.com, Inc.">L. Montulli</a>, “<a href="http://tools.ietf.org/html/rfc2965">HTTP State Management Mechanism</a>”, RFC 2965, October 2000.617 </td> 618 </tr> 649 <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D.</a> and <a href="mailto:lou@montulli.org" title="Epinions.com, Inc.">L. Montulli</a>, “<a href="https://tools.ietf.org/html/rfc2965">HTTP State Management Mechanism</a>”, RFC 2965, October 2000. 650 </td> 651 </tr> 619 652 <tr> 620 653 <td class="reference"><b id="RFC3365">[RFC3365]</b></td> 621 <td class="top">Schiller, J., “<a href="http ://tools.ietf.org/html/rfc3365">Strong Security Requirements for Internet Engineering Task Force Standard Protocols</a>”, BCP 61, RFC 3365, August 2002.622 </td> 623 </tr> 654 <td class="top">Schiller, J., “<a href="https://tools.ietf.org/html/rfc3365">Strong Security Requirements for Internet Engineering Task Force Standard Protocols</a>”, BCP 61, RFC 3365, August 2002. 655 </td> 656 </tr> 624 657 <tr> 625 658 <td class="reference"><b id="RFC3631">[RFC3631]</b></td> 626 <td class="top">Bellovin, S., Schiller, J., and C. Kaufman, “<a href="http ://tools.ietf.org/html/rfc3631">Security Mechanisms for the Internet</a>”, RFC 3631, December 2003.627 </td> 628 </tr> 659 <td class="top">Bellovin, S., Schiller, J., and C. Kaufman, “<a href="https://tools.ietf.org/html/rfc3631">Security Mechanisms for the Internet</a>”, RFC 3631, December 2003. 660 </td> 661 </tr> 629 662 <tr> 630 663 <td class="reference"><b id="RFC3986">[RFC3986]</b></td> 631 <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R.</a>, and <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">L. Masinter</a>, “<a href="http ://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD 66, RFC 3986, January 2005.632 </td> 633 </tr> 664 <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@gbiv.com" title="Day Software">Fielding, R.</a>, and <a href="mailto:LMM@acm.org" title="Adobe Systems Incorporated">L. Masinter</a>, “<a href="https://tools.ietf.org/html/rfc3986">Uniform Resource Identifier (URI): Generic Syntax</a>”, STD 66, RFC 3986, January 2005. 665 </td> 666 </tr> 634 667 <tr> 635 668 <td class="reference"><b id="RFC4178">[RFC4178]</b></td> 636 <td class="top">Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, “<a href="http ://tools.ietf.org/html/rfc4178">The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism</a>”, RFC 4178, October 2005.637 </td> 638 </tr> 669 <td class="top">Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, “<a href="https://tools.ietf.org/html/rfc4178">The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism</a>”, RFC 4178, October 2005. 670 </td> 671 </tr> 639 672 <tr> 640 673 <td class="reference"><b id="RFC4559">[RFC4559]</b></td> 641 <td class="top">Jaganathan, K., Zhu, L., and J. Brezak, “<a href="http ://tools.ietf.org/html/rfc4559">SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</a>”, RFC 4559, June 2006.642 </td> 643 </tr> 674 <td class="top">Jaganathan, K., Zhu, L., and J. Brezak, “<a href="https://tools.ietf.org/html/rfc4559">SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</a>”, RFC 4559, June 2006. 675 </td> 676 </tr> 644 677 <tr> 645 678 <td class="reference"><b id="Apache_Digest">[Apache_Digest]</b></td> 646 <td class="top">Apache Software Foundation, , “<a href="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html">Apache HTTP Server - mod_auth_digest</a>”, <<a href="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html">http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html</a>>.647 </td> 648 </tr> 679 <td class="top">Apache Software Foundation, ., “<a href="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html">Apache HTTP Server - mod_auth_digest</a>”, <<a href="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html">http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html</a>>. 680 </td> 681 </tr> 649 682 <tr> 650 683 <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td> 651 684 <td class="top">Gutmann, P., “<a href="http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf">Phishing Tips and Techniques</a>”, February 2008, <<a href="http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf">http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf</a>>. 652 685 </td> 653 </tr> 686 </tr> 654 687 <tr> 655 688 <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td> 656 689 <td class="top">Bray, T., “<a href="http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research">WS-Pagecount</a>”, September 2004, <<a href="http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research">http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research</a>>. 657 690 </td> 658 </tr> 691 </tr> 659 692 </table> 660 693 <h2 id="rfc.references.2"><a href="#rfc.section.6.2" id="rfc.section.6.2">6.2</a> Informative References 661 694 </h2> 662 <table> 695 <table> 663 696 <tr> 664 697 <td class="reference"><b id="RFC2109">[RFC2109]</b></td> 665 <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D. M.</a> and <a href="mailto:montulli@netscape.com" title="Netscape Communications Corp.">L. Montulli</a>, “<a href="http://tools.ietf.org/html/rfc2109">HTTP State Management Mechanism</a>”, RFC 2109, February 1997.666 </td> 667 </tr> 698 <td class="top"><a href="mailto:dmk@bell-labs.com" title="Bell Laboratories, Lucent Technologies">Kristol, D.</a> and <a href="mailto:montulli@netscape.com" title="Netscape Communications Corp.">L. Montulli</a>, “<a href="https://tools.ietf.org/html/rfc2109">HTTP State Management Mechanism</a>”, RFC 2109, February 1997. 699 </td> 700 </tr> 668 701 </table> 669 702 <hr class="noprint"> 670 <div class="avoidbreak"> 671 <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1> 672 <address class="vcard"><span class="vcardline"><span class="fn">Jeff Hodges</span><span class="n hidden"><span class="family-name">Hodges</span><span class="given-name">Jeff</span></span></span><span class="org vcardline">PayPal</span><span class="vcardline">EMail: <a href="mailto:Jeff.Hodges@PayPal.com"><span class="email">Jeff.Hodges@PayPal.com</span></a></span></address> 673 <address class="vcard"><span class="vcardline"><span class="fn">Barry Leiba</span><span class="n hidden"><span class="family-name">Leiba</span><span class="given-name">Barry</span></span></span><span class="org vcardline">Huawei Technologies</span><span class="vcardline tel">Phone: <a href="tel:+16468270648"><span class="value">+1 646 827 0648</span></a></span><span class="vcardline">EMail: <a href="mailto:barryleiba@computer.org"><span class="email">barryleiba@computer.org</span></a></span><span class="vcardline">URI: <a href="http://internetmessagingtechnology.org/" class="url">http://internetmessagingtechnology.org/</a></span></address> 674 </div> 675 <hr class="noprint"> 676 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> Acknowledgements 677 </h1> 678 <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic. Many others on the HTTPbis Working 679 Group have contributed to this document in the discussion. 680 </p> 681 <hr class="noprint"> 682 <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a> Document History 683 </h1> 684 <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p> 685 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> Changes between draft-sayre-http-security-variance-00 and draft-ietf-httpbis-security-properties-00 686 </h2> 687 <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p> 688 <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p> 689 <p id="rfc.section.B.1.p.3">Removed what was section 2 (Requirements Notation), the reference to RFC 2119, and any use of 2119ish all-caps words.</p> 690 <p id="rfc.section.B.1.p.4">In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 repertoire" to match the definition of "TEXT" in RFC 2616.</p> 691 <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p> 692 <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p> 693 <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> Changes between -00 and -01 694 </h2> 695 <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p> 696 <p id="rfc.section.B.2.p.2">Added the suggestions about splitting for browsers and automation, and about adding NTLM, to be beginning of 2.</p> 697 <p id="rfc.section.B.2.p.3">In 2.1, added "that involves a human using a web browser" in the first sentence.</p> 698 <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p> 699 <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p> 700 <div id="rfc.figure.u.2"></div><pre> 703 <div> 704 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> Acknowledgements 705 </h1> 706 <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic. Many others on the HTTPbis Working 707 Group have contributed to this document in the discussion. 708 </p> 709 </div> 710 <hr class="noprint"> 711 <div> 712 <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a> Document History 713 </h1> 714 <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p> 715 <div> 716 <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a> Changes between draft-sayre-http-security-variance-00 and draft-ietf-httpbis-security-properties-00 717 </h2> 718 <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p> 719 <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p> 720 <p id="rfc.section.B.1.p.3">Removed what was section 2 (Requirements Notation), the reference to RFC 2119, and any use of 2119ish all-caps words.</p> 721 <p id="rfc.section.B.1.p.4">In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 repertoire" to match the definition of "TEXT" in RFC 2616.</p> 722 <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p> 723 <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p> 724 </div> 725 <div> 726 <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> Changes between -00 and -01 727 </h2> 728 <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p> 729 <p id="rfc.section.B.2.p.2">Added the suggestions about splitting for browsers and automation, and about adding NTLM, to be beginning of 2.</p> 730 <p id="rfc.section.B.2.p.3">In 2.1, added "that involves a human using a web browser" in the first sentence.</p> 731 <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p> 732 <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p><span id="rfc.figure.u.2"></span><pre> 701 733 Digest includes many modes of operation, but only the simplest modes 702 734 enjoy any degree of interoperability. For example, most … … 706 738 to analyze the full request before determining whether the client 707 739 knows the shared secret. 708 </pre><p> to </p> 709 <div id="rfc.figure.u.3"></div><pre> 740 </pre><p> to </p><span id="rfc.figure.u.3"></span><pre> 710 741 Digest includes many modes of operation, but only the simplest 711 742 modes enjoy any degree of interoperability. For example, most … … 719 750 the request can be processed. 720 751 </pre><p id="rfc.section.B.2.p.6">In 2.4, asked for a definition of "Web Services".</p> 721 <p id="rfc.section.B.2.p.7">In A, added the WG.</p> 722 <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a> Changes between -01 and -02 723 </h2> 724 <p id="rfc.section.B.3.p.1">In section 2.1, added more to the paragraph on auto-completion of HTML forms.</p> 725 <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p> 726 <p id="rfc.section.B.3.p.3">Filled in section 2.5.</p> 727 <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a> Changes between -02 and -03 728 </h2> 729 <p id="rfc.section.B.4.p.1">Changed IPR licensing from "full3978" to "pre5378Trust200902".</p> 730 <h2 id="rfc.section.B.5"><a href="#rfc.section.B.5">B.5</a> Changes between -03 and -04 731 </h2> 732 <p id="rfc.section.B.5.p.1">Changed authors to be Jeff Hodges (JH) and Barry Leiba (BL) with permission of Paul Hoffman, Alexey Melnikov, and Mark Nottingham 733 (httpbis chair). 734 </p> 735 <p id="rfc.section.B.5.p.2">Added "OVERALL ISSUE" to introduction.</p> 736 <p id="rfc.section.B.5.p.3">Added links to email messages on mailing list(s) where various suggestions for this document were brought up. I.e. added various 737 links to those comments herein delimited by "[[...]]" braces. 738 </p> 739 <p id="rfc.section.B.5.p.4">Noted JH's belief that "HTTP+HTML Form based authentication" aka "Forms And Cookies" doesn't properly belong in the section 740 where it presently resides. Added link to httpstate WG. 741 </p> 742 <p id="rfc.section.B.5.p.5">Added references to OAuth. Section needs to be filled-in as yet.</p> 743 <p id="rfc.section.B.5.p.6">Moved ref to RFC2109 to new "Informative References" section, and added a placeholder "IANA Considerations" section in order 744 to satisfy IDnits checking. 745 </p> 752 <p id="rfc.section.B.2.p.7">In A, added the WG.</p> 753 </div> 754 <div> 755 <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a> Changes between -01 and -02 756 </h2> 757 <p id="rfc.section.B.3.p.1">In section 2.1, added more to the paragraph on auto-completion of HTML forms.</p> 758 <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p> 759 <p id="rfc.section.B.3.p.3">Filled in section 2.5.</p> 760 </div> 761 <div> 762 <h2 id="rfc.section.B.4"><a href="#rfc.section.B.4">B.4</a> Changes between -02 and -03 763 </h2> 764 <p id="rfc.section.B.4.p.1">Changed IPR licensing from "full3978" to "pre5378Trust200902".</p> 765 </div> 766 <div> 767 <h2 id="rfc.section.B.5"><a href="#rfc.section.B.5">B.5</a> Changes between -03 and -04 768 </h2> 769 <p id="rfc.section.B.5.p.1">Changed authors to be Jeff Hodges (JH) and Barry Leiba (BL) with permission of Paul Hoffman, Alexey Melnikov, and Mark Nottingham 770 (httpbis chair). 771 </p> 772 <p id="rfc.section.B.5.p.2">Added "OVERALL ISSUE" to introduction.</p> 773 <p id="rfc.section.B.5.p.3">Added links to email messages on mailing list(s) where various suggestions for this document were brought up. I.e. added various 774 links to those comments herein delimited by "[[...]]" braces. 775 </p> 776 <p id="rfc.section.B.5.p.4">Noted JH's belief that "HTTP+HTML Form based authentication" aka "Forms And Cookies" doesn't properly belong in the section 777 where it presently resides. Added link to httpstate WG. 778 </p> 779 <p id="rfc.section.B.5.p.5">Added references to OAuth. Section needs to be filled-in as yet.</p> 780 <p id="rfc.section.B.5.p.6">Moved ref to RFC2109 to new "Informative References" section, and added a placeholder "IANA Considerations" section in order 781 to satisfy IDnits checking. 782 </p> 783 </div> 784 </div> 785 <hr class="noprint"> 786 <div class="avoidbreak"> 787 <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1> 788 <p><b>Jeff Hodges</b><br>PayPal<br>EMail: <a href="mailto:Jeff.Hodges@PayPal.com">Jeff.Hodges@PayPal.com</a></p> 789 <p><b>Barry Leiba</b><br>Huawei Technologies<br>Phone: <a href="tel:+16468270648">+1 646 827 0648</a><br>EMail: <a href="mailto:barryleiba@computer.org">barryleiba@computer.org</a><br>URI: <a href="http://internetmessagingtechnology.org/">http://internetmessagingtechnology.org/</a></p> 790 </div> 746 791 </body> 747 792 </html>
Note: See TracChangeset
for help on using the changeset viewer.