June 2006 Lemonade Internet Draft: ENCRYPTION AND PROXY DEPLOYMENTS S. H. Maes Document: draft-maes-lemonade-xencrypted-02 R. Cromwell Eds. Expires: December 2006 June 2006 Security considerations for Lemonade Proxy Deployments Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. Abstract Some deployment models in mobile operator markets depend on deployment of an IMAP proxy server in the operator network. This document discusses security considerations of such an approach and provides recommendations. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. 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 [RFC2119]. Maes [Page 1]  June 2006 When describing the general syntax, some definitions are omitted as they are defined in [RFC3501]. Table of Contents Status of this Memo .......................................... 1 Abstract...................................................... 1 Conventions used in this document............................. 1 Table of Contents............................................. 2 1. Introduction............................................ 2 2. Lemonade Proxy.......................................... 2 2.1. Definitions......................................... 2 2.2. Description of the challenges....................... 3 3. Recommendations......................................... 3 3.1. Guidelines.......................................... 3 3.2. Object level encryption across domain............... 3 4. Message content processing on proxy..................... 4 5. Security Considerations................................. 4 Normative References.......................................... 4 Future Work................................................... 5 Version History............................................... 5 Acknowledgments............................................... 5 Authors Addresses............................................. 5 Intellectual Property Statement............................... 6 Full Copyright Statement...................................... 6 1. Introduction In some proxy deployments, the client may connect to a proxy that sits in an operator network, but the backend email storage server sits in a separate enterprise network. The enterprise network is assumed to be secure, but the operator network may not be trusted. If unencrypted information lies in the operator network, that information is vulnerable to attacks. 2. Lemonade Proxy 2.1. Definitions A Lemonade proxy is defined as an intermediary that proxies (i.e. re- directs or performs) some of the Lemonade IMAP store or Lemonade Submit server functions ahead of another Lemonade IMAP store or Lemonade Submit server. See [LEMONADEPRFILEBIS] for some examples of such situations. In a particular implementation or deployment, the functions interwork and do not negatively interfere (i.e. unnecessarily or incorrectly Maes Expires – December 2006 [Page 2]  June 2006 overlapping). The components are aware of each others and mutually complementing each others when needed. 2.2. Description of the challenges If no operator specific enhancements are being added by an operator proxy, then an SSL pass-through proxy with SASL authentication is a far lower risk and is the best current practice. If a Lemonade server is implemented as a backend IMAP server with additional command processing done on the proxy, there are more complex security issues. This proxy must be able to send commands to the backend server to accomplish its tasks, as well as read information coming from the backend server. An attacker who compromises the proxy thus can send commands to the backend to change the state of the mail storage, possibly corrupting it. In addition, it can read responses from the mail server that might contain confidential email information. This proxy may also send bogus responses back to the client. Clearly, this setup is not ideal and exposes numerous risks, and is thus not recommended if it can be avoided. In addition, if an SMTP proxy is used, the SMTP proxy may, in collusion with the IMAP proxy, create a URLAUTH for any message it wishes to steal, and then use BURL+SMTP to forward messages to an outside mailbox of its choice. 3. Recommendations 3.1. Guidelines This draft recommends that in such deployment cases, precautions be taken to avoid leakage of confidential data in the message store. It may be difficult to avoid traffic analysis of envelope data, but steps can be taken by the deployment and the end users to reduce the risk of message content itself being intercepted. All users are recommended to use a secure end-to-end message encryption in such deployments, such as S/MIME. An enterprise or other IMAP service provider using such a deployment model in concert with an operator should recommend this to all of its users, and help provide provisioning of S/MIME, OpenPGP or another secure end-to-end messaging service. Clients should support one of these mechanisms. 3.2. Object level encryption across domain An IMAP provider, enterprise, or other organization may also wish to provide end-to-end encryption for users in cases where the sender is Maes Expires – December 2006 [Page 3]  June 2006 not using S/MIME, OpenPGP or another mechanism. It is recommended that such a server be designed to implement S/MIME or OpenPGP transcoding (e.g. the same way that transcoding is done when requested via [CONVERT]), such that when a client issues an IMAP FETCH BODY, the IMAP server will convert the body part on the fly into an S/MIME or OpenPGP mime-type. Servers will also need a way for clients to provision their public keys with the server. On the outband channel, when using APPEND, clients may wish to use end-to-end encryption to communicate with the server. Clients may encrypt messages they are appending to the server using the server's public key and a suitable format like S/MIME or OpenPGP. Note that this may be tricky when using CATENATE. 4. Message content processing on proxy When the proxy is expected to perform actual processing and transformation of message content (e.g. transcoding as described in [CONVERT]), additional challenges arise as this would require that the proxy be able to access the message in clear. It is beyond the scope of this document to detail the implementation of transcoding services. In general, it is recommended that they reside within the same domain as the IMAP server, and are not performed by third party services, which may compromise the privacy of the data being transcoded. So even in presence of proxy, such function should rather be performed in the domain of the email server. Note that a proxy implementation of transcoding (and other manipulations) requires a mechanism that allows the client or server to one-time reveal session keys used to decrypt the body part. Another workable approach is to implement a secure proxies and allow decryption and re-encryption of the messages by the proxies. Besides requiring secure implementation, this implies a need for trusted proxies. 5. Security Considerations This draft discusses security implications, issues and recommendations when using Lemonade proxies. Normative References {CONVERT] Maes, S.H., Cromwell R., "CONVERT", draft-ietf-lemonade- convert-xx.txt, (work in progress). Maes Expires – December 2006 [Page 4]  June 2006 [LEMONADEPROFILEBIS] Maes, S.H., Melnikov A. and D. Cridland, " LEMONADE profile bis", draft-ietf-lemonade-profile-bis-xx.txt, (work in progress). [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 Informative References <> Future Work [1] Detail the options and recommendations [2] Detail select encryption algorithms [3] Detail key exchange mechanisms. [4] Detail dealing with notifications [5] Detail the analysis of message processing in the proxy. Version History Release 02 Rewritten to describe the problem of proxies and recommend using existing object level encryption methods Add deployment recommendations when using proxies Release 01 Add reference to block cipher padding mechanism used Add initial key management recommendations Release 00 Initial release published in February 2006 Acknowledgments <> Authors Addresses Stephane H. Maes Oracle Corporation 500 Oracle Parkway M/S 4op634 Redwood Shores, CA 94065 USA Phone: +1-650-607-6296 Maes Expires – December 2006 [Page 5]  June 2006 Email: stephane.maes@oracle.com Ray Cromwell Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Intellectual Property Statement 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 of the 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 implementers 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE Maes Expires – December 2006 [Page 6]  June 2006 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 assigns. Maes Expires – December 2006 [Page 7]