Changeset 787 for draft-ietf-httpbis-security-properties/latest
- Timestamp:
- 11/03/10 10:48:42 (13 years ago)
- Location:
- draft-ietf-httpbis-security-properties/latest
- Files:
-
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.html
r551 r787 2 2 PUBLIC "-//W3C//DTD HTML 4.01//EN"> 3 3 <html lang="en"> 4 <head profile="http://www.w3.org/2006/03/hcard ">4 <head profile="http://www.w3.org/2006/03/hcard 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)"> … … 37 37 } 38 38 39 dl.empty dd { 39 ul.empty { 40 list-style-type: none; 41 } 42 ul.empty li { 40 43 margin-top: .5em; 41 44 } … … 118 121 } 119 122 table.header { 123 border-spacing: 1px; 120 124 width: 95%; 121 125 font-size: 10pt; … … 129 133 white-space: nowrap; 130 134 } 131 t d.header{135 table.header td { 132 136 background-color: gray; 133 137 width: 50%; … … 259 263 @page { 260 264 @top-left { 261 content: "I NTERNET DRAFT";265 content: "Internet-Draft"; 262 266 } 263 267 @top-right { … … 268 272 } 269 273 @bottom-left { 270 content: "Ho ffman & Melnikov";274 content: "Hodges & Leiba"; 271 275 } 272 276 @bottom-center { … … 290 294 } 291 295 </style><link rel="Author" href="#rfc.authors"> 292 <link rel="Copyright" href="#rfc.copyright ">296 <link rel="Copyright" href="#rfc.copyrightnotice"> 293 297 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1"> 294 298 <link rel="Chapter" title="2 Existing HTTP Security Mechanisms" href="#rfc.section.2"> 295 299 <link rel="Chapter" title="3 Revisions To HTTP" href="#rfc.section.3"> 296 <link rel="Chapter" title="4 Security Considerations" href="#rfc.section.4"> 297 <link rel="Chapter" href="#rfc.section.5" title="5 Normative References"> 300 <link rel="Chapter" title="4 IANA Considerations" href="#rfc.section.4"> 301 <link rel="Chapter" title="5 Security Considerations" href="#rfc.section.5"> 302 <link rel="Chapter" href="#rfc.section.6" title="6 References"> 298 303 <link rel="Appendix" title="A Acknowledgements" href="#rfc.section.A"> 299 304 <link rel="Appendix" title="B Document History" href="#rfc.section.B"> 300 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.426, 2009-03-07 10:31:10, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/"> 301 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/"> 302 <meta name="DC.Creator" content="Hoffman, P."> 303 <meta name="DC.Creator" content="Melnikov, A."> 304 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties-latest"> 305 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-03"> 306 <meta name="DC.Description.Abstract" content="Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes the trade-offs of each."> 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/"> 306 <link rel="schema.dct" href="http://purl.org/dc/terms/"> 307 <meta name="dct.creator" content="Hodges, J."> 308 <meta name="dct.creator" content="Leiba, B."> 309 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties-latest"> 310 <meta name="dct.issued" scheme="ISO8601" content="2009-03"> 311 <meta name="dct.abstract" content="Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement (MTI) security mechanisms, so that all conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes the trade-offs of each."> 312 <meta name="description" content="Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement (MTI) security mechanisms, so that all conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes the trade-offs of each."> 307 313 </head> 308 314 <body> 309 <table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1"> 310 <tr> 311 <td class="header left">Network Working Group</td> 312 <td class="header right">P. Hoffman</td> 313 </tr> 314 <tr> 315 <td class="header left">Internet Draft</td> 316 <td class="header right">VPN Consortium</td> 317 </tr> 318 <tr> 319 <td class="header left"> 320 <draft-ietf-httpbis-security-properties-latest> 321 322 </td> 323 <td class="header right">A. Melnikov</td> 324 </tr> 325 <tr> 326 <td class="header left">Intended status: Informational</td> 327 <td class="header right">Isode Ltd.</td> 328 </tr> 329 <tr> 330 <td class="header left">Expires: September 2009</td> 331 <td class="header right">March 9, 2009</td> 332 </tr> 315 <table class="header"> 316 <tbody> 317 <tr> 318 <td class="left">Network Working Group</td> 319 <td class="right">J. Hodges</td> 320 </tr> 321 <tr> 322 <td class="left">Internet-Draft</td> 323 <td class="right">PayPal</td> 324 </tr> 325 <tr> 326 <td class="left">Intended status: Informational</td> 327 <td class="right">B. Leiba</td> 328 </tr> 329 <tr> 330 <td class="left">Expires: September 2009</td> 331 <td class="right">Huawei Technologies</td> 332 </tr> 333 <tr> 334 <td class="left"></td> 335 <td class="right">March 2009</td> 336 </tr> 337 </tbody> 333 338 </table> 334 339 <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-latest</span></p> 335 340 <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1> 336 <p>This Internet-Draft is submitted to IETF pursuant to, and in full conformance with, the provisions of BCP 78 and BCP 79. This337 document may contain material from IETF Documents or IETF Contributions published or made publicly available before November338 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to339 allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s)340 co ntrolling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative341 works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate342 i t into languages other than English.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. 343 348 </p> 344 349 <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note … … 349 354 in progress”. 350 355 </p> 351 <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>>.352 </p> 353 <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>>.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>. 354 359 </p> 355 360 <p>This Internet-Draft will expire in September 2009.</p> … … 360 365 </p> 361 366 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 362 <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant363 implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes364 the trade-offs of each.367 <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement (MTI) security mechanisms, so that all 368 conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, 369 and analyzes the trade-offs of each. 365 370 </p> 366 371 <hr class="noprint"> 367 372 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> Introduction 368 373 </h1> 369 <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols are required to specify mandatory to implement security mechanisms. "The370 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 define374 <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 define 371 376 the term "strong security". 372 377 </p> 373 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: 374 379 </p> 375 <div id="rfc.figure.u.1"></div> <pre>380 <div id="rfc.figure.u.1"></div> <pre> 376 381 We have evolved in the IETF the notion of "mandatory to implement" 377 382 mechanisms. This philosophy evolves from our primary desire to … … 383 388 selection of non-overlapping mechanisms being deployed in the 384 389 different implementations. 385 </pre><p id="rfc.section.1.p.4">This document examines the effects of applying security constraints to Web applications, documents the properties that result390 </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 386 391 from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the 387 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. ]] 388 398 </p> 389 399 <hr class="noprint"> … … 391 401 </h1> 392 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> 393 <p id="rfc.section.2.p.2">[[ There is a suggestion that this section be split into "browser-like" and "automation-like" subsections. ]]</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> 394 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? 395 ]] 396 </p> 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> 397 417 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> Forms And Cookies 398 418 </h2> 399 <p id="rfc.section.2.1.p.1">Almost all HTTP authentication that involves a human using a web browser is accomplished through HTML forms, with session 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 400 432 identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described 401 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 402 434 later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented. 403 435 </p> 404 <p id="rfc.section.2.1.p. 2">Forms and cookies have many properties that make them an excellent solution for some implementers. However, many of those436 <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 405 437 properties introduce serious security trade-offs. 406 438 </p> 407 <p id="rfc.section.2.1.p. 3">HTML forms provide a large degree of control over presentation, which is an imperative for many websites. However, this increases439 <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 408 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. 409 441 </p> 410 <p id="rfc.section.2.1.p. 4">HTML forms provide acceptable internationalization if used carefully, at the cost of being transmitted as normal HTTP content442 <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 411 443 in all cases (credentials are not differentiated in the protocol). 412 444 </p> 413 <p id="rfc.section.2.1.p. 5">Many Web browsers have an auto-complete feature that stores a user's information and pre-populates fields in forms. This is445 <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 414 446 considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security 415 447 concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML … … 417 449 is clear that some form creators do not use this facility when they should. 418 450 </p> 419 <p id="rfc.section.2.1.p. 6">The cookies that result from a successful form submission make it unnecessary to validate credentials with each HTTP request;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; 420 452 this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting) 421 453 attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because … … 424 456 data. 425 457 </p> 426 <p id="rfc.section.2.1.p. 7">HTML forms and cookies provide flexible ways of ending a session from the client.</p>427 <p id="rfc.section.2.1.p. 8">HTML forms require an HTML rendering engine for which many protocols have no use.</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> 428 460 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> HTTP Access Authentication 429 461 </h2> … … 451 483 </p> 452 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 453 observe or receive them, and session data can be transmitted along 485 observe or receive them, and session data can be transmitted alongside credentials with each request, allowing servers to 454 486 validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic. 455 487 </p> … … 498 530 service might be a barrier to deployment. 499 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> 500 540 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> Centrally-Issued Tickets 501 541 </h2> … … 516 556 application protocols. 517 557 </p> 518 <p id="rfc.section.2.4.p.2">[[ This section could really use a good definition of "Web Services" to differentiate it from REST. ]]</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> 519 563 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> Transport Layer Security 520 564 </h2> … … 535 579 </p> 536 580 <hr class="noprint"> 537 <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a> SecurityConsiderations581 <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a> IANA Considerations 538 582 </h1> 539 <p id="rfc.section.4.p.1">This entire document is about security considerations.</p> 540 <h1 class="np" id="rfc.references"><a href="#rfc.section.5" id="rfc.section.5">5.</a> Normative References 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 541 586 </h1> 542 <table summary="Normative References"> 587 <p id="rfc.section.5.p.1">This entire document is about security considerations.</p> 588 <hr class="noprint"> 589 <h1 id="rfc.references" class="np"><a id="rfc.section.6" href="#rfc.section.6">6.</a> References 590 </h1> 591 <h2 class="np" id="rfc.references.1"><a href="#rfc.section.6.1" id="rfc.section.6.1">6.1</a> Normative References 592 </h2> 593 <table> 543 594 <tr> 544 595 <td class="reference"><b id="RFC2026">[RFC2026]</b></td> … … 547 598 </tr> 548 599 <tr> 600 <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> 604 <tr> 605 <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> 609 <tr> 610 <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> 614 <tr> 615 <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> 619 <tr> 620 <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> 624 <tr> 625 <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> 629 <tr> 630 <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> 634 <tr> 635 <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> 639 <tr> 640 <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> 644 <tr> 645 <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> 649 <tr> 650 <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td> 651 <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 </td> 653 </tr> 654 <tr> 655 <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td> 656 <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 </td> 658 </tr> 659 </table> 660 <h2 id="rfc.references.2"><a href="#rfc.section.6.2" id="rfc.section.6.2">6.2</a> Informative References 661 </h2> 662 <table> 663 <tr> 549 664 <td class="reference"><b id="RFC2109">[RFC2109]</b></td> 550 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. 551 666 </td> 552 </tr>553 <tr>554 <td class="reference"><b id="RFC2145">[RFC2145]</b></td>555 <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.556 </td>557 </tr>558 <tr>559 <td class="reference"><b id="RFC2616">[RFC2616]</b></td>560 <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.561 </td>562 </tr>563 <tr>564 <td class="reference"><b id="RFC2617">[RFC2617]</b></td>565 <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.566 </td>567 </tr>568 <tr>569 <td class="reference"><b id="RFC2965">[RFC2965]</b></td>570 <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.571 </td>572 </tr>573 <tr>574 <td class="reference"><b id="RFC3365">[RFC3365]</b></td>575 <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.576 </td>577 </tr>578 <tr>579 <td class="reference"><b id="RFC3631">[RFC3631]</b></td>580 <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.581 </td>582 </tr>583 <tr>584 <td class="reference"><b id="RFC3986">[RFC3986]</b></td>585 <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.586 </td>587 </tr>588 <tr>589 <td class="reference"><b id="RFC4178">[RFC4178]</b></td>590 <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.591 </td>592 </tr>593 <tr>594 <td class="reference"><b id="RFC4559">[RFC4559]</b></td>595 <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.596 </td>597 </tr>598 <tr>599 <td class="reference"><b id="Apache_Digest">[Apache_Digest]</b></td>600 <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>>.601 </td>602 </tr>603 <tr>604 <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td>605 <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>>.606 </td>607 </tr>608 <tr>609 <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td>610 <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>>.611 </td>612 667 </tr> 613 668 </table> 614 669 <hr class="noprint"> 615 <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1> 616 <address class="vcard"><span class="vcardline"><span class="fn">Paul Hoffman</span><span class="n hidden"><span class="family-name">Hoffman</span><span class="given-name">Paul</span></span></span><span class="org vcardline">VPN Consortium</span><span class="vcardline">EMail: <a href="mailto:paul.hoffman@vpnc.org"><span class="email">paul.hoffman@vpnc.org</span></a></span></address> 617 <address class="vcard"><span class="vcardline"><span class="fn">Alexey Melnikov</span><span class="n hidden"><span class="family-name">Melnikov</span><span class="given-name">Alexey</span></span></span><span class="org vcardline">Isode Ltd.</span><span class="vcardline">EMail: <a href="mailto:alexey.melnikov@isode.com"><span class="email">alexey.melnikov@isode.com</span></a></span></address> 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> 618 675 <hr class="noprint"> 619 676 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> Acknowledgements … … 626 683 </h1> 627 684 <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p> 628 <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-00685 <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 629 686 </h2> 630 687 <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p> … … 668 725 <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p> 669 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> 670 746 </body> 671 747 </html> -
draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.txt
r551 r787 2 2 3 3 4 Network Working Group P. Hoffman5 Internet-Draft VPN Consortium6 Intended status: Informational A. Melnikov7 Expires: September 10, 2009 Isode Ltd.8 March 9,20094 Network Working Group J. Hodges 5 Internet-Draft PayPal 6 Intended status: Informational B. Leiba 7 Expires: September 2, 2009 Huawei Technologies 8 March 2009 9 9 10 10 … … 43 43 http://www.ietf.org/shadow.html. 44 44 45 This Internet-Draft will expire on September 10, 2009.45 This Internet-Draft will expire on September 2, 2009. 46 46 47 47 Copyright Notice … … 53 53 54 54 55 Ho ffman & Melnikov Expires September 10, 2009 [Page 1]55 Hodges & Leiba Expires September 2, 2009 [Page 1] 56 56 57 57 … … 68 68 69 69 Recent IESG practice dictates that IETF protocols must specify 70 mandatory-to-implement security mechanisms, so that all conformant71 implementations share a common baseline. This document examines all72 widely deployed HTTP security technologies, and analyzes the trade-73 offs of each.70 mandatory-to-implement (MTI) security mechanisms, so that all 71 conformant implementations share a common baseline. This document 72 examines all widely deployed HTTP security technologies, and analyzes 73 the trade-offs of each. 74 74 75 75 … … 78 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 79 79 2. Existing HTTP Security Mechanisms . . . . . . . . . . . . . . 3 80 2.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 380 2.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 4 81 81 2.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 5 82 2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 5 83 2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 5 84 2.2.3. Authentication Using Certificates in TLS . . . . . . . 6 85 2.2.4. Other Access Authentication Schemes . . . . . . . . . 6 86 2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 7 87 2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 7 88 2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 8 89 3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 8 90 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 91 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8 92 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 93 Appendix B. Document History . . . . . . . . . . . . . . . . . . 10 82 2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 6 83 2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 6 84 2.2.3. Authentication Using Certificates in TLS . . . . . . . 7 85 2.2.4. Other Access Authentication Schemes . . . . . . . . . 7 86 2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 8 87 2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 8 88 2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 9 89 3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 9 90 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 92 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 93 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 94 6.2. Informative References . . . . . . . . . . . . . . . . . . 11 95 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 96 Appendix B. Document History . . . . . . . . . . . . . . . . . . 11 94 97 B.1. Changes between draft-sayre-http-security-variance-00 95 and draft-ietf-httpbis-security-properties-00 . . . . . 10 96 B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 10 97 B.3. Changes between -01 and -02 . . . . . . . . . . . . . . . 11 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 99 100 101 102 103 104 105 106 107 108 109 110 111 112 Hoffman & Melnikov Expires September 10, 2009 [Page 2] 98 and 99 draft-ietf-httpbis-security-properties-00 . . . . . . . . 11 100 B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 11 101 B.3. Changes between -01 and -02 . . . . . . . . . . . . . . . 12 102 B.4. Changes between -02 and -03 . . . . . . . . . . . . . . . 12 103 B.5. Changes between -03 and -04 . . . . . . . . . . . . . . . 13 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 105 106 107 108 109 110 111 112 Hodges & Leiba Expires September 2, 2009 [Page 2] 113 113 114 114 … … 118 118 1. Introduction 119 119 120 Recent IESG practice dictates that IETF protocols are required to121 specify mandatory to implementsecurity mechanisms. "The IETF120 Recent IESG practice dictates that IETF protocols be required to 121 specify mandatory-to-implement (MTI) security mechanisms. "The IETF 122 122 Standards Process" [RFC2026] does not require that protocols specify 123 123 mandatory security mechanisms. "Strong Security Requirements for … … 146 146 laundry list of security technologies and tradeoffs. 147 147 148 [[ OVERALL ISSUE: It isn't entirely clear to the present editors what 149 the purpose of this document is. On one hand it could be a 150 compendium of peer-entity authentication mechanisms (as it is 151 presently) and make MTI recommendations thereof, or it could be a 152 place for various security considerations (either coalesced here from 153 the other httpbis specs, or reserved for the more gnarly cross-spec 154 composite ones), or both. This needs to be clarified. ]] 155 148 156 149 157 2. Existing HTTP Security Mechanisms … … 153 161 154 162 [[ There is a suggestion that this section be split into "browser- 155 like" and "automation-like" subsections. ]] 163 like" and "automation-like" subsections. See: 164 165 166 167 168 169 Hodges & Leiba Expires September 2, 2009 [Page 3] 170 171 172 Internet-Draft Security Requirements for HTTP March 2009 173 174 175 http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/ 176 0180.html 177 178 http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/ 179 0183.html 180 181 ]] 156 182 157 183 [[ NTLM (shudder) was brought up in the WG a few times in the 158 discussion of the -00 draft. Should we add a section on it? ]] 184 discussion of the -00 draft. Should we add a section on it? See.. 185 186 http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/ 187 0132.html 188 189 http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/ 190 0135.html 191 192 ]] 159 193 160 194 2.1. Forms And Cookies 195 196 [[ JH: I am not convinced that this subsection properly belongs in 197 this overall section in that "HTTP+HTML Form based authentication" 198 <http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication> 199 is not properly a part of HTTP itself. Rather, it is a piece of 200 applications layered on top of HTTP. Use of cookies for state 201 management (e.g. session maintanence) can be considered such, however 202 (although there is no overall specification for HTTP user agents 203 stipulating that they must implement cookies (nominally [RFC2109])). 204 Perhaps this section should be should be retitled "HTTP 205 Authentication". 206 207 Note: The httpstate WG was recently chartered to develop a successor 208 to [RFC2109]. See.. 209 210 http://www.ietf.org/dyn/wg/charter/httpstate-charter.html 211 212 ]] 161 213 162 214 Almost all HTTP authentication that involves a human using a web … … 164 216 stored in cookies. For cookies, most implementations rely on the 165 217 "Netscape specification", which is described loosely in section 10 of 166 167 168 169 Hoffman & Melnikov Expires September 10, 2009 [Page 3]170 171 172 Internet-Draft Security Requirements for HTTP March 2009173 174 175 218 "HTTP State Management Mechanism" [RFC2109]. The protocol in RFC 176 219 2109 is relatively widely implemented, but most clients don't 177 220 advertise support for it. RFC 2109 was later updated [RFC2965], but 178 221 the newer version is not widely implemented. 222 223 224 225 226 Hodges & Leiba Expires September 2, 2009 [Page 4] 227 228 229 Internet-Draft Security Requirements for HTTP March 2009 230 179 231 180 232 Forms and cookies have many properties that make them an excellent … … 220 272 have no use. 221 273 222 223 224 225 226 Hoffman & Melnikov Expires September 10, 2009 [Page 4]227 228 229 Internet-Draft Security Requirements for HTTP March 2009230 231 232 274 2.2. HTTP Access Authentication 233 275 … … 236 278 which defines two optional mechanisms. Both of these mechanisms are 237 279 extremely rarely used in comparison to forms and cookies, but some 280 281 282 283 Hodges & Leiba Expires September 2, 2009 [Page 5] 284 285 286 Internet-Draft Security Requirements for HTTP March 2009 287 288 238 289 degree of support for one or both is available in many 239 290 implementations. Neither scheme provides presentation control, … … 269 320 Digest has some properties that are preferable to Basic and Cookies. 270 321 Credentials are not immediately reusable by parties that observe or 271 receive them, and session data can be transmitted along 322 receive them, and session data can be transmitted alongside 272 323 credentials with each request, allowing servers to validate 273 324 credentials only when absolutely necessary. Authentication data … … 278 329 implementations do not implement the mode that provides full message 279 330 integrity. Perhaps one reason is that implementation experience has 280 281 282 283 Hoffman & Melnikov Expires September 10, 2009 [Page 5]284 285 286 Internet-Draft Security Requirements for HTTP March 2009287 288 289 331 shown that in some cases, especially those involving large requests 290 332 or responses such as streams, the message integrity mode is … … 293 335 whether message-body integrity has been violated and hence whether 294 336 the request can be processed. 337 338 339 340 Hodges & Leiba Expires September 2, 2009 [Page 6] 341 342 343 Internet-Draft Security Requirements for HTTP March 2009 344 295 345 296 346 Digest is extremely susceptible to offline dictionary attacks, making … … 335 385 SPNEGO [RFC4178] GSSAPI [RFC4559]. In Microsoft's implementation, 336 386 SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan 337 338 339 340 Hoffman & Melnikov Expires September 10, 2009 [Page 6]341 342 343 Internet-Draft Security Requirements for HTTP March 2009344 345 346 387 Manager protocols). 347 388 … … 351 392 cryptography, but extensions for use of other authentication 352 393 mechnanisms such as PKIX certificates and two-factor tokens are also 394 395 396 397 Hodges & Leiba Expires September 2, 2009 [Page 7] 398 399 400 Internet-Draft Security Requirements for HTTP March 2009 401 402 353 403 common. Kerberos was designed to work under the assumption that 354 404 packets traveling along the network can be read, modified, and … … 362 412 However the requirement for having a separate network authentication 363 413 service might be a barrier to deployment. 414 415 2.2.4.2. OAuth 416 417 [[ See.. 418 419 http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt 420 421 http://www.ietf.org/id/draft-hammer-oauth-10.txt 422 423 ]] 364 424 365 425 2.3. Centrally-Issued Tickets … … 390 450 based application protocols. 391 451 452 453 454 Hodges & Leiba Expires September 2, 2009 [Page 8] 455 456 457 Internet-Draft Security Requirements for HTTP March 2009 458 459 392 460 [[ This section could really use a good definition of "Web Services" 393 to differentiate it from REST. ]] 394 395 396 397 Hoffman & Melnikov Expires September 10, 2009 [Page 7] 398 399 400 Internet-Draft Security Requirements for HTTP March 2009 401 461 to differentiate it from REST. See.. 462 463 http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/ 464 0536.html 465 466 ]] 402 467 403 468 2.5. Transport Layer Security … … 428 493 429 494 430 4. Security Considerations 495 4. IANA Considerations 496 497 This document has no actions for IANA. 498 499 500 5. Security Considerations 431 501 432 502 This entire document is about security considerations. 433 503 434 504 435 5. Normative References 505 6. References 506 507 508 509 510 511 Hodges & Leiba Expires September 2, 2009 [Page 9] 512 513 514 Internet-Draft Security Requirements for HTTP March 2009 515 516 517 6.1. Normative References 436 518 437 519 [Apache_Digest] … … 448 530 3", BCP 9, RFC 2026, October 1996. 449 531 450 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management451 452 453 454 Hoffman & Melnikov Expires September 10, 2009 [Page 8]455 456 457 Internet-Draft Security Requirements for HTTP March 2009458 459 460 Mechanism", RFC 2109, February 1997.461 462 532 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use 463 533 and Interpretation of HTTP Version Numbers", RFC 2145, … … 493 563 494 564 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 565 566 567 568 Hodges & Leiba Expires September 2, 2009 [Page 10] 569 570 571 Internet-Draft Security Requirements for HTTP March 2009 572 573 495 574 Kerberos and NTLM HTTP Authentication in Microsoft 496 575 Windows", RFC 4559, June 2006. … … 500 579 www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research>. 501 580 581 6.2. Informative References 582 583 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 584 Mechanism", RFC 2109, February 1997. 585 502 586 503 587 Appendix A. Acknowledgements … … 508 592 509 593 510 511 Hoffman & Melnikov Expires September 10, 2009 [Page 9]512 513 514 Internet-Draft Security Requirements for HTTP March 2009515 516 517 594 Appendix B. Document History 518 595 … … 543 620 Added the suggestions about splitting for browsers and automation, 544 621 and about adding NTLM, to be beginning of 2. 622 623 624 625 Hodges & Leiba Expires September 2, 2009 [Page 11] 626 627 628 Internet-Draft Security Requirements for HTTP March 2009 629 545 630 546 631 In 2.1, added "that involves a human using a web browser" in the … … 561 646 562 647 to 563 564 565 566 567 568 Hoffman & Melnikov Expires September 10, 2009 [Page 10]569 570 571 Internet-Draft Security Requirements for HTTP March 2009572 648 573 649 … … 596 672 Filled in section 2.5. 597 673 674 B.4. Changes between -02 and -03 675 676 Changed IPR licensing from "full3978" to "pre5378Trust200902". 677 678 679 680 681 682 Hodges & Leiba Expires September 2, 2009 [Page 12] 683 684 685 Internet-Draft Security Requirements for HTTP March 2009 686 687 688 B.5. Changes between -03 and -04 689 690 Changed authors to be Jeff Hodges (JH) and Barry Leiba (BL) with 691 permission of Paul Hoffman, Alexey Melnikov, and Mark Nottingham 692 (httpbis chair). 693 694 Added "OVERALL ISSUE" to introduction. 695 696 Added links to email messages on mailing list(s) where various 697 suggestions for this document were brought up. I.e. added various 698 links to those comments herein delimited by "[[...]]" braces. 699 700 Noted JH's belief that "HTTP+HTML Form based authentication" aka 701 "Forms And Cookies" doesn't properly belong in the section where it 702 presently resides. Added link to httpstate WG. 703 704 Added references to OAuth. Section needs to be filled-in as yet. 705 706 Moved ref to RFC2109 to new "Informative References" section, and 707 added a placeholder "IANA Considerations" section in order to satisfy 708 IDnits checking. 709 598 710 599 711 Authors' Addresses 600 712 601 Paul Hoffman 602 VPN Consortium 603 604 Email: paul.hoffman@vpnc.org 605 606 607 Alexey Melnikov 608 Isode Ltd. 609 610 Email: alexey.melnikov@isode.com 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 Hoffman & Melnikov Expires September 10, 2009 [Page 11] 626 627 713 Jeff Hodges 714 PayPal 715 716 Email: Jeff.Hodges@PayPal.com 717 718 719 Barry Leiba 720 Huawei Technologies 721 722 Phone: +1 646 827 0648 723 Email: barryleiba@computer.org 724 URI: http://internetmessagingtechnology.org/ 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 Hodges & Leiba Expires September 2, 2009 [Page 13] 740 741 -
draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.xml
r551 r787 17 17 docName="draft-ietf-httpbis-security-properties-latest"> 18 18 19 <?xml-stylesheet type='text/xsl' href='rfc2629xslt/rfc2629.xslt' ?> 20 21 <?rfc toc="yes" ?> 22 <?rfc symrefs="yes" ?> 23 <?rfc sortrefs="yes"?> 24 <?rfc strict="yes" ?> 25 <?rfc compact="yes" ?> 26 <?rfc subcompact="no" ?> 27 <?rfc linkmailto='no'?> 28 <?rfc comments="yes"?> 29 <?rfc inline="yes"?> 30 31 <front> 32 <title>Security Requirements for HTTP</title> 33 <author initials='P.' surname="Hoffman" fullname='Paul Hoffman'> 34 <organization>VPN Consortium</organization> 35 <address><email>paul.hoffman@vpnc.org</email> </address> 36 </author> 37 <author initials='A.' surname="Melnikov" fullname='Alexey Melnikov'> 38 <organization>Isode Ltd.</organization> 39 <address><email>alexey.melnikov@isode.com</email> </address> 40 </author> 41 <date year="2009" month='March'/> 42 <abstract> 43 <t>Recent IESG practice dictates that IETF protocols must specify 44 mandatory-to-implement security mechanisms, so that 45 all conformant implementations share a common baseline. This 46 document examines all widely deployed HTTP security 47 technologies, and analyzes the trade-offs of 48 each.</t> 49 </abstract> 50 </front> 51 52 <middle> 19 <?xml-stylesheet type="text/xsl" href="rfc2629xslt/rfc2629.xslt" ?> 20 21 <?rfc toc="yes" ?> 22 <?rfc symrefs="yes" ?> 23 <?rfc sortrefs="yes"?> 24 <?rfc strict="yes" ?> 25 <?rfc compact="yes" ?> 26 <?rfc subcompact="no" ?> 27 <?rfc linkmailto="no"?> 28 <?rfc comments="yes"?> 29 <?rfc inline="yes"?> 30 31 <front> 32 <title>Security Requirements for HTTP</title> 33 <author initials="J." surname="Hodges" fullname="Jeff Hodges"> 34 <organization>PayPal</organization> 35 <address> 36 <email>Jeff.Hodges@PayPal.com</email> 37 </address> 38 </author> 39 <author initials='B.' surname="Leiba" fullname='Barry Leiba'> 40 <organization>Huawei Technologies</organization> 41 <address> 42 <phone>+1 646 827 0648</phone> 43 <email>barryleiba@computer.org</email> 44 <uri>http://internetmessagingtechnology.org/</uri> 45 </address> 46 </author> 47 <date year="2009" month="March"/> 48 <abstract> 49 <t> 50 Recent IESG practice dictates that IETF protocols must 51 specify mandatory-to-implement (MTI) security mechanisms, so 52 that all conformant implementations share a common 53 baseline. This document examines all widely deployed 54 HTTP security technologies, and analyzes the 55 trade-offs of each. 56 </t> 57 </abstract> 58 </front> 59 60 <middle> 53 61 54 <section title="Introduction"> 55 56 <t>Recent IESG practice dictates that IETF protocols are required to 57 specify mandatory to implement security mechanisms. "The IETF 58 Standards Process" <xref target="RFC2026"/> does not require that 59 protocols specify mandatory security mechanisms. "Strong Security 60 Requirements for IETF Standard Protocols" <xref target="RFC3365"/> 61 requires that all IETF protocols provide a mechanism for implementers 62 to provide strong security. RFC 3365 does not define the term "strong 63 security".</t> 64 65 <t>"Security Mechanisms for the Internet" <xref target="RFC3631"/> is 66 not an IETF procedural RFC, but it is perhaps most relevant. Section 67 2.2 states:</t> 68 69 <figure><artwork> 62 <section title="Introduction"> 63 64 <t> 65 Recent IESG practice dictates that IETF protocols be 66 required to specify mandatory-to-implement (MTI) security 67 mechanisms. "The IETF Standards Process" <xref 68 target="RFC2026"/> does not require that protocols 69 specify mandatory security mechanisms. "Strong 70 Security Requirements for IETF Standard Protocols" 71 <xref target="RFC3365"/> requires that all IETF 72 protocols provide a mechanism for implementers to 73 provide strong security. RFC 3365 does not define the 74 term "strong security". 75 </t> 76 77 <t> 78 "Security Mechanisms for the Internet" <xref 79 target="RFC3631"/> is not an IETF procedural RFC, but 80 it is perhaps most relevant. Section 2.2 states: 81 </t> 82 83 <figure> 84 <artwork> 70 85 We have evolved in the IETF the notion of "mandatory to implement" 71 86 mechanisms. This philosophy evolves from our primary desire to … … 77 92 selection of non-overlapping mechanisms being deployed in the 78 93 different implementations. 79 </artwork></figure> 80 81 <t>This document examines the effects of applying security constraints 82 to Web applications, documents the properties that result from each 83 method, and will make Best Current Practice recommendations for HTTP 84 security in a later document version. At the moment, it is mostly a 85 laundry list of security technologies and tradeoffs.</t> 86 87 </section> 88 89 <section title="Existing HTTP Security Mechanisms"> 90 91 <t>For HTTP, the IETF generally defines "security mechanisms" as some 92 combination of access authentication and/or a secure transport.</t> 93 94 <t>[[ There is a suggestion that this section be split into 95 "browser-like" and "automation-like" subsections. ]]</t> 96 97 <t>[[ NTLM (shudder) was brought up in the WG a few times in 98 the discussion of the -00 draft. Should we add a section on it? ]]</t> 99 100 <section title="Forms And Cookies"> 101 102 <t>Almost all HTTP authentication that involves a human 103 using a web browser is accomplished through HTML forms, 104 with session identifiers stored in cookies. For cookies, most implementations 105 rely on the "Netscape specification", which is described loosely in 106 section 10 of "HTTP State Management Mechanism" <xref 107 target="RFC2109"/>. The protocol in RFC 2109 is relatively widely 108 implemented, but most clients don't advertise support for it. RFC 2109 109 was later updated <xref target="RFC2965"/>, but the newer version is 110 not widely implemented.</t> 111 112 <t>Forms and cookies have many properties that make them an 113 excellent solution for some implementers. However, many of those 114 properties introduce serious security trade-offs.</t> 115 116 <t>HTML forms provide a large degree of control over presentation, 117 which is an imperative for many websites. However, this increases user 118 reliance on the appearance of the interface. Many users do not 119 understand the construction of URIs <xref target="RFC3986"/>, or their 120 presentation in common clients <xref target="PhishingHOWTO"/>. 121 As a result, 122 forms are extremely vulnerable to spoofing.</t> 123 124 <t>HTML forms provide acceptable internationalization if used 125 carefully, at the cost of being transmitted as normal HTTP content in 126 all cases (credentials are not differentiated in the protocol).</t> 127 128 <t>Many Web browsers have an auto-complete feature that stores a 129 user's information and pre-populates fields in forms. This is 130 considered to be a convenience mechanism, and convenience mechanisms 131 often have negative security properties. The security concerns with 132 auto-completion are particularly poignant for web browsers that reside 133 on computers with multiple users. HTML forms provide a facility for 134 sites to indicate that a field, such as a password, should never be 135 pre-populated. However, it is clear that some form creators do not use 136 this facility when they should.</t> 137 138 <t>The cookies that result from a successful form submission make it 139 unnecessary to validate credentials with each HTTP request; this makes 140 cookies an excellent property for scalability. Cookies are susceptible 141 to a large variety of XSS (cross-site scripting) attacks, and measures 142 to prevent such attacks will never be as stringent as necessary for 143 authentication credentials because cookies are used for many purposes. 144 Cookies are also susceptible to a wide variety of attacks from 145 malicious intermediaries and observers. The possible attacks depend on 146 the contents of the cookie data. There is no standard format for most 147 of the data.</t> 148 149 <t>HTML forms and cookies provide flexible ways of ending a session 150 from the client.</t> 151 152 <t>HTML forms require an HTML rendering engine for which many protocols 153 have no use.</t> 154 155 </section> 156 157 <section title="HTTP Access Authentication"> 158 159 <t>HTTP 1.1 provides a simple authentication framework, "HTTP 160 Authentication: Basic and Digest Access Authentication" <xref 161 target="RFC2617"/>, which defines two optional mechanisms. Both of these 162 mechanisms are extremely rarely used in comparison to forms and 163 cookies, but some degree of support for one or both is available in 164 many implementations. Neither scheme provides presentation control, 165 logout capabilities, or interoperable internationalization.</t> 166 167 <section title="Basic Authentication"> 168 169 <t>Basic Authentication (normally called just "Basic") transmits 170 usernames and passwords in the clear. It is very easy to implement, 171 but not at all secure unless used over a secure transport.</t> 172 173 <t>Basic has very poor scalability properties because credentials must 174 be revalidated with every request, and because secure transports 175 negate many of HTTP's caching mechanisms. Some implementations use 176 cookies in combination with Basic credentials, but there is no 177 standard method of doing so.</t> 178 179 <t>Since Basic credentials are clear text, they are reusable by any 180 party. This makes them compatible with any authentication database, at 181 the cost of making the user vulnerable to mismanaged or malicious 182 servers, even over a secure channel.</t> 183 184 <t>Basic is not interoperable when used with credentials that contain 185 characters outside of the ISO 8859-1 repertoire.</t> 186 187 </section> 188 189 <section title="Digest Authentication"> 190 191 <t>In Digest Authentication, the client transmits the results of 192 hashing user credentials with properties of the request and values 193 from the server challenge. Digest is susceptible to man-in-the-middle 194 attacks when not used over a secure transport.</t> 195 196 <t>Digest has some properties that are preferable to Basic and 197 Cookies. Credentials are not immediately reusable by parties that 198 observe or receive them, and session data can be transmitted along 199 side credentials with each request, allowing servers to validate 200 credentials only when absolutely necessary. Authentication data 201 session keys are distinct from other protocol traffic.</t> 202 203 <t>Digest includes many modes of operation, but only the simplest 204 modes enjoy any degree of interoperability. For example, most 205 implementations do not implement the mode that provides full message 206 integrity. Perhaps one reason is that implementation experience has 207 shown that in some cases, especially those involving large requests or 208 responses such as streams, the message integrity mode is impractical 209 because it requires servers to analyze the full request before 210 determining whether the client knows the shared secret or whether 211 message-body integrity has been violated and hence whether the request 212 can be processed.</t> 213 214 <t>Digest is extremely susceptible to offline dictionary attacks, 215 making it practical for attackers to perform a namespace walk 216 consisting of a few million passwords for most users.</t> 217 218 <t>Many of the most widely-deployed HTTP/1.1 clients are not compliant 219 when GET requests include a query string <xref target="Apache_Digest"/>.</t> 220 221 <t>Digest either requires that authentication databases be expressly designed 222 to accommodate it, or requires access to cleartext passwords. 223 As a result, many authentication databases that chose to do the former are 224 incompatible, including the most common method of storing passwords 225 for use with Forms and Cookies.</t> 226 227 <t>Many Digest capabilities included to prevent replay attacks expose 228 the server to Denial of Service attacks.</t> 229 230 <t>Digest is not interoperable when used with credentials that contain 231 characters outside of the ISO 8859-1 repertoire.</t> 232 233 </section> 234 235 <section title="Authentication Using Certificates in TLS"> 236 237 <t>Running HTTP over TLS provides authentication of the HTTP server to 238 the client. HTTP over TLS can also provides authentication of the 239 client to the server using certificates. Although forms are a much 240 more common way to authenticate users to HTTP servers, TLS client 241 certificates are widely used in some environments. The 242 public key infrastructure (PKI) used 243 to validate certificates in TLS can be rooted in public trust anchors 244 or can be based on local trust anchors.</t> 245 246 </section> 247 248 <section title="Other Access Authentication Schemes"> 249 250 <t>There are many niche schemes that make use of the HTTP 251 Authentication framework, but very few are well documented. Some are 252 bound to transport layer connections.</t> 253 254 <section title="Negotiate (GSS-API) Authentication"> 255 256 <t>Microsoft has designed an HTTP authentication mechanism that utilizes 257 SPNEGO <xref target="RFC4178"/> GSSAPI <xref target='RFC4559'/>. In Microsoft's 258 implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT 259 Lan Manager protocols).</t> 260 261 <t>In Kerberos, clients and servers rely on a trusted third-party authentication service 262 which maintains its own authentication database. Kerberos is typically used with shared 263 secret key cryptography, but extensions for use of other authentication mechnanisms such 264 as PKIX certificates and two-factor tokens are also common. 265 Kerberos was designed to work under the assumption that packets traveling along 266 the network can be read, modified, and inserted at will.</t> 267 268 <t>Unlike Digest, Negotiate authentication can take multiple round trips (client sending 269 authentication data in Authorization, server sending authentication data in WWW-Authenticate) 270 to complete. 271 </t> 272 273 <t>Kerberos authentication is generally more secure than Digest. However the requirement 274 for having a separate network authentication service might be a barrier to deployment.</t> 275 276 <!-- 277 Kerberos didn't support Unicode till relatively recently. I am not sure if this 278 is an issue with Microsoft's implementation. 279 --> 280 281 </section> 282 283 </section> 284 285 </section> 286 287 <section title="Centrally-Issued Tickets"> 288 289 <t>Many large Internet services rely on authentication schemes that 290 center on clients consulting a single service for a time-limited 291 ticket that is validated with undocumented heuristics. Centralized 292 ticket issuing has the advantage that users may employ one set of 293 credentials for many services, and clients don't send credentials to 294 many servers. This approach is often no more than a sophisticated 295 application of forms and cookies.</t> 296 297 <t>All of the schemes in wide use are proprietary and non-standard, 298 and usually are undocumented. There are many standardization efforts 299 in progress, as usual.</t> 300 301 </section> 302 303 <section title='Web Services'> 304 305 <t>Many security properties mentioned in this document have been recast in 306 XML-based protocols, using HTTP as a substitute for TCP. Like the 307 amalgam of HTTP technologies mentioned above, the XML-based protocols 308 are defined by an ever-changing combination of standard and 309 vendor-produced specifications, some of which may be obsoleted at any 310 time <xref target="WS-Pagecount"/> without any documented change control 311 procedures. These protocols usually don't have much in common with the 312 Architecture of the World Wide Web. It's not clear why the term "Web" is 313 used to group them, but they are obviously out of scope for HTTP-based 314 application protocols.</t> 315 316 <t>[[ This section could really use a good definition of 317 "Web Services" to differentiate it from REST. ]]</t> 318 319 </section> 320 321 <section title="Transport Layer Security"> 322 323 <t>In addition to using TLS for client and/or server authentication, it is also 324 very commonly used to protect the confidentiality and integrity of the 325 HTTP session. For instance, both HTTP Basic authentication and Cookies 326 are often protected against snooping by TLS.</t> 327 328 <t>It should be noted that, in that case, TLS does not protect against a 329 breach of the credential store at the server or against a keylogger or 330 phishing interface at the client. TLS does not change the fact that 331 Basic Authentication passwords are reusable and does not address that 332 weakness.</t> 333 334 </section> 335 336 </section> 337 338 <section title="Revisions To HTTP"> 339 340 <t>Is is possible that HTTP will be revised in the future. "HTTP/1.1" 341 <xref target="RFC2616"/> and "Use and Interpretation of HTTP Version 342 Numbers" <xref target="RFC2145"/> define conformance requirements in 343 relation to version numbers. In HTTP 1.1, all authentication 344 mechanisms are optional, and no single transport substrate is 345 specified. Any HTTP revision that adds a mandatory security mechanism 346 or transport substrate will have to increment the HTTP version number 347 appropriately. All widely used schemes are non-standard and/or 348 proprietary.</t> 349 350 </section> 351 352 <section title="Security Considerations"> 353 354 <t>This entire document is about security considerations.</t> 355 356 </section> 357 358 </middle> 359 360 <back> 361 362 <references title='Normative References'> 94 </artwork> 95 </figure> 96 97 <t> 98 This document examines the effects of applying 99 security constraints to Web applications, documents 100 the properties that result from each method, and will 101 make Best Current Practice recommendations for HTTP 102 security in a later document version. At the moment, 103 it is mostly a laundry list of security technologies 104 and tradeoffs. 105 </t> 106 107 <t> 108 [[ OVERALL ISSUE: It isn't entirely clear to the present editors 109 what the purpose of this document is. On one hand it 110 could be a compendium of peer-entity authentication 111 mechanisms (as it is presently) and make MTI recommendations 112 thereof, or it could be a place for various security 113 considerations (either coalesced here from the other 114 httpbis specs, or reserved for the more gnarly cross-spec 115 composite ones), or both. This needs to be clarified. 116 ]] 117 </t> 118 119 </section> 120 121 <section title="Existing HTTP Security Mechanisms"> 122 123 <t> 124 For HTTP, the IETF generally defines "security 125 mechanisms" as some combination of access 126 authentication and/or a secure transport. 127 </t> 128 129 <t> 130 [[ There is a suggestion that this section be split 131 into "browser-like" and "automation-like" 132 subsections. See: 133 <list> 134 <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0180.html</t> 135 <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0183.html</t> 136 </list> 137 ]] 138 </t> 139 140 <t> 141 [[ NTLM (shudder) 142 was brought up in the WG a few times 143 in the discussion of the -00 draft. Should we add a 144 section on it? See.. 145 <list> 146 <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0132.html</t> 147 <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0135.html</t> 148 </list> 149 ]] 150 </t> 151 152 <section title="Forms And Cookies"> 153 154 <t> 155 [[ JH: I am not convinced that this subsection 156 properly belongs in this overall section in that 157 "HTTP+HTML Form based authentication" 158 <http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication> 159 is not properly a part of HTTP itself. Rather, it is 160 a piece of applications layered on top of HTTP. Use of cookies for 161 state management (e.g. session maintanence) can be 162 considered such, however (although there is no 163 overall specification for HTTP user agents stipulating 164 that they must implement cookies (nominally 165 <xref target="RFC2109"/>)). Perhaps this section should be 166 should be retitled "HTTP Authentication". 167 </t> 168 <t> 169 Note: The httpstate WG was recently chartered to develop a successor to 170 <xref target="RFC2109"/>. See.. 171 <list> 172 <t>http://www.ietf.org/dyn/wg/charter/httpstate-charter.html</t> 173 </list> 174 </t> 175 <t> 176 ]] 177 </t> 178 179 <t> 180 Almost all HTTP authentication that involves a 181 human using a web browser is accomplished through 182 HTML forms, with session identifiers stored in 183 cookies. For cookies, most implementations rely on 184 the "Netscape specification", which is described 185 loosely in section 10 of "HTTP State Management 186 Mechanism" <xref target="RFC2109"/>. The protocol 187 in RFC 2109 is relatively widely implemented, but 188 most clients don't advertise support for it. RFC 189 2109 was later updated <xref target="RFC2965"/>, 190 but the newer version is not widely implemented. 191 </t> 192 193 <t> 194 Forms and cookies have many properties that make 195 them an excellent solution for some 196 implementers. However, many of those properties 197 introduce serious security trade-offs. 198 </t> 199 200 <t> 201 HTML forms provide a large degree of control over 202 presentation, which is an imperative for many 203 websites. However, this increases user reliance on 204 the appearance of the interface. Many users do not 205 understand the construction of URIs <xref 206 target="RFC3986"/>, or their presentation in 207 common clients <xref target="PhishingHOWTO"/>. As 208 a result, forms are extremely vulnerable to 209 spoofing. 210 </t> 211 212 <t> 213 HTML forms provide acceptable internationalization 214 if used carefully, at the cost of being 215 transmitted as normal HTTP content in all cases 216 (credentials are not differentiated in the 217 protocol). 218 </t> 219 220 <t> 221 Many Web browsers have an auto-complete feature 222 that stores a user's information and pre-populates 223 fields in forms. This is considered to be a 224 convenience mechanism, and convenience mechanisms 225 often have negative security properties. The 226 security concerns with auto-completion are 227 particularly poignant for web browsers that reside 228 on computers with multiple users. HTML forms 229 provide a facility for sites to indicate that a 230 field, such as a password, should never be 231 pre-populated. However, it is clear that some form 232 creators do not use this facility when they 233 should. 234 </t> 235 236 <t> 237 The cookies that result from a successful form 238 submission make it unnecessary to validate 239 credentials with each HTTP request; this makes 240 cookies an excellent property for 241 scalability. Cookies are susceptible to a large 242 variety of XSS (cross-site scripting) attacks, and 243 measures to prevent such attacks will never be as 244 stringent as necessary for authentication 245 credentials because cookies are used for many 246 purposes. Cookies are also susceptible to a wide 247 variety of attacks from malicious intermediaries 248 and observers. The possible attacks depend on the 249 contents of the cookie data. There is no standard 250 format for most of the data. 251 </t> 252 253 <t> 254 HTML forms and cookies provide flexible ways of 255 ending a session from the client. 256 </t> 257 258 <t> 259 HTML forms require an HTML rendering engine for 260 which many protocols have no use. 261 </t> 262 263 </section> 264 265 <section title="HTTP Access Authentication"> 266 267 <t> 268 HTTP 1.1 provides a simple authentication 269 framework, "HTTP Authentication: Basic and Digest 270 Access Authentication" <xref target="RFC2617"/>, 271 which defines two optional mechanisms. Both of 272 these mechanisms are extremely rarely used in 273 comparison to forms and cookies, but some degree 274 of support for one or both is available in many 275 implementations. Neither scheme provides 276 presentation control, logout capabilities, or 277 interoperable internationalization. 278 </t> 279 280 <section title="Basic Authentication"> 281 282 <t> 283 Basic Authentication (normally called just 284 "Basic") transmits usernames and passwords in 285 the clear. It is very easy to implement, but 286 not at all secure unless used over a secure 287 transport. 288 </t> 289 290 <t> 291 Basic has very poor scalability properties 292 because credentials must be revalidated with 293 every request, and because secure transports 294 negate many of HTTP's caching mechanisms. Some 295 implementations use cookies in combination 296 with Basic credentials, but there is no 297 standard method of doing so. 298 </t> 299 300 <t> 301 Since Basic credentials are clear text, they 302 are reusable by any party. This makes them 303 compatible with any authentication database, 304 at the cost of making the user vulnerable to 305 mismanaged or malicious servers, even over a 306 secure channel. 307 </t> 308 309 <t> 310 Basic is not interoperable when used with 311 credentials that contain characters outside of 312 the ISO 8859-1 repertoire. 313 </t> 314 315 </section> 316 317 <section title="Digest Authentication"> 318 319 <t> 320 In Digest Authentication, the client transmits 321 the results of hashing user credentials with 322 properties of the request and values from the 323 server challenge. Digest is susceptible to 324 man-in-the-middle attacks when not used over a 325 secure transport. 326 </t> 327 328 <t> 329 Digest has some properties that are preferable 330 to Basic and Cookies. Credentials are not 331 immediately reusable by parties that observe 332 or receive them, and session data can be 333 transmitted alongside credentials with each 334 request, allowing servers to validate 335 credentials only when absolutely 336 necessary. Authentication data session keys 337 are distinct from other protocol traffic. 338 </t> 339 340 <t> 341 Digest includes many modes of operation, but 342 only the simplest modes enjoy any degree of 343 interoperability. For example, most 344 implementations do not implement the mode that 345 provides full message integrity. Perhaps one 346 reason is that implementation experience has 347 shown that in some cases, especially those 348 involving large requests or responses such as 349 streams, the message integrity mode is 350 impractical because it requires servers to 351 analyze the full request before determining 352 whether the client knows the shared secret or 353 whether message-body integrity has been 354 violated and hence whether the request can be 355 processed. 356 </t> 357 358 <t> 359 Digest is extremely susceptible to offline 360 dictionary attacks, making it practical for 361 attackers to perform a namespace walk 362 consisting of a few million passwords for most 363 users. 364 </t> 365 366 <t> 367 Many of the most widely-deployed HTTP/1.1 368 clients are not compliant when GET requests 369 include a query string <xref 370 target="Apache_Digest"/>. 371 </t> 372 373 <t> 374 Digest either requires that authentication 375 databases be expressly designed to accommodate 376 it, or requires access to cleartext passwords. 377 As a result, many authentication databases 378 that chose to do the former are incompatible, 379 including the most common method of storing 380 passwords for use with Forms and Cookies. 381 </t> 382 383 <t> 384 Many Digest capabilities included to prevent 385 replay attacks expose the server to Denial of 386 Service attacks. 387 </t> 388 389 <t> 390 Digest is not interoperable when used with 391 credentials that contain characters outside of 392 the ISO 8859-1 repertoire. 393 </t> 394 395 </section> 396 397 <section title="Authentication Using Certificates in TLS"> 398 399 <t> 400 Running HTTP over TLS provides authentication 401 of the HTTP server to the client. HTTP over 402 TLS can also provides authentication of the 403 client to the server using 404 certificates. Although forms are a much more 405 common way to authenticate users to HTTP 406 servers, TLS client certificates are widely 407 used in some environments. The public key 408 infrastructure (PKI) used to validate 409 certificates in TLS can be rooted in public 410 trust anchors or can be based on local trust 411 anchors. 412 </t> 413 414 </section> 415 416 <section title="Other Access Authentication Schemes"> 417 418 <t> 419 There are many niche schemes that make use of 420 the HTTP Authentication framework, but very 421 few are well documented. Some are bound to 422 transport layer connections. 423 </t> 424 425 <section title="Negotiate (GSS-API) Authentication"> 426 427 <t> 428 Microsoft has designed an HTTP 429 authentication mechanism that utilizes 430 SPNEGO <xref target="RFC4178"/> GSSAPI 431 <xref target="RFC4559"/>. In Microsoft's 432 implementation, SPNEGO allows selection 433 between Kerberos and NTLM (Microsoft NT 434 Lan Manager protocols). 435 </t> 436 437 <t> 438 In Kerberos, clients and servers rely on a 439 trusted third-party authentication service 440 which maintains its own authentication 441 database. Kerberos is typically used with 442 shared secret key cryptography, but 443 extensions for use of other authentication 444 mechnanisms such as PKIX certificates and 445 two-factor tokens are also common. 446 Kerberos was designed to work under the 447 assumption that packets traveling along 448 the network can be read, modified, and 449 inserted at will. 450 </t> 451 452 <t> 453 Unlike Digest, Negotiate authentication 454 can take multiple round trips (client 455 sending authentication data in 456 Authorization, server sending 457 authentication data in WWW-Authenticate) 458 to complete. 459 </t> 460 461 <t> 462 Kerberos authentication is generally more 463 secure than Digest. However the 464 requirement for having a separate network 465 authentication service might be a barrier 466 to deployment. 467 </t> 468 469 <!-- 470 Kerberos didn't support Unicode till relatively recently. I am not sure if this 471 is an issue with Microsoft's implementation. 472 --> 473 474 </section> 475 476 <section title="OAuth"> 477 478 <t> 479 [[ See.. 480 <list> 481 <t>http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt</t> 482 <t>http://www.ietf.org/id/draft-hammer-oauth-10.txt</t> 483 </list> 484 ]] 485 </t> 486 487 </section> 488 489 </section> 490 491 </section> 492 493 <section title="Centrally-Issued Tickets"> 494 495 <t> 496 Many large Internet services rely on 497 authentication schemes that center on clients 498 consulting a single service for a time-limited 499 ticket that is validated with undocumented 500 heuristics. Centralized ticket issuing has the 501 advantage that users may employ one set of 502 credentials for many services, and clients don't 503 send credentials to many servers. This approach is 504 often no more than a sophisticated application of 505 forms and cookies. 506 </t> 507 508 <t> 509 All of the schemes in wide use are proprietary and 510 non-standard, and usually are undocumented. There 511 are many standardization efforts in progress, as 512 usual. 513 </t> 514 515 </section> 516 517 <section title="Web Services"> 518 519 <t> 520 Many security properties mentioned in this 521 document have been recast in XML-based protocols, 522 using HTTP as a substitute for TCP. Like the 523 amalgam of HTTP technologies mentioned above, the 524 XML-based protocols are defined by an 525 ever-changing combination of standard and 526 vendor-produced specifications, some of which may 527 be obsoleted at any time <xref 528 target="WS-Pagecount"/> without any documented 529 change control procedures. These protocols usually 530 don't have much in common with the Architecture of 531 the World Wide Web. It's not clear why the term 532 "Web" is used to group them, but they are 533 obviously out of scope for HTTP-based application 534 protocols. 535 </t> 536 537 <t> 538 [[ This section could really use a good definition 539 of "Web Services" to differentiate it from 540 REST. See.. 541 <list> 542 <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0536.html</t> 543 </list> 544 ]] 545 </t> 546 547 </section> 548 549 <section title="Transport Layer Security"> 550 551 <t> 552 In addition to using TLS for client and/or server 553 authentication, it is also very commonly used to 554 protect the confidentiality and integrity of the 555 HTTP session. For instance, both HTTP Basic 556 authentication and Cookies are often protected 557 against snooping by TLS. 558 </t> 559 560 <t> 561 It should be noted that, in that case, TLS does 562 not protect against a breach of the credential 563 store at the server or against a keylogger or 564 phishing interface at the client. TLS does not 565 change the fact that Basic Authentication 566 passwords are reusable and does not address that 567 weakness. 568 </t> 569 570 </section> 571 572 </section> 573 574 <section title="Revisions To HTTP"> 575 576 <t> 577 Is is possible that HTTP will be revised in the 578 future. "HTTP/1.1" <xref target="RFC2616"/> and "Use 579 and Interpretation of HTTP Version Numbers" <xref 580 target="RFC2145"/> define conformance requirements in 581 relation to version numbers. In HTTP 1.1, all 582 authentication mechanisms are optional, and no single 583 transport substrate is specified. Any HTTP revision 584 that adds a mandatory security mechanism or transport 585 substrate will have to increment the HTTP version 586 number appropriately. All widely used schemes are 587 non-standard and/or proprietary. 588 </t> 589 590 </section> 591 592 <section title="IANA Considerations"> 593 <t>This document has no actions for IANA.</t> 594 </section> 595 596 <section title="Security Considerations"> 597 598 <t>This entire document is about security considerations.</t> 599 600 </section> 601 602 603 604 </middle> 605 606 <back> 607 608 <references title="Normative References"> 363 609 364 610 &rfc2026; 365 &rfc2109;366 611 &rfc2145; 367 612 &rfc2616; … … 374 619 &rfc4559; 375 620 376 <reference anchor= 'Apache_Digest'377 target= 'http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html'>621 <reference anchor="Apache_Digest" 622 target="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html"> 378 623 <front> 379 624 <title>Apache HTTP Server - mod_auth_digest</title> … … 381 626 <organization /> 382 627 </author> 383 <date year= '' month=''/>628 <date year="" month="" /> 384 629 </front> 385 630 </reference> 386 631 387 <reference anchor= 'PhishingHOWTO'388 target= 'http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf'>632 <reference anchor="PhishingHOWTO" 633 target="http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf"> 389 634 <front> 390 635 <title>Phishing Tips and Techniques</title> 391 636 <author initials="P." surname="Gutmann" fullname="Peter Gutmann"> 392 637 <organization /></author> 393 <date year= '2008' month='February'/>638 <date year="2008" month="February" /> 394 639 </front> 395 640 </reference> 396 641 397 <reference anchor= 'WS-Pagecount'398 target= 'http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research'>642 <reference anchor="WS-Pagecount" 643 target="http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research"> 399 644 <front> 400 645 <title>WS-Pagecount</title> … … 402 647 <organization /> 403 648 </author> 404 <date year= '2004' month='September'/>649 <date year="2004" month="September" /> 405 650 </front> 406 651 </reference> 407 652 408 </references> 409 410 <section title='Acknowledgements'> 411 412 <t>Much of the material in this document was written by Rob Sayre, 413 who first promoted the topic. Many others on the HTTPbis Working 414 Group have contributed to this document in the discussion.</t> 415 416 </section> 417 418 <section title='Document History'> 419 420 <t>[This entire section is to be removed when published as an RFC.]</t> 421 422 <section title='Changes between draft-sayre-http-security-variance-00 and 423 draft-ietf-httpbis-security-properties-00'> 424 425 <t>Changed the authors to Paul Hoffman and Alexey Melnikov, with permission 426 of Rob Sayre.</t> 427 428 <t>Made lots of minor editorial changes.</t> 429 430 <t>Removed what was section 2 (Requirements Notation), the reference 431 to RFC 2119, and any use of 2119ish all-caps words.</t> 432 433 <t>In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 434 repertoire" to match the definition of "TEXT" in RFC 2616.</t> 435 436 <t>Added minor text to the Security Considerations section.</t> 437 438 <t>Added URLs to the two non-RFC references.</t> 439 440 </section> 441 442 443 <section title='Changes between -00 and -01'> 444 445 <t>Fixed some editorial nits reported by Iain Calder.</t> 446 447 <t>Added the suggestions about splitting for browsers and 448 automation, and about adding NTLM, to be beginning of 2.</t> 449 450 <t>In 2.1, added "that involves a human 451 using a web browser" in the first sentence.</t> 452 453 <t>In 2.1, changed "session key" to "session identifier".</t> 454 455 <t>In 2.2.2, changed 653 </references> 654 655 <references title="Informative References"> 656 657 &rfc2109; 658 659 660 </references> 661 662 <section title="Acknowledgements"> 663 664 <t> 665 Much of the material in this document was written by 666 Rob Sayre, who first promoted the topic. Many others 667 on the HTTPbis Working Group have contributed to this 668 document in the discussion. 669 </t> 670 671 </section> 672 673 <section title="Document History"> 674 675 <t>[This entire section is to be removed when published as an RFC.]</t> 676 677 <section title="Changes between draft-sayre-http-security-variance-00 and 678 draft-ietf-httpbis-security-properties-00"> 679 680 <t>Changed the authors to Paul Hoffman and Alexey Melnikov, with permission 681 of Rob Sayre.</t> 682 683 <t>Made lots of minor editorial changes.</t> 684 685 <t>Removed what was section 2 (Requirements Notation), the reference 686 to RFC 2119, and any use of 2119ish all-caps words.</t> 687 688 <t>In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 689 repertoire" to match the definition of "TEXT" in RFC 2616.</t> 690 691 <t>Added minor text to the Security Considerations section.</t> 692 693 <t>Added URLs to the two non-RFC references.</t> 694 695 </section> 696 697 698 <section title="Changes between -00 and -01"> 699 700 <t>Fixed some editorial nits reported by Iain Calder.</t> 701 702 <t>Added the suggestions about splitting for browsers and 703 automation, and about adding NTLM, to be beginning of 2.</t> 704 705 <t>In 2.1, added "that involves a human 706 using a web browser" in the first sentence.</t> 707 708 <t>In 2.1, changed "session key" to "session identifier".</t> 709 710 <t>In 2.2.2, changed 456 711 <figure><artwork><![CDATA[ 457 712 Digest includes many modes of operation, but only the simplest modes … … 463 718 knows the shared secret. 464 719 ]]></artwork></figure> 465 to720 to 466 721 <figure><artwork><![CDATA[ 467 722 Digest includes many modes of operation, but only the simplest … … 478 733 </t> 479 734 480 <t>In 2.4, asked for a definition of "Web Services".</t> 481 482 <t>In A, added the WG.</t> 483 484 </section> 485 486 487 <section title='Changes between -01 and -02'> 488 489 <t>In section 2.1, added more to the paragraph on auto-completion of 490 HTML forms.</t> 491 492 <t>Added the section on TLS for authentication.</t> 493 494 <t>Filled in section 2.5.</t> 495 496 </section> 497 498 499 </section> 500 501 </back> 735 <t>In 2.4, asked for a definition of "Web Services".</t> 736 737 <t>In A, added the WG.</t> 738 739 </section> 740 741 742 <section title="Changes between -01 and -02"> 743 744 <t>In section 2.1, added more to the paragraph on auto-completion of 745 HTML forms.</t> 746 747 <t>Added the section on TLS for authentication.</t> 748 749 <t>Filled in section 2.5.</t> 750 751 </section> 752 753 754 <section title="Changes between -02 and -03"> 755 756 <t> 757 Changed IPR licensing from "full3978" to "pre5378Trust200902". 758 </t> 759 760 </section> 761 762 763 <section title="Changes between -03 and -04"> 764 765 <t> 766 Changed authors to be 767 Jeff Hodges (JH) and Barry Leiba (BL) 768 with permission of Paul 769 Hoffman, Alexey Melnikov, and Mark Nottingham 770 (httpbis chair). 771 </t> 772 773 <t> 774 Added "OVERALL ISSUE" to introduction. 775 </t> 776 777 <t> 778 Added links to email messages on mailing list(s) where 779 various suggestions for this document were brought up. I.e. 780 added various links to those comments herein 781 delimited by "[[...]]" braces. 782 </t> 783 784 <t> 785 Noted JH's belief that "HTTP+HTML Form based authentication" 786 aka "Forms And Cookies" doesn't properly belong in 787 the section where it presently resides. Added link to httpstate WG. 788 </t> 789 790 <t> 791 Added references to OAuth. Section needs to be filled-in as yet. 792 </t> 793 794 <t> 795 Moved ref to RFC2109 to new "Informative References" section, and 796 added a placeholder "IANA Considerations" section in order 797 to satisfy IDnits checking. 798 </t> 799 800 801 </section> 802 803 </section> 804 805 </back> 502 806 503 807 </rfc> 808 809 810 <!-- PLEASE DO NOT DELETE!!! The below is used by XEmacs XML major-mode --> 811 <!-- 812 Local Variables: 813 mode: xml 814 indent-tabs-mode:nil 815 sgml-omittag:t 816 sgml-shorttag:t 817 sgml-namecase-general:t 818 sgml-general-insert-case:lower 819 sgml-minimize-attributes:nil 820 sgml-always-quote-attributes:t 821 sgml-indent-step:4 822 sgml-indent-data:t 823 sgml-parent-document:nil 824 sgml-exposed-tags:nil 825 sgml-local-catalogs:nil 826 sgml-local-ecat-files:nil 827 End: 828 --> 829 <!-- PLEASE DO NOT DELETE!!! The above is used by XEmacs XML major-mode --> 830
Note: See TracChangeset
for help on using the changeset viewer.