Subject: Straw-man charter for http-bis

From: Mark Nottingham <[email-masked]>
Date: Wed, 30 May 2007 22:57:25 +1000

Revision based upon feedback and discussion;

---8<---
HyperText Transfer Protocol Revision (http-bis) Charter

Last Modified: 2007-05-30

Chair(s):
[TBD]

Applications Area Director(s):
Chris Newman <[email-masked]>
Lisa Dusseault <[email-masked]>

Applications Area Advisor:
[TBD]

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
In Subject: subscribe
Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/

Description of Working Group:
HTTP is one of the most successful and widely-used protocols on the  
Internet today. However, its specification has several editorial  
issues. Additionally, after years of implementation and extension,  
several ambiguities have arisen, impairing interoperability and the  
ability to easily implement and use HTTP to its full potential.

The working group will refine RFC2616 to:
   * Incorporate errata and updates
   * Improve editorial quality
   * Clarify conformance requirements
   * Remove known ambiguities where they affect interoperability
   * Clarify methods and requirements for extensibility
   * Remove or deprecate those features that are not widely  
implemented, unduly affect interoperability and are not well-supported
   * Where necessary, add implementation advice
   * Document the security properties of HTTP and its associated  
mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for  
common applications

In doing so, it should consider:
   * Implementer experience
   * Demonstrated use of HTTP
   * Impact on existing implementations and deployments

The Working Group must not introduce a new version of HTTP, and  
should not introduce new features or capabilities to HTTP.

The Working Group's specification deliverables are:
    * A document that is suitable to supersede RFC2616
    * A document cataloguing the security properties of HTTP

Additionally, the Working Group should review (and may document) test  
suites for HTTP conformance, as they are made available.

Goals and Milestones:
Sep 2007 - First HTTP Revision Internet Draft
Nov 2007 - First HTTP Security Properties Internet Draft
Dec 2007 - IETF 70 Meeting, Vancouver, BC, Canada
Mar 2008 - IETF 71 Meeting, Philadelphia, PA, USA
Apr 2008 - Request Last Call for HTTP Revision
May 2008 - Request Last Call for HTTP Security Properties
Jul 2008 - IETF 72 Meeting, TBD
Aug 2008 - Submit HTTP Revision to IESG for consideration as a  
Proposed Standard
Aug 2008 - Submit HTTP Security Properties to IESG for consideration  
as Best Current Practice
--->8---

On 06/03/2007, at 5:54 PM, Mark Nottingham wrote:

>
> Below, I've cut-and-pasted a straw-man charter along the lines that  
> have been previously discussed. It's on a fairly short time-scale,  
> to focus efforts on interop and editorial work, rather than  
> spinning off into large-scale revisions or adding new features.
>
> The tentative path forward is to discuss this informally in Prague,  
> have a formal BoF in Chicago, and start thereafter.
>
> Comments would be very much appreciated.
>
> Cheers,
>
> ---8<---
> HyperText Transfer Protocol Revision (http-bis) Charter
>
> Last Modified: 2007-01-14
>
> Chair(s):
> [TBD]
>
> Applications Area Director(s):
> [TBD]
> Lisa Dusseault <[email-masked]>
>
> Applications Area Advisor:
> [TBD]
>
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked]
> In Subject: subscribe
> Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/
>
> Description of Working Group:
> HTTP is one of the most successful and widely-used protocols on the  
> Internet today. However, its specification has several editorial  
> issues. Additionally, after years of implementation and extension,  
> several ambiguities have arisen, impairing interoperability and the  
> ability to easily implement and use HTTP to its full potential.
>
> The working group will refine RFC2616 to:
>   * Incorporate errata
>   * Improve editorial quality
>   * Clarify conformance requirements and targets
>   * Eliminate ambiguities where they affect interoperability
>   * Document the extensibility model of HTTP
>   * Add implementation advice (e.g., deprecating problematic  
> optional features, if necessary)
>   * Update to reflect current IETF practice
>   * Identify mandatory-to-implement security mechanisms
>
> In doing so, it should consider:
>   * Implementer experience
>   * Demonstrated use of HTTP
>   * Impact on existing implementations and deployments
>
> The working group must not introduce a new version of HTTP. It  
> should not introduce new features or capabilities to HTTP, except  
> where doing so is necessary to improve interoperability.
>
> The Working Group's sole specification deliverable is a document  
> that is suitable to supersede RFC2616.
>
> Additionally, the working group may produce one or more test suites  
> for HTTP conformance, if there is sufficient interest.
>
> Goals and Milestones:
> Sep 2007 - First HTTP Revision Internet Draft
> Dec 2007 - IETF 70 Meeting, TBD
> Mar 2008 - IETF 71 Meeting, TBD
> Apr 2008 - Request Last Call for HTTP Revision
> Jul 2008 - IETF 72 Meeting, TBD
> Aug 2008 - Submit HTTP Revision to IESG for consideration as a  
> Proposed Standard
> --->8---
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>

--
Mark Nottingham     http://www.mnot.net/

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 30 May 2007 14:06:54 +0100

Hi Mark,

> Aug 2008 - Submit HTTP Revision to IESG for consideration as a  

I think the target should be to move the document to Draft.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 May 2007 15:11:21 +0200

> I think the target should be to move the document to Draft.

Actually, it already *is* a Draft Standard, so I think the target should 
be to *keep* it a Draft Standard, with an eye on the possibility to 
actually get it to full Standard (which may require creative solutions 
to the MIME dependencies).

Best regards, Julian

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 30 May 2007 14:27:55 +0100

Julian Reschke wrote:

> Actually, it already *is* a Draft Standard,

Good point.

> so I think the target should be to *keep* it a Draft Standard, with an 
> eye on the possibility to actually get it to full Standard (which may 
> require creative solutions to the MIME dependencies).

Right. I meant "move to Full or at least recycle as Draft".

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 May 2007 07:51:10 -0700

Serious question, not a gratuitous opening of a big can-o-worms: 
would the WG also consider extensions to HTTP that would go into 
different documents? That is, is the WG only for the revision of the 
base spec, or also open to ( animated && lengthy && contentious ) 
discussion of other documents as well?

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 May 2007 16:59:14 +0200

Paul Hoffman wrote:
> Serious question, not a gratuitous opening of a big can-o-worms: would 
> the WG also consider extensions to HTTP that would go into different 
> documents? That is, is the WG only for the revision of the base spec, or 
> also open to ( animated && lengthy && contentious ) discussion of other 
> documents as well?

I guess the idea was that the more we restrict the scope of what we want 
to do, the easier it'll be to gather the right group of people to do it.

For instance, RFC2617 needs a revision badly as well (for instance, wrt 
to I18N of usernames and passwords, and, as far as I can recall, certain 
problems with the definition of Digest Auth). IMHO; this should occur in 
a separate working group.

Are there any specific extensions you have in mind?

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 May 2007 08:33:27 -0700

At 4:59 PM +0200 5/30/07, Julian Reschke wrote:
>I guess the idea was that the more we restrict the scope of what we 
>want to do, the easier it'll be to gather the right group of people 
>to do it.

Fully agree.

>For instance, RFC2617 needs a revision badly as well (for instance, 
>wrt to I18N of usernames and passwords, and, as far as I can recall, 
>certain problems with the definition of Digest Auth). IMHO; this 
>should occur in a separate working group.

The proposed charter has:
   * Document the security properties of HTTP and its associated
     mechanisms (e.g., Basic and Digest authentication, cookies, TLS)
     for common applications
So, would obviously-needed changes to the associated mechanisms be in 
scope for the WG, or not?

>Are there any specific extensions you have in mind?

Definitely not. I was asking whether or not we want to clamp down on 
charter creep now or later.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 May 2007 17:44:52 +0200

> scope for the WG, or not?

I would have hoped that we can concentrate on revising RFC2616, and do 
just that. However, we got signals from IESG members that a revision of 
RFC2616 would not be accepted unless it improves the security story. 
IMHO a very bad idea.

Fixing it needs, but that needs to be done somewhere else.

> charter creep now or later.

:-) I'd prefer the charter to be as small & precise as possible.

Best regards, Julian

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 May 2007 09:47:29 -0700

Splitting my previous question into two:

a) Will this WG consider clarifications and revisions to main-line 
HTTP-related RFCs, most notably the security ones?

b) Will this WG consider new extensions to HTTP outside the main documents?

If the answer to (a) is "no", then we need a second WG, which will 
likely have a lot of membership overlap. To me, that seems 
non-optimal.

I'm OK either way with (b), but hope that if the answer is "yes" that 
they aren't even considered until all the other work is done first.

---

From: Keith Moore <[email-masked]>
Date: Wed, 30 May 2007 13:03:23 -0400

Eliot Lear wrote:
> The HTTP auth model needs a lot of work.  Creating an update without
> addressing it seems to me pointless.
Not that I disagree, but sites that are currently using forms+ssl to do
logins aren't going to go back to a model where the browser gets to
control the UI for the username/password prompt.  So maybe what is
needed is an auth model that lets the server give credentials to the
browser, along with some advice for how to use it.  And whatever
mechanism were defined to pass these credentials around would need to be
substantially better than what can currently be done with SSL and
cookies (if that's even possible) otherwise there would be no point in
defining it.

IMHO, the first work item of httpbis should be a defect list for http
1.1 and associated documents.    The next step would be to assess which
defects could reasonably be corrected in a revision to the http document
(probably to recycle at DS).  Then the group could be rechartered to
revise the http specification and to correct other defects that could
reasonably be done by that group.  One or more additional groups could
be spun up to correct the remaining defects.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 May 2007 20:26:30 +0200

> b) Will this WG consider new extensions to HTTP outside the main documents?

My preferred answer to both is "no", because I really doubt that we'll 
be able to finish in a reasonable amount of time.

> likely have a lot of membership overlap. To me, that seems non-optimal.

I do agree that RFC2617 needs a revision as well, I'm just not sure that 
we currently have the right people to do it. If a BOF would show that 
there are people willing to work on this (and implementors willing to 
update their products), then fine...

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 May 2007 20:28:13 +0200

Keith Moore wrote:
> ...

Preparations have started for this at 
<http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/>.

> ...

Best regards, Julian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 30 May 2007 15:30:33 +0000

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 May 2007 23:20:28 +0200

> addressing it seems to me pointless.

Well, RFC2616 needs updating, so does RFC2617. Why does this need to be 
the same activity?

Best regards, Julian

---

From: "Robert Sayre" <[email-masked]>
Date: Wed, 30 May 2007 17:48:59 -0400

> mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for

I think this is excellent news. Below, you'll find the text I
mentioned in a previous thread. It's not very well-written, and I'm
not sure I'll have much time to work on it, but it's a start.

I think there is important work to be done to the core spec, and
extensions and revisions to 2617 are needed. I appreciate the narrow
scope of the charter, and I think it would be best to leave it that
way until it's clear we are making good progress on the listed
milestones.

-- 

Robert Sayre

---------------------------------------------------------------------

Network Working Group                                           R. Sayre
Internet-Draft                                       Mozilla Corporation
Intended status: Informational                          January 15, 2007
Expires: July 19, 2007

                     Security Requirements for HTTP
               draft-sayre-http-security-variance-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 19, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2007).

Abstract

   Recent IESG practice dictates that IETF protocols must specify
   mandatory to implement security mechanisms, so that all conformant
   implementations share a common baseline.  This document examines all
   widely deployed HTTP security technologies, and analyzes the trade-
   offs of each.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  4
   3.  Existing HTTP Security Mechanisms  . . . . . . . . . . . . . .  5
     3.1.  Forms And Cookies  . . . . . . . . . . . . . . . . . . . .  5
     3.2.  HTTP Access Authentication . . . . . . . . . . . . . . . .  6
       3.2.1.  Basic Authentication . . . . . . . . . . . . . . . . .  6
       3.2.2.  Digest Authentication  . . . . . . . . . . . . . . . .  6
       3.2.3.  Other Schemes  . . . . . . . . . . . . . . . . . . . .  7
     3.3.  Centrally-Issued Tickets . . . . . . . . . . . . . . . . .  7
     3.4.  Web Services . . . . . . . . . . . . . . . . . . . . . . .  7
     3.5.  Transport Layer Security . . . . . . . . . . . . . . . . .  8
   4.  Revisions To HTTP  . . . . . . . . . . . . . . . . . . . . . .  9
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   6.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13

1.  Introduction

   Note: this is document is just a laundry list of security
   technologies and tradeoffs for the moment.

   This document examines the effects of applying security constraints
   to Web applications, documents the properties that result from each
   method, and will make Best Current Practice recommendations for HTTP
   security in a later document version.

2.  Requirements Notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Existing HTTP Security Mechanisms

   For HTTP, the IETF generally defines "security mechanisms" as some
   combination of access authentication and/or a secure transport.

3.1.  Forms And Cookies

   Almost all HTTP authentication is accomplished through HTML forms,
   with session keys stored in cookies.  For cookies, most
   implementations rely on the Netscape specification.  One update, HTTP
   State Management Mechanism [RFC2109] is relatively widely
   implemented, but most clients don't advertise support for it.  HTTP
   State Management Mechanism was later updated [RFC2965], but the newer
   version is not widely implemented.

   Forms and cookies have number of properties that make them an
   excellent solution for some implementors.  However, many of those
   properties introduce serious security trade-offs.

   HTML forms provide a large degree of control over presentation, an
   imperative for many websites.  However, this increases user reliance
   on the appearance of the interface.  Many users do not understand the
   construction of URIs [RFC3986], or their presentation in common
   clients [todo: citation].  As a result, forms are extremely
   vulnerable to spoofing.

   HTML forms provide acceptable internationalization if used carefully,
   at the cost of being transmitted as normal HTTP content in all cases
   (credentials are not differentiated in the protocol).

   HTML forms provide a facility for sites to indicate a password should
   never be pre-populated. [@more on autocomplete]

   The cookies that result from a successful form submission make it
   unessecary to validate credentials with each HTTP request, an
   excellent property for scalability.  Cookies are susceptible to a
   large variety of XSS (Cross-site scripting) attacks, and measures to
   prevent such attacks will never be as stringent as necessary for
   authentication credentials, because cookies are used for many
   purposes.  Cookies are also susceptible to a wide variety of attacks
   from malicious intermediaries and observers.  The possible attacks
   depend on the contents of the cookie data.  There is no standard
   format for most of the data.

   HTML forms and cookies provide flexible ways of ending a session from
   the client.

   HTML forms require an HTML rendering engine, which many protocols
   have no use for.

3.2.  HTTP Access Authentication

   HTTP 1.1 provides a simple authentication framework, and HTTP
   Authentication: Basic and Digest Access Authentication [RFC2617]
   defines two OPTIONAL mechanisms.  Both of these mechanisms are
   extremely rarely used in comparison to forms and cookies, but some
   degree of support for one or both is available in many
   implementations.  Neither scheme provides presentation control,
   logout capabilities, or interoperable internationalization.

3.2.1.  Basic Authentication

   Basic Authentication transmits usernames and passwords in the clear.
   It is very easy to implement, but not at all secure unless used over
   a secure transport.

   Basic has very poor scalability properties, because credentials must
   be revalidated with every request, and secure transports negate many
   of HTTP's caching mechanisms.  Some implementations use cookies in
   combination with Basic credentials, but there is no standard method
   of doing so.

   Since Basic credentials are clear text, they are reusable by any
   party.  This makes them compatible with any authentication database,
   at the cost of making the user vulnerable to mismanaged or malicious
   servers, even over a secure channel.

   Basic is not interoperable when used with credentials that contain
   characters outside of the Latin-1 range.

3.2.2.  Digest Authentication

   In Digest Authentication, the client transmits the results of hashing
   user credentials with properties of the request and values from the
   server challenge.  Digest is susceptible to man in the middle attacks
   when not used over a secure transport.

   Digest has some properties that are preferable to Basic and Cookies.
   Credentials are not immediately reusable by parties that observe or
   recieve them, and session data can be transmitted along side
   credentials with each request, allowing servers to validate
   credentials only when absolutely necessary.  Authentication data
   session keys are distinct from other protocol traffic.

   Digest includes many modes of operation, but only the simplest modes
   enjoy any degree of interoperability.  For example, most
   implementations do not implement the mode that provides full message
   integrity.  Additionally, implementation experience has shown that
   the mode is impractical, because it requires servers to analyze the
   full request before determining whether the client knows the shared
   secret.

   Digest is extremely susceptible to offline dictionary attacks, making
   it practical for attackers to perform a namespace walk consisting of
   a few million passwords [todo: cite].

   Many of the most widely-deployed HTTP/1.1 clients are not compliant
   when GET requests include a query string [Apache_Digest].

   Digest requires that authentication databases be expressly designed
   to accomodate it.  As a result, many authentication databases are
   incompatible, including the most common method of storing passwords
   for use with Forms and Cookies.

   Many Digest capabilities included to prevent replay attacks expose
   the server to Denial of Service attacks.

   Digest is not interoperable when used with credentials that contain
   characters outside of the Latin-1 range.

3.2.3.  Other Schemes

   There are many niche schemes that make use of the HTTP Authentication
   framework, but very few are well documented.  Some are bound to
   transport layer connections.

3.3.  Centrally-Issued Tickets

   Many large Internet services rely on authentication schemes that
   center on clients consulting a single service for a time-limited
   ticket that is validated with undocumented heuristics.  Centralized
   ticket issuing has the advantage that users may employ one set of
   credentials for many services, and clients don't send credentials to
   many servers.  This approach is often no more than a sophisticated
   application of Forms and Cookies.

   All of the schemes in wide use are proprietary, undocumented, and
   non-standard.  There are many standardization efforts in progress, as
   usual.

3.4.  Web Services

   Many security properties mentioned above have been recast in XML-
   based protocols, using HTTP as a substitute for TCP.  Like the
   amalgam of HTTP technologies mentioned above, the XML-based protocols
   are defined by an ever-changing combination of standard and vendor-
   produced specifications, some of which may be obsoleted at any time
   [WS-Pagecount], with no documented change control procedures.  These
   protocols usually don't have much in common the Architecture of the
   World Wide Web. It's not clear why term "Web" is used to group them,
   but they are obviously out of scope for HTTP-based application
   protocols.

3.5.  Transport Layer Security

   [todo]

4.  Revisions To HTTP

   Is is possible that HTTP will be revised in the future.  HTTP 1.1
   [RFC2616] and Use and Interpretation of HTTP Version Numbers
   [RFC2145] define conformance requirements in relation to version
   numbers.  In HTTP 1.1, all authentication mechanisms are OPTIONAL,
   and no single transport substrate is specified.  Any HTTP revision
   that adds a mandatory security mechanism or transport substrate MUST
   increment the HTTP version number appropriately.  All widely used
   schemes are non-standard and/or proprietary.

5.  Security Considerations

6.  Normative References

   [Apache_Digest]
              ASF, "Apache HTTP Server - mod_auth_digest".

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, October 1996.

   [RFC2109]  Kristol, D. and L. Montulli, "HTTP State Management
              Mechanism", RFC 2109, February 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2145]  Mogul, J., Fielding, R., Gettys, J., and H. Nielsen, "Use
              and Interpretation of HTTP Version Numbers", RFC 2145,
              May 1997.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2617]  Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
              Leach, P., Luotonen, A., and L. Stewart, "HTTP
              Authentication: Basic and Digest Access Authentication",
              RFC 2617, June 1999.

   [RFC2965]  Kristol, D. and L. Montulli, "HTTP State Management
              Mechanism", RFC 2965, October 2000.

   [RFC3365]  Schiller, J., "Strong Security Requirements for Internet
              Engineering Task Force Standard Protocols", BCP 61,
              RFC 3365, August 2002.

   [RFC3631]  Bellovin, S., Schiller, J., and C. Kaufman, "Security
              Mechanisms for the Internet", RFC 3631, December 2003.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [WS-Pagecount]
              Bray, T., "WS-Pagecount", September 2004.

Author's Address

   Robert Sayre
   Mozilla Corporation

Full Copyright Statement

   Copyright (C) The Internet Society (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

---

From: David Morris <[email-masked]>
Date: Wed, 30 May 2007 15:10:42 -0700 (PDT)

Just to acknowledge reading the proposal and noting that it seems like a
reasonable scope of effort.

Dave Morris

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 May 2007 08:54:40 +1000

> HTTP-related RFCs, most notably the security ones?

There's been talk of incorporating parts of others (e.g., authority  
for the status code registry) or more prominent references (e.g., to  
2145). The big question at this point is whether 2617 will be  
directly included in the charter.

> b) Will this WG consider new extensions to HTTP outside the main  

I think that's an emphatic "no". It can always be re-chartered if  
that seems wise down the road.

Cheers,

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 May 2007 15:55:19 -0700

At 11:20 PM +0200 5/30/07, Julian Reschke wrote:
>Eliot Lear wrote:
>>Julian Reschke wrote:
>>>For instance, RFC2617 needs a revision badly as well (for 
>>>instance, wrt to I18N of usernames and passwords, and, as far as I 
>>>can recall, certain problems with the definition of Digest Auth). 
>>>IMHO; this should occur in a separate working group.
>>
>>The HTTP auth model needs a lot of work.  Creating an update 
>>without addressing it seems to me pointless.
>
>Well, RFC2616 needs updating, so does RFC2617. Why does this need to 
>be the same activity?

If the effort for the two are temporally linked (they have to be done 
at the same time), and there will be a lot of overlap in the groups 
working on the two (that is, HTTP implementers and HTTP weenies are 
needed for both efforts), having two WGs seems like a waste of 
resources.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 May 2007 08:58:41 +1000

On 31/05/2007, at 1:30 AM, Eliot Lear wrote:

> The HTTP auth model needs a lot of work.

Agreed.

> Creating an update without addressing it seems to me pointless.

Not to me. The scope of the two activities is vastly different; I've  
only seen support for doing minor changes and clarifications to 2616,  
while 2617 needs wholesale revision or replacement in many eyes.

To be fair, there are some small clarification/editorial-type issues  
(e.g., encoding of credentials) in 2617 that could be addressed by  
this style of charter. The concern that I have is that a) it would be  
difficult to keep the lid on and limit it to just those changes, and  
b) doing so would do a lot of good in the world, considering Kieth's  
point.

Paul just noted that if the efforts are temporally linked, doing them  
separately is a waste of resources. I'm wondering if they are; e.g.,  
could a WG do 2616bis, and then be re-chartered to do 2617bis (with a  
similar scope)?

Cheers,

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 31 May 2007 02:08:31 +0200

>     * A document that is suitable to supersede RFC2616

Or documents? I.e. the discussion to split certain informal parts of
RFC2616 to a separate document? Or is that ruled out?

>     * A document cataloguing the security properties of HTTP

Regards
Henrik

---

From: "Larry Masinter" <[email-masked]>
Date: Wed, 30 May 2007 17:13:15 -0700

I'm sympathetic to the desire to keep the charter narrow, but I wonder
if it is feasible to update 2616 without updating 2617. I thought
that it was more of a convenience and that the split between
the two was (to some degree) artificial.

If you really want to limit scope, what do you think about
issuing an informational RFC on 'what changes are needed to 2617'
(starting with the Sayre draft, I'd think)? Then 2616bis
could be published and the group rechartered to do the
2617 update (and, if needed, yet another turn of the crank
on 2616bisbis.)

Larry

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 May 2007 00:19:31 -0400

> needed for both efforts), having two WGs seems like a waste of resources.
I'm thinking that perhaps RFC2617 should be moved to historic.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 May 2007 14:23:06 +1000

> 2617 update (and, if needed, yet another turn of the crank

Robert's draft is orthogonal to a 2617 update; the idea of that is to  
address the need for MTI security.

It would be interesting to compile issues for 2617 as well, to see  
what the scope of work would be. If we can keep the scope to errata  
and clarifications (i.e., not introducing new schemes), it might be  
doable.

Anybody?

---

From: "Robert Sayre" <[email-masked]>
Date: Thu, 31 May 2007 01:28:39 -0400

> address the need for MTI security.

My draft is orthogonal to things that are unimplementable, because it
seeks to document what has actually happened, and why it did. It may
be possible to design an MTI scheme for HTTP. So far, the text in my
draft leads me to believe that HTTP authentication is wedged between
graphic design, scalability, and security in such a way that
implementors of a given protocol will never be able to agree on shared
trade-offs. But I have only written what I know. I'm sure the document
can be augmented and corrected.

> and clarifications (i.e., not introducing new schemes), it might be

My feeling is that the current schemes can be updated by documenting
the internationalization behavior of popular implementations, but
nothing else is worth doing.

-- 

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

---

From: Yves Lafon <[email-masked]>
Date: Thu, 31 May 2007 03:21:52 -0400 (EDT)

On Thu, 31 May 2007, Mark Nottingham wrote:

> Not to me. The scope of the two activities is vastly different; I've only 
> seen support for doing minor changes and clarifications to 2616, while 2617 
> needs wholesale revision or replacement in many eyes.

At worst, basic auth could be back in 2616, but fixing auth in general or 
even the issues with digest is way bigger than what planned in the 
proposed scope.

> separately is a waste of resources. I'm wondering if they are; e.g., could a 
> WG do 2616bis, and then be re-chartered to do 2617bis (with a similar scope)?

If two groups are created, there will be overlap in membership, but not 
in the work done, so I don't see a big issue here. I would be against 
doing a 2617bis to fix only typos, much more is needed.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Eliot Lear <[email-masked]>
Date: Thu, 31 May 2007 07:38:03 +0000

An authentication requirements document sits in "Last Call" right now as 
we speak.  My concern is that we'll close 2616bis only to discover that 
not only do we need a 2617bis but also a 2616bisbis.  The only real 
question is whether or not we can move fast enough on the auth work so 
that you're not left twiddling your thumbs too long.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 May 2007 10:15:18 +0200

Paul Hoffman wrote:
> If the effort for the two are temporally linked (they have to be done at 
> the same time), and there will be a lot of overlap in the groups working 
> on the two (that is, HTTP implementers and HTTP weenies are needed for 
> both efforts), having two WGs seems like a waste of resources.

Good point. I think they can be done separately, that is, there can be a 
RFC2616bis without a RFC2617bis. RFC2616bis would just continue to refer 
to RFC2617, which at some point of time would be obsoleted by its revision.

Am I missing something?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 May 2007 10:20:10 +0200

> seeks to document what has actually happened, and why it did. It may

Can somebody please remind me what that draft is? It's not 
<http://tools.ietf.org/html/draft-sayre-http-hmac-digest-01>, right?

> nothing else is worth doing.

I think that really needs to be done, and if the charter would restrict 
changes to RFC2617 to do just that, that might be feasible.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 May 2007 10:20:57 +0200

> that you're not left twiddling your thumbs too long.

Pointer, please :-).

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 31 May 2007 20:53:03 +1000

Considering the scope of 2616bis is errata, and explicitly not new  
features/mechanisms, I'm not sure I follow. Do you think that  
designing new auth mechanisms will expose new errata?

My initial thought is that it's much more likely that it'll require  
who new features, or no changes to HTTP at all.

On 31/05/2007, at 5:37 PM, Eliot Lear wrote:

> An authentication requirements document sits in "Last Call" right  
> now as we speak.  My concern is that we'll close 2616bis only to  
> discover that not only do we need a 2617bis but also a 2616bisbis.   
> The only real question is whether or not we can move fast enough on  
> the auth work so that you're not left twiddling your thumbs too long.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 May 2007 14:25:14 +0200

Eliot Lear wrote:
> Julian Reschke wrote:
>> But that would be an update to RCF2617, not RFC2616bis, right?
> 
> Do we know enough to know?

Well, RFC2616 doesn't define authentication, it relies on RFC2617. So as 
long as we keep that separation, I don't see any problem. Of course I'm 
making the assumption that we don't want to change this.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 May 2007 14:19:41 +0200

Eliot Lear wrote:
> Mark,
> If you do the errata and then we need any update to cover authentication 
> - whatsoever - we end up with bisbis.  That's my point.

Best regards, Julian

---

From: "Robert Sayre" <[email-masked]>
Date: Thu, 31 May 2007 09:02:25 -0400

> <http://tools.ietf.org/html/draft-sayre-http-hmac-digest-01>, right?

Nope, it's here:
<http://lists.w3.org/Archives/Public/ietf-http-wg/2007AprJun/0132.html>

Regarding that Digest work, I have since improved it based on feedback
I got. In particular, Phillip Hallam-Baker's comments were right on
the mark.

The new and improved version is pretty good (and blogged long ago).
Doing the right thing, and thus meeting the very sane requirements
given in Sam Hartman's draft, is a task prone to ratholes of the
non-technical variety. It also attracts volume-oriented participants.

-- 

Robert Sayre

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 May 2007 15:08:16 +0200

> <http://lists.w3.org/Archives/Public/ietf-http-wg/2007AprJun/0132.html>

...so, are you going to submit it as an ID?

Best regards, Julian

(I think it would be a good starting point for future work on RFC2617)

---

From: "Robert Sayre" <[email-masked]>
Date: Thu, 31 May 2007 09:32:45 -0400

> needed for both efforts), having two WGs seems like a waste of

I don't think this follows. Personally, I don't want to participate in
the group working on 2617 until it's clear that it isn't yet another
list full of bombast about "trust", "identity", "federation", and a
bunch of other jargon that never amounts to anything technically
feasible. I don't think there is a good economic argument for bringing
that noise over here, where I definitely do want to participate.

-- 

Robert Sayre

---

From: "Robert Sayre" <[email-masked]>
Date: Thu, 31 May 2007 09:36:46 -0400

> ...so, are you going to submit it as an ID?

If that makes a difference, I am happy to.

-- 

Robert Sayre

---

From: Eliot Lear <[email-masked]>
Date: Thu, 31 May 2007 09:22:36 +0000

Julian Reschke wrote:
> Eliot Lear wrote:
>> An authentication requirements document sits in "Last Call" right now 
>> as we speak.
>
> Pointer, please :-).

draft-hartman-webauth-phishing-03.txt

---

From: Eliot Lear <[email-masked]>
Date: Thu, 31 May 2007 12:18:53 +0000

Mark,

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Thu, 31 May 2007 12:23:44 +0000

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 31 May 2007 09:42:22 -0400

Hi Robert,

> nothing else is worth doing.

I disagree. I think we need to go a lot further. My suggestion would be to 
throw away 2617 as-is, and instead do something more akin to the SASL 
document set, i.e. a "framework" document describing the general issues of 
http authentication that lays out the ground-work for the existing 
http-based auth schemes, plus documents other auth schemes in use 
(form-based, cookie-based etc). We then have separate documents for each of 
the http-based schemes basic and digest - and we should add Kerberos/SPNEGO 
to that too. Having those as separate documents will make updates in the 
future an easier process. If we want to document other types in more detail 
(as proposed or informational) that could be done too.

I would also like to see the "webmail" (proxying credentials though a 
web-app to some back end service) issue dealt with too - ideally with the 
Kerberos mechanism as a basis (and others too that make sense).

I think all that is a lot more work than just a quick rev of 2617. Given 
that it involves a lot of security there will be a need to have the direct 
participation of the Security area folks. They are less likely to be 
interested in the minutiae of 2616bis though. So I think separate working 
groups would be better because of the different cross-area participation 
requirements.

-- 
Cyrus Daboo

---

From: "Robert Sayre" <[email-masked]>
Date: Thu, 31 May 2007 09:49:19 -0400

On 5/31/07, Cyrus Daboo <[email-masked]> wrote:
> throw away 2617 as-is,
...
> So I think separate working

Fully agree. I should have written "no other work on 2617 is worth doing".

-- 

Robert Sayre

---

From: Keith Moore <[email-masked]>
Date: Thu, 31 May 2007 11:26:15 -0400

> who new features, or no changes to HTTP at all.
I think it likely that some minor enhancements to HTTP will be needed by
a new authentication method.  However I don't know that this would
require an update to the base HTTP specification; a separate document
might be sufficient.

The more I think about it, the more I believe that a separate working
group for HTTP security is needed.  This work should not need to be
critical path for httpbis.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 31 May 2007 12:10:03 -0700

Just to reiterate what I have said before, I think it is absurd to make
minor editorial modifications to RFC 2616 in a new revision.  If minor
editorial changes are necessary right now, the RFC editor can make them
with a simple set of instructions from the original authors.  However,
I don't see them as necessary -- the existing list of errata is
sufficient until such time as the more pressing security issues can
be resolved in other specifications.

The reason that RFC 2616 had so many editorial mistakes is because the
RFC became completely unreadable due to far too much committee-driven
discussion being added in the revision from 2068 to 2616.
If an actual revision is desired for HTTP/1.1, then a ground-up reorg
of the specification and formal ABNF productions are necessary.
I don't care if that matches "group consensus desires" or not;
sometimes the work needs to be done regardless of popular opinion.

What matters is not what work the working group is willing to embark
upon, but what work the group is willing to review at the end.  If I
completely rewrite the HTTP/1.1 specification without adding features,
and submit that new draft for review, will the working group consider
it to be out of scope?  If not, then limiting the scope of changes
to the specification (aside from not adding new features) is irrelevant
to the charter.  If it will be out of scope, then I have no interest
in participating here and will fork the standard to a place that
isn't being driven by a short-term corporate agenda.

If an IETF HTTP WG is to be recreated, then its task items should be
to create what the working group believes to be the best documents
to replace 2616 and 2617.  The charter does not need to constrain that.

In any case, the IESG has expressed many times that an application
protocol will not move forward without providing a required solution
for secure authentication.  Thus, it is foolish to start a 2616 revision
without first completing some form of 2617 revision, whether or not
that includes new features for HTTP.  That is not going to happen as
long as you guys are burning up all of the available HTTP reviewers'
time on irrelevant changes to 2616.

Cheers,

Roy T. Fielding                            <http://roy.gbiv.com/>
Chief Scientist, Day Software              <http://www.day.com/>

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 31 May 2007 20:57:28 +0200

tor 2007-05-31 klockan 09:42 -0400 skrev Cyrus Daboo:

> to that too.

Note: Both Kerberos & SPNEGO both break the foundations laid out by
RFC2616 and 2617, tying authentication to connections and not messages.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 1 Jun 2007 07:15:57 +1000

> be resolved in other specifications.

I'm very aware of your feelings. I'm also aware of the pain that  
folks go through when they try to implement the current spec. Yes,  
some of that is caused by the organisation and committee-speak there,  
but much more is on very specific points where the spec is silent or  
misleading -- our issues list now has more than sixty issues. That  
this effort will help in those cases. No, it's not a magic pill, but  
a complete rewrite wouldn't be either, and it would have much less  
chance of success.

> isn't being driven by a short-term corporate agenda.

Is your threat to attempt a fork of HTTP if you don't get your way a  
hypothetical, or something you're actually considering?

Also, on what do you base the accusation that this is being driven by  
"short-term corporate agendas?"

In any case, I don't think re-organising parts of the spec is off the  
table; indeed, it's already been discussed on a small scale. Re- 
writing the entire spec sentence-for-sentence is, in my opinion.

> to replace 2616 and 2617.  The charter does not need to constrain  

That would be disruptive and unproductive. You may be willing to re- 
write HTTP from scratch, but the review requirements are much higher  
than required for what we're attempting (with step-by-step diffs, by  
the way).

Somehow, HTTP has been implemented and become one of the most widely- 
deployed application protocols today, despite your claims that the  
spec needs to be re-written from scratch. I don't hear *anyone* else  
saying that this necessary, or a realistic option.

> time on irrelevant changes to 2616.

This concern has already been discussed extensively, and as of Prague  
we believe we have a workable solution.

Thanks,

---

From: Cyrus Daboo <[email-masked]>
Date: Thu, 31 May 2007 17:16:02 -0400

Hi Henrik,

--On May 31, 2007 8:57:28 PM +0200 Henrik Nordstrom 
<[email-masked]> wrote:

>> (form-based, cookie-based etc). We then have separate documents for each
>> of  the http-based schemes basic and digest - and we should add
>> Kerberos/SPNEGO  to that too.
>

Well there is already RFC4559 and some folks in the security area were 
working on tidying that up a bit more for a proposed standard.

-- 
Cyrus Daboo

---

From: Eric Lawrence <[email-masked]>
Date: Thu, 31 May 2007 14:28:26 -0700

Cyrus--

You're right, but Henrik's point still stands.  The existing implementation of Negotiate/NTLM is significantly different than the conventional HTTP authentication "per-message" model.  It may be difficult (or undesirable) to roll this into RFC2616.

Eric Lawrence
Program Manager
Internet Explorer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Thursday, May 31, 2007 2:16 PM
To: Henrik Nordstrom
Cc: Robert Sayre; Mark Nottingham; Larry Masinter; Eliot Lear; Julian Reschke; Paul Hoffman; Apps Discuss; [email-masked]
Subject: Re: Straw-man charter for http-bis -- call for errata/clarifications to 2617

Hi Henrik,

--
Cyrus Daboo

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 31 May 2007 23:35:27 +0200

> working on tidying that up a bit more for a proposed standard.

Sure, but it doesn't make it follow the HTTP specs any better.

It's not very visible when reading the rfc until one gets to the
security considerations section, or alternatively study how the "scheme"
actually operates on the wire.

NTLM and Negotiate is not HTTP authentication schemes, it's something
completely different masqueraded to look like HTTP authentication at a
first glance, but with far going implications on the HTTP message,
transport and security models.

Regards
Henrik

---

From: Paul Leach <[email-masked]>
Date: Thu, 31 May 2007 14:54:58 -0700

A couple of thoughts:
1. The requirements (use of connection-keep-alive, proxy issues, etc)
for secure use of per-connection authentication could be described in
2617bis.  AFAIK, these could reflect some actual implementation
experience.
2. A "shared key" auth method could be introduced that would do
per-message security, and a framework whereby mechanisms for negotiating
that key could be used -- Kerb/SPNEGO being the obvious ones. There
would be severe chicken/egg deployment issues around this, but maybe
over the long run it would get adopted.

-----Original Message-----
From: Eric Lawrence
Sent: Thursday, May 31, 2007 2:28 PM

Cyrus--

You're right, but Henrik's point still stands.  The existing
implementation of Negotiate/NTLM is significantly different than the
conventional HTTP authentication "per-message" model.  It may be
difficult (or undesirable) to roll this into RFC2616.

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 01 Jun 2007 00:04:09 +0200

> difficult (or undesirable) to roll this into RFC2616.

I would undesirable. It requires a far too big change in the transport &
message model of HTTP, and in it's current form has some serious (but
partially documented) security implications when using proxies.

HTTP is explicitly designed as a transport-independent message oriented
protocol where each message is self-contained and not dependent on being
sent on a specific transport connection.

RFC4559 is completely connection oriented, with messages far from
self-contained and very dependent of which transport connection is being
used.

Regards
Henrik

---

From: Paul Leach <[email-masked]>
Date: Thu, 31 May 2007 15:05:40 -0700

Sometimes, the best is the enemy of the good. I think this is one of
cases. As all good engineers should, I have great emotional sympathy for
Roy's approach of producing the best possible HTTP spec, but while a
brand-new, easy-to-implement-from HTTP/1.1 spec would sure be wonderful,
if it isn't very likely to get done, then it isn't in reality better
than a careful revision of the current one. (Another aspect of good
engineering is dealing with tradeoffs.)

Indeed, the above analysis also applies to the proposed charter:
wouldn't an informational RFC "HTTP Implementors Guide" be nearly as
good as the proposed RFC2616bis? And far less work, hence available much
sooner?

(And hey, since it isn't us, who are these evil "short-term corporate
interests"? Are they available to  take other heat off us, too? :-)

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 01 Jun 2007 00:12:23 +0200

> 2617bis.  AFAIK, these could reflect some actual implementation

Connection oriented authentication requires support in the base HTTP
specs for such schemes, as it has far going implications on transport
and message requirements.

Would be more fruitful to rework NTLM/Negotiate to fit in the HTTP
message model I think, operating somewhat similar in principle (but
obviously not algorithm) to Digest MD5-sess with a virtual session
identifier separate from the transport connection.

Such work would fit nicely in RFC2617bis.

Regards
Henrik

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 01 Jun 2007 00:28:05 +0200

> saying that this necessary, or a realistic option.

It probably is from the perspective of having a easy to read and error
free protocol specification, but this is not one of the requirements for
an IETF protocol standard.

Imho the goal of this effort is to push HTTP/1.1 specifications forward
to the level that it can be accepted as an IEFT standard. Not to make a
perfect specification.

Once that is accomplished work should start on the next version of HTTP
to improve both specifications and protocol based on what is learnt from
HTTP, WebDAV, CalDAV and other HTTP extensions or applications using
HTTP as a meaningful substrate, but that's a separate effort.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 1 Jun 2007 08:32:53 +1000

> good as the proposed RFC2616bis? And far less work, hence available  

That's an interesting suggestion. My initial feeling is that it might  
be harder to settle on text if given a blank slate.

Also, much of the work for bis is done, or in train -- see the issues  
list and draft-lafon. For the apps-discuss people who may not have  
seen them;
   http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/
   http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/draft-lafon- 
rfc2616bis-latest.txt

> interests"? Are they available to  take other heat off us, too? :-)

I'm sure someone could be found, for the right price...

---

From: Paul Leach <[email-masked]>
Date: Thu, 31 May 2007 15:39:35 -0700

-----Original Message-----
From: Henrik Nordstrom [mailto:[email-masked]] 
Sent: Thursday, May 31, 2007 3:12 PM
To: Paul Leach
Cc: Eric Lawrence; Cyrus Daboo; [email-masked]
Subject: RE: Straw-man charter for http-bis -- call for
errata/clarifications to 2617

Connection oriented authentication requires support in the base HTTP
specs for such schemes, as it has far going implications on transport
and message requirements.
[Paul Leach] Since I think people safely use it today, I don't think any
additions are needed. At least when no proxy server is involved -- I
forget the trick used to make sure that proxies preserve connection
semantics before relying on Kerb/SPNEGO when using a proxy. It may be
that they won't be used if a proxy is involved.

Would be more fruitful to rework NTLM/Negotiate to fit in the HTTP
message model I think, operating somewhat similar in principle (but
obviously not algorithm) to Digest MD5-sess with a virtual session
identifier separate from the transport connection.
[Paul Leach] That was what my second suggestion from the message, part
of which you quoted above, was about. I guess it wasn't clear enough. 

It would be a better approach, but it would still be pretty helpful to
tell people how to interop with the existing approach.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 31 May 2007 15:59:15 -0700

On May 31, 2007, at 2:15 PM, Mark Nottingham wrote:
> some of that is caused by the organisation and committee-speak  
> there, but much more is on very specific points where the spec is  
> silent or misleading -- our issues list now has more than sixty  
> issues. That this effort will help in those cases. No, it's not a  
> magic pill, but a complete rewrite wouldn't be either, and it would  
> have much less chance of success.
>
> Is your threat to attempt a fork of HTTP if you don't get your way  
> a hypothetical, or something you're actually considering?

It is not "if I don't get my way".  Who appointed you to be the
determinant of group consensus in the first place?  I am not going
to support an IETF working group that says "nobody is allowed
to do a better job describing HTTP than what is in our charter."
If you don't allow people to produce drafts, and allow the working
group to evaluate those drafts on the basis of whether the contents
are better or not, then all you are doing is dictating the content
of the specification based upon some imagined position of authority.

So, you should decide whether your work item is to replace 2616
or to produce a list of errata to be published in RFC form.  If it
is the former, than I know a lot more about this subject than you
and I know for a fact that just making small changes around the
edges is not sufficient.  We already tried that twice.

If I make the real changes that are needed in draft form and submit
them to the WG, then I will expect them to be evaluated without bias
or the WG to be closed.  If the answer is "that's too much
for me to review, so you aren't allowed to do that in the IETF"
then I won't.  I will do it elsewhere and the IETF specification
will become irrelevant.

> Also, on what do you base the accusation that this is being driven  
> by "short-term corporate agendas?"

On the basis that you presuppose every work item as being limited
to what you want to do, rather than a task that can be accomplished
if someone does it, and the continual reference to vendors and
"developers" that never actually show themselves on this list.

> In any case, I don't think re-organising parts of the spec is off  
> the table; indeed, it's already been discussed on a small scale. Re- 

In your opinion.  You chose to ignore mine, in spite of the fact that
I have a bit of history on the subject, and that is why I have to make
comments on these proposals.

> write HTTP from scratch, but the review requirements are much  
> higher than required for what we're attempting (with step-by-step  
> diffs, by the way).
>
> Somehow, HTTP has been implemented and become one of the most  
> widely-deployed application protocols today, despite your claims  
> that the spec needs to be re-written from scratch. I don't hear  
> *anyone* else saying that this necessary, or a realistic option.

I don't hear anyone else saying that 2616 needs to be revised before
2617, yet you continue to take that as an assumption.  2616 doesn't
*need* to be revised at all.  2617 desperately does need to in order
to meet the IESG requirements.  Why is that unclear?

I do not desire a revision on 2616.  However, if a revision is called
for, then the minimum revision is something that can be reviewed
in its entirety.  That was not the case for 2616, and certainly won't
be the case for the patchwork of issues you have collected so far.

....Roy

---

From: Henrik Nordstrom <[email-masked]>
Date: Fri, 01 Jun 2007 01:08:06 +0200

> that they won't be used if a proxy is involved.

The no-proxy case is workable, as both endpoints then know they need to
go outside the HTTP specs and can bend the protocol pretty much as they
desire. But it doesn't make it fit better into the HTTP specs.

The proxy case is quite ugly. Doable, but requires a bit crossed fingers
and guesswork on how the clients and servers behave. We just went
through this with the Squid proxy about a year ago which was a quite
interesting experience..

> That was what my second suggestion from the message, part

Good. So lets keep that in mind when talking about RFC2617bis.

If Microsoft is willing to rework their authentication schemes so that a
future revision fits the HTTP message model, perhaps by using virtual
sessions instead of transport connections to identify the authentication
session then the need for extending HTTP to officially supporting
transport level authentication disappears.

> tell people how to interop with the existing approach. 

The existing RFC is perfectly fine for that purpose.

The question here is if the requirements of RFC4559 "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft Windows" should be on
the table while revising the HTTP specifications or not. I say firmly
not.

But I am perfectly fine with RFC2617bis including a generic framework
for strong session identification with replay protection, which can then
be utilized to implement NTLM and other session oriented authentication
schemes without requiring a closely tied transport<->session relation as
is the case today.

Regards
Henrik