<XENCRYPTED> March 2006
Lemonade
Internet Draft: XENCRYPTED S. H. Maes
Document: draft-maes-lemonade-xencrypted-01 R. Cromwell
(Editors)
Expires: September 2006 March 2006
XENCRYPTED
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).
Abstract
Some deployment models for Lemonade [LEMONADEPROFILE] may require a
non-pass-through proxy to fit OMA requirements. The proxy sits
between the client and the backend Lemonade server and executes
commands on behalf of the client, and rewriting some of the
responses. XENCRYPT introduces a new encrypted literal type that
allows the backend Lemonade server to end-to-end encrypt sensitive
Maes Expires – September 2006 [Page 1]
<XENCRYPTED> March 2006
data returned from the mail store, such as message bodies and
headers.
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].
An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocol(s) it
implements. An implementation that satisfies all the MUST or REQUIRED
level and all the SHOULD level requirements for a protocol is said to
be "unconditionally compliant" to that protocol; one that satisfies
all the MUST level requirements but not all the SHOULD level
requirements is said to be "conditionally compliant." When
describing the general syntax, some definitions are omitted as they
are defined in [RFC3501].
Table of Contents
Status of this Memo...............................................1
Copyright Notice..................................................1
Abstract..........................................................1
Conventions used in this document.................................2
Table of Contents.................................................2
1. Introduction...................................................2
2. The CAPABILITY Command.........................................3
3. XENCRYPTED literal.............................................3
4. Key Management / Provisioning..................................4
5. Formal Syntax..................................................4
Security Considerations...........................................4
References........................................................6
Future Work.......................................................7
Version History...................................................7
Acknowledgments...................................................7
Authors Addresses.................................................8
Intellectual Property Statement...................................8
Disclaimer of Validity............................................8
Copyright Statement...............................................9
Acknowledgement...................................................9
1.
Introduction
Maes Expires – September 2006 [Page 2]
<XENCRYPTED> March 2006
XENCRYPTED introduces a new encrypted literal type which allows a
Lemonade IMAP server to perform end-to-end encryption on selected
message attributes such as headers and body parts, as well as
allowing the client to encrypt selected literals.
XENCRYPTED is designed to lower some of the security risks inherent
in a proxy deployment model that are required by OMA and desired by
mobile operators. [MEMAIL][OMA-ME-RD]
2.
The CAPABILITY Command
Servers which support XENCRYPTED MUST return ‘XENCRYPTED’ in the
response list to a capability command followed ‘=’ and the algorithm
used.
Example: A LEMONADE server that implements XENCRYPTED
C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE XENCRYPTED=3DES
S: a001 OK CAPABILITY completed
3.
XENCRYPTED literal
To support selective encryption of any value returned in the
response, a new encrypted literal is introduced that parallels the
techniques used by IMAP [BINARY] literal and [LITERAL+] and is
designed to work in conjunction with them.
It is expected that untrusted users such as operator proxies will log
in on behalf of the user with separate credentials. A server which
recognizes an untrusted proxy user SHOULD encrypt all message
envelope data as well as body parts with encrypted literals. The
server must apply this rule even to [URLAUTH]/[BURL] requests.
Upon recognizing and encrypted literal, the client decodes the
literal according to content transfer encoding used, followed by
decryption decoding according to the algorithm specified in the
capability response.
If the client wishes to send an encrypted literal, such as during an
APPEND, it first encrypts the payload according to the encryption
method, and sends the literal with content transfer encoding of its
choice (8-bit or base64)
Example: logged in as authorization identity (user
john.smith+proxy), XENCRYPTED=3DES returned in CAPABILITY response
C: a1 FETCH 2 BINARY[1]
Maes Expires – September 2006 [Page 3]
<XENCRYPTED> March 2006
S: * 2 FETCH (BINARY[1] ~{X123}
S: …binary and encrypted with 3DES data…
S: )
C: a1 FETCH completed
4.
Key Management / Provisioning
The key used to encrypt data using algorithms such as 3DES or AES,
must be computed or provisioned into the device. If the client uses
SASL [RFC2222] to authenticate, then a session key should be computed
according to Section 2.4 of [RFC2831]. Otherwise, a key must be
provisioned via a mechanism which is out-of-band with respect to the
proxy server, either through an alternate TCP or HTTP mechanism, such
as a TLS or HTTPS connection, a secure SMS, or manually by user entry
of a shared secret.
The user’s password or shared secret with the server may also be used
to derive this key.
5.
Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation. Elements not defined here can be found in
the formal syntax of the [ABNF], [RFC3501], and [ABNFEXTEND].
The create ABNF grammar in [RFC3501] is hereby modified to the
grammar defined in [ABNFEXTEND]
literalx = “~{X“ number [“+”] “}“ CRLF *BINCHAR /
“{X” number [“+”] “}” CRLF base64
string =/ literalx
BINCHAR = <0x00 – 0xFF>
; encrypted data payload
; subject to RFC2630 Section 6.3 padding before encrypting
Security Considerations
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 network (e.g. enterprise). 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.
Maes Expires – September 2006 [Page 4]
<XENCRYPTED> March 2006
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.
If a server is implemented 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 email 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.
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.
XENCRYPTED is not intended to solve all of these problems, it is only
intended to solve the problem of information confidentiality for the
message store.
Untagged XENCRYPTED literals should be used in FETCH responses, which
contain encrypted message information to be passed through the
Lemonade proxy on the operator network.
The key exchange for encryption should not occur through the proxy
using any mechanism subject to man-in-the-middle attacks. If
necessarily, it can be done through another channel such as manually
entered by user (e.g. password), or via an out of band protocol, such
as an HTTP SSL request to the enterprise server or the key exchange
mechanism via outband notifications as proposed in [NOTIFICATIONS].
Any other additional server responses containing sensitive
information (passwords, etc.) should be XENCRYPTED.
Currently, the encrypted literals are subject to replay attacks
against the client, wherein the proxy may substitute actual server
returned encrypted literals with previously returned encrypted
literals, allowing the proxy to mix-and-match IMAP data, such as
attaching envelope parameters from one message onto body parts from
another, effectively spoofing and manipulating authorship. The risk
from this is deemed low, but future drafts may include protection
against replay, but incorporating more of SASL’s confidentiality and
integrity protection, only at the object level of literals, as
opposed to the entire stream.
Maes Expires – September 2006 [Page 5]
<XENCRYPTED> March 2006
It is beyond the scope of this document to define 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. A proxy implementation of transcoding
cannot be secured by XENCRYPTED, but it may be feasible in the future
to define an extension to allow the client to selectively choose
parts of the message that can be decrypted.
References
[BURL] Newman, C., "Message Composition", draft-ietf-lemonade-burl-xx
(work in progress).
[LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile",
draft-ietf-lemonade-profile-XX.txt, (work in progress).
[LITERAL+] Myers, J., "IMAP4 non-synchronizing literals", RFC 2088,
January 1997.
[MEMAIL] Maes, S.H., “Lemonade and Mobile e-mail", draft-maes-
lemonade-mobile-email-xx.txt, (work in progress).
[NOTIFICATIONS] Maes, S.H. , "Lemonade notifications and filters",
draft-ietf-lemonade-notifications-0x (work in progress).
[OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document,
(Work in progress). http://www.openmobilealliance.org/
[P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and
Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn
S-M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP
Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in
progress).
[RFC2119] Brader, S. "Keywords for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
http://www.ietf.org/rfc/rfc2119
[RFC2222] Myers, J. "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
http://www.ietf.org/rfc/rfc2222
[RFC2831] Leach, P., and Newman, C. "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000.
http://www.ietf.org/rfc/rfc2831
Maes Expires – September 2006 [Page 6]
<XENCRYPTED> March 2006
[RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol
Version 4 rev1", RFC 3501, March 2003.
http://www.ietf.org/rfc/rfc3501
[BINARY] Nerenberg, L. “IMAP4 Binary Content Extension”, RFC3516,
April 2003.
http://www.ietf.org/rfc/rfc3516
[URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) -
URLAUTH Extension", draft-ietf-lemonade-urlauth-08
(work in progress), October 2005.
Future Work
- Rationalize integrity and confidentiality mechanism with SASL
mechanism
- More rigorous enumeration and definition of out-of-band key
exchange mechanisms
- Mechanism to prohibit proxy from obtaining URLAUTHs except as those
specifically requested by client
- Client Selective reveal of data for transcoding
- Allow multiple encryption schemes? (CAPABILITY
XENCRYPTED=3DES,RC4,AES etc)
- Allow client to select preferred algorithm
- Enhanced security concerns section, dealing with proxy hiding
stronger encryption schemes
- MUST implements (3DES?)
Version History
Release 01
Add reference to block cipher padding mechanism used
Add initial key management recommendations
Release 00
Initial release published in February 2006
Acknowledgments
The following contributed to the authoring of XENCRYPTED.
The authors want to thank all who have contributed key insight and
extensively reviewed and discussed the concepts of LPSEARCH and its
early introduction P-IMAP [P-IMAP]. In particular, this includes the
authors of the P-IMAP draft: Rafiul Ahad – Oracle Corporation, Eugene
Chiu – Oracle Corporation, Ray Cromwell – Oracle Corporation, Jia-der
Day – Oracle Corporation, Vi Ha – Oracle Corporation, Wook-Hyun Jeong
– Samsung Electronics Co. LTF, Chang Kuang – Oracle Corporation,
Rodrigo Lima – Oracle Corporation, Stephane H. Maes – Oracle
Maes Expires – September 2006 [Page 7]
<XENCRYPTED> March 2006
Corporation, Gustaf Rosell - Sony Ericsson, Jean Sini – Symbol
Technologies, Sung-Mu Son – LG Electronics, Fan Xiaohui - CHINA
MOBILE COMMUNICATIONS CORPORATION (CMCC), Zhao Lijun - CHINA MOBILE
COMMUNICATIONS CORPORATION (CMCC).
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
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 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.
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.
Disclaimer of Validity
Maes Expires – September 2006 [Page 8]
<XENCRYPTED> March 2006
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.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Maes Expires – September 2006 [Page 9]