Internet DRAFT - draft-maes-lemonade-xencrypted
draft-maes-lemonade-xencrypted
<ENCRYPTION AND PROXY DEPLOYMENTS> 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]
<ENCRYPTION AND PROXY DEPLOYMENTS> 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]
<ENCRYPTION AND PROXY DEPLOYMENTS> 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]
<ENCRYPTION AND PROXY DEPLOYMENTS> 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]
<ENCRYPTION AND PROXY DEPLOYMENTS> 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
<<Editor’s note: to be done>>
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
<<TDB>>
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]
<ENCRYPTION AND PROXY DEPLOYMENTS> 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]
<ENCRYPTION AND PROXY DEPLOYMENTS> 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]
