5 August, 2009 Network Working Group A. Cheney Internet Draft Sabre Inc. Category: Standards Draft August 2009 SAFE (Server-side Asynchronous Framework Execution) Scripting Method draft-cheney-safe-04 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on February 1, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Cheney Standards Draft [Page 1] Internet-Draft SAFE Scripting Method August 2009 Comments Please send comments to austin.cheney@us.army.mil Abstract SAFE Scripting Method is a model for allowing application interactivity in email while simultaneously elminating security vulnerabilities associated with client-side scripting. Introduction SAFE (Server-side Asynchronous Framework Execution) Scripting Method has only two intended objectives: 1) This model provides a method to allow behavior, or event-oriented, execution of programmatic application code across email. Such code will be referred to as script. 2) This models seeks to provide an alternative to client-side scripting of world wide web (WWW) documents free of security vulnerabilities with cross-site scripting (XSS) and cross-site request forgery (CSRF). Each of these objectives is mutually necessary for the functional existence of the other. The SAFE model refers to the model of steps necessary to achieve the SAFE Scripting Method as explained below. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [34]. Three externally defined requirements are necessary for the implementation of this proposed model. One additional requirement is necessary and will be further expanded later in this document. The external requirements MUST NOT be defined by this document. 1) The first requirement is a standardized and well understood document structure definition, such as a markup language, that conforms to the conventions of the standardized Document Object Model (DOM) and accurately describes data intended for transmission across SMTP while simultaneously representing sufficient current common practices of representing or describing data intended for distribution as email or SMTP, which MUST NOT be (X)HTML. This requirement shall be arbitrarily referred to as 'markup' for the remainder of this document. 2) The second requirement is a standardized and widely adopted transmission scheme that reflects the primitive model defined by RFC 5321 while simultaneously respecting the rules and constraints defined by the document structure noted in Requirement 1, markup. This requirement shall be arbitrarily referred to as 'protocol' for the remainder of this document and MAY be representitive of RFC 5598. Cheney Standards Draft [Page 2] Internet-Draft SAFE Scripting Method August 2009 3) The third requirement is a certificate authority granting organization that is entirely external to any organization providing Requirement 1 (markup) or Requirement 2 (protocol). This requirement shall be arbitrarily referred to as CA, short for certificate authority, for the remainder of this document. 4) The third requirement is the standardization and adoption of a new programming language object, XMLSmtpPush object, which is intended to offer comparable functionality to the XMLHttpRequest object available on the WWW. Elaboration of intended objectives Allowing script execution in email is absolutely necessary to provide a minimal expectation of user experience and interaction, as well as promoting the advancement of data and commerce exchange. Behavior and event oriented scripting in email must not be compared with similar functionality available on WWW. On the WWW such scripting executes locally to the end user, which allows a degree of freedom and rapid programmatic response not available to this model at the cost of frequent security violations. In this model scripts are executed on an email server, a mediating agent of the data transmission that is never an end point of that transmission. Execution occurs in response to an event, specific expected data, a defined document feature, or other programmatic condition. This means the code executed by any script language must be pushed back to the initiated user as either a new document or as an asynchronous alteration to an established document. The reason why scripts must be executed on the server and not the client is to eliminate security vulnerabilities associated with script execution. Understandably, this opens new and more difficult to detect security vulnerabilities where compromises violate expectations of privacy. Email is inherently private and it is the liability of the distant server's owner to ensure data that passes through that mail server remains private through best current security practices. Models established by RFC 5321 Model for SMTP Use (Client/Server Model) +----------+ +----------+ +------+ | | | | | User |<-->| | SMTP | | +------+ | Sender- |Commands/Replies| Receiver-| +------+ | SMTP |<-------------->| SMTP | +------+ | File |<-->| | and Mail | |<-->| File | |System| | | | | |System| +------+ +----------+ +----------+ +------+ Sender-SMTP Receiver-SMTP Cheney Standards Draft [Page 3] Internet-Draft SAFE Scripting Method August 2009 Primitive model of email transmission between clients using the same server +---------------------------------+ | | +------------+ | | +---------+ | Initiating | | Mail- | | Distant | | Client |<-->| Server |<-->| Client | +------------+ | | +---------+ | | +---------------------------------+ Primitive model of email transmission between unrelated networks +-----------+ +-----------+ | | | | +------------+ | Mail- | | | +---------+ | Initiating | | Server | | Distant | | Distant | | Client |<-->| of |-------->| Mail- |--->| Client | +------------+ | Local | | Server | +---------+ | Domain | | | | | | | +-----------+ +-----------+ SAFE Model The SAFE model exists to allow transmission interactivity through execution of script opposed to programmatic interactivity that exists only through use of client-side programming language execution in WWW. In other words, the SAFE Model exists to provide interaction using dynamic communications that do not result in new or separate content documents that would appear to be additional emails. The mail clients MUST be expected to execute changes to the DOM of an establish document but MUST NOT process any other instructions with regard to this model or transmission interaction. This is secure because changes to the DOM only allow for the deletion, addition, or alteration to text or markup code data to a document only. The SAFE model expects that all communications will be encrypted as a result of assymmetric key exchange. SAFE - Step One In the SAFE Model the first step is to establish authorization between the two communicating clients to ensure the distant client is not a forged identity or spoofed address. If authorization is not established encryption could be exist with a fraudulent identity. A CA, as defined in Requirement 3, is necessary to ensure the integrity of the authorization process. Cheney Standards Draft [Page 4] Internet-Draft SAFE Scripting Method August 2009 The distant client MUST respond with a digital certificate signed with a digital signature. Upon certificate receipt the initiating client MUST contact the issuing CA to recieve a key to decrypt the digital signature. Since this key can only decrypt signatures signed with a private key stored at the distant user authorization is verified. This CA MUST NOT be on the same domain as either client address or any email server mediating in the transmission in order to provide an uncompromised validation of trust. This process SHOULD be transparent to the user of the originating client. +-----------+ Signature | | Public +------------+ +------------+ | Third | Key | Initiating | | Initiating |------->| Party |---------->| Client | | Client | | CA | +------------+ +------------+ | | Decrypt ^ +-----------+ Signature | +-----------+ +-----------+ | | Signed | | | Mail- | Digital | | +---------+ | Server | Cert | Distant | | Distant | | of |<--------| Mail- |<---| Client | | Local | | Server | +---------+ | Domain | | | | | | | +-----------+ +-----------+ SAFE - Step Two The second step is for both communicating clients to share public keys and engage in asymmetric encryption only after authorization is verified using Step One. If the initiating client inserts their public key in the first communication to the distant client, using a convention providing by the markup language for describing public keys, and the distant client responds with their public key, using the same markup convention, this step is unnecessary as both clients already have each others public key. Otherwise additional communications are required to exchange public keys between the initiating client and distant client. SAFE - Step Three The third step is for the initiating client to engage in communication to the distant client, such as sending an email. When the distant client is ready to engage script execution it must prompt its local mail server to initiate Step Four. This communication between the distant client and its local mail server MAY occur using any transmission protocol even if that protocol is not affiliated with email or SMTP and even if that method of communication is proprietary. When communicating to the distant mail server the distant client MUST include the public key value of the initiating client. Cheney Standards Draft [Page 5] Internet-Draft SAFE Scripting Method August 2009 +-----------+ +-----------+ | | | |1. +---------+ +------------+ | Mail- | | |--->| | | Initiating | | Server | | Distant | | Distant | | Client |--->| of |-------->| Mail- |2. | Client | +------------+ | Local | | Server |<---| | | Domain | | | +---------+ | | | | +-----------+ +-----------+ SAFE - Step Four The forth step is for the distant client's email server to send a public key exchange request to the initial client. The distant mail server must have a public/private key pair that is entirely unique and not affiliated with the key pair used by the distant client. This separate key pair is necessary, because it notifies the initial client that it will be engaging in communication with a different entity and it prevents accidental or involuntary entry into a model of script execution. This additional notification provides the initiating user a final opportunity to disallow use of the SAFE Model for any reason. Only the distant mail server needs to send a message with its key value since it was provide the initiating client's public key in Step Three. +-----------+ +-----------+ +------------+ | | | | | | | Mail- | | | | Initiating |<----------| Server |<----------| Distant | | Client | | of | | Mail- | | | | Local | | Server | +------------+ | Domain | | | | | | | +-----------+ +-----------+ SAFE - Step Five The fifth step is for the initial client and distant email server to engage in encrypted communication. At this point communication between the initiating client and the distant mail server MAY occur as many times as the distant mail server sends a response to the initiating client or as many times as the initiating client communicates to the distant mail server only. SAFE - Step Six The sixth step is to close communications between the initiating client and the distant mail server and then send a notification to the distant client. This communication from the distant mail server to the distant client verifies that SAFE Model communication has occured and properly terminated. The termination communication MUST contain the final communication that is intended to be delivered to the distant client. Cheney Standards Draft [Page 6] Internet-Draft SAFE Scripting Method August 2009 Once the SAFE Model has terminated the private data stored on the distant mail server MUST be destroyed or purged. If an interruption to communication occurs, so that a proper termination is never generated, the distant server MUST provide a defined timeout by which all stored communication will be automatically destroyed or purged. The initiating client SHOULD be provided with the opportunity to terminate the SAFE Model at every possible opportunity. SAFE - Step Seven The distant client MUST send an automated response email to the initiating client once the distant client verfies termination of the SAFE Model. If the distant client fails to send a response within a given timeout, specified by the initiating client's user agent from the time of most prior response, the SAFE Model MUST be presummed to have failed. If the SAFE Model has failed the initiating client MAY start over in order to initiate a new SAFE Model instance or MAY communicate directly to the distant client without use of the SAFE Model. SAFE - Summary The end result of the SAFE Model is that communication may be encrypted between two distant clients and a separate simultaneous application session may be established between an independent third- party which is already present in the transmission path of the two clients. This effectively means, given SMTP derived protocols as a push transmission, the initiating client will be communicating directly to the distant client while such communications may be intercepted and automatically responded to by the distant server. The distant server, however, MUST be a mediating agent of communication and MUST NOT be a destination of communication. Additional security constraints applied to SAFE Model * All script, or programmatic execution, that is to occur during the SAFE Model MUST occur only from code that resides locally on the distant server. Local is defined as the single operating system on which the single specific mail server executes or resides. Scripts or other programmatic code MUST NOT request, refer to, or source in any code that is not stored local to the executing server. * Any code specified to execute during the SAFE Model MUST reside as a new instance of the original code in a single 'sand-boxed' location so that other code is not executed by mistake and code is not open to security compromises as a result availability to a data transmission. * Communications that arise between the distant server and initial client in the SAFE Model MUST be considered temporary and private. The distant server MUST NOT pass communication received or generated from the SAFE Model to the distant client until except for the final terminating communication of the SAFE Model to the distant client. Cheney Standards Draft [Page 7] Internet-Draft SAFE Scripting Method August 2009 *It is RECOMMENDED that a separate email address be specified for a distant client that is present to receive maintenance and status data from the distant server. This is entended to ensure that there is no collusion of maintenance data and user communication. Maintenance data and other gathered data, such as statistics, MUST NOT be reported or generated with uniquely identifiable user information, content, or header data. Such data MAY be generated for internal reporting to the owner of the distant mail server and distant client if it cannot be matched against uniquely identifiable user data. * Communications sent from the distant server MUST be sent with the same MIME content type as the data received by the distant server from the initiating client. If this results in incompatibilities at the distant mail server the distant mail server MUST properly terminate the SAFE Model, but send an error report to the distant client instead of the intended communication. * The CA MUST NOT reside within the same domain as either the initiating client, the initiating client's direct mail server, the distant server, or the distant client. XMLSmtpPush object definition This programmatic object exists to allow script code to open a transmission path from a point of execution to a known addressable point independent of the communication details specified in either the tranmission header information or document specifications. This transmission path MUST be a unidirectional path from the agent of execution, typically the agent of execution would be the distant server of the SAFE Model, to the addressable provoking entity, which would typically be the initial client of the SAFE Model. This represents a fire and forget method of transport where the agent of execution sends data once and expects to never receive either a success or failure transmission status. The XMLSmtpPush object MUST NOT open a tranmission to any destination other than the provoking entity. The XMLSmtpPush object MUST retrieve data from the most recent document header specific in the markup language, if available, or if that is not available then from the packet header of the transmission protocol. If the header data is not understood, not defined, or not well-formed the data MAY be transported with RFC 5322 conformant headers. Data transmitted by this object using RFC 5322 conformant headers SHOULD NOT expect successful or accurate interaction with the intended document. Despite its name, the XMLSmtpPush object is not intended for limited implementation across the SMTP protocol only. The object is intended for functional operation across any protocol that conforms to the defined protocol requirements of RFC 5322, or compatible protocols, and its primitive models. Cheney Standards Draft [Page 8] Internet-Draft SAFE Scripting Method August 2009 XMLSmtpPush object methods abort() The abort() method stops the current request by closing the transmission path before any data is sent if the transmission path is opened and returns a value of "false". If a transmission path is not opened a value of "false" is returned. This method is required to occur at least once per open method. If this method does not occur to close an open method an error MUST be thrown. getHeaderDatagram() The getHeaderDatagram() method returns the header names and values in a JSON object or multidimensional array. If the document header cannot be detected or understood a value of null MUST be returned. getHeader("headername") This method returns the string value of a single specified header if the specified header exists, otherwise this method returns a value of null. open() The open method opens an asynchronous transmission path from the executing agent to the provoking entity. The open method MUST NOT send data. send(variable1,variable2,...) The send method MUST send data to the provoking entity. The send method MUST NOT open or prepare a transmission path, which is the function of the open method. This means a send method MUST execute only after an open method has executed. If a send method attempts to execute without a prior instantiated open method an error MUST be thrown. This granular strict functionality between the open and send methods is intended to provide script authors greater control of various different data sets to be sent while simultaneously reducing complexity derived from such granularity. The send method expects to receive instructions for altering a document and the new content that is to be provided, if any, where such instructions are stored in a function defined as a single named variable. Such a named function SHOULD be conservative in its instructions and liberal in its static content. The specified instructions MUST be expressed as DOM methods, XPath expressions, and/or the innerHTML method with anticipation that such instructions will be processed by the client without decisions or formatting onto the instructions, its content, or its perceived impact on the document. DOM instructions MUST be specific to the document received by the agent of execution, or they SHOULD expect to fail to execute at the provoking entity. Cheney Standards Draft [Page 9] Internet-Draft SAFE Scripting Method August 2009 Example of XMLSmtpPush object in JavaScript language assuming MML header var checkoutPage1 = function () { var safe, insta, instb, div = document.getElementById('content'), select = document.getElementById('selectlist').value, checkbox = document.getElementById('checkbox').checked, chkresponse = document.createElement('p'), slctresponse = document.createElement('p'), from = document.getElementByTagName('from')[0], replyto = from = document.getElementByTagName('reply-to')[0]; chkresponse.setAttribute('id', 'checkresponse'); chkresponse.textContent = "Text returned for checked checkbox"; slctresponse.setAttribute('id', 'selectresponse'); insta = function () { div.appendChild('chkresponse'); }; instb = function () { div.appendChild('slctresponse'); }; if (XMLSmtpPush) { safe = new XMLSmtpPush(); if (safe.getHeader('from').value !== undefined) { safe.open(getHeader(from).value); } else if (safe.getHeader('reply-to').value !== undefined) { safe.open(getHeader(replyto).value); } if (checkbox === true && select === "default") { safe.send(insta); } else if (checkbox === true && select === "first") { slctresponse.txtContent = "You selected the first option."; safe.send(insta, instb); } else if (checkbox === true && select === "second") { slctresponse.txtContent = "You selected the second option."; safe.send(insta, instb); } else if (checkbox === false && select === "first") { slctresponse.txtContent = "You selected the first option."; safe.send(instb); } else if (checkbox === false && select === "second") { slctresponse.txtContent = "You selected the second option."; safe.send(instb); } safe.abort(); return true; } else { return false; } }; Cheney Standards Draft [Page 10] Internet-Draft SAFE Scripting Method August 2009 Processing role of the client The client MUST be prepared to execute DOM instructions, XPath expressions, or the innerHTML method. Any other client-side script execution MUST NOT occur aside from meta-language parsing of a document only with regard to the appropriate meta language the markup language conforms to. The user MUST NOT be allowed to interfere with the processing of such instructions. If the user did not wish for such instructions to execute the user would not have voluntarily allowed execution of the SAFE Model. The intent is to remove security vulnerabilities associated with client-side code execution requests from a message by pushing those vulnerabilities onto a server not directly associated with the user. The user SHOULD be fully aware that data MAY be coming in as asynchronous updates and not new documents by convention of the SAFE Model. Security Client-side script execution is associated with the highest quantity of security vulnerabilities in computing. Eliminating client-side scripting on the web and instead using SAFE can nullify most of these problems making the internet a safer place. IANA Considerations This document contains no IANA considerations. References [ARCHITECTURE] Crocker D. "Internet Mail Architecture", RFC 5598, Brandenburg Internetworking, June 2009. [DOM] Wood L, Apparao V, Byrne S, Champion M, Isaacs S, Jacobs I, Le Hors A, Nicol G, Robie J, Sutor R, Wilson C, Sharpe P, Smith B, Sorensen J, Whitmer R. "Document Object Model (DOM) Level 1 Specification Version 1.0", W3C Recommendation, SoftQuad Inc., Netscape, Sun, ArborText, Microsoft, W3C, Inso EPS, Texcel Research, IBM, Novell, iMall, October 1998. [FORMAT] Resnick P. "Internet Message Format", RFC 5322, Qualcomm, October 2008. [IANA] Reynolds J "Assigned Numbers", STD 2, RFC 3232, January 2002. Cheney Standards Draft [Page 11] Internet-Draft SAFE Scripting Method August 2009 [JAVASCRIPT] Crockford D. "JavaScript: The Good Parts", Yahoo! Press and O'Reilly Media, May 2008. [Book] ECMA International. "Standard ECMA-262, ECMAScript Language Specification 3rd edition", December 1999. [JSON] Crockford D. "The application/json Media Type for JavaScript Object Notation (JSON)", RFC 4627, July 2006. [MIME] Freed N, Borenstein N. "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996. Freed N, Borenstein N. "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual, November 1996. Moore K. "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, University of Tennessee, November 1996. Nelson S, Parks C, Mitra. "The Model Primary Content Type for Multipurpose Internet Mail Extensions", RFC 2077, LLNL, NIST, WorldMaker, January 1997. Freed N, Klensin J. "Media Type Specifications and Registration Procedures", RFC 4288, Sun Microsystems, December 2005. Freed N, Klensin J. "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 4289, Sun Microsystems, December 2005. [MML] Cheney A. "Mail Markup Language", Internet Draft, April 2009. [SMTP] Klensin J. "Simple Mail Transfer Protocol", RFC 5321, October 2008. Cheney Standards Draft [Page 12] Internet-Draft SAFE Scripting Method August 2009 [W3C-XML-SCHEMA] Fallside D, Walmsley P. "XML Schema Part 0: Primer Second Edition", W3C Recommendation, IBM, October 2004. Walmsley P. "Definitive XML Schema", Prentice Hall, December 2001. [BOOK] [WAI-ARIA] Cooper M, Schwerdtfeger R, Seeman L, Pappas L. "Accessible Rich Internet Applications (WAI-ARIA) Version 1.0", W3C Working Draft, W3C, IBM, UB Access, Society for Technical Communication, August 2008. [WCAG] Caldwell B, Cooper M, Guarino R, Vanderheiden G. "Web Content Accessibility Guidelines 2.0", W3C Candidate Recommendation, University of Wisconsin-Madison, W3C, Google Inc., Trace R&D Center, April 2008. [XFORMS] Boyer J. "XForms 1.0 (Third Edition)", W3C Recommendation, IBM, October 2007. [XML] Bray T, Paoli J, Sperberg-McQueen C, Maler E, Yergeau, F. "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C Recommendation, Textuality, Microsoft, W3C, Sun, August 2006. [XHTML] Pemberton S, Austin D, Axelsson J, Celik T, Dominiak D, Elenbaas H, Epperson B, Ishikawa M, Matsui S, McCarron S, Navarro A, Peruvemba S, Relyea R, Schnitzenbaumer S, Start P. "XHTML 1.0 The Extensible HyperText Markup Language (Second Edition)", W3C Recommendation, CWI, W3C, Grainger, Opera Software, Microsoft, Openwave Systems, Philips Electronics, Netscape/AOL, Panasonic, Applied Testing and Technology, WebGeek Inc., Oracle, SAP, Sony Ericsson, August 2002. [XHTML2] Axelsson J, Birbeck M, Dubinko M, Epperson B, Ishikawa M, McCarron S, Navarro A, Pemberton S. "XHTML 2.0", W3C Working Draft, Opera Software, x-port.net, Websense, W3C, Applied Testing and Technology, WebGeek Inc., CWI, July 2006. Cheney Standards Draft [Page 13] Internet-Draft SAFE Scripting Method August 2009 Acknowledgements This work was inspired by the AJAX concept, the security vulernabilities of client side scripting on the WWW, and the potential implications of the Mail Markup Language (MML). Author's Address Austin Cheney User Interface Technologist, Travelocity 3150 Sabre Drive Southlake, TX 76092 PHONE: (682) 605-1000 EMAIL: austin.cheney@us.army.mil Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Expires February 1, 2010 Cheney Standards Track [Page 14]