source: draft-ietf-httpbis-security-properties/05/draft-ietf-httpbis-security-properties-05.xml @ 790

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

snapshot draft-ietf-httpbis-security-properties-05

  • Property svn:eol-style set to native
  • Property svn:executable set to *
File size: 33.6 KB
Line 
1<?xml version="1.0" encoding="UTF-8"?>
2<!DOCTYPE rfc [
3<!ENTITY rfc2026 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2026.xml">
4<!ENTITY rfc2109 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2109.xml">
5<!ENTITY rfc2145 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2145.xml">
6<!ENTITY rfc2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
7<!ENTITY rfc2617 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml">
8<!ENTITY rfc2965 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2965.xml">
9<!ENTITY rfc3365 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3365.xml">
10<!ENTITY rfc3631 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3631.xml">
11<!ENTITY rfc3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
12<!ENTITY rfc4178 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4178.xml">
13<!ENTITY rfc4559 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4559.xml">
14]>
15
16<rfc category="info" ipr="pre5378Trust200902"
17  docName="draft-ietf-httpbis-security-properties-05">
18
19    <?xml-stylesheet type="text/xsl" href="rfc2629xslt/rfc2629.xslt" ?>
20
21    <?rfc toc="yes" ?>
22    <?rfc symrefs="yes" ?>
23    <?rfc sortrefs="yes"?>
24    <?rfc strict="yes" ?>
25    <?rfc compact="yes" ?>
26    <?rfc subcompact="no" ?>
27    <?rfc linkmailto="no"?>
28    <?rfc comments="yes"?>
29    <?rfc inline="yes"?>
30
31    <front>
32        <title>Security Requirements for HTTP</title>
33        <author initials="J." surname="Hodges" fullname="Jeff Hodges">
34            <organization>PayPal</organization>
35            <address>
36                <email>Jeff.Hodges@PayPal.com</email> 
37            </address>
38        </author>
39        <author initials='B.' surname="Leiba" fullname='Barry Leiba'>
40            <organization>Huawei Technologies</organization>
41            <address>
42                <phone>+1 646 827 0648</phone>
43                <email>barryleiba@computer.org</email>
44                <uri>http://internetmessagingtechnology.org/</uri>
45            </address>
46        </author>
47        <date year="2010" month="March" day="11"/>
48        <abstract>
49            <t>
50                Recent IESG practice dictates that IETF protocols must
51                specify mandatory-to-implement (MTI) security mechanisms, so
52                that all conformant implementations share a common
53                baseline. This document examines all widely deployed
54                HTTP security technologies, and analyzes the
55                trade-offs of each.
56            </t>
57        </abstract>
58    </front>
59
60    <middle>
61 
62        <section title="Introduction">
63
64            <t>
65                Recent IESG practice dictates that IETF protocols be
66                required to specify mandatory-to-implement (MTI) security
67                mechanisms. "The IETF Standards Process" <xref
68                target="RFC2026"/> does not require that protocols
69                specify mandatory security mechanisms. "Strong
70                Security Requirements for IETF Standard Protocols"
71                <xref target="RFC3365"/> requires that all IETF
72                protocols provide a mechanism for implementers to
73                provide strong security. RFC 3365 does not define the
74                term "strong security".
75            </t>
76
77            <t>
78                "Security Mechanisms for the Internet" <xref
79                target="RFC3631"/> is not an IETF procedural RFC, but
80                it is perhaps most relevant. Section 2.2 states:
81            </t>
82
83            <figure>
84                <artwork>
85  We have evolved in the IETF the notion of "mandatory to implement"
86  mechanisms.  This philosophy evolves from our primary desire to
87  ensure interoperability between different implementations of a
88  protocol.  If a protocol offers many options for how to perform a
89  particular task, but fails to provide for at least one that all
90  must implement, it may be possible that multiple, non-interoperable
91  implementations may result.  This is the consequence of the
92  selection of non-overlapping mechanisms being deployed in the
93  different implementations.
94                </artwork>
95            </figure>
96
97            <t>
98                This document examines the effects of applying
99                security constraints to Web applications, documents
100                the properties that result from each method, and will
101                make Best Current Practice recommendations for HTTP
102                security in a later document version. At the moment,
103                it is mostly a laundry list of security technologies
104                and tradeoffs.
105            </t>
106
107            <t>
108                [[ OVERALL ISSUE:  It isn't entirely clear to the present editors
109                what the purpose of this document is. On one hand it
110                could be a compendium of peer-entity authentication
111                mechanisms (as it is presently) and make MTI recommendations
112                thereof, or it could be a place for various security
113                considerations (either coalesced here from the other
114                httpbis specs, or reserved for the more gnarly cross-spec
115                composite ones), or both. This needs to be clarified.
116                ]]
117            </t>
118
119        </section>
120
121        <section title="Existing HTTP Security Mechanisms">
122
123            <t>
124                For HTTP, the IETF generally defines "security
125                mechanisms" as some combination of access
126                authentication and/or a secure transport.
127            </t>
128
129            <t>
130                [[ There is a suggestion that this section be split
131                into "browser-like" and "automation-like"
132                subsections. See:
133                <list>
134                    <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0180.html</t>
135                    <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0183.html</t>
136                </list>
137                ]]
138            </t>
139
140            <t>
141                [[ NTLM (shudder)
142                was brought up in the WG a few times
143                in the discussion of the -00 draft. Should we add a
144                section on it? See..
145                <list>
146                    <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0132.html</t>
147                    <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0135.html</t>
148                </list>
149                ]]
150            </t>
151
152            <section title="Forms And Cookies">
153
154                <t>
155                    [[ JH: I am not convinced that this subsection
156                    properly belongs in this overall section in that
157                    "HTTP+HTML Form based authentication"
158                    &lt;http://en.wikipedia.org/wiki/HTTP%2BHTML_Form_based_authentication&gt;
159                    is not properly a part of HTTP itself. Rather, it is
160                    a piece of applications layered on top of HTTP. Use of cookies for
161                    state management (e.g. session maintanence) can be
162                    considered such, however (although there is no
163                    overall specification for HTTP user agents stipulating
164                    that they must implement cookies (nominally
165                    <xref target="RFC2109"/>)). Perhaps this section should be
166                    should be retitled "HTTP Authentication".
167                    </t>
168                <t>
169                    Note: The httpstate WG was recently chartered to develop a successor to
170                    <xref target="RFC2109"/>. See..
171                    <list>
172                        <t>http://www.ietf.org/dyn/wg/charter/httpstate-charter.html</t>
173                    </list>
174                </t>
175                <t>
176                    ]]
177                </t>
178
179                <t>
180                    Almost all HTTP authentication that involves a
181                    human using a web browser is accomplished through
182                    HTML forms, with session identifiers stored in
183                    cookies. For cookies, most implementations rely on
184                    the "Netscape specification", which is described
185                    loosely in section 10 of "HTTP State Management
186                    Mechanism" <xref target="RFC2109"/>. The protocol
187                    in RFC 2109 is relatively widely implemented, but
188                    most clients don't advertise support for it. RFC
189                    2109 was later updated <xref target="RFC2965"/>,
190                    but the newer version is not widely implemented.
191                </t>
192
193                <t>
194                    Forms and cookies have many properties that make
195                    them an excellent solution for some
196                    implementers. However, many of those properties
197                    introduce serious security trade-offs.
198                </t>
199
200                <t>
201                    HTML forms provide a large degree of control over
202                    presentation, which is an imperative for many
203                    websites. However, this increases user reliance on
204                    the appearance of the interface. Many users do not
205                    understand the construction of URIs <xref
206                    target="RFC3986"/>, or their presentation in
207                    common clients <xref target="PhishingHOWTO"/>.  As
208                    a result, forms are extremely vulnerable to
209                    spoofing.
210                </t>
211
212                <t>
213                    HTML forms provide acceptable internationalization
214                    if used carefully, at the cost of being
215                    transmitted as normal HTTP content in all cases
216                    (credentials are not differentiated in the
217                    protocol).
218                </t>
219
220                <t>
221                    Many Web browsers have an auto-complete feature
222                    that stores a user's information and pre-populates
223                    fields in forms. This is considered to be a
224                    convenience mechanism, and convenience mechanisms
225                    often have negative security properties. The
226                    security concerns with auto-completion are
227                    particularly poignant for web browsers that reside
228                    on computers with multiple users. HTML forms
229                    provide a facility for sites to indicate that a
230                    field, such as a password, should never be
231                    pre-populated. However, it is clear that some form
232                    creators do not use this facility when they
233                    should.
234                </t>
235
236                <t>
237                    The cookies that result from a successful form
238                    submission make it unnecessary to validate
239                    credentials with each HTTP request; this makes
240                    cookies an excellent property for
241                    scalability. Cookies are susceptible to a large
242                    variety of XSS (cross-site scripting) attacks, and
243                    measures to prevent such attacks will never be as
244                    stringent as necessary for authentication
245                    credentials because cookies are used for many
246                    purposes.  Cookies are also susceptible to a wide
247                    variety of attacks from malicious intermediaries
248                    and observers. The possible attacks depend on the
249                    contents of the cookie data. There is no standard
250                    format for most of the data.
251                </t>
252
253                <t>
254                    HTML forms and cookies provide flexible ways of
255                    ending a session from the client.
256                </t>
257
258                <t>
259                    HTML forms require an HTML rendering engine for
260                    which many protocols have no use.
261                </t>
262
263            </section>
264
265            <section title="HTTP Access Authentication">
266
267                <t>
268                    HTTP 1.1 provides a simple authentication
269                    framework, "HTTP Authentication: Basic and Digest
270                    Access Authentication" <xref target="RFC2617"/>,
271                    which defines two optional mechanisms. Both of
272                    these mechanisms are extremely rarely used in
273                    comparison to forms and cookies, but some degree
274                    of support for one or both is available in many
275                    implementations. Neither scheme provides
276                    presentation control, logout capabilities, or
277                    interoperable internationalization.
278                </t>
279
280                <section title="Basic Authentication">
281
282                    <t>
283                        Basic Authentication (normally called just
284                        "Basic") transmits usernames and passwords in
285                        the clear. It is very easy to implement, but
286                        not at all secure unless used over a secure
287                        transport.
288                    </t>
289
290                    <t>
291                        Basic has very poor scalability properties
292                        because credentials must be revalidated with
293                        every request, and because secure transports
294                        negate many of HTTP's caching mechanisms. Some
295                        implementations use cookies in combination
296                        with Basic credentials, but there is no
297                        standard method of doing so.
298                    </t>
299
300                    <t>
301                        Since Basic credentials are clear text, they
302                        are reusable by any party. This makes them
303                        compatible with any authentication database,
304                        at the cost of making the user vulnerable to
305                        mismanaged or malicious servers, even over a
306                        secure channel.
307                    </t>
308
309                    <t>
310                        Basic is not interoperable when used with
311                        credentials that contain characters outside of
312                        the ISO 8859-1 repertoire.
313                    </t>
314
315                </section>
316
317                <section title="Digest Authentication">
318                   
319                    <t>
320                        In Digest Authentication, the client transmits
321                        the results of hashing user credentials with
322                        properties of the request and values from the
323                        server challenge. Digest is susceptible to
324                        man-in-the-middle attacks when not used over a
325                        secure transport.
326                    </t>
327
328                    <t>
329                        Digest has some properties that are preferable
330                        to Basic and Cookies. Credentials are not
331                        immediately reusable by parties that observe
332                        or receive them, and session data can be
333                        transmitted alongside credentials with each
334                        request, allowing servers to validate
335                        credentials only when absolutely
336                        necessary. Authentication data session keys
337                        are distinct from other protocol traffic.
338                    </t>
339
340                    <t>
341                        Digest includes many modes of operation, but
342                        only the simplest modes enjoy any degree of
343                        interoperability.  For example, most
344                        implementations do not implement the mode that
345                        provides full message integrity.  Perhaps one
346                        reason is that implementation experience has
347                        shown that in some cases, especially those
348                        involving large requests or responses such as
349                        streams, the message integrity mode is
350                        impractical because it requires servers to
351                        analyze the full request before determining
352                        whether the client knows the shared secret or
353                        whether message-body integrity has been
354                        violated and hence whether the request can be
355                        processed.
356                    </t>
357
358                    <t>
359                        Digest is extremely susceptible to offline
360                        dictionary attacks, making it practical for
361                        attackers to perform a namespace walk
362                        consisting of a few million passwords for most
363                        users.
364                    </t>
365
366                    <t>
367                        Many of the most widely-deployed HTTP/1.1
368                        clients are not compliant when GET requests
369                        include a query string <xref
370                        target="Apache_Digest"/>.
371                    </t>
372
373                    <t>
374                        Digest either requires that authentication
375                        databases be expressly designed to accommodate
376                        it, or requires access to cleartext passwords.
377                        As a result, many authentication databases
378                        that chose to do the former are incompatible,
379                        including the most common method of storing
380                        passwords for use with Forms and Cookies.
381                    </t>
382
383                    <t>
384                        Many Digest capabilities included to prevent
385                        replay attacks expose the server to Denial of
386                        Service attacks.
387                    </t>
388
389                    <t>
390                        Digest is not interoperable when used with
391                        credentials that contain characters outside of
392                        the ISO 8859-1 repertoire.
393                    </t>
394
395                </section>
396
397                <section title="Authentication Using Certificates in TLS">
398
399                    <t>
400                        Running HTTP over TLS provides authentication
401                        of the HTTP server to the client. HTTP over
402                        TLS can also provides authentication of the
403                        client to the server using
404                        certificates. Although forms are a much more
405                        common way to authenticate users to HTTP
406                        servers, TLS client certificates are widely
407                        used in some environments.  The public key
408                        infrastructure (PKI) used to validate
409                        certificates in TLS can be rooted in public
410                        trust anchors or can be based on local trust
411                        anchors.
412                    </t>
413
414                </section>
415
416                <section title="Other Access Authentication Schemes">
417
418                    <t>
419                        There are many niche schemes that make use of
420                        the HTTP Authentication framework, but very
421                        few are well documented. Some are bound to
422                        transport layer connections.
423                    </t>
424
425                    <section title="Negotiate (GSS-API) Authentication">
426
427                        <t>
428                            Microsoft has designed an HTTP
429                            authentication mechanism that utilizes
430                            SPNEGO <xref target="RFC4178"/> GSSAPI
431                            <xref target="RFC4559"/>. In Microsoft's
432                            implementation, SPNEGO allows selection
433                            between Kerberos and NTLM (Microsoft NT
434                            Lan Manager protocols).
435                        </t>
436
437                        <t>
438                            In Kerberos, clients and servers rely on a
439                            trusted third-party authentication service
440                            which maintains its own authentication
441                            database. Kerberos is typically used with
442                            shared secret key cryptography, but
443                            extensions for use of other authentication
444                            mechnanisms such as PKIX certificates and
445                            two-factor tokens are also common.
446                            Kerberos was designed to work under the
447                            assumption that packets traveling along
448                            the network can be read, modified, and
449                            inserted at will.
450                        </t>
451
452                        <t>
453                            Unlike Digest, Negotiate authentication
454                            can take multiple round trips (client
455                            sending authentication data in
456                            Authorization, server sending
457                            authentication data in WWW-Authenticate)
458                            to complete.
459                        </t>
460
461                        <t>
462                            Kerberos authentication is generally more
463                            secure than Digest. However the
464                            requirement for having a separate network
465                            authentication service might be a barrier
466                            to deployment.
467                        </t>
468
469                        <!--
470                        Kerberos didn't support Unicode till relatively recently. I am not sure if this
471                        is an issue with Microsoft's implementation.
472                        -->
473
474                    </section>
475
476                    <section title="OAuth">
477
478                        <t>
479                            [[ See..
480                            <list>
481                                <t>http://www.ietf.org/id/draft-hammer-http-token-auth-01.txt</t>
482                                <t>http://www.ietf.org/id/draft-hammer-oauth-10.txt</t>
483                            </list>
484                            ]]
485                        </t>
486
487                    </section>
488
489                </section>
490
491            </section>
492
493            <section title="Centrally-Issued Tickets">
494
495                <t>
496                    Many large Internet services rely on
497                    authentication schemes that center on clients
498                    consulting a single service for a time-limited
499                    ticket that is validated with undocumented
500                    heuristics. Centralized ticket issuing has the
501                    advantage that users may employ one set of
502                    credentials for many services, and clients don't
503                    send credentials to many servers. This approach is
504                    often no more than a sophisticated application of
505                    forms and cookies.
506                </t>
507
508                <t>
509                    All of the schemes in wide use are proprietary and
510                    non-standard, and usually are undocumented. There
511                    are many standardization efforts in progress, as
512                    usual.
513                </t>
514
515            </section>
516
517            <section title="Web Services">
518
519                <t>
520                    Many security properties mentioned in this
521                    document have been recast in XML-based protocols,
522                    using HTTP as a substitute for TCP. Like the
523                    amalgam of HTTP technologies mentioned above, the
524                    XML-based protocols are defined by an
525                    ever-changing combination of standard and
526                    vendor-produced specifications, some of which may
527                    be obsoleted at any time <xref
528                    target="WS-Pagecount"/> without any documented
529                    change control procedures. These protocols usually
530                    don't have much in common with the Architecture of
531                    the World Wide Web. It's not clear why the term
532                    "Web" is used to group them, but they are
533                    obviously out of scope for HTTP-based application
534                    protocols.
535                </t>
536
537                <t>
538                    [[ This section could really use a good definition
539                    of "Web Services" to differentiate it from
540                    REST. See..
541                    <list>
542                        <t>http://lists.w3.org/Archives/Public/ietf-http-wg/2008JanMar/0536.html</t>
543                    </list>
544                    ]]
545                </t>
546
547            </section>
548
549            <section title="Transport Layer Security">
550
551                <t>
552                    In addition to using TLS for client and/or server
553                    authentication, it is also very commonly used to
554                    protect the confidentiality and integrity of the
555                    HTTP session. For instance, both HTTP Basic
556                    authentication and Cookies are often protected
557                    against snooping by TLS.
558                </t>
559
560                <t>
561                    It should be noted that, in that case, TLS does
562                    not protect against a breach of the credential
563                    store at the server or against a keylogger or
564                    phishing interface at the client. TLS does not
565                    change the fact that Basic Authentication
566                    passwords are reusable and does not address that
567                    weakness.
568                </t>
569
570            </section>
571
572        </section>
573
574        <section title="Revisions To HTTP">
575
576            <t>
577                Is is possible that HTTP will be revised in the
578                future. "HTTP/1.1" <xref target="RFC2616"/> and "Use
579                and Interpretation of HTTP Version Numbers" <xref
580                target="RFC2145"/> define conformance requirements in
581                relation to version numbers. In HTTP 1.1, all
582                authentication mechanisms are optional, and no single
583                transport substrate is specified. Any HTTP revision
584                that adds a mandatory security mechanism or transport
585                substrate will have to increment the HTTP version
586                number appropriately. All widely used schemes are
587                non-standard and/or proprietary.
588            </t>
589
590        </section>
591
592        <section title="IANA Considerations">
593            <t>This document has no actions for IANA.</t>
594        </section>
595
596        <section title="Security Considerations">
597
598            <t>This entire document is about security considerations.</t>
599
600        </section>
601
602
603
604    </middle>
605
606    <back>
607
608        <references title="Normative References">
609
610&rfc2026;
611&rfc2145;
612&rfc2616;
613&rfc2617;
614&rfc2965;
615&rfc3365;
616&rfc3631;
617&rfc3986;
618&rfc4178;
619&rfc4559;
620
621<reference anchor="Apache_Digest"
622  target="http://httpd.apache.org/docs/1.3/mod/mod_auth_digest.html">
623<front>
624  <title>Apache HTTP Server - mod_auth_digest</title>
625  <author surname="Apache Software Foundation">
626  <organization />
627  </author>
628<date year="" month="" />
629</front>
630</reference>
631
632<reference anchor="PhishingHOWTO"
633  target="http://www.cs.auckland.ac.nz/~pgut001/pubs/phishing.pdf">
634<front>
635  <title>Phishing Tips and Techniques</title>
636  <author initials="P." surname="Gutmann" fullname="Peter Gutmann">
637  <organization /></author>
638  <date year="2008" month="February" />
639</front>
640</reference>
641
642<reference anchor="WS-Pagecount"
643  target="http://www.tbray.org/ongoing/When/200x/2004/09/21/WS-Research">
644<front>
645  <title>WS-Pagecount</title>
646  <author initials="T." surname="Bray" fullname="Tim Bray">
647  <organization />
648  </author>
649  <date year="2004" month="September" />
650</front>
651</reference>
652
653        </references>
654
655        <references title="Informative References">
656
657&rfc2109;
658
659
660        </references>
661
662        <section title="Acknowledgements">
663
664            <t>
665                Much of the material in this document was written by
666                Rob Sayre, who first promoted the topic. Many others
667                on the HTTPbis Working Group have contributed to this
668                document in the discussion.
669            </t>
670
671        </section>
672
673        <section title="Document History">
674
675            <t>[This entire section is to be removed when published as an RFC.]</t>
676
677            <section title="Changes between draft-sayre-http-security-variance-00 and
678                draft-ietf-httpbis-security-properties-00">
679
680                <t>Changed the authors to Paul Hoffman and Alexey Melnikov, with permission
681                    of Rob Sayre.</t>
682
683                <t>Made lots of minor editorial changes.</t>
684
685                <t>Removed what was section 2 (Requirements Notation), the reference
686                    to RFC 2119, and any use of 2119ish all-caps words.</t>
687
688                <t>In 3.2.1 and 3.2.2, changed "Latin-1 range" to "ISO 8859-1
689                    repertoire" to match the definition of "TEXT" in RFC 2616.</t>
690
691                <t>Added minor text to the Security Considerations section.</t>
692
693                <t>Added URLs to the two non-RFC references.</t>
694
695            </section>
696
697
698            <section title="Changes between -00 and -01">
699
700                <t>Fixed some editorial nits reported by Iain Calder.</t>
701
702                <t>Added the suggestions about splitting for browsers and
703                    automation, and about adding NTLM, to be beginning of 2.</t>
704
705                <t>In 2.1, added "that involves a human
706                    using a web browser" in the first sentence.</t>
707
708                <t>In 2.1, changed "session key" to "session identifier".</t>
709
710                <t>In 2.2.2, changed
711<figure><artwork><![CDATA[
712Digest includes many modes of operation, but only the simplest modes
713enjoy any degree of interoperability.  For example, most
714implementations do not implement the mode that provides full message
715integrity.  Additionally, implementation experience has shown that
716the message integrity mode is impractical because it requires servers
717to analyze the full request before determining whether the client
718knows the shared secret.
719]]></artwork></figure>
720                    to
721<figure><artwork><![CDATA[
722Digest includes many modes of operation, but only the simplest
723modes enjoy any degree of interoperability.  For example, most
724implementations do not implement the mode that provides full message
725integrity.  Perhaps one reason is that implementation experience has
726shown that in some cases, especially those involving large requests
727or responses such as streams, the message integrity mode is
728impractical because it requires servers to analyze the full request
729before determining whether the client knows the shared secret or
730whether message-body integrity has been violated and hence whether
731the request can be processed.
732]]></artwork></figure>
733</t>
734
735                <t>In 2.4, asked for a definition of "Web Services".</t>
736
737                <t>In A, added the WG.</t>
738
739            </section>
740
741
742            <section title="Changes between -01 and -02">
743
744                <t>In section 2.1, added more to the paragraph on auto-completion of
745                    HTML forms.</t>
746
747                <t>Added the section on TLS for authentication.</t>
748
749                <t>Filled in section 2.5.</t>
750
751            </section>
752
753
754            <section title="Changes between -02 and -03">
755
756                <t>
757                    Changed IPR licensing from "full3978" to "pre5378Trust200902".
758                </t>
759
760            </section>
761
762
763            <section title="Changes between -03 and -04">
764
765                <t>
766                    Changed authors to be
767                    Jeff Hodges (JH) and Barry Leiba (BL)
768                     with permission of Paul
769                    Hoffman, Alexey Melnikov, and Mark Nottingham
770                    (httpbis chair).
771                </t>
772
773                <t>
774                    Added "OVERALL ISSUE" to introduction.
775                </t>
776
777                <t>
778                    Added links to email messages on mailing list(s) where
779                    various suggestions for this document were brought up. I.e.
780                    added various links to those comments herein
781                    delimited by "[[...]]" braces.
782                </t>
783
784                <t>
785                    Noted JH's belief that "HTTP+HTML Form based authentication"
786                    aka "Forms And Cookies" doesn't properly belong in
787                    the section where it presently resides. Added link to httpstate WG.
788                </t>
789
790                <t>
791                    Added references to OAuth. Section needs to be filled-in as yet.
792                </t>
793
794                <t>
795                    Moved ref to RFC2109 to new "Informative References" section, and
796                    added a placeholder "IANA Considerations" section in order
797                    to satisfy IDnits checking.
798                </t>
799
800
801            </section>
802
803            <section title="Changes between -04 and -05">
804
805                <t>
806                    Fixed incorrect &lt;date&gt; year from 2009 to 2010. mea culpa.
807                </t>
808
809            </section>
810
811        </section>
812
813    </back>
814
815</rfc>
816
817
818<!-- PLEASE DO NOT DELETE!!! The below is used by XEmacs XML major-mode -->
819<!--
820Local Variables:
821mode: xml
822indent-tabs-mode:nil
823sgml-omittag:t
824sgml-shorttag:t
825sgml-namecase-general:t
826sgml-general-insert-case:lower
827sgml-minimize-attributes:nil
828sgml-always-quote-attributes:t
829sgml-indent-step:4
830sgml-indent-data:t
831sgml-parent-document:nil
832sgml-exposed-tags:nil
833sgml-local-catalogs:nil
834sgml-local-ecat-files:nil
835End:
836-->
837<!-- PLEASE DO NOT DELETE!!! The above is used by XEmacs XML major-mode -->
838
Note: See TracBrowser for help on using the repository browser.