source: draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.redxml @ 227

Last change on this file since 227 was 220, checked in by paul.hoffman@…, 12 years ago

With a few nits from Julian

File size: 36.6 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!--
3    This XML document is the output of clean-for-DTD.xslt; a tool that strips
4    extensions to RFC2629(bis) from documents for processing with xml2rfc.
5-->
6<!DOCTYPE rfc
7  PUBLIC "" "rfc2629.dtd">
8<rfc category="info" ipr="full3978" docName="draft-ietf-httpbis-security-properties-01">
9
10
11<?xml-stylesheet type='text/xsl' href='rfc2629xslt/rfc2629.xslt' ?>
12
13
14<?rfc toc="yes" ?>
15
16<?rfc symrefs="yes" ?>
17
18<?rfc sortrefs="yes"?>
19
20<?rfc strict="yes" ?>
21
22<?rfc compact="yes" ?>
23
24<?rfc subcompact="no" ?>
25
26<?rfc linkmailto='no'?>
27
28<?rfc comments="yes"?>
29
30<?rfc inline="yes"?>
31
32<front>
33  <title>Security Requirements for HTTP</title>
34  <author initials="P." surname="Hoffman" fullname="Paul Hoffman">
35    <organization>VPN Consortium</organization>
36    <address><email>paul.hoffman@vpnc.org</email> </address>
37  </author>
38  <author initials="A." surname="Melnikov" fullname="Alexey Melnikov">
39     <organization>Isode Ltd.</organization>
40     <address><email>alexey.melnikov@isode.com</email> </address>
41  </author>
42  <date year="2008" month="February"/>
43  <abstract>
44    <t>Recent IESG practice dictates that IETF protocols must specify
45      mandatory-to-implement security mechanisms, so that
46      all conformant implementations share a common baseline. This
47      document examines all widely deployed HTTP security
48      technologies, and analyzes the trade-offs of
49      each.</t>
50  </abstract>
51</front>
52
53<middle>
54 
55<section title="Introduction">
56
57<t>Recent IESG practice dictates that IETF protocols are required to
58specify mandatory to implement security mechanisms. "The IETF
59Standards Process" <xref target="RFC2026"/> does not require that
60protocols specify mandatory security mechanisms. "Strong Security
61Requirements for IETF Standard Protocols" <xref target="RFC3365"/>
62requires that all IETF protocols provide a mechanism for implementers
63to provide strong security. RFC 3365 does not define the term "strong
64security".</t>
65
66<t>"Security Mechanisms for the Internet" <xref target="RFC3631"/> is
67not an IETF procedural RFC, but it is perhaps most relevant. Section
682.2 states:</t>
69
70<figure><artwork><![CDATA[
71
72  We have evolved in the IETF the notion of "mandatory to implement"
73  mechanisms.  This philosophy evolves from our primary desire to
74  ensure interoperability between different implementations of a
75  protocol.  If a protocol offers many options for how to perform a
76  particular task, but fails to provide for at least one that all
77  must implement, it may be possible that multiple, non-interoperable
78  implementations may result.  This is the consequence of the
79  selection of non-overlapping mechanisms being deployed in the
80  different implementations.
81]]></artwork></figure>
82
83<t>This document examines the effects of applying security constraints
84to Web applications, documents the properties that result from each
85method, and will make Best Current Practice recommendations for HTTP
86security in a later document version. At the moment, it is mostly a
87laundry list of security technologies and tradeoffs.</t>
88
89</section>
90
91<section title="Existing HTTP Security Mechanisms">
92
93<t>For HTTP, the IETF generally defines "security mechanisms" as some
94combination of access authentication and/or a secure transport.</t>
95
96<t>[[ There is a suggestion that this section be split into
97"browser-like" and "automation-like" subsections. ]]</t>
98
99<t>[[ NTLM (shudder) was brought up in the WG a few times in
100the discussion of the -00 draft. Should we add a section on it? ]]</t>
101
102<section title="Forms And Cookies">
103
104<t>Almost all HTTP authentication that involves a human
105using a web browser is accomplished through HTML forms,
106with session identifiers stored in cookies. For cookies, most implementations
107rely on the "Netscape specification", which is described loosely in
108section 10 of "HTTP State Management Mechanism" <xref target="RFC2109"/>. The protocol in RFC 2109 is relatively widely
109implemented, but most clients don't advertise support for it. RFC 2109
110was later updated <xref target="RFC2965"/>, but the newer version is
111not widely implemented.</t>
112
113<t>Forms and cookies have many properties that make them an
114excellent solution for some implementers. However, many of those
115properties introduce serious security trade-offs.</t>
116
117<t>HTML forms provide a large degree of control over presentation,
118which is an imperative for many websites. However, this increases user
119reliance on the appearance of the interface. Many users do not
120understand the construction of URIs <xref target="RFC3986"/>, or their
121presentation in common clients <xref target="PhishingHOWTO"/>.
122As a result,
123forms are extremely vulnerable to spoofing.</t>
124
125<t>HTML forms provide acceptable internationalization if used
126carefully, at the cost of being transmitted as normal HTTP content in
127all cases (credentials are not differentiated in the protocol).</t>
128
129<t>HTML forms provide a facility for sites to indicate that a password
130should never be pre-populated.
131[[ More needed here on autocomplete ]]</t>
132
133<t>The cookies that result from a successful form submission make it
134unnecessary to validate credentials with each HTTP request; this makes
135cookies an excellent property for scalability. Cookies are susceptible
136to a large variety of XSS (cross-site scripting) attacks, and measures
137to prevent such attacks will never be as stringent as necessary for
138authentication credentials because cookies are used for many purposes.
139Cookies are also susceptible to a wide variety of attacks from
140malicious intermediaries and observers. The possible attacks depend on
141the contents of the cookie data. There is no standard format for most
142of the data.</t>
143
144<t>HTML forms and cookies provide flexible ways of ending a session
145from the client.</t>
146
147<t>HTML forms require an HTML rendering engine for which many protocols
148have no use.</t>
149
150</section>
151
152<section title="HTTP Access Authentication">
153
154<t>HTTP 1.1 provides a simple authentication framework, "HTTP
155Authentication: Basic and Digest Access Authentication" <xref target="RFC2617"/>, which defines two optional mechanisms. Both of these
156mechanisms are extremely rarely used in comparison to forms and
157cookies, but some degree of support for one or both is available in
158many implementations. Neither scheme provides presentation control,
159logout capabilities, or interoperable internationalization.</t>
160
161<section title="Basic Authentication">
162
163<t>Basic Authentication (normally called just "Basic") transmits
164usernames and passwords in the clear. It is very easy to implement,
165but not at all secure unless used over a secure transport.</t>
166
167<t>Basic has very poor scalability properties because credentials must
168be revalidated with every request, and because secure transports
169negate many of HTTP's caching mechanisms. Some implementations use
170cookies in combination with Basic credentials, but there is no
171standard method of doing so.</t>
172
173<t>Since Basic credentials are clear text, they are reusable by any
174party. This makes them compatible with any authentication database, at
175the cost of making the user vulnerable to mismanaged or malicious
176servers, even over a secure channel.</t>
177
178<t>Basic is not interoperable when used with credentials that contain
179characters outside of the ISO 8859-1 repertoire.</t>
180
181</section>
182
183<section title="Digest Authentication">
184
185<t>In Digest Authentication, the client transmits the results of
186hashing user credentials with properties of the request and values
187from the server challenge. Digest is susceptible to man-in-the-middle
188attacks when not used over a secure transport.</t>
189
190<t>Digest has some properties that are preferable to Basic and
191Cookies. Credentials are not immediately reusable by parties that
192observe or receive them, and session data can be transmitted along
193side credentials with each request, allowing servers to validate
194credentials only when absolutely necessary. Authentication data
195session keys are distinct from other protocol traffic.</t>
196
197<t>Digest includes many modes of operation, but only the simplest
198modes enjoy any degree of interoperability.  For example, most
199implementations do not implement the mode that provides full message
200integrity.  Perhaps one reason is that implementation experience has
201shown that in some cases, especially those involving large requests or
202responses such as streams, the message integrity mode is impractical
203because it requires servers to analyze the full request before
204determining whether the client knows the shared secret or whether
205message-body integrity has been violated and hence whether the request
206can be processed.</t>
207
208<t>Digest is extremely susceptible to offline dictionary attacks,
209making it practical for attackers to perform a namespace walk
210consisting of a few million passwords
211[[ CITATION NEEDED ]].</t>
212
213<t>Many of the most widely-deployed HTTP/1.1 clients are not compliant
214when GET requests include a query string <xref target="Apache_Digest"/>.</t>
215
216<t>Digest either requires that authentication databases be expressly designed
217to accommodate it, or requires access to cleartext passwords.
218As a result, many authentication databases that chose to do the former are
219incompatible, including the most common method of storing passwords
220for use with Forms and Cookies.</t>
221
222<t>Many Digest capabilities included to prevent replay attacks expose
223the server to Denial of Service attacks.</t>
224
225<t>Digest is not interoperable when used with credentials that contain
226characters outside of the ISO 8859-1 repertoire.</t>
227
228</section>
229
230<section title="Other Access Authentication Schemes">
231
232<t>There are many niche schemes that make use of the HTTP
233Authentication framework, but very few are well documented. Some are
234bound to transport layer connections.</t>
235
236<section title="Negotiate (GSS-API) Authentication">
237
238<t>[[ A discussion about "SPNEGO-based Kerberos and NTLM HTTP
239Authentication in Microsoft Windows" <xref target="RFC4559"/>
240goes here. ]]</t>
241
242</section>
243
244</section>
245
246</section>
247
248<section title="Centrally-Issued Tickets">
249
250<t>Many large Internet services rely on authentication schemes that
251center on clients consulting a single service for a time-limited
252ticket that is validated with undocumented heuristics. Centralized
253ticket issuing has the advantage that users may employ one set of
254credentials for many services, and clients don't send credentials to
255many servers. This approach is often no more than a sophisticated
256application of forms and cookies.</t>
257
258<t>All of the schemes in wide use are proprietary and non-standard,
259and usually are undocumented. There are many standardization efforts
260in progress, as usual.</t>
261
262</section>
263
264<section title="Web Services">
265
266<t>Many security properties mentioned in this document have been recast in
267XML-based protocols, using HTTP as a substitute for TCP. Like the
268amalgam of HTTP technologies mentioned above, the XML-based protocols
269are defined by an ever-changing combination of standard and
270vendor-produced specifications, some of which may be obsoleted at any
271time <xref target="WS-Pagecount"/> without any documented change control
272procedures. These protocols usually don't have much in common with the
273Architecture of the World Wide Web. It's not clear why the term "Web" is
274used to group them, but they are obviously out of scope for HTTP-based
275application protocols.</t>
276
277<t>[[ This section could really use a good definition of
278"Web Services" to differentiate it from REST. ]]</t>
279
280</section>
281
282<section title="Transport Layer Security">
283
284<t>[[ A discussion of HTTP over TLS needs to be added
285here. ]]</t>
286
287<t>[[ Discussion of connection confidentiality should be separate from
288the discussion of access authentication based on mutual authentication with
289certificates in TLS. ]]</t>
290
291</section>
292
293</section>
294
295<section title="Revisions To HTTP">
296
297<t>Is is possible that HTTP will be revised in the future. "HTTP/1.1"
298<xref target="RFC2616"/> and "Use and Interpretation of HTTP Version
299Numbers" <xref target="RFC2145"/> define conformance requirements in
300relation to version numbers. In HTTP 1.1, all authentication
301mechanisms are optional, and no single transport substrate is
302specified. Any HTTP revision that adds a mandatory security mechanism
303or transport substrate will have to increment the HTTP version number
304appropriately. All widely used schemes are non-standard and/or
305proprietary.</t>
306
307</section>
308
309<section title="Security Considerations">
310
311<t>This entire document is about security considerations.</t>
312
313</section>
314
315</middle>
316
317<back>
318
319<references title="Normative References">
320
321
322
323<reference anchor="RFC2026">
324
325<front>
326<title abbrev="Internet Standards Process">The Internet Standards Process -- Revision 3</title>
327<author initials="S." surname="Bradner" fullname="Scott O. Bradner">
328<organization>Harvard University</organization>
329<address>
330<postal>
331<street>1350 Mass. Ave.</street>
332<city>Cambridge</city>
333<region>MA</region>
334<code>02138</code>
335<country>US</country></postal>
336<phone>+1 617 495 3864</phone>
337<email>sob@harvard.edu</email></address></author>
338<date year="1996" month="October"/>
339<abstract>
340<t>This memo documents the process used by the Internet community for the standardization of protocols and procedures.  It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process.  It also addresses the intellectual property rights and copyright issues associated with the standards process.</t></abstract></front>
341
342<seriesInfo name="BCP" value="9"/>
343<seriesInfo name="RFC" value="2026"/>
344<format type="TXT" octets="86731" target="ftp://ftp.isi.edu/in-notes/rfc2026.txt"/>
345</reference>
346
347
348
349<reference anchor="RFC2109">
350
351<front>
352<title>HTTP State Management Mechanism</title>
353<author initials="D.M." surname="Kristol" fullname="David M. Kristol">
354<organization>Bell Laboratories, Lucent Technologies</organization>
355<address>
356<postal>
357<street>600 Mountain Ave.  Room 2A-227</street>
358<street>Murray Hill</street>
359<street>NJ  07974</street></postal>
360<phone>(908) 582-2250</phone>
361<facsimile>(908) 582-5809</facsimile>
362<email>dmk@bell-labs.com</email></address></author>
363<author initials="L." surname="Montulli" fullname="Lou Montulli">
364<organization>Netscape Communications Corp.</organization>
365<address>
366<postal>
367<street>501 E. Middlefield Rd.</street>
368<street>Mountain View</street>
369<street>CA  94043</street></postal>
370<phone>(415) 528-2600</phone>
371<email>montulli@netscape.com</email></address></author>
372<date year="1997" month="February"/>
373<keyword>cookie</keyword>
374<keyword>hypertext transfer protocol</keyword></front>
375
376<seriesInfo name="RFC" value="2109"/>
377<format type="TXT" octets="43469" target="ftp://ftp.isi.edu/in-notes/rfc2109.txt"/>
378<format type="HTML" octets="60359" target="http://xml.resource.org/public/rfc/html/rfc2109.html"/>
379<format type="XML" octets="47217" target="http://xml.resource.org/public/rfc/xml/rfc2109.xml"/>
380</reference>
381
382
383
384<reference anchor="RFC2145">
385
386<front>
387<title abbrev="HTTP Version Numbers">Use and Interpretation of HTTP Version Numbers</title>
388<author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul">
389<organization>Western Research Laboratory</organization>
390<address>
391<postal>
392<street>Digital Equipment Corporation</street>
393<street>250 University Avenue</street>
394<street>Palo Alto</street>
395<street>California</street>
396<street>94305</street>
397<country>USA</country></postal>
398<email>mogul@wrl.dec.com</email></address></author>
399<author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
400<organization>Department of Information and Computer Science</organization>
401<address>
402<postal>
403<street>University of California</street>
404<street>Irvine</street>
405<street>CA 92717-3425</street>
406<country>USA</country></postal>
407<facsimile>+1 (714) 824-4056</facsimile>
408<email>fielding@ics.uci.edu</email></address></author>
409<author initials="J." surname="Gettys" fullname="Jim Gettys">
410<organization>MIT Laboratory for Computer Science</organization>
411<address>
412<postal>
413<street>545 Technology Square</street>
414<street>Cambridge</street>
415<street>MA 02139</street>
416<country>USA</country></postal>
417<facsimile>+1 (617) 258 8682</facsimile>
418<email>jg@w3.org</email></address></author>
419<author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
420<organization>W3 Consortium</organization>
421<address>
422<postal>
423<street>MIT Laboratory for Computer Science</street>
424<street>545 Technology Square</street>
425<street>Cambridge</street>
426<street>MA 02139</street>
427<country>USA</country></postal>
428<facsimile>+1 (617) 258 8682</facsimile>
429<email>frystyk@w3.org</email></address></author>
430<date year="1997" month="May"/>
431<area>Applications</area>
432<keyword>HTTP</keyword>
433<keyword>hypertext transfer protocol</keyword>
434<abstract>
435<t>
436   HTTP request and response messages include an HTTP protocol version
437   number.  Some confusion exists concerning the proper use and
438   interpretation of HTTP version numbers, and concerning
439   interoperability of HTTP implementations of different protocol
440   versions.  This document is an attempt to clarify the situation.  It
441   is not a modification of the intended meaning of the existing
442   HTTP/1.0 and HTTP/1.1 documents, but it does describe the intention
443   of the authors of those documents, and can be considered definitive
444   when there is any ambiguity in those documents concerning HTTP
445   version numbers, for all versions of HTTP.
446</t></abstract></front>
447
448<seriesInfo name="RFC" value="2145"/>
449<format type="TXT" octets="13659" target="ftp://ftp.isi.edu/in-notes/rfc2145.txt"/>
450<format type="HTML" octets="25554" target="http://xml.resource.org/public/rfc/html/rfc2145.html"/>
451<format type="XML" octets="14130" target="http://xml.resource.org/public/rfc/xml/rfc2145.xml"/>
452</reference>
453
454
455
456<reference anchor="RFC2616">
457
458<front>
459<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
460<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
461<organization abbrev="UC Irvine">Department of Information and Computer Science</organization>
462<address>
463<postal>
464<street>University of California, Irvine</street>
465<city>Irvine</city>
466<region>CA</region>
467<code>92697-3425</code></postal>
468<facsimile>+1(949)824-1715</facsimile>
469<email>fielding@ics.uci.edu</email></address></author>
470<author initials="J." surname="Gettys" fullname="James Gettys">
471<organization abbrev="Compaq/W3C">World Wide Web Consortium</organization>
472<address>
473<postal>
474<street>MIT Laboratory for Computer Science, NE43-356</street>
475<street>545 Technology Square</street>
476<city>Cambridge</city>
477<region>MA</region>
478<code>02139</code></postal>
479<facsimile>+1(617)258-8682</facsimile>
480<email>jg@w3.org</email></address></author>
481<author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
482<organization abbrev="Compaq">Compaq Computer Corporation</organization>
483<address>
484<postal>
485<street>Western Research Laboratory</street>
486<street>250 University Avenue</street>
487<city>Palo Alto</city>
488<region>CA</region>
489<code>94305</code></postal>
490<email>mogul@wrl.dec.com</email></address></author>
491<author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
492<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
493<address>
494<postal>
495<street>MIT Laboratory for Computer Science, NE43-356</street>
496<street>545 Technology Square</street>
497<city>Cambridge</city>
498<region>MA</region>
499<code>02139</code></postal>
500<facsimile>+1(617)258-8682</facsimile>
501<email>frystyk@w3.org</email></address></author>
502<author initials="L." surname="Masinter" fullname="Larry Masinter">
503<organization abbrev="Xerox">Xerox Corporation</organization>
504<address>
505<postal>
506<street>MIT Laboratory for Computer Science, NE43-356</street>
507<street>3333 Coyote Hill Road</street>
508<city>Palo Alto</city>
509<region>CA</region>
510<code>94034</code></postal>
511<email>masinter@parc.xerox.com</email></address></author>
512<author initials="P." surname="Leach" fullname="Paul J. Leach">
513<organization abbrev="Microsoft">Microsoft Corporation</organization>
514<address>
515<postal>
516<street>1 Microsoft Way</street>
517<city>Redmond</city>
518<region>WA</region>
519<code>98052</code></postal>
520<email>paulle@microsoft.com</email></address></author>
521<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
522<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
523<address>
524<postal>
525<street>MIT Laboratory for Computer Science, NE43-356</street>
526<street>545 Technology Square</street>
527<city>Cambridge</city>
528<region>MA</region>
529<code>02139</code></postal>
530<facsimile>+1(617)258-8682</facsimile>
531<email>timbl@w3.org</email></address></author>
532<date year="1999" month="June"/>
533<abstract>
534<t>
535   The Hypertext Transfer Protocol (HTTP) is an application-level
536   protocol for distributed, collaborative, hypermedia information
537   systems. It is a generic, stateless, protocol which can be used for
538   many tasks beyond its use for hypertext, such as name servers and
539   distributed object management systems, through extension of its
540   request methods, error codes and headers . A feature of HTTP is
541   the typing and negotiation of data representation, allowing systems
542   to be built independently of the data being transferred.
543</t>
544<t>
545   HTTP has been in use by the World-Wide Web global information
546   initiative since 1990. This specification defines the protocol
547   referred to as "HTTP/1.1", and is an update to RFC 2068 .
548</t></abstract></front>
549
550<seriesInfo name="RFC" value="2616"/>
551<format type="TXT" octets="422317" target="ftp://ftp.isi.edu/in-notes/rfc2616.txt"/>
552<format type="PS" octets="5529857" target="ftp://ftp.isi.edu/in-notes/rfc2616.ps"/>
553<format type="PDF" octets="550558" target="ftp://ftp.isi.edu/in-notes/rfc2616.pdf"/>
554<format type="HTML" octets="636125" target="http://xml.resource.org/public/rfc/html/rfc2616.html"/>
555<format type="XML" octets="493420" target="http://xml.resource.org/public/rfc/xml/rfc2616.xml"/>
556</reference>
557
558
559
560<reference anchor="RFC2617">
561
562<front>
563<title abbrev="HTTP Authentication">HTTP Authentication: Basic and Digest Access Authentication</title>
564<author initials="J." surname="Franks" fullname="John Franks">
565<organization>Northwestern University, Department of Mathematics</organization>
566<address>
567<postal>
568<street>Northwestern University</street>
569<city>Evanston</city>
570<region>IL</region>
571<code>60208-2730</code>
572<country>USA</country></postal>
573<email>john@math.nwu.edu</email></address></author>
574<author initials="P.M." surname="Hallam-Baker" fullname="Phillip M. Hallam-Baker">
575<organization>Verisign Inc.</organization>
576<address>
577<postal>
578<street>301 Edgewater Place</street>
579<street>Suite 210</street>
580<city>Wakefield</city>
581<region>MA</region>
582<code>01880</code>
583<country>USA</country></postal>
584<email>pbaker@verisign.com</email></address></author>
585<author initials="J.L." surname="Hostetler" fullname="Jeffery L. Hostetler">
586<organization>AbiSource, Inc.</organization>
587<address>
588<postal>
589<street>6 Dunlap Court</street>
590<city>Savoy</city>
591<region>IL</region>
592<code>61874</code>
593<country>USA</country></postal>
594<email>jeff@AbiSource.com</email></address></author>
595<author initials="S.D." surname="Lawrence" fullname="Scott D. Lawrence">
596<organization>Agranat Systems, Inc.</organization>
597<address>
598<postal>
599<street>5 Clocktower Place</street>
600<street>Suite 400</street>
601<city>Maynard</city>
602<region>MA</region>
603<code>01754</code>
604<country>USA</country></postal>
605<email>lawrence@agranat.com</email></address></author>
606<author initials="P.J." surname="Leach" fullname="Paul J. Leach">
607<organization>Microsoft Corporation</organization>
608<address>
609<postal>
610<street>1 Microsoft Way</street>
611<city>Redmond</city>
612<region>WA</region>
613<code>98052</code>
614<country>USA</country></postal>
615<email>paulle@microsoft.com</email></address></author>
616<author initials="A." surname="Luotonen" fullname="Ari Luotonen">
617<organization>Netscape Communications Corporation</organization>
618<address>
619<postal>
620<street>501 East Middlefield Road</street>
621<city>Mountain View</city>
622<region>CA</region>
623<code>94043</code>
624<country>USA</country></postal></address></author>
625<author initials="L." surname="Stewart" fullname="Lawrence C. Stewart">
626<organization>Open Market, Inc.</organization>
627<address>
628<postal>
629<street>215 First Street</street>
630<city>Cambridge</city>
631<region>MA</region>
632<code>02142</code>
633<country>USA</country></postal>
634<email>stewart@OpenMarket.com</email></address></author>
635<date year="1999" month="June"/>
636<abstract>
637<t>
638   "HTTP/1.0", includes the specification for a Basic Access
639   Authentication scheme. This scheme is not considered to be a secure
640   method of user authentication (unless used in conjunction with some
641   external secure system such as SSL ), as the user name and
642   password are passed over the network as cleartext.
643      </t>
644<t>
645   This document also provides the specification for HTTP's
646   authentication framework, the original Basic authentication scheme
647   and a scheme based on cryptographic hashes, referred to as "Digest
648   Access Authentication".  It is therefore also intended to serve as a
649   replacement for RFC 2069 .  Some optional elements specified by
650   RFC 2069 have been removed from this specification due to problems
651   found since its publication; other new elements have been added for
652   compatibility, those new elements have been made optional, but are
653   strongly recommended.
654      </t>
655<t>
656   Like Basic, Digest access authentication verifies that both parties
657   to a communication know a shared secret (a password); unlike Basic,
658   this verification can be done without sending the password in the
659   clear, which is Basic's biggest weakness. As with most other
660   authentication protocols, the greatest sources of risks are usually
661   found not in the core protocol itself but in policies and procedures
662   surrounding its use.
663    </t></abstract></front>
664
665<seriesInfo name="RFC" value="2617"/>
666<format type="TXT" octets="77638" target="ftp://ftp.isi.edu/in-notes/rfc2617.txt"/>
667<format type="HTML" octets="116625" target="http://xml.resource.org/public/rfc/html/rfc2617.html"/>
668<format type="XML" octets="88198" target="http://xml.resource.org/public/rfc/xml/rfc2617.xml"/>
669</reference>
670
671
672
673<reference anchor="RFC2965">
674
675<front>
676<title>HTTP State Management Mechanism</title>
677<author initials="D. M." surname="Kristol" fullname="David M. Kristol">
678<organization>Bell Laboratories, Lucent Technologies</organization>
679<address>
680<postal>
681<street>600 Mountain Ave.  Room 2A-333</street>
682<city>Murray Hill</city>
683<region>NJ</region>
684<code>07974</code></postal>
685<phone>(908) 582-2250</phone>
686<facsimile>(908) 582-1239</facsimile>
687<email>dmk@bell-labs.com</email></address></author>
688<author initials="L." surname="Montulli" fullname="Lou Montulli">
689<organization>Epinions.com, Inc.</organization>
690<address>
691<postal>
692<street>2037 Landings Dr.</street>
693<city>Mountain View</city>
694<region>CA</region>
695<code>94301</code></postal>
696<email>lou@montulli.org</email></address></author>
697<date year="2000" month="October"/>
698<abstract>
699<t>
700     This document specifies a way to create a stateful session with
701     Hypertext Transfer Protocol (HTTP) requests and responses.  It
702     describes three new headers, Cookie, Cookie2, and Set-Cookie2, which
703     carry state information between participating origin servers and user
704     agents.  The method described here differs from Netscape's Cookie
705     proposal , but it can interoperate with HTTP/1.0 user
706     agents that use Netscape's method.  (See the HISTORICAL section.)
707    </t>
708<t>
709     This document reflects implementation experience with RFC 2109 and
710     obsoletes it.
711     </t></abstract></front>
712
713<seriesInfo name="RFC" value="2965"/>
714<format type="TXT" octets="56176" target="ftp://ftp.isi.edu/in-notes/rfc2965.txt"/>
715<format type="HTML" octets="84336" target="http://xml.resource.org/public/rfc/html/rfc2965.html"/>
716<format type="XML" octets="60779" target="http://xml.resource.org/public/rfc/xml/rfc2965.xml"/>
717</reference>
718
719
720
721<reference anchor="RFC3365">
722
723<front>
724<title>Strong Security Requirements for Internet Engineering Task Force Standard Protocols</title>
725<author initials="J." surname="Schiller" fullname="J. Schiller">
726<organization/></author>
727<date year="2002" month="August"/></front>
728
729<seriesInfo name="BCP" value="61"/>
730<seriesInfo name="RFC" value="3365"/>
731<format type="TXT" octets="16411" target="ftp://ftp.isi.edu/in-notes/rfc3365.txt"/>
732</reference>
733
734
735
736<reference anchor="RFC3631">
737
738<front>
739<title>Security Mechanisms for the Internet</title>
740<author initials="S." surname="Bellovin" fullname="S. Bellovin">
741<organization/></author>
742<author initials="J." surname="Schiller" fullname="J. Schiller">
743<organization/></author>
744<author initials="C." surname="Kaufman" fullname="C. Kaufman">
745<organization/></author>
746<date year="2003" month="December"/>
747<abstract>
748<t>Security must be built into Internet Protocols for those protocols to offer their services securely.  Many security problems can be traced to improper implementations.  However, even a proper implementation will have security problems if the fundamental protocol is itself exploitable.  Exactly how security should be implemented in a protocol will vary, because of the structure of the protocol itself.  However, there are many protocols for which standard Internet security mechanisms, already developed, may be applicable.  The precise one that is appropriate in any given situation can vary.  We review a number of different choices, explaining the properties of each.</t></abstract></front>
749
750<seriesInfo name="RFC" value="3631"/>
751<format type="TXT" octets="47064" target="ftp://ftp.isi.edu/in-notes/rfc3631.txt"/>
752</reference>
753
754
755
756<reference anchor="RFC3986">
757
758<front>
759<title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
760<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
761<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
762<address>
763<postal>
764<street>Massachusetts Institute of Technology</street>
765<street>77 Massachusetts Avenue</street>
766<city>Cambridge</city>
767<region>MA</region>
768<code>02139</code>
769<country>USA</country></postal>
770<phone>+1-617-253-5702</phone>
771<facsimile>+1-617-258-5999</facsimile>
772<email>timbl@w3.org</email>
773<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
774<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
775<organization abbrev="Day Software">Day Software</organization>
776<address>
777<postal>
778<street>5251 California Ave., Suite 110</street>
779<city>Irvine</city>
780<region>CA</region>
781<code>92617</code>
782<country>USA</country></postal>
783<phone>+1-949-679-2960</phone>
784<facsimile>+1-949-679-2972</facsimile>
785<email>fielding@gbiv.com</email>
786<uri>http://roy.gbiv.com/</uri></address></author>
787<author initials="L." surname="Masinter" fullname="Larry Masinter">
788<organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
789<address>
790<postal>
791<street>345 Park Ave</street>
792<city>San Jose</city>
793<region>CA</region>
794<code>95110</code>
795<country>USA</country></postal>
796<phone>+1-408-536-3024</phone>
797<email>LMM@acm.org</email>
798<uri>http://larry.masinter.net/</uri></address></author>
799<date year="2005" month="January"/>
800<area>Applications</area>
801<keyword>uniform resource identifier</keyword>
802<keyword>URI</keyword>
803<keyword>URL</keyword>
804<keyword>URN</keyword>
805<keyword>WWW</keyword>
806<keyword>resource</keyword>
807<abstract>
808<t>
809A Uniform Resource Identifier (URI) is a compact sequence of characters
810that identifies an abstract or physical resource.  This specification
811defines the generic URI syntax and a process for resolving URI references
812that might be in relative form, along with guidelines and security
813considerations for the use of URIs on the Internet.
814The URI syntax defines a grammar that is a superset of all valid URIs,
815allowing an implementation to parse the common components of a URI
816reference without knowing the scheme-specific requirements of every
817possible identifier.  This specification does not define a generative
818grammar for URIs; that task is performed by the individual
819specifications of each URI scheme.
820</t></abstract></front>
821
822<seriesInfo name="STD" value="66"/>
823<seriesInfo name="RFC" value="3986"/>
824<format type="TXT" octets="141811" target="ftp://ftp.isi.edu/in-notes/rfc3986.txt"/>
825<format type="HTML" octets="213584" target="http://xml.resource.org/public/rfc/html/rfc3986.html"/>
826<format type="XML" octets="163534" target="http://xml.resource.org/public/rfc/xml/rfc3986.xml"/>
827</reference>
828
829
830
831<reference anchor="RFC4559">
832
833<front>
834<title>SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows</title>
835<author initials="K." surname="Jaganathan" fullname="K. Jaganathan">
836<organization/></author>
837<author initials="L." surname="Zhu" fullname="L. Zhu">
838<organization/></author>
839<author initials="J." surname="Brezak" fullname="J. Brezak">
840<organization/></author>
841<date year="2006" month="June"/>
842<abstract>
843<t>This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 2000 use Kerberos for security enhancements of web transactions.  The Hypertext Transport Protocol (HTTP) auth-scheme of "negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed.  This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism.  Details of Simple And Protected Negotiate (SPNEGO) implementation are not provided in this document.  This memo provides information for the Internet community.</t></abstract></front>
844
845<seriesInfo name="RFC" value="4559"/>
846<format type="TXT" octets="16088" target="ftp://ftp.isi.edu/in-notes/rfc4559.txt"/>
847</reference>
848
849
850<reference anchor="Apache_Digest" target="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html">
851<front>
852  <title>Apache HTTP Server - mod_auth_digest</title>
853  <author surname="Apache Software Foundation">
854  <organization/>
855  </author>
856<date year="" month=""/>
857</front>
858</reference>
859
860<reference anchor="PhishingHOWTO" target="http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf">
861<front>
862  <title>Phishing Tips and Techniques</title>
863  <author initials="P." surname="Gutmann" fullname="Peter Gutmann">
864  <organization/></author>
865  <date year="2008" month="February"/>
866</front>
867</reference>
868
869<reference anchor="WS-Pagecount" target="http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research">
870<front>
871  <title>WS-Pagecount</title>
872  <author initials="T." surname="Bray" fullname="Tim Bray">
873  <organization/>
874  </author>
875  <date year="2004" month="September"/>
876</front>
877</reference>
878
879</references>
880
881<section title="Acknowledgements">
882
883<t>Much of the material in this document was written by Rob Sayre,
884who first promoted the topic. Many others on the HTTPbis Working
885Group have contributed to this document in the discussion.</t>
886
887</section>
888
889<section title="Document History">
890
891<t>[This entire section is to be removed when published as an RFC.]</t>
892
893<section title="Changes between draft-sayre-http-security-variance-00 and   draft-ietf-httpbis-security-properties-00">
894
895<t>Changed the authors to Paul Hoffman and Alexey Melnikov, with permission
896of Rob Sayre.</t>
897
898<t>Made lots of minor editorial changes.</t>
899
900<t>Removed what was section 2 (Requirements Notation), the reference
901to RFC 2119, and any use of 2119ish all-caps words.</t>
902
903<t>In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1
904repertoire" to match the definition of "TEXT" in RFC 2616.</t>
905
906<t>Added minor text to the Security Considerations section.</t>
907
908<t>Added URLs to the two non-RFC references.</t>
909
910</section>
911
912<section title="Changes between -00 and -01">
913
914<t>Fixed some editorial nits reported by Iain Calder.</t>
915
916<t>Added the suggestions about splitting for browsers and
917automation, and about adding NTLM, to be beginning of 2.</t>
918
919<t>In 2.1, added "that involves a human
920using a web browser" in the first sentence.</t>
921
922<t>In 2.1, changed "session key" to "session identifier".</t>
923
924<t>In 2.2.2, changed
925<figure><artwork><![CDATA[
926
927Digest includes many modes of operation, but only the simplest modes
928enjoy any degree of interoperability.  For example, most
929implementations do not implement the mode that provides full message
930integrity.  Additionally, implementation experience has shown that
931the message integrity mode is impractical because it requires servers
932to analyze the full request before determining whether the client
933knows the shared secret.
934]]></artwork></figure>
935to
936<figure><artwork><![CDATA[
937
938Digest includes many modes of operation, but only the simplest
939modes enjoy any degree of interoperability.  For example, most
940implementations do not implement the mode that provides full message
941integrity.  Perhaps one reason is that implementation experience has
942shown that in some cases, especially those involving large requests
943or responses such as streams, the message integrity mode is
944impractical because it requires servers to analyze the full request
945before determining whether the client knows the shared secret or
946whether message-body integrity has been violated and hence whether
947the request can be processed.
948]]></artwork></figure>
949</t>
950
951<t>In 2.4, asked for a definition of "Web Services".</t>
952
953<t>In A, added the WG.</t>
954
955</section>
956
957</section>
958
959</back>
960
961</rfc>
Note: See TracBrowser for help on using the repository browser.