source: draft-ietf-httpbis-security-properties/latest/draft-ietf-httpbis-security-properties.txt @ 787

Last change on this file since 787 was 787, checked in by julian.reschke@…, 10 years ago

update to what was submitted as draft 04

File size: 28.2 KB
Line 
1
2
3
4Network Working Group                                          J. Hodges
5Internet-Draft                                                    PayPal
6Intended status: Informational                                  B. Leiba
7Expires: September 2, 2009                           Huawei Technologies
8                                                              March 2009
9
10
11                     Security Requirements for HTTP
12             draft-ietf-httpbis-security-properties-latest
13
14Status of this Memo
15
16   This Internet-Draft is submitted to IETF in full conformance with the
17   provisions of BCP 78 and BCP 79.  This document may contain material
18   from IETF Documents or IETF Contributions published or made publicly
19   available before November 10, 2008.  The person(s) controlling the
20   copyright in some of this material may not have granted the IETF
21   Trust the right to allow modifications of such material outside the
22   IETF Standards Process.  Without obtaining an adequate license from
23   the person(s) controlling the copyright in such materials, this
24   document may not be modified outside the IETF Standards Process, and
25   derivative works of it may not be created outside the IETF Standards
26   Process, except to format it for publication as an RFC or to
27   translate it into languages other than English.
28
29   Internet-Drafts are working documents of the Internet Engineering
30   Task Force (IETF), its areas, and its working groups.  Note that
31   other groups may also distribute working documents as Internet-
32   Drafts.
33
34   Internet-Drafts are draft documents valid for a maximum of six months
35   and may be updated, replaced, or obsoleted by other documents at any
36   time.  It is inappropriate to use Internet-Drafts as reference
37   material or to cite them other than as "work in progress."
38
39   The list of current Internet-Drafts can be accessed at
40   http://www.ietf.org/ietf/1id-abstracts.txt.
41
42   The list of Internet-Draft Shadow Directories can be accessed at
43   http://www.ietf.org/shadow.html.
44
45   This Internet-Draft will expire on September 2, 2009.
46
47Copyright Notice
48
49   Copyright (c) 2009 IETF Trust and the persons identified as the
50   document authors.  All rights reserved.
51
52
53
54
55Hodges & Leiba          Expires September 2, 2009               [Page 1]
56
57Internet-Draft       Security Requirements for HTTP           March 2009
58
59
60   This document is subject to BCP 78 and the IETF Trust's Legal
61   Provisions Relating to IETF Documents in effect on the date of
62   publication of this document (http://trustee.ietf.org/license-info).
63   Please review these documents carefully, as they describe your rights
64   and restrictions with respect to this document.
65
66Abstract
67
68   Recent IESG practice dictates that IETF protocols must specify
69   mandatory-to-implement (MTI) security mechanisms, so that all
70   conformant implementations share a common baseline.  This document
71   examines all widely deployed HTTP security technologies, and analyzes
72   the trade-offs of each.
73
74
75Table of Contents
76
77   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
78   2.  Existing HTTP Security Mechanisms  . . . . . . . . . . . . . .  3
79     2.1.  Forms And Cookies  . . . . . . . . . . . . . . . . . . . .  4
80     2.2.  HTTP Access Authentication . . . . . . . . . . . . . . . .  5
81       2.2.1.  Basic Authentication . . . . . . . . . . . . . . . . .  6
82       2.2.2.  Digest Authentication  . . . . . . . . . . . . . . . .  6
83       2.2.3.  Authentication Using Certificates in TLS . . . . . . .  7
84       2.2.4.  Other Access Authentication Schemes  . . . . . . . . .  7
85     2.3.  Centrally-Issued Tickets . . . . . . . . . . . . . . . . .  8
86     2.4.  Web Services . . . . . . . . . . . . . . . . . . . . . . .  8
87     2.5.  Transport Layer Security . . . . . . . . . . . . . . . . .  9
88   3.  Revisions To HTTP  . . . . . . . . . . . . . . . . . . . . . .  9
89   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
90   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
91   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
92     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
93     6.2.  Informative References . . . . . . . . . . . . . . . . . . 11
94   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 11
95   Appendix B.  Document History  . . . . . . . . . . . . . . . . . . 11
96     B.1.  Changes between draft-sayre-http-security-variance-00
97           and
98           draft-ietf-httpbis-security-properties-00  . . . . . . . . 11
99     B.2.  Changes between -00 and -01  . . . . . . . . . . . . . . . 11
100     B.3.  Changes between -01 and -02  . . . . . . . . . . . . . . . 12
101     B.4.  Changes between -02 and -03  . . . . . . . . . . . . . . . 12
102     B.5.  Changes between -03 and -04  . . . . . . . . . . . . . . . 13
103   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
104
105
106
107
108
109
110
111Hodges & Leiba          Expires September 2, 2009               [Page 2]
112
113Internet-Draft       Security Requirements for HTTP           March 2009
114
115
1161.  Introduction
117
118   Recent IESG practice dictates that IETF protocols be required to
119   specify mandatory-to-implement (MTI) security mechanisms.  "The IETF
120   Standards Process" [RFC2026] does not require that protocols specify
121   mandatory security mechanisms.  "Strong Security Requirements for
122   IETF Standard Protocols" [RFC3365] requires that all IETF protocols
123   provide a mechanism for implementers to provide strong security.  RFC
124   3365 does not define the term "strong security".
125
126   "Security Mechanisms for the Internet" [RFC3631] is not an IETF
127   procedural RFC, but it is perhaps most relevant.  Section 2.2 states:
128
129
130     We have evolved in the IETF the notion of "mandatory to implement"
131     mechanisms.  This philosophy evolves from our primary desire to
132     ensure interoperability between different implementations of a
133     protocol.  If a protocol offers many options for how to perform a
134     particular task, but fails to provide for at least one that all
135     must implement, it may be possible that multiple, non-interoperable
136     implementations may result.  This is the consequence of the
137     selection of non-overlapping mechanisms being deployed in the
138     different implementations.
139
140   This document examines the effects of applying security constraints
141   to Web applications, documents the properties that result from each
142   method, and will make Best Current Practice recommendations for HTTP
143   security in a later document version.  At the moment, it is mostly a
144   laundry list of security technologies and tradeoffs.
145
146   [[ OVERALL ISSUE: It isn't entirely clear to the present editors what
147   the purpose of this document is.  On one hand it could be a
148   compendium of peer-entity authentication mechanisms (as it is
149   presently) and make MTI recommendations thereof, or it could be a
150   place for various security considerations (either coalesced here from
151   the other httpbis specs, or reserved for the more gnarly cross-spec
152   composite ones), or both.  This needs to be clarified. ]]
153
154
1552.  Existing HTTP Security Mechanisms
156
157   For HTTP, the IETF generally defines "security mechanisms" as some
158   combination of access authentication and/or a secure transport.
159
160   [[ There is a suggestion that this section be split into "browser-
161   like" and "automation-like" subsections.  See:
162
163
164
165
166
167Hodges & Leiba          Expires September 2, 2009               [Page 3]
168
169Internet-Draft       Security Requirements for HTTP           March 2009
170
171
172      http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
173      0180.html
174
175      http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
176      0183.html
177
178   ]]
179
180   [[ NTLM (shudder) was brought up in the WG a few times in the
181   discussion of the -00 draft.  Should we add a section on it?  See..
182
183      http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
184      0132.html
185
186      http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
187      0135.html
188
189   ]]
190
1912.1.  Forms And Cookies
192
193   [[ JH: I am not convinced that this subsection properly belongs in
194   this overall section in that "HTTP+HTML Form based authentication"
195   <http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication>
196   is not properly a part of HTTP itself.  Rather, it is a piece of
197   applications layered on top of HTTP.  Use of cookies for state
198   management (e.g. session maintanence) can be considered such, however
199   (although there is no overall specification for HTTP user agents
200   stipulating that they must implement cookies (nominally [RFC2109])).
201   Perhaps this section should be should be retitled "HTTP
202   Authentication".
203
204   Note: The httpstate WG was recently chartered to develop a successor
205   to [RFC2109].  See..
206
207      http://www.ietf.org/dyn/wg/charter/httpstate-charter.html
208
209   ]]
210
211   Almost all HTTP authentication that involves a human using a web
212   browser is accomplished through HTML forms, with session identifiers
213   stored in cookies.  For cookies, most implementations rely on the
214   "Netscape specification", which is described loosely in section 10 of
215   "HTTP State Management Mechanism" [RFC2109].  The protocol in RFC
216   2109 is relatively widely implemented, but most clients don't
217   advertise support for it.  RFC 2109 was later updated [RFC2965], but
218   the newer version is not widely implemented.
219
220
221
222
223Hodges & Leiba          Expires September 2, 2009               [Page 4]
224
225Internet-Draft       Security Requirements for HTTP           March 2009
226
227
228   Forms and cookies have many properties that make them an excellent
229   solution for some implementers.  However, many of those properties
230   introduce serious security trade-offs.
231
232   HTML forms provide a large degree of control over presentation, which
233   is an imperative for many websites.  However, this increases user
234   reliance on the appearance of the interface.  Many users do not
235   understand the construction of URIs [RFC3986], or their presentation
236   in common clients [PhishingHOWTO].  As a result, forms are extremely
237   vulnerable to spoofing.
238
239   HTML forms provide acceptable internationalization if used carefully,
240   at the cost of being transmitted as normal HTTP content in all cases
241   (credentials are not differentiated in the protocol).
242
243   Many Web browsers have an auto-complete feature that stores a user's
244   information and pre-populates fields in forms.  This is considered to
245   be a convenience mechanism, and convenience mechanisms often have
246   negative security properties.  The security concerns with auto-
247   completion are particularly poignant for web browsers that reside on
248   computers with multiple users.  HTML forms provide a facility for
249   sites to indicate that a field, such as a password, should never be
250   pre-populated.  However, it is clear that some form creators do not
251   use this facility when they should.
252
253   The cookies that result from a successful form submission make it
254   unnecessary to validate credentials with each HTTP request; this
255   makes cookies an excellent property for scalability.  Cookies are
256   susceptible to a large variety of XSS (cross-site scripting) attacks,
257   and measures to prevent such attacks will never be as stringent as
258   necessary for authentication credentials because cookies are used for
259   many purposes.  Cookies are also susceptible to a wide variety of
260   attacks from malicious intermediaries and observers.  The possible
261   attacks depend on the contents of the cookie data.  There is no
262   standard format for most of the data.
263
264   HTML forms and cookies provide flexible ways of ending a session from
265   the client.
266
267   HTML forms require an HTML rendering engine for which many protocols
268   have no use.
269
2702.2.  HTTP Access Authentication
271
272   HTTP 1.1 provides a simple authentication framework, "HTTP
273   Authentication: Basic and Digest Access Authentication" [RFC2617],
274   which defines two optional mechanisms.  Both of these mechanisms are
275   extremely rarely used in comparison to forms and cookies, but some
276
277
278
279Hodges & Leiba          Expires September 2, 2009               [Page 5]
280
281Internet-Draft       Security Requirements for HTTP           March 2009
282
283
284   degree of support for one or both is available in many
285   implementations.  Neither scheme provides presentation control,
286   logout capabilities, or interoperable internationalization.
287
2882.2.1.  Basic Authentication
289
290   Basic Authentication (normally called just "Basic") transmits
291   usernames and passwords in the clear.  It is very easy to implement,
292   but not at all secure unless used over a secure transport.
293
294   Basic has very poor scalability properties because credentials must
295   be revalidated with every request, and because secure transports
296   negate many of HTTP's caching mechanisms.  Some implementations use
297   cookies in combination with Basic credentials, but there is no
298   standard method of doing so.
299
300   Since Basic credentials are clear text, they are reusable by any
301   party.  This makes them compatible with any authentication database,
302   at the cost of making the user vulnerable to mismanaged or malicious
303   servers, even over a secure channel.
304
305   Basic is not interoperable when used with credentials that contain
306   characters outside of the ISO 8859-1 repertoire.
307
3082.2.2.  Digest Authentication
309
310   In Digest Authentication, the client transmits the results of hashing
311   user credentials with properties of the request and values from the
312   server challenge.  Digest is susceptible to man-in-the-middle attacks
313   when not used over a secure transport.
314
315   Digest has some properties that are preferable to Basic and Cookies.
316   Credentials are not immediately reusable by parties that observe or
317   receive them, and session data can be transmitted alongside
318   credentials with each request, allowing servers to validate
319   credentials only when absolutely necessary.  Authentication data
320   session keys are distinct from other protocol traffic.
321
322   Digest includes many modes of operation, but only the simplest modes
323   enjoy any degree of interoperability.  For example, most
324   implementations do not implement the mode that provides full message
325   integrity.  Perhaps one reason is that implementation experience has
326   shown that in some cases, especially those involving large requests
327   or responses such as streams, the message integrity mode is
328   impractical because it requires servers to analyze the full request
329   before determining whether the client knows the shared secret or
330   whether message-body integrity has been violated and hence whether
331   the request can be processed.
332
333
334
335Hodges & Leiba          Expires September 2, 2009               [Page 6]
336
337Internet-Draft       Security Requirements for HTTP           March 2009
338
339
340   Digest is extremely susceptible to offline dictionary attacks, making
341   it practical for attackers to perform a namespace walk consisting of
342   a few million passwords for most users.
343
344   Many of the most widely-deployed HTTP/1.1 clients are not compliant
345   when GET requests include a query string [Apache_Digest].
346
347   Digest either requires that authentication databases be expressly
348   designed to accommodate it, or requires access to cleartext
349   passwords.  As a result, many authentication databases that chose to
350   do the former are incompatible, including the most common method of
351   storing passwords for use with Forms and Cookies.
352
353   Many Digest capabilities included to prevent replay attacks expose
354   the server to Denial of Service attacks.
355
356   Digest is not interoperable when used with credentials that contain
357   characters outside of the ISO 8859-1 repertoire.
358
3592.2.3.  Authentication Using Certificates in TLS
360
361   Running HTTP over TLS provides authentication of the HTTP server to
362   the client.  HTTP over TLS can also provides authentication of the
363   client to the server using certificates.  Although forms are a much
364   more common way to authenticate users to HTTP servers, TLS client
365   certificates are widely used in some environments.  The public key
366   infrastructure (PKI) used to validate certificates in TLS can be
367   rooted in public trust anchors or can be based on local trust
368   anchors.
369
3702.2.4.  Other Access Authentication Schemes
371
372   There are many niche schemes that make use of the HTTP Authentication
373   framework, but very few are well documented.  Some are bound to
374   transport layer connections.
375
3762.2.4.1.  Negotiate (GSS-API) Authentication
377
378   Microsoft has designed an HTTP authentication mechanism that utilizes
379   SPNEGO [RFC4178] GSSAPI [RFC4559].  In Microsoft's implementation,
380   SPNEGO allows selection between Kerberos and NTLM (Microsoft NT Lan
381   Manager protocols).
382
383   In Kerberos, clients and servers rely on a trusted third-party
384   authentication service which maintains its own authentication
385   database.  Kerberos is typically used with shared secret key
386   cryptography, but extensions for use of other authentication
387   mechnanisms such as PKIX certificates and two-factor tokens are also
388
389
390
391Hodges & Leiba          Expires September 2, 2009               [Page 7]
392
393Internet-Draft       Security Requirements for HTTP           March 2009
394
395
396   common.  Kerberos was designed to work under the assumption that
397   packets traveling along the network can be read, modified, and
398   inserted at will.
399
400   Unlike Digest, Negotiate authentication can take multiple round trips
401   (client sending authentication data in Authorization, server sending
402   authentication data in WWW-Authenticate) to complete.
403
404   Kerberos authentication is generally more secure than Digest.
405   However the requirement for having a separate network authentication
406   service might be a barrier to deployment.
407
4082.2.4.2.  OAuth
409
410   [[ See..
411
412      http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt
413
414      http://www.ietf.org/id/draft-hammer-oauth-10.txt
415
416   ]]
417
4182.3.  Centrally-Issued Tickets
419
420   Many large Internet services rely on authentication schemes that
421   center on clients consulting a single service for a time-limited
422   ticket that is validated with undocumented heuristics.  Centralized
423   ticket issuing has the advantage that users may employ one set of
424   credentials for many services, and clients don't send credentials to
425   many servers.  This approach is often no more than a sophisticated
426   application of forms and cookies.
427
428   All of the schemes in wide use are proprietary and non-standard, and
429   usually are undocumented.  There are many standardization efforts in
430   progress, as usual.
431
4322.4.  Web Services
433
434   Many security properties mentioned in this document have been recast
435   in XML-based protocols, using HTTP as a substitute for TCP.  Like the
436   amalgam of HTTP technologies mentioned above, the XML-based protocols
437   are defined by an ever-changing combination of standard and vendor-
438   produced specifications, some of which may be obsoleted at any time
439   [WS-Pagecount] without any documented change control procedures.
440   These protocols usually don't have much in common with the
441   Architecture of the World Wide Web. It's not clear why the term "Web"
442   is used to group them, but they are obviously out of scope for HTTP-
443   based application protocols.
444
445
446
447Hodges & Leiba          Expires September 2, 2009               [Page 8]
448
449Internet-Draft       Security Requirements for HTTP           March 2009
450
451
452   [[ This section could really use a good definition of "Web Services"
453   to differentiate it from REST.  See..
454
455      http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/
456      0536.html
457
458   ]]
459
4602.5.  Transport Layer Security
461
462   In addition to using TLS for client and/or server authentication, it
463   is also very commonly used to protect the confidentiality and
464   integrity of the HTTP session.  For instance, both HTTP Basic
465   authentication and Cookies are often protected against snooping by
466   TLS.
467
468   It should be noted that, in that case, TLS does not protect against a
469   breach of the credential store at the server or against a keylogger
470   or phishing interface at the client.  TLS does not change the fact
471   that Basic Authentication passwords are reusable and does not address
472   that weakness.
473
474
4753.  Revisions To HTTP
476
477   Is is possible that HTTP will be revised in the future.  "HTTP/1.1"
478   [RFC2616] and "Use and Interpretation of HTTP Version Numbers"
479   [RFC2145] define conformance requirements in relation to version
480   numbers.  In HTTP 1.1, all authentication mechanisms are optional,
481   and no single transport substrate is specified.  Any HTTP revision
482   that adds a mandatory security mechanism or transport substrate will
483   have to increment the HTTP version number appropriately.  All widely
484   used schemes are non-standard and/or proprietary.
485
486
4874.  IANA Considerations
488
489   This document has no actions for IANA.
490
491
4925.  Security Considerations
493
494   This entire document is about security considerations.
495
496
4976.  References
498
499
500
501
502
503Hodges & Leiba          Expires September 2, 2009               [Page 9]
504
505Internet-Draft       Security Requirements for HTTP           March 2009
506
507
5086.1.  Normative References
509
510   [Apache_Digest]
511              Apache Software Foundation, "Apache HTTP Server -
512              mod_auth_digest", <http://httpd.apache.org/docs/1.3/mod/
513              mod_auth_digest.html>.
514
515   [PhishingHOWTO]
516              Gutmann, P., "Phishing Tips and Techniques",
517              February 2008,
518              <http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf>.
519
520   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
521              3", BCP 9, RFC 2026, October 1996.
522
523   [RFC2145]  Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
524              and Interpretation of HTTP Version Numbers", RFC 2145,
525              May 1997.
526
527   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
528              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
529              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
530
531   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
532              Leach, P., Luotonen, A., and L. Stewart, "HTTP
533              Authentication: Basic and Digest Access Authentication",
534              RFC 2617, June 1999.
535
536   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
537              Mechanism", RFC 2965, October 2000.
538
539   [RFC3365]  Schiller, J., "Strong Security Requirements for Internet
540              Engineering Task Force Standard Protocols", BCP 61,
541              RFC 3365, August 2002.
542
543   [RFC3631]  Bellovin, S., Schiller, J., and C. Kaufman, "Security
544              Mechanisms for the Internet", RFC 3631, December 2003.
545
546   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
547              Resource Identifier (URI): Generic Syntax", STD 66,
548              RFC 3986, January 2005.
549
550   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
551              Simple and Protected Generic Security Service Application
552              Program Interface (GSS-API) Negotiation Mechanism",
553              RFC 4178, October 2005.
554
555   [RFC4559]  Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
556
557
558
559Hodges & Leiba          Expires September 2, 2009              [Page 10]
560
561Internet-Draft       Security Requirements for HTTP           March 2009
562
563
564              Kerberos and NTLM HTTP Authentication in Microsoft
565              Windows", RFC 4559, June 2006.
566
567   [WS-Pagecount]
568              Bray, T., "WS-Pagecount", September 2004, <http://
569              www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research>.
570
5716.2.  Informative References
572
573   [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
574              Mechanism", RFC 2109, February 1997.
575
576
577Appendix A.  Acknowledgements
578
579   Much of the material in this document was written by Rob Sayre, who
580   first promoted the topic.  Many others on the HTTPbis Working Group
581   have contributed to this document in the discussion.
582
583
584Appendix B.  Document History
585
586   [This entire section is to be removed when published as an RFC.]
587
588B.1.  Changes between draft-sayre-http-security-variance-00 and
589      draft-ietf-httpbis-security-properties-00
590
591   Changed the authors to Paul Hoffman and Alexey Melnikov, with
592   permission of Rob Sayre.
593
594   Made lots of minor editorial changes.
595
596   Removed what was section 2 (Requirements Notation), the reference to
597   RFC 2119, and any use of 2119ish all-caps words.
598
599   In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1
600   repertoire" to match the definition of "TEXT" in RFC 2616.
601
602   Added minor text to the Security Considerations section.
603
604   Added URLs to the two non-RFC references.
605
606B.2.  Changes between -00 and -01
607
608   Fixed some editorial nits reported by Iain Calder.
609
610   Added the suggestions about splitting for browsers and automation,
611   and about adding NTLM, to be beginning of 2.
612
613
614
615Hodges & Leiba          Expires September 2, 2009              [Page 11]
616
617Internet-Draft       Security Requirements for HTTP           March 2009
618
619
620   In 2.1, added "that involves a human using a web browser" in the
621   first sentence.
622
623   In 2.1, changed "session key" to "session identifier".
624
625   In 2.2.2, changed
626
627
628   Digest includes many modes of operation, but only the simplest modes
629   enjoy any degree of interoperability.  For example, most
630   implementations do not implement the mode that provides full message
631   integrity.  Additionally, implementation experience has shown that
632   the message integrity mode is impractical because it requires servers
633   to analyze the full request before determining whether the client
634   knows the shared secret.
635
636   to
637
638
639   Digest includes many modes of operation, but only the simplest
640   modes enjoy any degree of interoperability.  For example, most
641   implementations do not implement the mode that provides full message
642   integrity.  Perhaps one reason is that implementation experience has
643   shown that in some cases, especially those involving large requests
644   or responses such as streams, the message integrity mode is
645   impractical because it requires servers to analyze the full request
646   before determining whether the client knows the shared secret or
647   whether message-body integrity has been violated and hence whether
648   the request can be processed.
649
650   In 2.4, asked for a definition of "Web Services".
651
652   In A, added the WG.
653
654B.3.  Changes between -01 and -02
655
656   In section 2.1, added more to the paragraph on auto-completion of
657   HTML forms.
658
659   Added the section on TLS for authentication.
660
661   Filled in section 2.5.
662
663B.4.  Changes between -02 and -03
664
665   Changed IPR licensing from "full3978" to "pre5378Trust200902".
666
667
668
669
670
671Hodges & Leiba          Expires September 2, 2009              [Page 12]
672
673Internet-Draft       Security Requirements for HTTP           March 2009
674
675
676B.5.  Changes between -03 and -04
677
678   Changed authors to be Jeff Hodges (JH) and Barry Leiba (BL) with
679   permission of Paul Hoffman, Alexey Melnikov, and Mark Nottingham
680   (httpbis chair).
681
682   Added "OVERALL ISSUE" to introduction.
683
684   Added links to email messages on mailing list(s) where various
685   suggestions for this document were brought up.  I.e. added various
686   links to those comments herein delimited by "[[...]]" braces.
687
688   Noted JH's belief that "HTTP+HTML Form based authentication" aka
689   "Forms And Cookies" doesn't properly belong in the section where it
690   presently resides.  Added link to httpstate WG.
691
692   Added references to OAuth.  Section needs to be filled-in as yet.
693
694   Moved ref to RFC2109 to new "Informative References" section, and
695   added a placeholder "IANA Considerations" section in order to satisfy
696   IDnits checking.
697
698
699Authors' Addresses
700
701   Jeff Hodges
702   PayPal
703
704   Email: Jeff.Hodges@PayPal.com
705
706
707   Barry Leiba
708   Huawei Technologies
709
710   Phone: +1 646 827 0648
711   Email: barryleiba@computer.org
712   URI:   http://internetmessagingtechnology.org/
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727Hodges & Leiba          Expires September 2, 2009              [Page 13]
728
Note: See TracBrowser for help on using the repository browser.