February 2005 Lemonade Internet Draft: Challenges of Intermediaries S. H. Maes Document: draft-smaes-lemonade-intermediary- D. Crocker challenges-01.txt Expires: August 2005 February 2005 Lemonade and the challenges of Intermediaries Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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 become aware will be disclosed, in accordance with RFC 3668. 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 This document discusses some of the issues posed by firewalls and other intermediaries to deployment of some basic IETF technologies. The intent of this document is to track such issues, explore possible approaches elegant or not that have been proposed so far to address them and initiate discussion on how such issues should be appropriately addressed by IETF. This first version 00 is provided to initiate discussion. Most of the content should be considered as initial place holders. Conventions used in this document Maes Expires - August 2005 [Page 1] February 2005 In examples, "C:" and "S:" indicate lines sent by the client 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]. Table of Contents Status of this Memo...............................................1 Abstract..........................................................1 Conventions used in this document.................................1 Table of Contents.................................................2 1. Introduction...................................................2 2. Description of the problem.....................................3 2.1. Mobile e-mail with IMAP4, POP3 and SMTP...................3 2.2. Lemonade..................................................4 2.3. Some challenges met with P-IMAP...........................4 2.3.1. HTTP / HTTPS firewalls...............................4 2.3.2. Time-outs............................................4 2.3.3. Deployment challenges................................5 3. Analysis.......................................................5 4. Initial considerations: A wish list for Lemonade...............5 Security Considerations...........................................6 References........................................................6 Version History...................................................6 Acknowledgments...................................................6 Authors Addresses.................................................7 Intellectual Property Statement...................................7 Full Copyright Statement..........................................7 1. Introduction Lemonade provides enhancements to Internet email to support diverse service environments. As discussions started to understand broader challenges of e-mail, the case of mobile e-mail was discussed. This discussion found at [MEMAIL]. In that document, it was pointed out that numbers of (mobile) e-mail deployment based on existing IETF specifications are not usable or encounter difficulties because the protocols often can not traverse firewalls with constrained settings (e.g. only allow HTTP or HTTPS). Maes Expires - August 2005 [Page 2] February 2005 In addition, many intermediaries found in mobile deployments between clients and servers are often set with limited timeout for pinholes, sessions etc... 2. Description of the problem 2.1. Mobile e-mail with IMAP4, POP3 and SMTP Following the analysis presented in [MEMAIL], a typical context for mobile users trying to access their e-mail is the following: - The user is on a mobile network, using a mobile device - The mobile device presents limitations in terms of the type of software / client that it can run - The device has limited resource capabilities and in particular is constrained by consideration on its battery life - The network provided by one or multiple service providers (operator) may present additional constraints, unreliability or other typical mobile behavior. - In general traffic is expensive. - The e-mail server is located in a corporation, behind a firewall. - The corporation has issued strict security and usage guidelines. - Multiple intermediaries and firewalls may exist between the mobile server and the corporate domain. Accordingly, users are often reduced to using the available e-mail clients on the mobile device (e.g. POP3 or IMAP4 and SMTP). For the sake of argument, let us assume that he or she uses a IMAP4/SMTP e-mail client. In order to receive and send e-mail, while satisfying its corporate guidelines, the user must be able to connect via IMAP4 and SMTP to its corporate server. We have observed the following challenges: - Some corporations guidelines prevent open in the firewall the ports used by IMAP 4 or SMTP, therefore preventing the user to access his or her e-mail just using this code. - Some corporations rightfully forbid using these protocols outside of secure connections (e.g. TLS, VPN). More and more often, mobile device support TLS [RFC2246], not necessarily the latest version. We have observed the following challenges: - Some corporation guidelines prevent open in the firewall the ports used by IMAP 4 over TLS or SMTP over TLS, therefore preventing the user to access his or her e-mail. As a result only user equipped with VPN clients compatible with their corporate VPN will be able to access their e-mail. Unfortunately, VPN clients on mobile devices are still rare. Installation on mobile Maes Expires - August 2005 [Page 3] February 2005 device is difficult if not often impossible. As a result employees of corporation that use customized VPN clients are totally unable to use their IMAP4 / SMTP client to access e-mail. Note also that even when using VPN, drops of connectivity, time outs of the intermediaries etc ... often disconnect the VPN. This is expensive and inefficient, especially if this forces applications like e-mail to re-send the same data multiple times. As corporation guidelines also prevent VPN automatic reconnect and password saving on the mobile device, users are rapidly very frustrated. The only user friendly and viable solutions to access corporate e- mail that remain are typically based on proprietary solutions available only on particular devices and network and compatible only with certain e-mail servers. These are typically costly, not widely available to most users. They establish their own secure reliable channel with push capability between the client and the device, sometimes involving network specific intermediaries (E.g. NOC û Network Operating Center). Proposals like Push IMAP [P-IMAP] attempt to address this with a more open standard oriented approach. 2.2. Lemonade Time outs of intermediaries are one of the fact or that contribute to the frequent losses of connectivity of mobile devices. In order to more efficiently address these issues with e-mail, and assuming that the firewall issue is not an issue, Lemonade introduced it its profile [LEMONADE] a quick reconnect scheme [RECONNECT]. 2.3. Some challenges met with P-IMAP 2.3.1. HTTP / HTTPS firewalls Among the solutions to address the firewall issues, Push_IMAP [P- IMAP], describes and allows binding to HTTP [RFC2616] as a possible option. P-IMAP proposes also mechanisms to handle losses of connections. However time-out and intermediaries still lead to challenges. 2.3.2. Time-outs For example, use of HTTP long live session / chunk encoding ([RFC2616]) described in [P-IMAP] to support exchange of asynchronous events from the server to the client; while technically sound, in practice does not work very well if intermediaries time-out too rapidly. It is very difficult to assess such time out in general. Maes Expires - August 2005 [Page 4] February 2005 2.3.3. Deployment challenges In general intermediaries also introduce additional security threats, especially if they perform protocol transformations while located across domains of trust. When such intermediaries are used across domains, it is possible that additional application level confidentiality, integrity and signature mechanisms must be introduced. In P-IMAP for example, emails and notification may be encrypted at the e-mail application level. Of course using SMIME [RFC2633] is another viable approach. << EditorÆs note: Add any additional discussions, examples...>> 3. Analysis Based on the examples discussed above, it seems clear that while there may not be any conceptual or design problem with the core protocol involved, there are issues with using them in real life deployments. In particular, it seems that we need to better understand: - How to deal with the issues posed by intermediaries? - How to appropriately separate the role of lower layers versus application level to provide transport and security when intermediaries are involved and such problems are met. At this stage, this may involve the design of IETF protocols, guidelines for implementation and deployment of these protocols and guidelines for implementation and deployments of intermediaries and in particular firewalls. Note also that the Lemonade discussions on traffic compression for (mobile e-mail) may also warrant compression in such discussions. 4. Initial considerations: A wish list for Lemonade << EditorÆs note: This section is expected to contain a discussion of what lemonade would like to see addressed. As a first stab this may include the following.>> We propose to collect feedback and to study feasibility and appropriateness of defining: - Ways to deal at the transport level with firewalls with constrained settings. - Ways to deal at the transport level with implementation or deployment based time-outs; even if no such time outs are built in the underlying protocols. - Ways or guidelines to perform some of these functions at the application level, when there are no transport level viable approach Maes Expires - August 2005 [Page 5] February 2005 and when it is judged that this does not warrant changes at the transport level or below. - Guidelines for implementation and deployement of intermediaries to mitigate the issues identified in this document. Security Considerations Security considerations are discussed throughout section 2 with respect to firewalls, confidentiality, integrity and the risk posed by intermediaries. << EditorÆs note: More to be added as document expands.>> References [LEMONADE] Maes, S.H. and Melnikov, A., "Lemonade Profile", draft- ietf-lemonade-profile-xx.txt,(work in progress) [MEMAIL] Maes, S.H., ôLemonade and Mobile e-mail", draft-maes- lemonade-mobile-email-xx.txt, (work in progress). [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and Chiu, E., Day, J. and Sini, J., "Push Extensions to the IMAP Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in progress). [RECONNECT] Melnikov, A. and C. Wilson, "IMAP4 extension for quick reconnect", draft-ietf-lemonade-reconnect-XX.txt, work in progress). [RFC2246] Dierks, T. et al., "The TLS Protocol", version 1.0 RFC2246, January 1999. ftp://ftp.ietf.org/rfc/rfc2246.txt [RFC2616] Fielding, R. et al. "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. http://www.ietf.org/rfc/rfc2616 [RFC2633] Ramsdell, B. et al., "S/MIME Version 3 Message Specification", RFC2633, June 1999. http://www.ietf.org/rfc/rfc2633.txt. Version History Revision 01: [1] Editorial fixes. Acknowledgments Maes Expires - August 2005 [Page 6] February 2005 This document is based on the discussions that took place within the Lemonade working group. Authors Addresses Stephane H. Maes Oracle Corporation 500 Oracle Parkway M/S 4op634 Redwood Shores, CA 94065 USA Phone: +1-650-607-6296 Email: stephane.maes@oracle.com Dave Crocker <> 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 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Full Copyright Statement Maes Expires - August 2005 [Page 7] February 2005 Copyright (C) The Internet Society 2004. 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 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 - August 2005 [Page 8]