Internet Draft: Deployment Considerations for lemonade-compliant Mobile Email R. Gellens Document: draft-ietf-lemonade-deployments-00.txt Qualcomm Expires: August 2006 February 2005 Deployment Considerations for lemonade-compliant Mobile Email 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. Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract This document discusses deployment issues and describes implicit requirements for successful deployment of mobile email based on the IETF lemonade documents. Gellens [Page 1] Expires August 2006 Internet Draft Lemonade Deployment Considerations February 2006 Table of Contents 1 Conventions Used in this Document . . . . . . . . . . . . . . 2 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 4 TCP Connections . . . . . . . . . . . . . . . . . . . . . . . 3 4.1 Lifetime . . . . . . . . . . . . . . . . . . . . . . . . 3 4.2 Maintenance during temporary transport loss . . . . . . . 3 5 Dormancy . . . . . . . . . . . . . . . . . . . . . . . . . . 3 6 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7 Security Considerations . . . . . . . . . . . . . . . . . . . 4 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 10 Normative References . . . . . . . . . . . . . . . . . . . . . 6 11 Informative References . . . . . . . . . . . . . . . . . . . 6 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property Statement . . . . . . . . . . . . . . . 6 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7 1 Conventions Used in this Document The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 2 Introduction The IETF lemonade group has developed a set of extensions to IMAP and Message Submission, along with a profile document which restricts server behavior and describes client usage [PROFILE]. Successful deployment of lemonade-compliant mobile email requires additional functionality, which is generally assumed and hence often not covered in email RFCs. This document describes some of these additional considerations, with a focus on those which have been reported to be problematic. 3 Ports Both IMAP and Message Submission have been assigned well-known ports [IANA] which MUST be available. IMAP uses port 143. Message Submission uses port 587. It is REQUIRED that the client be able to contact the server on these ports. Hence the client and server systems, as well as any intermediary systems, MUST allow communication on these ports. Gellens [Page 2] Expires August 2006 Internet Draft Lemonade Deployment Considerations February 2006 In addition to communications between the client and server systems, lemonade forward-without-download requires that the Message Submission server be able to establish a TCP connection to the IMAP server. Unless specially configured, this uses port 143. It should be noted that systems which don't support TCP on arbitrary ports aren't full Internet clients. As a result, such systems must use gateways to the Internet which necessarily result in data integrity problems. 4 TCP Connections Both IMAP and Message Submission use TCP. Hence the client system MUST be able to establish and maintain TCP connections to these servers. The Message Submission server MUST be able to initiate a connection to the IMAP server. 4.1 Lifetime The duration of the TCP connections between the client and server systems for both IMAP and Message Submission can be arbitrarily long. The client system, the server, as well as all intermediate systems MUST NOT terminate these TCP connections simply because of their duration. Both protocols do permit application-level timeouts if no data is received within a period of time, under the control of the server. However, it has been reported that some mobile carrier network infrastructure elements impose time restrictions of their own on TCP connections other than HTTP. Such behavior is harmful to mobile email and all other TCP-based protocols. It is unclear how widespread such reported behavior is, or if it is an accidental consequence of an attempt at optimizing for HTTP traffic or a deliberate choice. Either way, such a barrier to TCP connections is a significant risk to the increasing usage of IETF protocols on mobile networks. 4.2 Maintenance during temporary transport loss TCP is designed to withstand temporary loss of lower-level connectivity. Such transient loss is not uncommon in mobile systems (for example, due to handoffs, fade, etc.). The TCP connection SHOULD be able to survive temporary lower-level loss when the IP address of the client does not change (for example, short-duration loss of the mobile device's traffic channel). Thus, the TCP/IP stack on the client, the server, and any intermediate systems SHOULD maintain the TCP connection during transient loss of connectivity. Gellens [Page 3] Expires August 2006 Internet Draft Lemonade Deployment Considerations February 2006 5 Dormancy Some mobile devices and networks support dormant mode, where the traffic channel is brought down during idle periods, yet the PPP or equivalent level remains active, and the mobile retains its IP address. Maintenance of TCP connections during dormancy SHOULD be supported by the client, server, and any intermediate systems. 6 Firewalls One or more firewalls might exist in the path between the client and server systems, as well as between the Message Submission and IMAP servers. Proper deployment REQUIRES that TCP connections be possible from the client system to the IMAP and Message Submission ports on the servers, as well as from the Message Submission server to the IMAP server. This may require configuring firewalls to permit such usage. Firewalls deployed in the network path MUST conform to [FIREWALLS]. Application proxies, which are a not uncommon mechanism, are discussed in [PROXIES]. 7 Security Considerations There are numerous security considerations whenever an organization chooses to make any of its services available via the Internet. This includes email from mobile clients. Sites concerned about email security should perform a threat analysis, get relevant defenses and/or insurance in place and then make a conscious decision to open up this service. Piggybacking email traffic on the HTTP port in an attempt to avoid firewall configuration explicitly permitting mobile email connections would bypass this important step and reduces the overall security of the system. Organizations might wish to purchase a messaging server which comes with some indemnity and/or a messaging server which is used "on the edge" by the organization that sells the server. This document does not attempt to catalogue either the various risks an organization might face or the numerous techniques which can be used to protect against the risks. However, to help illustrate the deployment considerations, a very small sample of some of the risks and countermeasures appear below. Gellens [Page 4] Expires August 2006 Internet Draft Lemonade Deployment Considerations February 2006 Some organizations are concerned that permitting direct access to their mail servers via the Internet increases their vulnerability, since a successful exploit against a mail server can potentially expose all mail and authentication credentials stored on that server, and can serve as an injection point for spam. In addition, there are concerns over eavesdropping or modification of mail data and authentication credentials. There exist a large number of approaches which can mitigate the risks while allowing access to mail services via mobile clients. Placing servers inside one or more DMZs can protect the rest of the network from a compromised server. An additional way to reduce the risk is to store authentication credentials on a system which is not accessible from the Internet, and which the servers within the DMZ can access only by sending the credentials as received from the client and receiving an authorized/not authorized response. Many additional techniques for further isolation exist, such as having the DMZ IMAP server have no mail store of its own. When a client connects to such a server, the DMZ IMAP server might contact the authentication server and receive a ticket, which it passes to the mail store in order to access the client's mail. In this way a compromised IMAP server cannot be used to access the mail or credentials for other users. It is important to realize that simply throwing an extra box in front of the mail servers, such as a gateway which may use HTTP or any of a number of synchronization protocols to communicate with clients, does not itself change the security aspects. By adding such a gateway, the overall security of the system, and the vulnerability of the mail servers, may remain unchanged or may be significantly degraded. Isolation and indirection can be used to protect against specific risks, but to be effective, such steps need to be done after a threat analysis, and with understanding of the issues involved. Organizations SHOULD deploy servers which support the use of TLS for all connections and which can be optionally configured to require TLS. When TLS is used, it SHOULD be via the STARTTLS extensions rather than the alternate port method. TLS can be an effective measure to protect against specific threats, including eavesdropping and alteration, of the traffic between the end-points. However, just because TLS is deployed does not mean the system is "secure." 8 IANA Considerations Gellens [Page 5] Expires August 2006 Internet Draft Lemonade Deployment Considerations February 2006 None. 9 Acknowledgments Chris Newman suggested very helpful text. 10 Normative References [IANA] [PROFILE] draft-ietf-lemonade-profile 11 Informative References [FIREWALLS] RFC 2979 [PROXIES] RFC 1919 12 Author's Address Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121 randy@qualcomm.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. Gellens [Page 6] Expires August 2006 Internet Draft Lemonade Deployment Considerations February 2006 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 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 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Gellens [Page 7] Expires August 2006