Changeset 278
- Timestamp:
- 13/07/08 19:21:18 (15 years ago)
- Location:
- draft-ietf-httpbis-security-properties
- Files:
-
- 3 added
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.html
r227 r278 1 <!DOCTYPE html2 PUBLIC "-//W3C//DTD HTML 4.01//EN">3 <html lang="en">4 <head profile="http://www.w3.org/2006/03/hcard">5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">6 <title>Security Requirements for HTTP</title><style type="text/css" title="Xml2Rfc (sans serif)">7 a {8 text-decoration: none;9 }10 a.smpl {11 color: black;12 }13 a:hover {14 text-decoration: underline;15 }16 a:active {17 text-decoration: underline;18 }19 address {20 margin-top: 1em;21 margin-left: 2em;22 font-style: normal;23 }24 body {25 color: black;26 font-family: verdana, helvetica, arial, sans-serif;27 font-size: 10pt;28 }29 cite {30 font-style: normal;31 }32 dd {33 margin-right: 2em;34 }35 dl {36 margin-left: 2em;37 }38 39 dl.empty dd {40 margin-top: .5em;41 }42 dl p {43 margin-left: 0em;44 }45 dt {46 margin-top: .5em;47 }48 h1 {49 font-size: 14pt;50 line-height: 21pt;51 page-break-after: avoid;52 }53 h1.np {54 page-break-before: always;55 }56 h1 a {57 color: #333333;58 }59 h2 {60 font-size: 12pt;61 line-height: 15pt;62 page-break-after: avoid;63 }64 h2 a {65 color: black;66 }67 h3 {68 font-size: 10pt;69 page-break-after: avoid;70 }71 h3 a {72 color: black;73 }74 h4 {75 font-size: 10pt;76 page-break-after: avoid;77 }78 h4 a {79 color: black;80 }81 h5 {82 font-size: 10pt;83 page-break-after: avoid;84 }85 h5 a {86 color: black;87 }88 img {89 margin-left: 3em;90 }91 li {92 margin-left: 2em;93 margin-right: 2em;94 }95 ol {96 margin-left: 2em;97 margin-right: 2em;98 }99 ol p {100 margin-left: 0em;101 }102 p {103 margin-left: 2em;104 margin-right: 2em;105 }106 pre {107 margin-left: 3em;108 background-color: lightyellow;109 padding: .25em;110 }111 pre.text2 {112 border-style: dotted;113 border-width: 1px;114 background-color: #f0f0f0;115 width: 69em;116 }117 pre.inline {118 background-color: white;119 padding: 0em;120 }121 pre.text {122 border-style: dotted;123 border-width: 1px;124 background-color: #f8f8f8;125 width: 69em;126 }127 pre.drawing {128 border-style: solid;129 border-width: 1px;130 background-color: #f8f8f8;131 padding: 2em;132 }133 table {134 margin-left: 2em;135 }136 table.header {137 width: 95%;138 font-size: 10pt;139 color: white;140 }141 td.top {142 vertical-align: top;143 }144 td.topnowrap {145 vertical-align: top;146 white-space: nowrap;147 }148 td.header {149 background-color: gray;150 width: 50%;151 }152 td.reference {153 vertical-align: top;154 white-space: nowrap;155 padding-right: 1em;156 }157 thead {158 display:table-header-group;159 }160 ul.toc {161 list-style: none;162 margin-left: 1.5em;163 margin-right: 0em;164 padding-left: 0em;165 }166 li.tocline0 {167 line-height: 150%;168 font-weight: bold;169 font-size: 10pt;170 margin-left: 0em;171 margin-right: 0em;172 }173 li.tocline1 {174 line-height: normal;175 font-weight: normal;176 font-size: 9pt;177 margin-left: 0em;178 margin-right: 0em;179 }180 li.tocline2 {181 font-size: 0pt;182 }183 ul p {184 margin-left: 0em;185 }186 ul.ind {187 list-style: none;188 margin-left: 1.5em;189 margin-right: 0em;190 padding-left: 0em;191 }192 li.indline0 {193 font-weight: bold;194 line-height: 200%;195 margin-left: 0em;196 margin-right: 0em;197 }198 li.indline1 {199 font-weight: normal;200 line-height: 150%;201 margin-left: 0em;202 margin-right: 0em;203 }204 205 .comment {206 background-color: yellow;207 }208 .center {209 text-align: center;210 }211 .error {212 color: red;213 font-style: italic;214 font-weight: bold;215 }216 .figure {217 font-weight: bold;218 text-align: center;219 font-size: 9pt;220 }221 .filename {222 color: #333333;223 font-weight: bold;224 font-size: 12pt;225 line-height: 21pt;226 text-align: center;227 }228 .fn {229 font-weight: bold;230 }231 .hidden {232 display: none;233 }234 .left {235 text-align: left;236 }237 .right {238 text-align: right;239 }240 .title {241 color: #990000;242 font-size: 18pt;243 line-height: 18pt;244 font-weight: bold;245 text-align: center;246 margin-top: 36pt;247 }248 .vcardline {249 display: block;250 }251 .warning {252 font-size: 14pt;253 background-color: yellow;254 }255 256 257 @media print {258 .noprint {259 display: none;260 }261 262 a {263 color: black;264 text-decoration: none;265 }266 267 table.header {268 width: 90%;269 }270 271 td.header {272 width: 50%;273 color: black;274 background-color: white;275 vertical-align: top;276 font-size: 12pt;277 }278 279 ul.toc a::after {280 content: leader('.') target-counter(attr(href), page);281 }282 283 a.iref {284 content: target-counter(attr(href), page);285 }286 287 .print2col {288 column-count: 2;289 -moz-column-count: 2;290 column-fill: auto;291 }292 }293 294 @page {295 @top-left {296 content: "INTERNET DRAFT";297 }298 @top-right {299 content: "February 2008";300 }301 @top-center {302 content: "Security Requirements for HTTP";303 }304 @bottom-left {305 content: "Hoffman & Melnikov";306 }307 @bottom-center {308 content: "Informational";309 }310 @bottom-right {311 content: "[Page " counter(page) "]";312 }313 }314 315 @page:first {316 @top-left {317 content: normal;318 }319 @top-right {320 content: normal;321 }322 @top-center {323 content: normal;324 }325 }326 </style><link rel="Author" href="#rfc.authors">327 <link rel="Copyright" href="#rfc.copyright">328 <link rel="Chapter" title="1 Introduction" href="#rfc.section.1">329 <link rel="Chapter" title="2 Existing HTTP Security Mechanisms" href="#rfc.section.2">330 <link rel="Chapter" title="3 Revisions To HTTP" href="#rfc.section.3">331 <link rel="Chapter" title="4 Security Considerations" href="#rfc.section.4">332 <link rel="Chapter" href="#rfc.section.5" title="5 Normative References">333 <link rel="Appendix" title="A Acknowledgements" href="#rfc.section.A">334 <link rel="Appendix" title="B Document History" href="#rfc.section.B">335 <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.362, 2008-02-29 17:10:19, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">336 <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">337 <meta name="DC.Creator" content="Hoffman, P.">338 <meta name="DC.Creator" content="Melnikov, A.">339 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties-01">340 <meta name="DC.Date.Issued" scheme="ISO8601" content="2008-02">341 <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.">342 </head>343 <body>344 <table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1">345 <tr>346 <td class="header left">Network Working Group</td>347 <td class="header right">P. Hoffman</td>348 </tr>349 <tr>350 <td class="header left">Internet Draft</td>351 <td class="header right">VPN Consortium</td>352 </tr>353 <tr>354 <td class="header left">355 <draft-ietf-httpbis-security-properties-01>356 357 </td>358 <td class="header right">A. Melnikov</td>359 </tr>360 <tr>361 <td class="header left">Intended status: Informational</td>362 <td class="header right">Isode Ltd.</td>363 </tr>364 <tr>365 <td class="header left">Expires: August 2008</td>366 <td class="header right">February 2008</td>367 </tr>368 </table>369 <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-01</span></p>370 <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1>371 <p>By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she372 is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section373 6 of BCP 79.374 </p>375 <p>Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note376 that other groups may also distribute working documents as Internet-Drafts.377 </p>378 <p>Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other379 documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work380 in progress”.381 </p>382 <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>>.383 </p>384 <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>>.385 </p>386 <p>This Internet-Draft will expire in August 2008.</p>387 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>388 <p>Copyright © The IETF Trust (2008). All Rights Reserved.</p>389 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>390 <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant391 implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes392 the trade-offs of each.393 </p>394 <hr class="noprint">395 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> Introduction396 </h1>397 <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols are required to specify mandatory to implement security mechanisms. "The398 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 define399 the term "strong security".400 </p>401 <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:402 </p>403 <div id="rfc.figure.u.1"></div><pre>404 We have evolved in the IETF the notion of "mandatory to implement"405 mechanisms. This philosophy evolves from our primary desire to406 ensure interoperability between different implementations of a407 protocol. If a protocol offers many options for how to perform a408 particular task, but fails to provide for at least one that all409 must implement, it may be possible that multiple, non-interoperable410 implementations may result. This is the consequence of the411 selection of non-overlapping mechanisms being deployed in the412 different implementations.413 </pre><p id="rfc.section.1.p.4">This document examines the effects of applying security constraints to Web applications, documents the properties that result414 from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the415 moment, it is mostly a laundry list of security technologies and tradeoffs.416 </p>417 <hr class="noprint">418 <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a> Existing HTTP Security Mechanisms419 </h1>420 <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>421 <p id="rfc.section.2.p.2">[[ There is a suggestion that this section be split into "browser-like" and "automation-like" subsections. ]]</p>422 <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?423 ]]424 </p>425 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> Forms And Cookies426 </h2>427 <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 session428 identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described429 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 was430 later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented.431 </p>432 <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 those433 properties introduce serious security trade-offs.434 </p>435 <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 increases436 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.437 </p>438 <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 content439 in all cases (credentials are not differentiated in the protocol).440 </p>441 <p id="rfc.section.2.1.p.5">HTML forms provide a facility for sites to indicate that a password should never be pre-populated. [[ More needed here on442 autocomplete ]]443 </p>444 <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;445 this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting)446 attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because447 cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries448 and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the449 data.450 </p>451 <p id="rfc.section.2.1.p.7">HTML forms and cookies provide flexible ways of ending a session from the client.</p>452 <p id="rfc.section.2.1.p.8">HTML forms require an HTML rendering engine for which many protocols have no use.</p>453 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> HTTP Access Authentication454 </h2>455 <p id="rfc.section.2.2.p.1">HTTP 1.1 provides a simple authentication framework, "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, which defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies,456 but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,457 logout capabilities, or interoperable internationalization.458 </p>459 <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a> Basic Authentication460 </h3>461 <p id="rfc.section.2.2.1.p.1">Basic Authentication (normally called just "Basic") transmits usernames and passwords in the clear. It is very easy to implement,462 but not at all secure unless used over a secure transport.463 </p>464 <p id="rfc.section.2.2.1.p.2">Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure465 transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials,466 but there is no standard method of doing so.467 </p>468 <p id="rfc.section.2.2.1.p.3">Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication469 database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel.470 </p>471 <p id="rfc.section.2.2.1.p.4">Basic is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>472 <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a> Digest Authentication473 </h3>474 <p id="rfc.section.2.2.2.p.1">In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and475 values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport.476 </p>477 <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 that478 observe or receive them, and session data can be transmitted along side credentials with each request, allowing servers to479 validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic.480 </p>481 <p id="rfc.section.2.2.2.p.3">Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most482 implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation483 experience has shown that in some cases, especially those involving large requests or responses such as streams, the message484 integrity mode is impractical because it requires servers to analyze the full request before determining whether the client485 knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed.486 </p>487 <p id="rfc.section.2.2.2.p.4">Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk488 consisting of a few million passwords [[ CITATION NEEDED ]].489 </p>490 <p id="rfc.section.2.2.2.p.5">Many of the most widely-deployed HTTP/1.1 clients are not compliant when GET requests include a query string <a href="#Apache_Digest"><cite title="Apache HTTP Server - mod_auth_digest">[Apache_Digest]</cite></a>.491 </p>492 <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accommodate it, or requires access to cleartext493 passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common494 method of storing passwords for use with Forms and Cookies.495 </p>496 <p id="rfc.section.2.2.2.p.7">Many Digest capabilities included to prevent replay attacks expose the server to Denial of Service attacks.</p>497 <p id="rfc.section.2.2.2.p.8">Digest is not interoperable when used with credentials that contain characters outside of the ISO 8859-1 repertoire.</p>498 <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a> Other Access Authentication Schemes499 </h3>500 <p id="rfc.section.2.2.3.p.1">There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are501 bound to transport layer connections.502 </p>503 <h4 id="rfc.section.2.2.3.1"><a href="#rfc.section.2.2.3.1">2.2.3.1</a> Negotiate (GSS-API) Authentication504 </h4>505 <p id="rfc.section.2.2.3.1.p.1">[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows" <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a> goes here. ]]506 </p>507 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> Centrally-Issued Tickets508 </h2>509 <p id="rfc.section.2.3.p.1">Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited510 ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ511 one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more512 than a sophisticated application of forms and cookies.513 </p>514 <p id="rfc.section.2.3.p.2">All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization515 efforts in progress, as usual.516 </p>517 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> Web Services518 </h2>519 <p id="rfc.section.2.4.p.1">Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for520 TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination521 of standard and vendor-produced specifications, some of which may be obsoleted at any time <a href="#WS-Pagecount"><cite title="WS-Pagecount">[WS-Pagecount]</cite></a> without any documented change control procedures. These protocols usually don't have much in common with the Architecture522 of the World Wide Web. It's not clear why the term "Web" is used to group them, but they are obviously out of scope for HTTP-based523 application protocols.524 </p>525 <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>526 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> Transport Layer Security527 </h2>528 <p id="rfc.section.2.5.p.1">[[ A discussion of HTTP over TLS needs to be added here. ]]</p>529 <p id="rfc.section.2.5.p.2">[[ Discussion of connection confidentiality should be separate from the discussion of access authentication based on mutual530 authentication with certificates in TLS. ]]531 </p>532 <hr class="noprint">533 <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a> Revisions To HTTP534 </h1>535 <p id="rfc.section.3.p.1">Is is possible that HTTP will be revised in the future. "HTTP/1.1" <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and "Use and Interpretation of HTTP Version Numbers" <a href="#RFC2145"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and536 no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate537 will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary.538 </p>539 <hr class="noprint">540 <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a> Security Considerations541 </h1>542 <p id="rfc.section.4.p.1">This entire document is about security considerations.</p>543 <h1 class="np" id="rfc.references"><a href="#rfc.section.5" id="rfc.section.5">5.</a> Normative References544 </h1>545 <table summary="Normative References">546 <tr>547 <td class="reference"><b id="RFC2026">[RFC2026]</b></td>548 <td class="top"><a href="mailto:sob@harvard.edu" title="Harvard University">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2026">The Internet Standards Process -- Revision 3</a>”, BCP 9, RFC 2026, October 1996.549 </td>550 </tr>551 <tr>552 <td class="reference"><b id="RFC2109">[RFC2109]</b></td>553 <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.554 </td>555 </tr>556 <tr>557 <td class="reference"><b id="RFC2145">[RFC2145]</b></td>558 <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.559 </td>560 </tr>561 <tr>562 <td class="reference"><b id="RFC2616">[RFC2616]</b></td>563 <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.564 </td>565 </tr>566 <tr>567 <td class="reference"><b id="RFC2617">[RFC2617]</b></td>568 <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.569 </td>570 </tr>571 <tr>572 <td class="reference"><b id="RFC2965">[RFC2965]</b></td>573 <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.574 </td>575 </tr>576 <tr>577 <td class="reference"><b id="RFC3365">[RFC3365]</b></td>578 <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.579 </td>580 </tr>581 <tr>582 <td class="reference"><b id="RFC3631">[RFC3631]</b></td>583 <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.584 </td>585 </tr>586 <tr>587 <td class="reference"><b id="RFC3986">[RFC3986]</b></td>588 <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.589 </td>590 </tr>591 <tr>592 <td class="reference"><b id="RFC4559">[RFC4559]</b></td>593 <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.594 </td>595 </tr>596 <tr>597 <td class="reference"><b id="Apache_Digest">[Apache_Digest]</b></td>598 <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>>.599 </td>600 </tr>601 <tr>602 <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td>603 <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>>.604 </td>605 </tr>606 <tr>607 <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td>608 <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>>.609 </td>610 </tr>611 </table>612 <hr class="noprint">613 <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1>614 <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>615 <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>616 <hr class="noprint">617 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> Acknowledgements618 </h1>619 <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic. Many others on the HTTPbis Working620 Group have contributed to this document in the discussion.621 </p>622 <hr class="noprint">623 <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a> Document History624 </h1>625 <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p>626 <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-00627 </h2>628 <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p>629 <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p>630 <p id="rfc.section.B.1.p.3">Removed what was section 2 (Requirements Notation), the reference to RFC 2119, and any use of 2119ish all-caps words.</p>631 <p id="rfc.section.B.1.p.4">In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 repertoire" to match the definition of "TEXT" in RFC 2616.</p>632 <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p>633 <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p>634 <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> Changes between -00 and -01635 </h2>636 <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p>637 <p id="rfc.section.B.2.p.2">Added the suggestions about splitting for browsers and automation, and about adding NTLM, to be beginning of 2.</p>638 <p id="rfc.section.B.2.p.3">In 2.1, added "that involves a human using a web browser" in the first sentence.</p>639 <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p>640 <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p>641 <div id="rfc.figure.u.2"></div><pre>642 Digest includes many modes of operation, but only the simplest modes643 enjoy any degree of interoperability. For example, most644 implementations do not implement the mode that provides full message645 integrity. Additionally, implementation experience has shown that646 the message integrity mode is impractical because it requires servers647 to analyze the full request before determining whether the client648 knows the shared secret.649 </pre><p> to </p>650 <div id="rfc.figure.u.3"></div><pre>651 Digest includes many modes of operation, but only the simplest652 modes enjoy any degree of interoperability. For example, most653 implementations do not implement the mode that provides full message654 integrity. Perhaps one reason is that implementation experience has655 shown that in some cases, especially those involving large requests656 or responses such as streams, the message integrity mode is657 impractical because it requires servers to analyze the full request658 before determining whether the client knows the shared secret or659 whether message-body integrity has been violated and hence whether660 the request can be processed.661 </pre><p id="rfc.section.B.2.p.6">In 2.4, asked for a definition of "Web Services".</p>662 <p id="rfc.section.B.2.p.7">In A, added the WG.</p>663 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>664 <p>Copyright © The IETF Trust (2008).</p>665 <p>This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the666 authors retain all their rights.667 </p>668 <p>This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION669 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE670 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN671 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.672 </p>673 <hr class="noprint">674 <h1 class="np"><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1>675 <p>The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might676 be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any677 license under such rights might or might not be available; nor does it represent that it has made any independent effort to678 identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and679 BCP 79.680 </p>681 <p>Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result682 of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users683 of this specification can be obtained from the IETF on-line IPR repository at <<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>>.684 </p>685 <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary686 rights that may cover technology that may be required to implement this standard. Please address the information to the IETF687 at <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>.688 </p>689 </body>690 </html> -
draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.xml
r221 r278 1 1 <?xml version="1.0" encoding="UTF-8"?> 2 <!DOCTYPE rfc [2 <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ 3 3 <!ENTITY rfc2026 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml"> 4 4 <!ENTITY rfc2109 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2109.xml"> … … 10 10 <!ENTITY rfc3631 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3631.xml"> 11 11 <!ENTITY rfc3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml"> 12 <!ENTITY rfc4178 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4178.xml"> 12 13 <!ENTITY rfc4559 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4559.xml"> 13 14 ]> 14 15 15 16 <rfc category="info" ipr="full3978" 16 docName="draft-ietf-httpbis-security-properties-0 1">17 docName="draft-ietf-httpbis-security-properties-02"> 17 18 18 19 <?xml-stylesheet type='text/xsl' href='rfc2629xslt/rfc2629.xslt' ?> … … 38 39 <address><email>alexey.melnikov@isode.com</email> </address> 39 40 </author> 40 <date year="2008" month= "February"/>41 <date year="2008" month='July'/> 41 42 <abstract> 42 43 <t>Recent IESG practice dictates that IETF protocols must specify … … 125 126 all cases (credentials are not differentiated in the protocol).</t> 126 127 127 <t>HTML forms provide a facility for sites to indicate that a password 128 should never be pre-populated. 129 [[ More needed here on autocomplete ]]</t> 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> 130 137 131 138 <t>The cookies that result from a successful form submission make it … … 207 214 <t>Digest is extremely susceptible to offline dictionary attacks, 208 215 making it practical for attackers to perform a namespace walk 209 consisting of a few million passwords 210 [[ CITATION NEEDED ]].</t> 216 consisting of a few million passwords for most users.</t> 211 217 212 218 <t>Many of the most widely-deployed HTTP/1.1 clients are not compliant … … 227 233 </section> 228 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 229 248 <section title="Other Access Authentication Schemes"> 230 249 … … 235 254 <section title="Negotiate (GSS-API) Authentication"> 236 255 237 <t>[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP 238 Authentication in Microsoft Windows" <xref target='RFC4559'/> 239 goes here. ]]</t> 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 --> 240 280 241 281 </section> … … 281 321 <section title="Transport Layer Security"> 282 322 283 <t>[[ A discussion of HTTP over TLS needs to be added 284 here. ]]</t> 285 286 <t>[[ Discussion of connection confidentiality should be separate from 287 the discussion of access authentication based on mutual authentication with 288 certificates in TLS. ]]</t> 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> 289 333 290 334 </section> … … 327 371 &rfc3631; 328 372 &rfc3986; 373 &rfc4178; 329 374 &rfc4559; 330 375 … … 336 381 <organization /> 337 382 </author> 338 383 <date year='' month='' /> 339 384 </front> 340 385 </reference> … … 394 439 395 440 </section> 441 396 442 397 443 <section title='Changes between -00 and -01'> … … 438 484 </section> 439 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 440 499 </section> 441 500 … … 443 502 444 503 </rfc> 445
Note: See TracChangeset
for help on using the changeset viewer.