INTERNET DRAFT J. Cohen, Microsoft
<draft-cohen-http-ext-postal-00.txt A. Hopmann, Microsoft
Y. Y. Goland, Microsoft
V. Valloppillil, Microsoft
P. Leach, Microsoft
S. Lawrence, Agranat Systems
Expires July, 1998 February 14, 1998
_Don't Go Postal_
An argument against improperly overloading the HTTP POST Method
Status of this Memo
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 made obsolete 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 HTTP working group at <http-wg@cuckoo.hpl.hp.com>. Discussions
of the working group are archived at
<URL:http://www.ics.uci.edu/pub/ietf/http/>.
Abstract
As time goes on, more and more groups are extending HTTP's
functionality. In using HTTP, a decision is made to either use a
new method name for new functionality or to overload an existing one
such as POST. Our belief is that in most cases, overloading
existing method names, with POST as a particularly troublesome
example, is a bad idea. We, as a group of individuals, suggest that
the default requirement for new HTTP functionality must be to create
a new method name.
Introduction
.
For those unfamiliar with the issue at hand, IPP, the Internet
Printing Protocol, has submitted their protocol for last call which
provides print functionality over HTTP. To encode the protocol, a
binary protocol payload is transmitted as the body of a POST.
Cohen et al. [Page 1]
INTERNET-DRAFT Don't Go Postal February 14, 1998
We disagree with the overloading of POST, and this document is
intended to explain our reasons for doing so.
.
.
Our recommendation is in part philosophical in that we believe that
new methods are a more clean way to deal with new functionality.
However, our most pressing reason is the security consequences of
overloading POST.
This paper is not intended to address the issue of whether building
on top of HTTP is wrong or right for a particular protocol, only to
address the choice of a new method or overloading an existing one
such as POST.
Table of contents and summaries
1. Definitions
.
2. Existing proxy/firewall security policies
.
The default action to a newly introduced protocol should not be to
unknowingly pass it.
3. semantic exposure for ACLs
Protocol designers should be mindful of the resource intensive
environment in which PFBs operate and expose as much operational
semantics as possible for easy security policy enforcement.
4. Code modification vs. administrator configuration
Building a protocol which can be supported by existing firewalls
is good, building one to deliberately "sneak by" an existing
security policy is bad.
5. Ideal world POST semantics
While the functionality expressed as a post may seem to fit the
description of what a new protocol does, but the word "POST" is
taken and people depend on it existing definition as HTTP form
data when they make their policies.
6. Using mime type
Mime type denotes content type, not operational semantics
7. End to end security and policy delegation
Depending on mime type assumes that one trusts the final
8. "Everyone else is doing it".
9. Current POST implementations.
Cohen et al. [Page 2]
INTERNET-DRAFT Don't Go Postal February 14, 1998
Currently, many implementations buffer or limit the size of POST
data bodies, which may make this protocol difficult to pass for
servers and proxies.
1 Definitions
Administrator
The person, group, or entity with the responsibility for
determining and enforcing a security policy on a proxy or
firewall.
PFB
Proxy/Firewall Boundary or host. This is a control point for
traffic within, between, or across one or more networks.
2 Existing proxy/firewall security policies
A new protocol may wish to ride on top of HTTP for many good
reasons, and the ability to operate in a proxied or firewalled
environment is one of them. However, we'd like to separate the
ability to function in that environment vs. being able to pass
through proxies and firewalls in their current administrative state.
Security policies are determined by network administrators,
corporate security departments, or organizational entities. For
reference, we refer to the appropriate policy make as the
"administrator". It is up to the administrator to decide what
protocols are passed, permitted or rejected across a PFB. Any
protocol that chooses to overload an existing method with new
functionality is, in effect, causing a deployed PFB security policy
to differ from the intent of the administrator.
The key point here is that by overloading POST to support, for
example, IPP, the PFB is now permitting a new printing protocol by
default.
While it may be tempting to pursue this way of doing things
because the new protocol will be supported in a ubiquitous manner
with no administrative effort required whatsoever, one should
carefully consider the consequences. While the designers of a new
protocol may feel that their new protocol introduces no new risks,
they do not have the right to decide what a PFB will support.
Security policies vary from very relaxed ones to extremely
restrictive ones. However, we believe that protocols should be
designed to represent and support the most conservative default
action. In this case, a restrictive administrator may wish to have a
policy of "deny all, specifically allow" as opposed to "allow all,
Cohen et al. [Page 3]
INTERNET-DRAFT Don't Go Postal February 14, 1998
specifically deny". By overloading POST, a new protocol forces the
administrator into a "allow all, specifically deny" stance.
3 Semantic exposure for specific ACLs
On most firewalls today, the administrator is given many methods
for constructing his security policy. Often, he or she is able to
choose between characteristics like source port, dest port, header
prologue, HTTP method, mime-type, etc. Some PFBs support these
methods as well as others, some support only a subset.
A protocol designer may say to herself "Ill just xpose my action
semantics within my protocol, not HTTP". We contend that there is
an onus on a protocol designer to expose the security aspects or
operational semantics as they may pertain to security in the easiest
manner to facilitate easily constructed ACLs.
By using a new method, one can expose the operational semantics of
what one is doing in a clear way, which allows a firewall or proxy
to examine only the smallest message. In the case of HTTP, this
would be the extreme beginning of the HTTP header.
Most PFBs are extremely busy, while most end servers are fairly
lightly loaded. Of course, there are exceptions to this rule, but
we believe it to be true in most cases. For example, take a large
internet connected organization. There are probably a small number
of extremely busy proxy servers and a larger group of web servers
(intra/extra/internet) which are on average, lightly loaded. The
sum of all accesses from all users to all web servers across a PFB
represents the load on the PFB itself, while an individual web
server must only serve its own clients. Since PFBs can be so busy,
it is imperative to design protocols in mind which place the minimum
load on the PFB to extract appropriate information to enforce its
security policy.
In general, if a PFB can get by only examining the HTTP header, or
even better, just the method so much the better.
The protocol may include more detailed semantic exposure inside the
content or tunnel protocol and the PFB may choose to examine that,
but the general exposure should happen at the earliest possible time
to facilitate the most efficient implementation of PFBs.
4 Code modification vs. administrator configuration
People often use the argument that since by default, their new
protocol will be hampered by the existence of PFBs, that tunneling
through via POST is a good thing. What is often overlooked is the
difference between a PFB which can be configured to accept the new
protocol and the PFB which must be upgraded to support the new
protocol. We accept that there are some firewalls which may need to
Cohen et al. [Page 4]
INTERNET-DRAFT Don't Go Postal February 14, 1998
be upgraded to support a new method and consequently the new
protocol.
.
However, most PFBs today, and surely the future ones of tomorrow
will continue to increase the flexibility they allow in creating
security policies. Of course, there is an onus on firewall and
proxy implementers to provide an easy and flexible way to express
their security policy.
For those PFBs which do not currently support the use of new methods
in their security enforcement, we assert that they need to add this
functionality to maintain the desired level of security. New
protocols should not have to accept a lower level of security due to
a small installed base of non-supportive PFBs, those products should
be enhanced to provide the appropriate level of security.
It one thing to say that a new protocol can be supported by most
existing firewalls, and another completely different thing to say
that most existing firewalls today will pass this protocol with
their current security policy.
It is a good thing for a protocol designer to say the first
statement. Most everyone would agree that we'd like to see new
protocols supported by existing PFBs.
However, it is not a good thing to say the second. While the folks
on the relaxed security side of the fence may agree, this would
likely make the hair on the necks of those who enforce restrictive
security policies bristle in displeasure.
5 Ideal world POST semantics
.
While the functionality expressed as a post may seem to fit the
description of what a new protocol does, but the word "POST" is
taken and people depend on it existing definition as HTTP form data
when they make their policies.
It has been argued that since an operation in a new protocol fits
the definition of the word "POST", overloading the method POST is a
good idea. Unfortunately, when the letters P.O.S.T. came into
existence as an HTTP method, the operational meaning was fairly
specific in that it was for HTTP form data submission. At the time,
the design environment and goal of HTTP wasn't sufficient to
represent what the protocol has become today and what it has been
modified to do in all cases. So, we assert that the method POST has
been taken, and what may be needed is another method. This new
method would be a generic post, or "PUSH" for example, which would
require a secondary expression of specific operational semantics
along with the request message. If PFBs were build to handle this,
Cohen et al. [Page 5]
INTERNET-DRAFT Don't Go Postal February 14, 1998
then an unqualified PUSH request could be denied or accepted by a
PFB based on the administrator's declared default action. We
believe that this is better than forcing everyone into a mode where
the default action becomes "allow all, specifically deny".
6 Using mime type
.
Mime type denotes content type, not operational semantics
.
.
It has also been argued that the PFB can just use the mime-type,
or HTTP content type to identify the message for policy enforcement.
Unfortunately, in the current base of installed PFBs, it is more
efficient to use the method name than a content type.
From an architecture perspective, content type should reflect the
type label associated with the content, not action which the content
will perform or the action which will be applied to it. GET and HEAD
perform different actions, but often on the same
labeled content. It is the method which indicates the action, not
the content label.
7 End to end security and policy delegation
Depending on mime type assumes that one trusts the final
destination of the message to enforce the mime-type declaration.
This causes an organization's security policy to depend on the
enforcement of an external entity and is not acceptable.
Further, what would happen if the client simply lied about the
content-type? The answer to that is simply that the recipients of
the message are required to reject inappropriately labeled content.
Unfortunately, it is very likely that the server or recipient of the
request message is not in the same administrative domain as the PFB
or the user.
This raises the question of who is actually in control. Would
your organization be willing to pass a request in hopes that an
external server would properly enforce your security policy? We
don't believe so.
Another issue which comes to light is the difference between end
to end security and organizational security. End to end security
would refer to method of security (TLS, SSL, SSH, etc) which would
be used between the client and the server. One could argue that
"this is *real* security". While it is true that the data in the
transaction is not vulnerable to interception or sniffing, and that
both parties are authenticated. However, as an administrator, I am
not charged with the responsibility of protecting my organizations
Cohen et al. [Page 6]
INTERNET-DRAFT Don't Go Postal February 14, 1998
assets from attack from outside as well as from within, as well as
keeping those assets from being accessed or transmitted across the
PFB. It makes little difference to me that a disgruntled employee
has authenticated himself to an internet fax or printer before he
transmits our customer list outside our company.
Of course, your saying "Well, I can just do that in email" and
that would be true. However, we still have a responsibility to take
precautions when possible, even if there are other ways to achieve
the same thing.
8 _Everyone else is doing it_
.
Its a trend that needs to be reversed and it is not a valid
reason.
.
.
The logical conclusion is of following this path is that POST will
become so meaningless since it will be the catch all method in use.
Firewall administrators will become fearful of it as well as
frustrated with the administrative nightmare it poses.
Every day, the firewall admin will have to check the latest list of
"allowed" mime types or the new protocols and block or accept them.
It seems unlikely they one can ever have a state where they can
classify valid POST mime-types to effect a "deny all, explicitly
permit" policy. As for new protocols like IPP, its likely that in
frustration firewall administrators will simply block everything,
and not support the new functionality.
9 Current POST implementations.
In certain cases, apache as an example, will, in certain cases
limit POST (and PUT) content to 48k. We wonder if many other
servers deployed today have similar restrictions. This could very
well make deployment of IPP difficult if not impossible in the
heavily proxied infrastructure today. By using a new method, and
presumably a new handler, the IPP server side implementation would
be out of the path of these limitations, and implemented to optimize
for the large POST case.
.
It would seem that the large data case would be common in large
print jobs.
10 Summary:
In the world of new internet protocols and the frequency of
security fire drills, we must be careful to provide adequately
exposed information to security policy enforcers with as little work
required at every opportunity. While the word "POST" may mean a lot
Cohen et al. [Page 7]
INTERNET-DRAFT Don't Go Postal February 14, 1998
of things or a general mode of communications, millions of connected
entities have created their security policies which depend on POST
to allow simple web access and form submission, not to allow any new
protocol which rides on top of HTTP. End to End security may
provide security against interception or sniffer attacks between a
client and server, but the enterprise administrator needs to have
access to the semantics so his security policy can make effective
enforcement decisions.
Using a new method which implies a specific action is more desirable
and makes life easier in dealing with security, implementation, and
administration of Firewalls, Proxies, or other security devices.
11 Security Considerations
This document clarifies security considerations in the HTTP
protocol. As such it does not, in and of itself, introduce new
security considerations.
12 IANA Considerations
This document introduces no new IANA considerations.
13 Copyright
The following copyright notice is copied from RFC 2026 [Bradner,
1996], Section 10.4, and describes the applicable copyright for this
document.
Copyright (C) The Internet Society February 10, 1998. All Rights
Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
Cohen et al. [Page 8]
INTERNET-DRAFT Don't Go Postal February 14, 1998
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.
14 Intellectual Property
The following notice is copied from RFC 2026 [Bradner, 1996],
Section 10.4, and describes the position of the IETF concerning
intellectual property claims made against this document.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use other technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
15 References
[Bradner, 1996] S. Bradner, "The Internet Standards Process -
Revision 3." RFC 2026, BCP 9. Harvard University. October, 1996.
[Fielding et al., 1997] R. Fielding, J. Gettys, J. Mogul, H.
Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1."
RFC 2068. U.C. Irvine, DEC, MIT/LCS. January, 1997.
[Herriot et al., 1998] R. Herriot, S. Butler, P. Moore, R. Turner,
"Internet Printing Protocol/1.0: Protocol Specification", Internet-
Draft, work-in-progress, January 1998. ftp://ietf.org/internet-
drafts/draft-ietf-ipp-protocol-05.txt
16 Authors' Addresses
Josh Cohen,
Alex Hopmann,
Yaron Y. Goland,
Vinod Valloppillil,
Paul Leach
Microsoft Corporation
Cohen et al. [Page 9]
INTERNET-DRAFT Don't Go Postal February 14, 1998
One Microsoft Way
Redmond, WA 98052-6399
Email: {joshco, alexhop, yarong, vinodv, paulle}@microsoft.com
Scott Lawrence
Agranat Systems, Inc.
1345 Main St.
Waltham, MA 02154
Email: lawrence@agranat.com
Cohen et al. [Page 10]