INTERNET DRAFT J. Cohen, Microsoft . Discussions of the working group are archived at . 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]