Changeset 216 for draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.html
- Timestamp:
- 22/02/08 19:16:51 (14 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.html
r213 r216 297 297 } 298 298 @top-right { 299 content: " January2008";299 content: " 2008"; 300 300 } 301 301 @top-center { … … 337 337 <meta name="DC.Creator" content="Hoffman, P."> 338 338 <meta name="DC.Creator" content="Melnikov, A."> 339 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties- latest">340 <meta name="DC.Date.Issued" scheme="ISO8601" content="2008- 01">339 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-security-properties-01.txt"> 340 <meta name="DC.Date.Issued" scheme="ISO8601" content="2008-WRONG SYNTAX FOR MONTH"> 341 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 342 </head> … … 353 353 <tr> 354 354 <td class="header left"> 355 <draft-ietf-httpbis-security-properties- latest>355 <draft-ietf-httpbis-security-properties-01.txt> 356 356 357 357 </td> … … 363 363 </tr> 364 364 <tr> 365 <td class="header left">Expires: July 2008</td>366 <td class="header right"> January2008</td>365 <td class="header left">Expires: WRONG SYNTAX FOR MONTH</td> 366 <td class="header right"> 2008</td> 367 367 </tr> 368 368 </table> 369 <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-latest</span></p> 369 <p class="title">Security Requirements for HTTP<br><span class="filename">draft-ietf-httpbis-security-properties-01.txt</span><div class="error">WARNING: The @docName attribute should contain the base name, not the filename (thus no file extension).</div> 370 </p> 370 371 <h1><a id="rfc.status" href="#rfc.status">Status of this Memo</a></h1> 371 372 <p>By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she … … 384 385 <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 386 </p> 386 <p>This Internet-Draft will expire in July 2008.</p>387 <p>This Internet-Draft will expire in WRONG SYNTAX FOR MONTH.</p> 387 388 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 388 389 <p>Copyright © The IETF Trust (2008). All Rights Reserved.</p> … … 396 397 </h1> 397 398 <p id="rfc.section.1.p.1">Recent IESG practice dictates that IETF protocols are required to specify mandatory to implement security mechanisms. "The 398 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 implement ors to provide strong security. RFC 3365 does not define399 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 399 400 the term "strong security". 400 401 </p> … … 402 403 </p> 403 404 <div id="rfc.figure.u.1"></div><pre> 404 405 406 407 408 409 410 411 412 405 We have evolved in the IETF the notion of "mandatory to implement" 406 mechanisms. This philosophy evolves from our primary desire to 407 ensure interoperability between different implementations of a 408 protocol. If a protocol offers many options for how to perform a 409 particular task, but fails to provide for at least one that all 410 must implement, it may be possible that multiple, non-interoperable 411 implementations may result. This is the consequence of the 412 selection of non-overlapping mechanisms being deployed in the 413 different implementations. 413 414 </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 414 415 from each method, and will make Best Current Practice recommendations for HTTP security in a later document version. At the … … 419 420 </h1> 420 421 <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> 422 <p id="rfc.section.2.p.2">[[ There is a suggestion that this section be split into "browser-like" and "automation-like" subsections. ]]</p> 423 <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? 424 ]] 425 </p> 421 426 <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a> Forms And Cookies 422 427 </h2> 423 <p id="rfc.section.2.1.p.1">Almost all HTTP authentication is accomplished through HTML forms, with session keys stored in cookies. For cookies, most 424 implementations rely on the "Netscape specification", which is described 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 <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 429 identifiers stored in cookies. For cookies, most implementations rely on the "Netscape specification", which is described 430 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 425 431 later updated <a href="#RFC2965"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a>, but the newer version is not widely implemented. 426 432 </p> 427 <p id="rfc.section.2.1.p.2">Forms and cookies have number of properties that make them an excellent solution for some implementors. However, many of those433 <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 428 434 properties introduce serious security trade-offs. 429 435 </p> 430 436 <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 431 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 [[ CITATION NEEDED ]]. As a result, forms are extremely vulnerable to spoofing.437 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. 432 438 </p> 433 439 <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 443 autocomplete ]] 438 444 </p> 439 <p id="rfc.section.2.1.p.6">The cookies that result from a successful form submission make it un essecary to validate credentials with each HTTP request;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; 440 446 this makes cookies an excellent property for scalability. Cookies are susceptible to a large variety of XSS (cross-site scripting) 441 447 attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because … … 445 451 </p> 446 452 <p id="rfc.section.2.1.p.7">HTML forms and cookies provide flexible ways of ending a session from the client.</p> 447 <p id="rfc.section.2.1.p.8">HTML forms require an HTML rendering engine , which many protocols have no use for.</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> 448 454 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> HTTP Access Authentication 449 455 </h2> 450 <p id="rfc.section.2.2.p.1">HTTP 1.1 provides a simple authentication framework, and "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a> defines two optional mechanisms. Both of these mechanisms are extremely rarely used in comparison to forms and cookies, but451 some degree of support for one or both is available in many implementations. Neither scheme provides presentation control,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, 452 458 logout capabilities, or interoperable internationalization. 453 459 </p> … … 475 481 </p> 476 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 477 implementations do not implement the mode that provides full message integrity. Additionally, implementation experience has 478 shown that the message integrity mode is impractical because it requires servers to analyze the full request before determining 479 whether the client knows the shared secret. 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. 480 487 </p> 481 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 … … 484 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>. 485 492 </p> 486 <p id="rfc.section.2.2.2.p.6">Digest either requires that authentication databases be expressly designed to accom odate it, or requires access to cleartext493 <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 487 494 passwords. As a result, many authentication databases that chose to do the former are incompatible, including the most common 488 495 method of storing passwords for use with Forms and Cookies. … … 497 504 <h4 id="rfc.section.2.2.3.1"><a href="#rfc.section.2.2.3.1">2.2.3.1</a> Negotiate (GSS-API) Authentication 498 505 </h4> 499 <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 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. ]] 500 507 </p> 501 508 <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a> Centrally-Issued Tickets … … 514 521 TCP. Like the amalgam of HTTP technologies mentioned above, the XML-based protocols are defined by an ever-changing combination 515 522 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 516 of the World Wide Web. It's not clear why t erm "Web" is used to group them, but they are obviously out of scope for HTTP-based523 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 517 524 application protocols. 518 525 </p> 526 <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> 519 527 <h2 id="rfc.section.2.5"><a href="#rfc.section.2.5">2.5</a> Transport Layer Security 520 528 </h2> … … 593 601 </tr> 594 602 <tr> 603 <td class="reference"><b id="PhishingHOWTO">[PhishingHOWTO]</b></td> 604 <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>>. 605 </td> 606 </tr> 607 <tr> 595 608 <td class="reference"><b id="WS-Pagecount">[WS-Pagecount]</b></td> 596 609 <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>>. … … 605 618 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> Acknowledgements 606 619 </h1> 607 <p id="rfc.section.A.p.1">Much of the material in this document was written by Rob Sayre, who first promoted the topic.</p> 620 <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 621 Group have contributed to this document in the discussion. 622 </p> 608 623 <hr class="noprint"> 609 624 <h1 id="rfc.section.B" class="np"><a href="#rfc.section.B">B.</a> Document History 610 625 </h1> 611 626 <p id="rfc.section.B.p.1">[This entire section is to be removed when published as an RFC.]</p> 612 <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-http -security-properties-00627 <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 613 628 </h2> 614 629 <p id="rfc.section.B.1.p.1">Changed the authors to Paul Hoffman and Alexey Melnikov, with permission of Rob Sayre.</p> 615 630 <p id="rfc.section.B.1.p.2">Made lots of minor editorial changes.</p> 616 631 <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> 617 <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 defin tion of "TEXT" in RFC 2616.</p>632 <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> 618 633 <p id="rfc.section.B.1.p.5">Added minor text to the Security Considerations section.</p> 619 634 <p id="rfc.section.B.1.p.6">Added URLs to the two non-RFC references.</p> 635 <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a> Changes between -00 and -01 636 </h2> 637 <p id="rfc.section.B.2.p.1">Fixed some editorial nits reported by Iain Calder.</p> 638 <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> 639 <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> 640 <p id="rfc.section.B.2.p.4">In 2.1, changed "session key" to "session identifier".</p> 641 <p id="rfc.section.B.2.p.5">In 2.2.2, changed </p> 642 <div id="rfc.figure.u.2"></div><pre> 643 Digest includes many modes of operation, but only the simplest modes 644 enjoy any degree of interoperability. For example, most 645 implementations do not implement the mode that provides full message 646 integrity. Additionally, implementation experience has shown that 647 the message integrity mode is impractical because it requires servers 648 to analyze the full request before determining whether the client 649 knows the shared secret. 650 </pre><p> to </p> 651 <div id="rfc.figure.u.3"></div><pre> 652 Digest includes many modes of operation, but only the simplest 653 modes enjoy any degree of interoperability. For example, most 654 implementations do not implement the mode that provides full message 655 integrity. Perhaps one reason is that implementation experience has 656 shown that in some cases, especially those involving large requests 657 or responses such as streams, the message integrity mode is 658 impractical because it requires servers to analyze the full request 659 before determining whether the client knows the shared secret or 660 whether message-body integrity has been violated and hence whether 661 the request can be processed. 662 </pre><p id="rfc.section.B.2.p.6">In 2.4, asked for a definition of "Web Services".</p> 663 <p id="rfc.section.B.2.p.7">In A, added the WG.</p> 620 664 <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1> 621 665 <p>Copyright © The IETF Trust (2008).</p>
Note: See TracChangeset
for help on using the changeset viewer.