[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
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]