idnits 2.17.1 draft-ietf-httpbis-security-properties-02.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 499. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 510. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 517. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 523. 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 (July 13, 2008) is 5766 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: January 14, 2009 Isode Ltd. 6 July 13, 2008 8 Security Requirements for HTTP 9 draft-ietf-httpbis-security-properties-02 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 January 14, 2009. 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 . . . . . . . . . . . . . . . . 5 54 2.2.1. Basic Authentication . . . . . . . . . . . . . . . . . 5 55 2.2.2. Digest Authentication . . . . . . . . . . . . . . . . 5 56 2.2.3. Authentication Using Certificates in TLS . . . . . . . 6 57 2.2.4. Other Access Authentication Schemes . . . . . . . . . 6 58 2.3. Centrally-Issued Tickets . . . . . . . . . . . . . . . . . 7 59 2.4. Web Services . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.5. Transport Layer Security . . . . . . . . . . . . . . . . . 8 61 3. Revisions To HTTP . . . . . . . . . . . . . . . . . . . . . . 8 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 5. Normative References . . . . . . . . . . . . . . . . . . . . . 8 64 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 65 Appendix B. Document History . . . . . . . . . . . . . . . . . . 10 66 B.1. Changes between draft-sayre-http-security-variance-00 67 and draft-ietf-httpbis-security-properties-00 . . . . . . 10 68 B.2. Changes between -00 and -01 . . . . . . . . . . . . . . . 10 69 B.3. Changes between -01 and -02 . . . . . . . . . . . . . . . 11 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 71 Intellectual Property and Copyright Statements . . . . . . . . . . 12 73 1. Introduction 75 Recent IESG practice dictates that IETF protocols are required to 76 specify mandatory to implement security mechanisms. "The IETF 77 Standards Process" [RFC2026] does not require that protocols specify 78 mandatory security mechanisms. "Strong Security Requirements for 79 IETF Standard Protocols" [RFC3365] requires that all IETF protocols 80 provide a mechanism for implementers to provide strong security. RFC 81 3365 does not define the term "strong security". 83 "Security Mechanisms for the Internet" [RFC3631] is not an IETF 84 procedural RFC, but it is perhaps most relevant. Section 2.2 states: 86 We have evolved in the IETF the notion of "mandatory to implement" 87 mechanisms. This philosophy evolves from our primary desire to 88 ensure interoperability between different implementations of a 89 protocol. If a protocol offers many options for how to perform a 90 particular task, but fails to provide for at least one that all 91 must implement, it may be possible that multiple, non-interoperable 92 implementations may result. This is the consequence of the 93 selection of non-overlapping mechanisms being deployed in the 94 different implementations. 96 This document examines the effects of applying security constraints 97 to Web applications, documents the properties that result from each 98 method, and will make Best Current Practice recommendations for HTTP 99 security in a later document version. At the moment, it is mostly a 100 laundry list of security technologies and tradeoffs. 102 2. Existing HTTP Security Mechanisms 104 For HTTP, the IETF generally defines "security mechanisms" as some 105 combination of access authentication and/or a secure transport. 107 [[ There is a suggestion that this section be split into "browser- 108 like" and "automation-like" subsections. ]] 110 [[ NTLM (shudder) was brought up in the WG a few times in the 111 discussion of the -00 draft. Should we add a section on it? ]] 113 2.1. Forms And Cookies 115 Almost all HTTP authentication that involves a human using a web 116 browser is accomplished through HTML forms, with session identifiers 117 stored in cookies. For cookies, most implementations rely on the 118 "Netscape specification", which is described loosely in section 10 of 119 "HTTP State Management Mechanism" [RFC2109]. The protocol in RFC 120 2109 is relatively widely implemented, but most clients don't 121 advertise support for it. RFC 2109 was later updated [RFC2965], but 122 the newer version is not widely implemented. 124 Forms and cookies have many properties that make them an excellent 125 solution for some implementers. However, many of those properties 126 introduce serious security trade-offs. 128 HTML forms provide a large degree of control over presentation, which 129 is an imperative for many websites. However, this increases user 130 reliance on the appearance of the interface. Many users do not 131 understand the construction of URIs [RFC3986], or their presentation 132 in common clients [PhishingHOWTO]. As a result, forms are extremely 133 vulnerable to spoofing. 135 HTML forms provide acceptable internationalization if used carefully, 136 at the cost of being transmitted as normal HTTP content in all cases 137 (credentials are not differentiated in the protocol). 139 Many Web browsers have an auto-complete feature that stores a user's 140 information and pre-populates fields in forms. This is considered to 141 be a convenience mechanism, and convenience mechanisms often have 142 negative security properties. The security concerns with auto- 143 completion are particularly poignant for web browsers that reside on 144 computers with multiple users. HTML forms provide a facility for 145 sites to indicate that a field, such as a password, should never be 146 pre-populated. However, it is clear that some form creators do not 147 use this facility when they should. 149 The cookies that result from a successful form submission make it 150 unnecessary to validate credentials with each HTTP request; this 151 makes cookies an excellent property for scalability. Cookies are 152 susceptible to a large variety of XSS (cross-site scripting) attacks, 153 and measures to prevent such attacks will never be as stringent as 154 necessary for authentication credentials because cookies are used for 155 many purposes. Cookies are also susceptible to a wide variety of 156 attacks from malicious intermediaries and observers. The possible 157 attacks depend on the contents of the cookie data. There is no 158 standard format for most of the data. 160 HTML forms and cookies provide flexible ways of ending a session from 161 the client. 163 HTML forms require an HTML rendering engine for which many protocols 164 have no use. 166 2.2. HTTP Access Authentication 168 HTTP 1.1 provides a simple authentication framework, "HTTP 169 Authentication: Basic and Digest Access Authentication" [RFC2617], 170 which defines two optional mechanisms. Both of these mechanisms are 171 extremely rarely used in comparison to forms and cookies, but some 172 degree of support for one or both is available in many 173 implementations. Neither scheme provides presentation control, 174 logout capabilities, or interoperable internationalization. 176 2.2.1. Basic Authentication 178 Basic Authentication (normally called just "Basic") transmits 179 usernames and passwords in the clear. It is very easy to implement, 180 but not at all secure unless used over a secure transport. 182 Basic has very poor scalability properties because credentials must 183 be revalidated with every request, and because secure transports 184 negate many of HTTP's caching mechanisms. Some implementations use 185 cookies in combination with Basic credentials, but there is no 186 standard method of doing so. 188 Since Basic credentials are clear text, they are reusable by any 189 party. This makes them compatible with any authentication database, 190 at the cost of making the user vulnerable to mismanaged or malicious 191 servers, even over a secure channel. 193 Basic is not interoperable when used with credentials that contain 194 characters outside of the ISO 8859-1 repertoire. 196 2.2.2. Digest Authentication 198 In Digest Authentication, the client transmits the results of hashing 199 user credentials with properties of the request and values from the 200 server challenge. Digest is susceptible to man-in-the-middle attacks 201 when not used over a secure transport. 203 Digest has some properties that are preferable to Basic and Cookies. 204 Credentials are not immediately reusable by parties that observe or 205 receive them, and session data can be transmitted along side 206 credentials with each request, allowing servers to validate 207 credentials only when absolutely necessary. Authentication data 208 session keys are distinct from other protocol traffic. 210 Digest includes many modes of operation, but only the simplest modes 211 enjoy any degree of interoperability. For example, most 212 implementations do not implement the mode that provides full message 213 integrity. Perhaps one reason is that implementation experience has 214 shown that in some cases, especially those involving large requests 215 or responses such as streams, the message integrity mode is 216 impractical because it requires servers to analyze the full request 217 before determining whether the client knows the shared secret or 218 whether message-body integrity has been violated and hence whether 219 the request can be processed. 221 Digest is extremely susceptible to offline dictionary attacks, making 222 it practical for attackers to perform a namespace walk consisting of 223 a few million passwords for most users. 225 Many of the most widely-deployed HTTP/1.1 clients are not compliant 226 when GET requests include a query string [Apache_Digest]. 228 Digest either requires that authentication databases be expressly 229 designed to accommodate it, or requires access to cleartext 230 passwords. As a result, many authentication databases that chose to 231 do the former are incompatible, including the most common method of 232 storing passwords for use with Forms and Cookies. 234 Many Digest capabilities included to prevent replay attacks expose 235 the server to Denial of Service attacks. 237 Digest is not interoperable when used with credentials that contain 238 characters outside of the ISO 8859-1 repertoire. 240 2.2.3. Authentication Using Certificates in TLS 242 Running HTTP over TLS provides authentication of the HTTP server to 243 the client. HTTP over TLS can also provides authentication of the 244 client to the server using certificates. Although forms are a much 245 more common way to authenticate users to HTTP servers, TLS client 246 certificates are widely used in some environments. The public key 247 infrastructure (PKI) used to validate certificates in TLS can be 248 rooted in public trust anchors or can be based on local trust 249 anchors. 251 2.2.4. Other Access Authentication Schemes 253 There are many niche schemes that make use of the HTTP Authentication 254 framework, but very few are well documented. Some are bound to 255 transport layer connections. 257 2.2.4.1. Negotiate (GSS-API) Authentication 259 Microsoft has designed an HTTP authentication mechanism that utilizes 260 SPNEGO [RFC4178] GSSAPI [RFC4559]. In Microsoft's implementation, 261 SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan 262 Manager protocols). 264 In Kerberos, clients and servers rely on a trusted third-party 265 authentication service which maintains its own authentication 266 database. Kerberos is typically used with shared secret key 267 cryptography, but extensions for use of other authentication 268 mechnanisms such as PKIX certificates and two-factor tokens are also 269 common. Kerberos was designed to work under the assumption that 270 packets traveling along the network can be read, modified, and 271 inserted at will. 273 Unlike Digest, Negotiate authentication can take multiple round trips 274 (client sending authentication data in Authorization, server sending 275 authentication data in WWW-Authenticate) to complete. 277 Kerberos authentication is generally more secure than Digest. 278 However the requirement for having a separate network authentication 279 service might be a barrier to deployment. 281 2.3. Centrally-Issued Tickets 283 Many large Internet services rely on authentication schemes that 284 center on clients consulting a single service for a time-limited 285 ticket that is validated with undocumented heuristics. Centralized 286 ticket issuing has the advantage that users may employ one set of 287 credentials for many services, and clients don't send credentials to 288 many servers. This approach is often no more than a sophisticated 289 application of forms and cookies. 291 All of the schemes in wide use are proprietary and non-standard, and 292 usually are undocumented. There are many standardization efforts in 293 progress, as usual. 295 2.4. Web Services 297 Many security properties mentioned in this document have been recast 298 in XML-based protocols, using HTTP as a substitute for TCP. Like the 299 amalgam of HTTP technologies mentioned above, the XML-based protocols 300 are defined by an ever-changing combination of standard and vendor- 301 produced specifications, some of which may be obsoleted at any time 302 [WS-Pagecount] without any documented change control procedures. 303 These protocols usually don't have much in common with the 304 Architecture of the World Wide Web. It's not clear why the term "Web" 305 is used to group them, but they are obviously out of scope for HTTP- 306 based application protocols. 308 [[ This section could really use a good definition of "Web Services" 309 to differentiate it from REST. ]] 311 2.5. Transport Layer Security 313 In addition to using TLS for client and/or server authentication, it 314 is also very commonly used to protect the confidentiality and 315 integrity of the HTTP session. For instance, both HTTP Basic 316 authentication and Cookies are often protected against snooping by 317 TLS. 319 It should be noted that, in that case, TLS does not protect against a 320 breach of the credential store at the server or against a keylogger 321 or phishing interface at the client. TLS does not change the fact 322 that Basic Authentication passwords are reusable and does not address 323 that weakness. 325 3. Revisions To HTTP 327 Is is possible that HTTP will be revised in the future. "HTTP/1.1" 328 [RFC2616] and "Use and Interpretation of HTTP Version Numbers" 329 [RFC2145] define conformance requirements in relation to version 330 numbers. In HTTP 1.1, all authentication mechanisms are optional, 331 and no single transport substrate is specified. Any HTTP revision 332 that adds a mandatory security mechanism or transport substrate will 333 have to increment the HTTP version number appropriately. All widely 334 used schemes are non-standard and/or proprietary. 336 4. Security Considerations 338 This entire document is about security considerations. 340 5. Normative References 342 [Apache_Digest] 343 Apache Software Foundation, "Apache HTTP Server - 344 mod_auth_digest", . 347 [PhishingHOWTO] 348 Gutmann, P., "Phishing Tips and Techniques", 349 February 2008, 350 . 352 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 353 3", BCP 9, RFC 2026, October 1996. 355 [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management 356 Mechanism", RFC 2109, February 1997. 358 [RFC2145] Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use 359 and Interpretation of HTTP Version Numbers", RFC 2145, 360 May 1997. 362 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 363 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 364 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 366 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 367 Leach, P., Luotonen, A., and L. Stewart, "HTTP 368 Authentication: Basic and Digest Access Authentication", 369 RFC 2617, June 1999. 371 [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management 372 Mechanism", RFC 2965, October 2000. 374 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 375 Engineering Task Force Standard Protocols", BCP 61, 376 RFC 3365, August 2002. 378 [RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security 379 Mechanisms for the Internet", RFC 3631, December 2003. 381 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 382 Resource Identifier (URI): Generic Syntax", STD 66, 383 RFC 3986, January 2005. 385 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 386 Simple and Protected Generic Security Service Application 387 Program Interface (GSS-API) Negotiation Mechanism", 388 RFC 4178, October 2005. 390 [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based 391 Kerberos and NTLM HTTP Authentication in Microsoft 392 Windows", RFC 4559, June 2006. 394 [WS-Pagecount] 395 Bray, T., "WS-Pagecount", September 2004, . 398 Appendix A. Acknowledgements 400 Much of the material in this document was written by Rob Sayre, who 401 first promoted the topic. Many others on the HTTPbis Working Group 402 have contributed to this document in the discussion. 404 Appendix B. Document History 406 [This entire section is to be removed when published as an RFC.] 408 B.1. Changes between draft-sayre-http-security-variance-00 and 409 draft-ietf-httpbis-security-properties-00 411 Changed the authors to Paul Hoffman and Alexey Melnikov, with 412 permission of Rob Sayre. 414 Made lots of minor editorial changes. 416 Removed what was section 2 (Requirements Notation), the reference to 417 RFC 2119, and any use of 2119ish all-caps words. 419 In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1 420 repertoire" to match the definition of "TEXT" in RFC 2616. 422 Added minor text to the Security Considerations section. 424 Added URLs to the two non-RFC references. 426 B.2. Changes between -00 and -01 428 Fixed some editorial nits reported by Iain Calder. 430 Added the suggestions about splitting for browsers and automation, 431 and about adding NTLM, to be beginning of 2. 433 In 2.1, added "that involves a human using a web browser" in the 434 first sentence. 436 In 2.1, changed "session key" to "session identifier". 438 In 2.2.2, changed 440 Digest includes many modes of operation, but only the simplest modes 441 enjoy any degree of interoperability. For example, most 442 implementations do not implement the mode that provides full message 443 integrity. Additionally, implementation experience has shown that 444 the message integrity mode is impractical because it requires servers 445 to analyze the full request before determining whether the client 446 knows the shared secret. 448 to 449 Digest includes many modes of operation, but only the simplest 450 modes enjoy any degree of interoperability. For example, most 451 implementations do not implement the mode that provides full message 452 integrity. Perhaps one reason is that implementation experience has 453 shown that in some cases, especially those involving large requests 454 or responses such as streams, the message integrity mode is 455 impractical because it requires servers to analyze the full request 456 before determining whether the client knows the shared secret or 457 whether message-body integrity has been violated and hence whether 458 the request can be processed. 460 In 2.4, asked for a definition of "Web Services". 462 In A, added the WG. 464 B.3. Changes between -01 and -02 466 In section 2.1, added more to the paragraph on auto-completion of 467 HTML forms. 469 Added the section on TLS for authentication. 471 Filled in section 2.5. 473 Authors' Addresses 475 Paul Hoffman 476 VPN Consortium 478 Email: paul.hoffman@vpnc.org 480 Alexey Melnikov 481 Isode Ltd. 483 Email: alexey.melnikov@isode.com 485 Full Copyright Statement 487 Copyright (C) The IETF Trust (2008). 489 This document is subject to the rights, licenses and restrictions 490 contained in BCP 78, and except as set forth therein, the authors 491 retain all their rights. 493 This document and the information contained herein are provided on an 494 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 495 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 496 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 497 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 498 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 499 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 501 Intellectual Property 503 The IETF takes no position regarding the validity or scope of any 504 Intellectual Property Rights or other rights that might be claimed to 505 pertain to the implementation or use of the technology described in 506 this document or the extent to which any license under such rights 507 might or might not be available; nor does it represent that it has 508 made any independent effort to identify any such rights. Information 509 on the procedures with respect to rights in RFC documents can be 510 found in BCP 78 and BCP 79. 512 Copies of IPR disclosures made to the IETF Secretariat and any 513 assurances of licenses to be made available, or the result of an 514 attempt made to obtain a general license or permission for the use of 515 such proprietary rights by implementers or users of this 516 specification can be obtained from the IETF on-line IPR repository at 517 http://www.ietf.org/ipr. 519 The IETF invites any interested party to bring to its attention any 520 copyrights, patents or patent applications, or other proprietary 521 rights that may cover technology that may be required to implement 522 this standard. Please address the information to the IETF at 523 ietf-ipr@ietf.org. 525 Acknowledgment 527 Funding for the RFC Editor function is provided by the IETF 528 Administrative Support Activity (IASA).