Changeset 216 for draft-ietf-httpbis-security-properties/latest
- Timestamp:
- 22/02/08 19:16:51 (15 years ago)
- Location:
- draft-ietf-httpbis-security-properties/latest
- Files:
-
- 2 added
- 3 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis-security-properties/latest/Makefile
r177 r216 1 xml2rfc = " $(HOME)/bin/xml2rfc-1.33pre4/xml2rfc.tcl"1 xml2rfc = "/Users/paul/Documents/xml2rfc-dev/xml2rfc.tcl" 2 2 saxpath = "$(HOME)/java/saxon-8-9-j/saxon8.jar" 3 3 saxon = java -classpath $(saxpath) net.sf.saxon.Transform -novw -
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> -
draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.xml
r179 r216 1 1 <?xml version="1.0" encoding="UTF-8"?> 2 <?xml-stylesheet type='text/xsl' href='../myxml2rfc.xslt'?>3 2 <!DOCTYPE rfc [ 4 3 <!ENTITY rfc2026 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml"> … … 14 13 ]> 15 14 16 <rfc category="info" ipr="full3978" docName="draft-ietf-httpbis-security-properties-latest"> 15 <rfc category="info" ipr="full3978" 16 docName="draft-ietf-httpbis-security-properties-01.txt"> 17 18 <?xml-stylesheet type='text/xsl' href='rfc2629xslt/rfc2629.xslt' ?> 17 19 18 20 <?rfc toc="yes" ?> … … 23 25 <?rfc subcompact="no" ?> 24 26 <?rfc linkmailto='no'?> 27 <?rfc comments="yes"?> 28 <?rfc inline="yes"?> 25 29 26 30 <front> … … 34 38 <address><email>alexey.melnikov@isode.com</email> </address> 35 39 </author> 36 <date month="January"year="2008"/>40 <date year="2008"/> 37 41 <abstract> 38 42 <t>Recent IESG practice dictates that IETF protocols must specify … … 54 58 protocols specify mandatory security mechanisms. "Strong Security 55 59 Requirements for IETF Standard Protocols" <xref target="RFC3365"/> 56 requires that all IETF protocols provide a mechanism for implement ors60 requires that all IETF protocols provide a mechanism for implementers 57 61 to provide strong security. RFC 3365 does not define the term "strong 58 62 security".</t> … … 63 67 64 68 <figure><artwork> 65 66 67 68 69 70 71 72 73 69 We have evolved in the IETF the notion of "mandatory to implement" 70 mechanisms. This philosophy evolves from our primary desire to 71 ensure interoperability between different implementations of a 72 protocol. If a protocol offers many options for how to perform a 73 particular task, but fails to provide for at least one that all 74 must implement, it may be possible that multiple, non-interoperable 75 implementations may result. This is the consequence of the 76 selection of non-overlapping mechanisms being deployed in the 77 different implementations. 74 78 </artwork></figure> 75 79 … … 87 91 combination of access authentication and/or a secure transport.</t> 88 92 93 <t>[[ There is a suggestion that this section be split into 94 "browser-like" and "automation-like" subsections. ]]</t> 95 96 <t>[[ NTLM (shudder) was brought up in the WG a few times in 97 the discussion of the -00 draft. Should we add a section on it? ]]</t> 98 89 99 <section title="Forms And Cookies"> 90 100 91 <t>Almost all HTTP authentication is accomplished through HTML forms, 92 with session keys stored in cookies. For cookies, most implementations 101 <t>Almost all HTTP authentication that involves a human 102 using a web browser is accomplished through HTML forms, 103 with session identifiers stored in cookies. For cookies, most implementations 93 104 rely on the "Netscape specification", which is described loosely in 94 105 section 10 of "HTTP State Management Mechanism" <xref … … 98 109 not widely implemented.</t> 99 110 100 <t>Forms and cookies have number ofproperties that make them an101 excellent solution for some implement ors. However, many of those111 <t>Forms and cookies have many properties that make them an 112 excellent solution for some implementers. However, many of those 102 113 properties introduce serious security trade-offs.</t> 103 114 … … 106 117 reliance on the appearance of the interface. Many users do not 107 118 understand the construction of URIs <xref target="RFC3986"/>, or their 108 presentation in common clients [[ CITATION NEEDED ]]. As a result, 119 presentation in common clients <xref target="PhishingHOWTO"/>. 120 As a result, 109 121 forms are extremely vulnerable to spoofing.</t> 110 122 … … 114 126 115 127 <t>HTML forms provide a facility for sites to indicate that a password 116 should never be pre-populated. [[ More needed here on autocomplete ]]</t> 128 should never be pre-populated. 129 [[ More needed here on autocomplete ]]</t> 117 130 118 131 <t>The cookies that result from a successful form submission make it 119 un essecary to validate credentials with each HTTP request; this makes132 unnecessary to validate credentials with each HTTP request; this makes 120 133 cookies an excellent property for scalability. Cookies are susceptible 121 134 to a large variety of XSS (cross-site scripting) attacks, and measures … … 130 143 from the client.</t> 131 144 132 <t>HTML forms require an HTML rendering engine ,which many protocols133 have no use for.</t>145 <t>HTML forms require an HTML rendering engine for which many protocols 146 have no use.</t> 134 147 135 148 </section> … … 137 150 <section title="HTTP Access Authentication"> 138 151 139 <t>HTTP 1.1 provides a simple authentication framework, and"HTTP152 <t>HTTP 1.1 provides a simple authentication framework, "HTTP 140 153 Authentication: Basic and Digest Access Authentication" <xref 141 target="RFC2617"/> defines two optional mechanisms. Both of these154 target="RFC2617"/>, which defines two optional mechanisms. Both of these 142 155 mechanisms are extremely rarely used in comparison to forms and 143 156 cookies, but some degree of support for one or both is available in … … 182 195 183 196 <t>Digest includes many modes of operation, but only the simplest 184 modes enjoy any degree of interoperability. For example, most197 modes enjoy any degree of interoperability. For example, most 185 198 implementations do not implement the mode that provides full message 186 integrity. Additionally, implementation experience has shown that the 187 message integrity mode is impractical because it requires servers to 188 analyze the full request before determining whether the client knows 189 the shared secret.</t> 199 integrity. Perhaps one reason is that implementation experience has 200 shown that in some cases, especially those involving large requests or 201 responses such as streams, the message integrity mode is impractical 202 because it requires servers to analyze the full request before 203 determining whether the client knows the shared secret or whether 204 message-body integrity has been violated and hence whether the request 205 can be processed.</t> 190 206 191 207 <t>Digest is extremely susceptible to offline dictionary attacks, 192 208 making it practical for attackers to perform a namespace walk 193 consisting of a few million passwords [[ CITATION NEEDED ]].</t> 209 consisting of a few million passwords 210 [[ CITATION NEEDED ]].</t> 194 211 195 212 <t>Many of the most widely-deployed HTTP/1.1 clients are not compliant … … 197 214 198 215 <t>Digest either requires that authentication databases be expressly designed 199 to accom odate it, or requires access to cleartext passwords.216 to accommodate it, or requires access to cleartext passwords. 200 217 As a result, many authentication databases that chose to do the former are 201 218 incompatible, including the most common method of storing passwords … … 219 236 220 237 <t>[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP 221 Authentication in Microsoft Windows" <xref target= "RFC4559"/> goes222 here.]]</t>238 Authentication in Microsoft Windows" <xref target='RFC4559'/> 239 goes here. ]]</t> 223 240 224 241 </section> … … 253 270 time <xref target="WS-Pagecount"/> without any documented change control 254 271 procedures. These protocols usually don't have much in common with the 255 Architecture of the World Wide Web. It's not clear why t erm "Web" is272 Architecture of the World Wide Web. It's not clear why the term "Web" is 256 273 used to group them, but they are obviously out of scope for HTTP-based 257 274 application protocols.</t> 258 275 276 <t>[[ This section could really use a good definition of 277 "Web Services" to differentiate it from REST. ]]</t> 278 259 279 </section> 260 280 261 281 <section title="Transport Layer Security"> 262 282 263 <t>[[ A discussion of HTTP over TLS needs to be added here. ]]</t> 283 <t>[[ A discussion of HTTP over TLS needs to be added 284 here. ]]</t> 264 285 265 286 <t>[[ Discussion of connection confidentiality should be separate from … … 315 336 <organization /> 316 337 </author> 317 <date year='' month='' /> 338 </front> 339 </reference> 340 341 <reference anchor='PhishingHOWTO' 342 target='http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf'> 343 <front> 344 <title>Phishing Tips and Techniques</title> 345 <author initials="P." surname="Gutmann" fullname="Peter Gutmann"> 346 <organization /></author> 347 <date year='2008' month='February' /> 318 348 </front> 319 349 </reference> … … 335 365 336 366 <t>Much of the material in this document was written by Rob Sayre, 337 who first promoted the topic.</t> 367 who first promoted the topic. Many others on the HTTPbis Working 368 Group have contributed to this document in the discussion.</t> 338 369 339 370 </section> … … 344 375 345 376 <section title='Changes between draft-sayre-http-security-variance-00 and 346 draft-ietf-http -security-properties-00'>377 draft-ietf-httpbis-security-properties-00'> 347 378 348 379 <t>Changed the authors to Paul Hoffman and Alexey Melnikov, with permission … … 355 386 356 387 <t>In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 357 repertoire" to match the defin tion of "TEXT" in RFC 2616.</t>388 repertoire" to match the definition of "TEXT" in RFC 2616.</t> 358 389 359 390 <t>Added minor text to the Security Considerations section.</t> … … 363 394 </section> 364 395 396 <section title='Changes between -00 and -01'> 397 398 <t>Fixed some editorial nits reported by Iain Calder.</t> 399 400 <t>Added the suggestions about splitting for browsers and 401 automation, and about adding NTLM, to be beginning of 2.</t> 402 403 <t>In 2.1, added "that involves a human 404 using a web browser" in the first sentence.</t> 405 406 <t>In 2.1, changed "session key" to "session identifier".</t> 407 408 <t>In 2.2.2, changed 409 <figure><artwork><![CDATA[ 410 Digest includes many modes of operation, but only the simplest modes 411 enjoy any degree of interoperability. For example, most 412 implementations do not implement the mode that provides full message 413 integrity. Additionally, implementation experience has shown that 414 the message integrity mode is impractical because it requires servers 415 to analyze the full request before determining whether the client 416 knows the shared secret. 417 ]]></artwork></figure> 418 to 419 <figure><artwork><![CDATA[ 420 Digest includes many modes of operation, but only the simplest 421 modes enjoy any degree of interoperability. For example, most 422 implementations do not implement the mode that provides full message 423 integrity. Perhaps one reason is that implementation experience has 424 shown that in some cases, especially those involving large requests 425 or responses such as streams, the message integrity mode is 426 impractical because it requires servers to analyze the full request 427 before determining whether the client knows the shared secret or 428 whether message-body integrity has been violated and hence whether 429 the request can be processed. 430 ]]></artwork></figure> 431 </t> 432 433 <t>In 2.4, asked for a definition of "Web Services".</t> 434 435 <t>In A, added the WG.</t> 436 437 </section> 438 365 439 </section> 366 440
Note: See TracChangeset
for help on using the changeset viewer.