idnits 2.17.00 (12 Aug 2021) /tmp/idnits34410/draft-ietf-httpbis-security-properties-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 465. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 22, 2008) is 5201 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2109 (Obsoleted by RFC 2965) ** Obsolete normative reference: RFC 2145 (Obsoleted by RFC 7230) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2965 (Obsoleted by RFC 6265) Summary: 7 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft VPN Consortium 4 Intended status: Informational A. Melnikov 5 Expires: August 25, 2008 Isode Ltd. 6 February 22, 2008 8 Security Requirements for HTTP 9 draft-ietf-httpbis-security-properties-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 25, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Recent IESG practice dictates that IETF protocols must specify 43 mandatory-to-implement security mechanisms, so that all conformant 44 implementations share a common baseline. This document examines all 45 widely deployed HTTP security technologies, and analyzes the trade- 46 offs of each. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Existing HTTP Security Mechanisms . . . . . . . . . . . . . . 3 52 2.1. Forms And Cookies . . . . . . . . . . . . . . . . . . . . 3 53 2.2. HTTP Access Authentication . . . . . . . . . . . . . . . . 4 54 2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 5 55 2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 5 56 2.2.3. Other Access Authentication Schemes . . . . . . . . . 6 57 2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 6 58 2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 7 60 3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 7 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 62 5. Normative References . . . . . . . . . . . . . . . . . . . . . 7 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 8 64 Appendix B. Document History . . . . . . . . . . . . . . . . . . 9 65 B.1. Changes between draft-sayre-http-security-variance-00 66 and draft-ietf-httpbis-security-properties-00 . . . . . . 9 67 B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 69 Intellectual Property and Copyright Statements . . . . . . . . . . 11 71 1. Introduction 73 Recent IESG practice dictates that IETF protocols are required to 74 specify mandatory to implement security mechanisms. "The IETF 75 Standards Process" [RFC2026] does not require that protocols specify 76 mandatory security mechanisms. "Strong Security Requirements for 77 IETF Standard Protocols" [RFC3365] requires that all IETF protocols 78 provide a mechanism for implementers to provide strong security. RFC 79 3365 does not define the term "strong security". 81 "Security Mechanisms for the Internet" [RFC3631] is not an IETF 82 procedural RFC, but it is perhaps most relevant. Section 2.2 states: 84 We have evolved in the IETF the notion of "mandatory to implement" 85 mechanisms. This philosophy evolves from our primary desire to 86 ensure interoperability between different implementations of a 87 protocol. If a protocol offers many options for how to perform a 88 particular task, but fails to provide for at least one that all 89 must implement, it may be possible that multiple, non-interoperable 90 implementations may result. This is the consequence of the 91 selection of non-overlapping mechanisms being deployed in the 92 different implementations. 94 This document examines the effects of applying security constraints 95 to Web applications, documents the properties that result from each 96 method, and will make Best Current Practice recommendations for HTTP 97 security in a later document version. At the moment, it is mostly a 98 laundry list of security technologies and tradeoffs. 100 2. Existing HTTP Security Mechanisms 102 For HTTP, the IETF generally defines "security mechanisms" as some 103 combination of access authentication and/or a secure transport. 105 [[ There is a suggestion that this section be split into "browser- 106 like" and "automation-like" subsections. ]] 108 [[ NTLM (shudder) was brought up in the WG a few times in the 109 discussion of the -00 draft. Should we add a section on it? ]] 111 2.1. Forms And Cookies 113 Almost all HTTP authentication that involves a human using a web 114 browser is accomplished through HTML forms, with session identifiers 115 stored in cookies. For cookies, most implementations rely on the 116 "Netscape specification", which is described loosely in section 10 of 117 "HTTP State Management Mechanism" [RFC2109]. The protocol in RFC 118 2109 is relatively widely implemented, but most clients don't 119 advertise support for it. RFC 2109 was later updated [RFC2965], but 120 the newer version is not widely implemented. 122 Forms and cookies have many properties that make them an excellent 123 solution for some implementers. However, many of those properties 124 introduce serious security trade-offs. 126 HTML forms provide a large degree of control over presentation, which 127 is an imperative for many websites. However, this increases user 128 reliance on the appearance of the interface. Many users do not 129 understand the construction of URIs [RFC3986], or their presentation 130 in common clients [PhishingHOWTO]. As a result, forms are extremely 131 vulnerable to spoofing. 133 HTML forms provide acceptable internationalization if used carefully, 134 at the cost of being transmitted as normal HTTP content in all cases 135 (credentials are not differentiated in the protocol). 137 HTML forms provide a facility for sites to indicate that a password 138 should never be pre-populated. [[ More needed here on autocomplete ]] 140 The cookies that result from a successful form submission make it 141 unnecessary to validate credentials with each HTTP request; this 142 makes cookies an excellent property for scalability. Cookies are 143 susceptible to a large variety of XSS (cross-site scripting) attacks, 144 and measures to prevent such attacks will never be as stringent as 145 necessary for authentication credentials because cookies are used for 146 many purposes. Cookies are also susceptible to a wide variety of 147 attacks from malicious intermediaries and observers. The possible 148 attacks depend on the contents of the cookie data. There is no 149 standard format for most of the data. 151 HTML forms and cookies provide flexible ways of ending a session from 152 the client. 154 HTML forms require an HTML rendering engine for which many protocols 155 have no use. 157 2.2. HTTP Access Authentication 159 HTTP 1.1 provides a simple authentication framework, "HTTP 160 Authentication: Basic and Digest Access Authentication" [RFC2617], 161 which defines two optional mechanisms. Both of these mechanisms are 162 extremely rarely used in comparison to forms and cookies, but some 163 degree of support for one or both is available in many 164 implementations. Neither scheme provides presentation control, 165 logout capabilities, or interoperable internationalization. 167 2.2.1. Basic Authentication 169 Basic Authentication (normally called just "Basic") transmits 170 usernames and passwords in the clear. It is very easy to implement, 171 but not at all secure unless used over a secure transport. 173 Basic has very poor scalability properties because credentials must 174 be revalidated with every request, and because secure transports 175 negate many of HTTP's caching mechanisms. Some implementations use 176 cookies in combination with Basic credentials, but there is no 177 standard method of doing so. 179 Since Basic credentials are clear text, they are reusable by any 180 party. This makes them compatible with any authentication database, 181 at the cost of making the user vulnerable to mismanaged or malicious 182 servers, even over a secure channel. 184 Basic is not interoperable when used with credentials that contain 185 characters outside of the ISO 8859-1 repertoire. 187 2.2.2. Digest Authentication 189 In Digest Authentication, the client transmits the results of hashing 190 user credentials with properties of the request and values from the 191 server challenge. Digest is susceptible to man-in-the-middle attacks 192 when not used over a secure transport. 194 Digest has some properties that are preferable to Basic and Cookies. 195 Credentials are not immediately reusable by parties that observe or 196 receive them, and session data can be transmitted along side 197 credentials with each request, allowing servers to validate 198 credentials only when absolutely necessary. Authentication data 199 session keys are distinct from other protocol traffic. 201 Digest includes many modes of operation, but only the simplest modes 202 enjoy any degree of interoperability. For example, most 203 implementations do not implement the mode that provides full message 204 integrity. Perhaps one reason is that implementation experience has 205 shown that in some cases, especially those involving large requests 206 or responses such as streams, the message integrity mode is 207 impractical because it requires servers to analyze the full request 208 before determining whether the client knows the shared secret or 209 whether message-body integrity has been violated and hence whether 210 the request can be processed. 212 Digest is extremely susceptible to offline dictionary attacks, making 213 it practical for attackers to perform a namespace walk consisting of 214 a few million passwords [[ CITATION NEEDED ]]. 216 Many of the most widely-deployed HTTP/1.1 clients are not compliant 217 when GET requests include a query string [Apache_Digest]. 219 Digest either requires that authentication databases be expressly 220 designed to accommodate it, or requires access to cleartext 221 passwords. As a result, many authentication databases that chose to 222 do the former are incompatible, including the most common method of 223 storing passwords for use with Forms and Cookies. 225 Many Digest capabilities included to prevent replay attacks expose 226 the server to Denial of Service attacks. 228 Digest is not interoperable when used with credentials that contain 229 characters outside of the ISO 8859-1 repertoire. 231 2.2.3. Other Access Authentication Schemes 233 There are many niche schemes that make use of the HTTP Authentication 234 framework, but very few are well documented. Some are bound to 235 transport layer connections. 237 2.2.3.1. Negotiate (GSS-API) Authentication 239 [[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP 240 Authentication in Microsoft Windows" [RFC4559] goes here. ]] 242 2.3. Centrally-Issued Tickets 244 Many large Internet services rely on authentication schemes that 245 center on clients consulting a single service for a time-limited 246 ticket that is validated with undocumented heuristics. Centralized 247 ticket issuing has the advantage that users may employ one set of 248 credentials for many services, and clients don't send credentials to 249 many servers. This approach is often no more than a sophisticated 250 application of forms and cookies. 252 All of the schemes in wide use are proprietary and non-standard, and 253 usually are undocumented. There are many standardization efforts in 254 progress, as usual. 256 2.4. Web Services 258 Many security properties mentioned in this document have been recast 259 in XML-based protocols, using HTTP as a substitute for TCP. Like the 260 amalgam of HTTP technologies mentioned above, the XML-based protocols 261 are defined by an ever-changing combination of standard and vendor- 262 produced specifications, some of which may be obsoleted at any time 263 [WS-Pagecount] without any documented change control procedures. 265 These protocols usually don't have much in common with the 266 Architecture of the World Wide Web. It's not clear why the term "Web" 267 is used to group them, but they are obviously out of scope for HTTP- 268 based application protocols. 270 [[ This section could really use a good definition of "Web Services" 271 to differentiate it from REST. ]] 273 2.5. Transport Layer Security 275 [[ A discussion of HTTP over TLS needs to be added here. ]] 277 [[ Discussion of connection confidentiality should be separate from 278 the discussion of access authentication based on mutual 279 authentication with certificates in TLS. ]] 281 3. Revisions To HTTP 283 Is is possible that HTTP will be revised in the future. "HTTP/1.1" 284 [RFC2616] and "Use and Interpretation of HTTP Version Numbers" 285 [RFC2145] define conformance requirements in relation to version 286 numbers. In HTTP 1.1, all authentication mechanisms are optional, 287 and no single transport substrate is specified. Any HTTP revision 288 that adds a mandatory security mechanism or transport substrate will 289 have to increment the HTTP version number appropriately. All widely 290 used schemes are non-standard and/or proprietary. 292 4. Security Considerations 294 This entire document is about security considerations. 296 5. Normative References 298 [Apache_Digest] 299 Apache Software Foundation, "Apache HTTP Server - 300 mod_auth_digest", . 303 [PhishingHOWTO] 304 Gutmann, P., "Phishing Tips and Techniques", 305 February 2008, 306 . 308 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 309 3", BCP 9, RFC 2026, October 1996. 311 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 312 Mechanism", RFC 2109, February 1997. 314 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use 315 and Interpretation of HTTP Version Numbers", RFC 2145, 316 May 1997. 318 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 319 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 320 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 322 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 323 Leach, P., Luotonen, A., and L. Stewart, "HTTP 324 Authentication: Basic and Digest Access Authentication", 325 RFC 2617, June 1999. 327 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 328 Mechanism", RFC 2965, October 2000. 330 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 331 Engineering Task Force Standard Protocols", BCP 61, 332 RFC 3365, August 2002. 334 [RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security 335 Mechanisms for the Internet", RFC 3631, December 2003. 337 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 338 Resource Identifier (URI): Generic Syntax", STD 66, 339 RFC 3986, January 2005. 341 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 342 Kerberos and NTLM HTTP Authentication in Microsoft 343 Windows", RFC 4559, June 2006. 345 [WS-Pagecount] 346 Bray, T., "WS-Pagecount", September 2004, . 349 Appendix A. Acknowledgements 351 Much of the material in this document was written by Rob Sayre, who 352 first promoted the topic. Many others on the HTTPbis Working Group 353 have contributed to this document in the discussion. 355 Appendix B. Document History 357 [This entire section is to be removed when published as an RFC.] 359 B.1. Changes between draft-sayre-http-security-variance-00 and 360 draft-ietf-httpbis-security-properties-00 362 Changed the authors to Paul Hoffman and Alexey Melnikov, with 363 permission of Rob Sayre. 365 Made lots of minor editorial changes. 367 Removed what was section 2 (Requirements Notation), the reference to 368 RFC 2119, and any use of 2119ish all-caps words. 370 In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 371 repertoire" to match the definition of "TEXT" in RFC 2616. 373 Added minor text to the Security Considerations section. 375 Added URLs to the two non-RFC references. 377 B.2. Changes between -00 and -01 379 Fixed some editorial nits reported by Iain Calder. 381 Added the suggestions about splitting for browsers and automation, 382 and about adding NTLM, to be beginning of 2. 384 In 2.1, added "that involves a human using a web browser" in the 385 first sentence. 387 In 2.1, changed "session key" to "session identifier". 389 In 2.2.2, changed 391 Digest includes many modes of operation, but only the simplest modes 392 enjoy any degree of interoperability. For example, most 393 implementations do not implement the mode that provides full message 394 integrity. Additionally, implementation experience has shown that 395 the message integrity mode is impractical because it requires servers 396 to analyze the full request before determining whether the client 397 knows the shared secret. 399 to 400 Digest includes many modes of operation, but only the simplest 401 modes enjoy any degree of interoperability. For example, most 402 implementations do not implement the mode that provides full message 403 integrity. Perhaps one reason is that implementation experience has 404 shown that in some cases, especially those involving large requests 405 or responses such as streams, the message integrity mode is 406 impractical because it requires servers to analyze the full request 407 before determining whether the client knows the shared secret or 408 whether message-body integrity has been violated and hence whether 409 the request can be processed. 411 In 2.4, asked for a definition of "Web Services". 413 In A, added the WG. 415 Authors' Addresses 417 Paul Hoffman 418 VPN Consortium 420 Email: paul.hoffman@vpnc.org 422 Alexey Melnikov 423 Isode Ltd. 425 Email: alexey.melnikov@isode.com 427 Full Copyright Statement 429 Copyright (C) The IETF Trust (2008). 431 This document is subject to the rights, licenses and restrictions 432 contained in BCP 78, and except as set forth therein, the authors 433 retain all their rights. 435 This document and the information contained herein are provided on an 436 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 437 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 438 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 439 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 440 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 441 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 443 Intellectual Property 445 The IETF takes no position regarding the validity or scope of any 446 Intellectual Property Rights or other rights that might be claimed to 447 pertain to the implementation or use of the technology described in 448 this document or the extent to which any license under such rights 449 might or might not be available; nor does it represent that it has 450 made any independent effort to identify any such rights. Information 451 on the procedures with respect to rights in RFC documents can be 452 found in BCP 78 and BCP 79. 454 Copies of IPR disclosures made to the IETF Secretariat and any 455 assurances of licenses to be made available, or the result of an 456 attempt made to obtain a general license or permission for the use of 457 such proprietary rights by implementers or users of this 458 specification can be obtained from the IETF on-line IPR repository at 459 http://www.ietf.org/ipr. 461 The IETF invites any interested party to bring to its attention any 462 copyrights, patents or patent applications, or other proprietary 463 rights that may cover technology that may be required to implement 464 this standard. Please address the information to the IETF at 465 ietf-ipr@ietf.org. 467 Acknowledgment 469 Funding for the RFC Editor function is provided by the IETF 470 Administrative Support Activity (IASA).