INTERNET DRAFT Roger deBry, IBM Carl Kugler, IBM Steve Gebert, IBM Harry Lewis, IBM Don Wright, Lexmark Scott Isaacson, Novell Tom Hasting, Xerox Expires: July 1998 February 19, 1998 The Use of Post: A Response to Status of this Document This document is an Internet-Draft. 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". To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Please send comments to the IPP working group at ipp@pwg.org. Abstract A recent Internet Draft [1] argues that the common use of POST to provide a uniform method of passing blocks of data to an application, is being misused in the definition of new application protocols, such as the Internet Printing Protocol. Cohen et. al. argue that a new PUSH method be defined for this purpose. This Internet Draft argues that the existing POST method provides all of the required functionality for back end applications, such as Print, without sacrificing the levels of security that customers expect. More importantly, from the customer’s point of view, it does this without any impact to existing, installed network components. DeBry et al. February 19,1998 INTERNET DRAFT Use of POST February 19, 1998 Josh Cohen et. al., have published an Internet Draft which provides a set of arguments for not overloading the POST method in HTTP. They admit that in part their argument is a philosophical one. In responding to the philosophical issues, let us first look carefully at the definition of POST in the HTTP/1.1 Specification. In part, it says: "POST is designed to allow a uniform method to cover the following functions: - Annotations of existing resources - Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles - Providing a block of data, such as the result of submitting a form, to a data handling process - Extending a database through an append operation" Let's focus on the third bullet, that is, providing a block of data to a data handling process. It is this use of POST which forms the cornerstone of many modern Web Applications. Visit Microsoft's own web site to see numerous examples of data driven applications and e- commerce applications which depend upon HTTP to pass data through the web server to some back end application. These are not simple forms driven applications, but use highly developed tools and technologies, such as servlets, server side scripts, and ActiveX components, to drive complex mission-critical applications. Indeed, the CGI interface and various Web server APIs were built specifically to exploit this ability of the POST method to uniformly ship data to an application on the other side of the Web server. Aviel Rubin [2], et al. in discussing the value of this interface in their book on Web Security say that: "If you are building a complex Web server site and are taking advantage of new application protocols, you may run into cases where firewalls interfere with your application's traffic. For this reason, it is best, wherever possible, to use applications that run on top of HTTP." From a philosophical point of view Cohen et. al. would have us believe that, in the case of IPP [3], we should not use POST to transport a Print request to a back end print application. Instead, he suggests a new method should be defined. It is interesting to note that he stops short of suggesting that a Data Base QUERY method be defined when using HTTP to direct a query to a back end data base application, or a BUY method be defined when using HTTP to buy something over the Web, or a TRANSACT method be defined when using HTTP to initiate a transaction to make an airline reservation. Are these applications less sensitive to security intrusions than Print? It is obvious that using POST to provide a block of data to a data DeBry, et al. Page [2] INTERNET DRAFT Use of POST February 19, 1998 handling process is common practice. Should printing really be treated differently?" From a philosophical point of view, one is also led to ask, Does defining a new method (or methods) in HTTP make the object of those new methods part of HTTP? I would guess that if I were on the HTTP working group, I'd have something to say about someone else creating a new HTTP method. It is perhaps for this reason that Cohen et. al. appear to back away from their original thesis that "the default requirement for (any) new HTTP functionality must be to create a new method name", and propose a single new method called PUSH. According to Cohen et. al., PUSH "would be a generic POST ... which would require a secondary expression of specific operational semantics along with the request message". We claim that this capability already exists today in the content- type header which is part of an existing HTTP message. In fact, the IPP protocol makes use of a new content-type, Application/IPP, to provide this "secondary expression of specific operational semantics". Cohen et. al. claim that content-type should not imply any semantics, but note this paragraph from the MIME specification [4] which describes the application media type: "The application media type is to be used for discrete data which do not fit in any of the other categories, and particularly for data to be processed by some type of application program." It seems therefore that a content type of application/xxx is perfectly suited to provide Cohen et. al.'s additional expression of operational semantics, and requires no change to the existing HTTP definition or to existing Web software. Cohen et. al. say that using content-type is also an exposure, because I can lie about the content-type. Isn't it just as easy to lie about a new method, or the suggested secondary expression? Even if we were to accept Cohen et. al.'s assertion that a new method is required, we would find it difficult to use anything other than the existing header structure of HTTP to carry the additional expression that Cohen et. al. suggests is required. An Internet Draft on HTTP extensions [5] supports this notion when it says that "Header fields can be used to pass information about any of the parties involved in the transaction, the transaction itself, or the resource identified by the Request-URI. The advantage of headers is that the header space is relatively open compared to that of methods and status codes. New headers can be introduced and must be ignored if the recipient does not recognize the header without affecting the outcome of the transaction ." The technical basis of Cohen et. al.'s dissertation is that overloading the POST method subverts existing security policies within organizations which may implement a protocol, such as IPP, which uses POST. Cohen et. al. point out that PFB administrators (PFB is a term coined by Cohen et al., and stands for Proxy/Firewall Boundary) today can choose among characteristics like source port, destination port, header prologue, HTTP method, mime-type, DeBry, et al. Page [3] INTERNET DRAFT Use of POST February 19, 1998 as well as others. Why isn't this sufficient? Today I can clearly define which resources (in the case of IPP, which printers), if any, are accessible from outside of my PFB. I can restrict access to resources to be from specific domains or IP addresses. I can further provide TLS authentication on top of PFB access to protect myself from unauthorized use of my resources. In this sense, why is access to some new function, such as print, any different from access to a database, a transaction system, or the many other back end resources being accessed daily on the Web today? Cohen et. al. claim that outbound print messages are a security risk. But so is outgoing email, ftp, and for that matter, walking out of the door with a briefcase full of confidential materials. The purpose of PFBs is to protect my internal computing resources from malicious attacks, not protect people from walking out of the door with confidential material. We submit that few administrators would care to prevent print requests from originating inside the PFB from reaching external servers. Cohen et. al.'s proposal would optimize IPP for those few at the expense of the many. Given that IPP uses an HTTP content header to provide secondary information about what's in the POST, an adminsitrator who really wants to filter based on content can do so. Perhaps this is a moot point in light of Cohen et. al.'s generic PUSH method where the PFB would also have to inspect some secondary fields in the HTTP request. Conclusion One of the major reasons the IPP working group decided to use POST was that it allowed us to very quickly deploy the protocol. By using this "uniform method" for passing blocks of data through a Web server, and by the way through Proxy/Firewall Boundaries, we have no dependencies on Web servers and PFBs having to be replaced or upgraded to support printing. We believe this very significant benefit should not be cast aside lightly. Other applications can and do use it. Cohen et. al. claim that new protocols should not have to accept a lower level of security to support a "small" installed base of non-supportive PFBs. I guess if I were a PFB vendor I'd be pleased with every opportunity to sell an upgraded product, but I'd like Cohen et. al. to explain their position to a customer who has to upgrade his network just to print! In conclusion, we claim that with the current design of HTTP, new capabilities can be added without sacrificing the levels of security that customers expect. Indeed, this capability is being used to deliver mission critical applications to the Web every day, without requiring customers to replace the installed base of Web servers or PFBs. Perhaps we could redesign HTTP to be more architecturally pure in this regard, although this is arguable. But even if we could, DeBry, et al. Page [4] INTERNET DRAFT Use of POST February 19, 1998 why would we spend the time to fix something that is not broken, only to require customers to buy the new version in order to do something that they can do today? Security Considerations This document provides clarification on security considerations in the use of HTTP. As such, it does not, in of itself, introduce new security considerations. IANA Considerations This document introduces no new IANA considerations. References [1] J. Cohen, A. Hopmann, Y.Y. Goland, V. Valloppillil, P. Leach, and S. Lawrence, "Don't go Postal: An argument against improperly overloading the HTTP POST Method" Internet Draft, work-in-progress, February 1998 [2] A. Rubin, D. Geer, and M. Ranum, "Web Security Sourcebook" John Wiley and Sons, 1997 [3] R. Herriot, S. Butler, P. Moore, and R. Turner, "Internet Printing Protocol/1.0: Protocol Specification", Internet Draft, work-in-progress, January 1998. [3] N. Freed and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996 [4] D. Connolly, H. Nielsen, R. Khare, Eric Prud'hommeaux, "PEP - an Extension Mechanism for HTTP", Internet Draft, work-in-progress, December 1997 Authors Addresses Roger deBry Carl Kugler Harry Lewis Steve Gebert IBM Corporation P.O. box 1900 Boulder, CO 80301-9191 (email rdebry, harryl, sgebert, kugler @us.ibm.com) Don Wright Lexmark International 740 New Circle Rc. Lexington, KY 40550 (email don@lexmark.com DeBry, et al. Page [5] INTERNET DRAFT Use of POST February 19, 1998 Scott Isaacson Novell, Inc. 122 E. 1700 So. Provo, Utah 84606 (email sisaacson@novell.com) Tom Hastings Xerox Corporation 701 S. Aviation Blvd. El Segundo, CA 90245 (email hasting@cp10.es.xerox.com) DeBry, et al. Page [6]