INTERNET DRAFT Roger deBry, IBM
<draft-debry-http-usepost-00.txt> Carl Kugler, IBM
Stee Gebert, IBM
Harry Lewis, IBM
Don Wright, Lexmark
Scott Isaacson, Noell
Tom Hasting, Xerox
Expires: July 1998 February 19, 1998
The Use of Post:
A Response to <draft-cohen-http-postal-00.txt>
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 alid 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
proide 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 proides all of the required
functionality for back end applications, such as Print, without
sacrificing the leels of security that customers expect. More
importantly, from the customers point of iew, 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., hae published an Internet Draft which provides a
set of arguments for not oerloading 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 coer the following
functions:
- Annotations of existing resources
- Posting a message to a bulletin board, newsgroup, mailing list, or
similar group of articles
- Proiding 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, proiding 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 drien applications and e-
commerce applications which depend upon HTTP to pass data through the
web serer to some back end application. These are not simple forms
drien applications, but use highly developed tools and technologies,
such as serlets, server side scripts, and ActiveX components, to
drie complex mission-critical applications. Indeed, the CGI
interface and arious 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 serer. Aviel Rubin [2], et
al. in discussing the alue of this interface in their book on Web
Security say that:
"If you are building a complex Web serer site and are taking
adantage of new application protocols, you may run into cases
where firewalls interfere with your application's traffic. For
this reason, it is best, whereer possible, to use applications
that run on top of HTTP."
From a philosophical point of iew Cohen et. al. would have us
beliee 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 oer the Web, or a TRANSACT method be defined when using
HTTP to initiate a transaction to make an airline reseration. Are
these applications less sensitie to security intrusions than Print?
It is obious 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 iew, 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 hae 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
proide 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 proide 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? Een 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 inolved in the transaction, the transaction itself,
or the resource identified by the Request-URI. The adantage of
headers is that the header space is relatiely 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
oerloading 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 proide 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 preent print requests from originating inside the PFB from
reaching external serers. Cohen et. al.'s proposal would optimize
IPP for those few at the expense of the many. Gien that IPP uses an
HTTP content header to proide 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 hae 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 ery quickly deploy the protocol. By using
this "uniform method" for passing blocks of data through a Web
serer, and by the way through Proxy/Firewall Boundaries,
we hae no dependencies on Web servers and PFBs having to be replaced
or upgraded to support printing. We beliee 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 hae
to accept a lower leel of security to support a "small" installed
base of non-supportie PFBs. I guess if I were a PFB vendor I'd be
pleased with eery 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 leels of security
that customers expect. Indeed, this capability is being used to
delier mission critical applications to the Web every day, without
requiring customers to replace the installed base of Web serers or
PFBs. Perhaps we could redesign HTTP to be more architecturally
pure in this regard, although this is arguable. But een 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 ersion in order to do something
that they can do today?
Security Considerations
This document proides 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
oerloading 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, Noember 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
Stee 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
Noell, Inc.
122 E. 1700 So.
Proo, Utah 84606
(email sisaacson@noell.com)
Tom Hastings
Xerox Corporation
701 S. Aiation Blvd.
El Segundo, CA 90245
(email hasting@cp10.es.xerox.com)
DeBry, et al. Page [6]