Changeset 279 for draft-ietf-httpbis-security-properties/latest
- Timestamp:
- 14/07/08 06:23:58 (15 years ago)
- Location:
- draft-ietf-httpbis-security-properties/latest
- Files:
-
- 1 deleted
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis-security-properties/latest
-
Property
svn:ignore
set to
*.redxml
-
Property
svn:ignore
set to
-
draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.html
r278 r279 1 <!DOCTYPE html 2 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: "July 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.379, 2008-07-06 13:38:32, 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-02"> 340 <meta name="DC.Date.Issued" scheme="ISO8601" content="2008-07"> 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-02> 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: January 2009</td> 366 <td class="header right">July 14, 2008</td> 367 </tr> 368 </table> 369 <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-02</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 she 372 is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 373 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. Note 376 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 other 379 documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work 380 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 January 2009.</p> 387 <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1> 388 <p>Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant 389 implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes 390 the trade-offs of each. 391 </p> 392 <hr class="noprint"> 393 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> Introduction 394 </h1> 395 <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols are required to specify mandatory to implement security mechanisms. "The 396 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 397 the term "strong security". 398 </p> 399 <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: 400 </p> 401 <div id="rfc.figure.u.1"></div><pre> 402 We have evolved in the IETF the notion of "mandatory to implement" 403 mechanisms. This philosophy evolves from our primary desire to 404 ensure interoperability between different implementations of a 405 protocol. If a protocol offers many options for how to perform a 406 particular task, but fails to provide for at least one that all 407 must implement, it may be possible that multiple, non-interoperable 408 implementations may result. This is the consequence of the 409 selection of non-overlapping mechanisms being deployed in the 410 different implementations. 411 </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 412 from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the 413 moment, it is mostly a laundry list of security technologies and tradeoffs. 414 </p> 415 <hr class="noprint"> 416 <h1 id="rfc.section.2" class="np"><a href="#rfc.section.2">2.</a> Existing HTTP Security Mechanisms 417 </h1> 418 <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> 419 <p id="rfc.section.2.p.2">[[ There is a suggestion that this section be split into "browser-like" and "automation-like" subsections. ]]</p> 420 <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? 421 ]] 422 </p> 423 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> Forms And Cookies 424 </h2> 425 <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 426 identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described 427 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 428 later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented. 429 </p> 430 <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 those 431 properties introduce serious security trade-offs. 432 </p> 433 <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 increases 434 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. 435 </p> 436 <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 content 437 in all cases (credentials are not differentiated in the protocol). 438 </p> 439 <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 is 440 considered to be a convenience mechanism, and convenience mechanisms often have negative security properties. The security 441 concerns with auto-completion are particularly poignant for web browsers that reside on computers with multiple users. HTML 442 forms provide a facility for sites to indicate that a field, such as a password, should never be pre-populated. However, it 443 is clear that some form creators do not use this facility when they should. 444 </p> 445 <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; 446 this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting) 447 attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because 448 cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries 449 and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the 450 data. 451 </p> 452 <p id="rfc.section.2.1.p.7">HTML forms and cookies provide flexible ways of ending a session from the client.</p> 453 <p id="rfc.section.2.1.p.8">HTML forms require an HTML rendering engine for which many protocols have no use.</p> 454 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> HTTP Access Authentication 455 </h2> 456 <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, 457 but some degree of support for one or both is available in many implementations. Neither scheme provides presentation control, 458 logout capabilities, or interoperable internationalization. 459 </p> 460 <h3 id="rfc.section.2.2.1"><a href="#rfc.section.2.2.1">2.2.1</a> Basic Authentication 461 </h3> 462 <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, 463 but not at all secure unless used over a secure transport. 464 </p> 465 <p id="rfc.section.2.2.1.p.2">Basic has very poor scalability properties because credentials must be revalidated with every request, and because secure 466 transports negate many of HTTP's caching mechanisms. Some implementations use cookies in combination with Basic credentials, 467 but there is no standard method of doing so. 468 </p> 469 <p id="rfc.section.2.2.1.p.3">Since Basic credentials are clear text, they are reusable by any party. This makes them compatible with any authentication 470 database, at the cost of making the user vulnerable to mismanaged or malicious servers, even over a secure channel. 471 </p> 472 <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> 473 <h3 id="rfc.section.2.2.2"><a href="#rfc.section.2.2.2">2.2.2</a> Digest Authentication 474 </h3> 475 <p id="rfc.section.2.2.2.p.1">In Digest Authentication, the client transmits the results of hashing user credentials with properties of the request and 476 values from the server challenge. Digest is susceptible to man-in-the-middle attacks when not used over a secure transport. 477 </p> 478 <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 479 observe or receive them, and session data can be transmitted along side credentials with each request, allowing servers to 480 validate credentials only when absolutely necessary. Authentication data session keys are distinct from other protocol traffic. 481 </p> 482 <p id="rfc.section.2.2.2.p.3">Digest includes many modes of operation, but only the simplest modes enjoy any degree of interoperability. For example, most 483 implementations do not implement the mode that provides full message integrity. Perhaps one reason is that implementation 484 experience has shown that in some cases, especially those involving large requests or responses such as streams, the message 485 integrity mode is impractical because it requires servers to analyze the full request before determining whether the client 486 knows the shared secret or whether message-body integrity has been violated and hence whether the request can be processed. 487 </p> 488 <p id="rfc.section.2.2.2.p.4">Digest is extremely susceptible to offline dictionary attacks, making it practical for attackers to perform a namespace walk 489 consisting of a few million passwords for most users. 490 </p> 491 <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>. 492 </p> 493 <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accommodate it, or requires access to cleartext 494 passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common 495 method of storing passwords for use with Forms and Cookies. 496 </p> 497 <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> 498 <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> 499 <h3 id="rfc.section.2.2.3"><a href="#rfc.section.2.2.3">2.2.3</a> Authentication Using Certificates in TLS 500 </h3> 501 <p id="rfc.section.2.2.3.p.1">Running HTTP over TLS provides authentication of the HTTP server to the client. HTTP over TLS can also provides authentication 502 of the client to the server using certificates. Although forms are a much more common way to authenticate users to HTTP servers, 503 TLS client certificates are widely used in some environments. The public key infrastructure (PKI) used to validate certificates 504 in TLS can be rooted in public trust anchors or can be based on local trust anchors. 505 </p> 506 <h3 id="rfc.section.2.2.4"><a href="#rfc.section.2.2.4">2.2.4</a> Other Access Authentication Schemes 507 </h3> 508 <p id="rfc.section.2.2.4.p.1">There are many niche schemes that make use of the HTTP Authentication framework, but very few are well documented. Some are 509 bound to transport layer connections. 510 </p> 511 <h4 id="rfc.section.2.2.4.1"><a href="#rfc.section.2.2.4.1">2.2.4.1</a> Negotiate (GSS-API) Authentication 512 </h4> 513 <p id="rfc.section.2.2.4.1.p.1">Microsoft has designed an HTTP authentication mechanism that utilizes SPNEGO <a href="#RFC4178"><cite title="The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism">[RFC4178]</cite></a> GSSAPI <a href="#RFC4559"><cite title="SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows">[RFC4559]</cite></a>. In Microsoft's implementation, SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan Manager protocols). 514 </p> 515 <p id="rfc.section.2.2.4.1.p.2">In Kerberos, clients and servers rely on a trusted third-party authentication service which maintains its own authentication 516 database. Kerberos is typically used with shared secret key cryptography, but extensions for use of other authentication mechnanisms 517 such as PKIX certificates and two-factor tokens are also common. Kerberos was designed to work under the assumption that packets 518 traveling along the network can be read, modified, and inserted at will. 519 </p> 520 <p id="rfc.section.2.2.4.1.p.3">Unlike Digest, Negotiate authentication can take multiple round trips (client sending authentication data in Authorization, 521 server sending authentication data in WWW-Authenticate) to complete. 522 </p> 523 <p id="rfc.section.2.2.4.1.p.4">Kerberos authentication is generally more secure than Digest. However the requirement for having a separate network authentication 524 service might be a barrier to deployment. 525 </p> 526 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> Centrally-Issued Tickets 527 </h2> 528 <p id="rfc.section.2.3.p.1">Many large Internet services rely on authentication schemes that center on clients consulting a single service for a time-limited 529 ticket that is validated with undocumented heuristics. Centralized ticket issuing has the advantage that users may employ 530 one set of credentials for many services, and clients don't send credentials to many servers. This approach is often no more 531 than a sophisticated application of forms and cookies. 532 </p> 533 <p id="rfc.section.2.3.p.2">All of the schemes in wide use are proprietary and non-standard, and usually are undocumented. There are many standardization 534 efforts in progress, as usual. 535 </p> 536 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> Web Services 537 </h2> 538 <p id="rfc.section.2.4.p.1">Many security properties mentioned in this document have been recast in XML-based protocols, using HTTP as a substitute for 539 TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination 540 of standard and vendor-produced specifications, some of which may be obsoleted at any time <a href="#WS-Pagecount"><cite title="WS-Pagecount">[WS-Pagecount]</cite></a> without any documented change control procedures. These protocols usually don't have much in common with the Architecture 541 of the World Wide Web. It's not clear why the term "Web" is used to group them, but they are obviously out of scope for HTTP-based 542 application protocols. 543 </p> 544 <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> 545 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> Transport Layer Security 546 </h2> 547 <p id="rfc.section.2.5.p.1">In addition to using TLS for client and/or server authentication, it is also very commonly used to protect the confidentiality 548 and integrity of the HTTP session. For instance, both HTTP Basic authentication and Cookies are often protected against snooping 549 by TLS. 550 </p> 551 <p id="rfc.section.2.5.p.2">It should be noted that, in that case, TLS does not protect against a breach of the credential store at the server or against 552 a keylogger or phishing interface at the client. TLS does not change the fact that Basic Authentication passwords are reusable 553 and does not address that weakness. 554 </p> 555 <hr class="noprint"> 556 <h1 id="rfc.section.3" class="np"><a href="#rfc.section.3">3.</a> Revisions To HTTP 557 </h1> 558 <p id="rfc.section.3.p.1">Is is possible that HTTP will be revised in the future. "HTTP/1.1" <a href="#RFC2616"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> and "Use and Interpretation of HTTP Version Numbers" <a href="#RFC2145"><cite title="Use and Interpretation of HTTP Version Numbers">[RFC2145]</cite></a> define conformance requirements in relation to version numbers. In HTTP 1.1, all authentication mechanisms are optional, and 559 no single transport substrate is specified. Any HTTP revision that adds a mandatory security mechanism or transport substrate 560 will have to increment the HTTP version number appropriately. All widely used schemes are non-standard and/or proprietary. 561 </p> 562 <hr class="noprint"> 563 <h1 id="rfc.section.4" class="np"><a href="#rfc.section.4">4.</a> Security Considerations 564 </h1> 565 <p id="rfc.section.4.p.1">This entire document is about security considerations.</p> 566 <h1 class="np" id="rfc.references"><a href="#rfc.section.5" id="rfc.section.5">5.</a> Normative References 567 </h1> 568 <table summary="Normative References"> 569 <tr> 570 <td class="reference"><b id="RFC2026">[RFC2026]</b></td> 571 <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. 572 </td> 573 </tr> 574 <tr> 575 <td class="reference"><b id="RFC2109">[RFC2109]</b></td> 576 <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. 577 </td> 578 </tr> 579 <tr> 580 <td class="reference"><b id="RFC2145">[RFC2145]</b></td> 581 <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. 582 </td> 583 </tr> 584 <tr> 585 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> 586 <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. 587 </td> 588 </tr> 589 <tr> 590 <td class="reference"><b id="RFC2617">[RFC2617]</b></td> 591 <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. 592 </td> 593 </tr> 594 <tr> 595 <td class="reference"><b id="RFC2965">[RFC2965]</b></td> 596 <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. 597 </td> 598 </tr> 599 <tr> 600 <td class="reference"><b id="RFC3365">[RFC3365]</b></td> 601 <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. 602 </td> 603 </tr> 604 <tr> 605 <td class="reference"><b id="RFC3631">[RFC3631]</b></td> 606 <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. 607 </td> 608 </tr> 609 <tr> 610 <td class="reference"><b id="RFC3986">[RFC3986]</b></td> 611 <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. 612 </td> 613 </tr> 614 <tr> 615 <td class="reference"><b id="RFC4178">[RFC4178]</b></td> 616 <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. 617 </td> 618 </tr> 619 <tr> 620 <td class="reference"><b id="RFC4559">[RFC4559]</b></td> 621 <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. 622 </td> 623 </tr> 624 <tr> 625 <td class="reference"><b id="Apache_Digest">[Apache_Digest]</b></td> 626 <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>>. 627 </td> 628 </tr> 629 <tr> 630 <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td> 631 <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>>. 632 </td> 633 </tr> 634 <tr> 635 <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td> 636 <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>>. 637 </td> 638 </tr> 639 </table> 640 <hr class="noprint"> 641 <h1 id="rfc.authors" class="np"><a href="#rfc.authors">Authors' Addresses</a></h1> 642 <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> 643 <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> 644 <hr class="noprint"> 645 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> Acknowledgements 646 </h1> 647 <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic. Many others on the HTTPbis Working 648 Group have contributed to this document in the discussion. 649 </p> 650 <hr class="noprint"> 651 <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a> Document History 652 </h1> 653 <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p> 654 <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 655 </h2> 656 <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p> 657 <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p> 658 <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> 659 <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> 660 <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p> 661 <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p> 662 <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> Changes between -00 and -01 663 </h2> 664 <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p> 665 <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> 666 <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> 667 <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p> 668 <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p> 669 <div id="rfc.figure.u.2"></div><pre> 670 Digest includes many modes of operation, but only the simplest modes 671 enjoy any degree of interoperability. For example, most 672 implementations do not implement the mode that provides full message 673 integrity. Additionally, implementation experience has shown that 674 the message integrity mode is impractical because it requires servers 675 to analyze the full request before determining whether the client 676 knows the shared secret. 677 </pre><p> to </p> 678 <div id="rfc.figure.u.3"></div><pre> 679 Digest includes many modes of operation, but only the simplest 680 modes enjoy any degree of interoperability. For example, most 681 implementations do not implement the mode that provides full message 682 integrity. Perhaps one reason is that implementation experience has 683 shown that in some cases, especially those involving large requests 684 or responses such as streams, the message integrity mode is 685 impractical because it requires servers to analyze the full request 686 before determining whether the client knows the shared secret or 687 whether message-body integrity has been violated and hence whether 688 the request can be processed. 689 </pre><p id="rfc.section.B.2.p.6">In 2.4, asked for a definition of "Web Services".</p> 690 <p id="rfc.section.B.2.p.7">In A, added the WG.</p> 691 <h2 id="rfc.section.B.3"><a href="#rfc.section.B.3">B.3</a> Changes between -01 and -02 692 </h2> 693 <p id="rfc.section.B.3.p.1">In section 2.1, added more to the paragraph on auto-completion of HTML forms.</p> 694 <p id="rfc.section.B.3.p.2">Added the section on TLS for authentication.</p> 695 <p id="rfc.section.B.3.p.3">Filled in section 2.5.</p> 696 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 697 <p>This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the 698 authors retain all their rights. 699 </p> 700 <p>This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION 701 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE 702 DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 703 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 704 </p> 705 <hr class="noprint"> 706 <h1 class="np"><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1> 707 <p>The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might 708 be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any 709 license under such rights might or might not be available; nor does it represent that it has made any independent effort to 710 identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and 711 BCP 79. 712 </p> 713 <p>Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result 714 of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users 715 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>>. 716 </p> 717 <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary 718 rights that may cover technology that may be required to implement this standard. Please address the information to the IETF 719 at <a href="mailto:ietf-ipr@ietf.org">ietf-ipr@ietf.org</a>. 720 </p> 721 </body> 722 </html> -
draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.xml
r278 r279 1 1 <?xml version="1.0" encoding="UTF-8"?> 2 <!DOCTYPE rfc SYSTEM "rfc2629.dtd"[2 <!DOCTYPE rfc [ 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">
Note: See TracChangeset
for help on using the changeset viewer.