draft-ietf-opes-smtp-security-01.txt   draft-ietf-opes-smtp-security-02.txt 
Open Pluggable Edge Services M. Stecher Open Pluggable Edge Services M. Stecher
Internet-Draft Secure Computing Internet-Draft Secure Computing
Expires: March 26, 2007 September 22, 2006 Expires: June 18, 2007 December 15, 2006
Integrity, privacy and security in OPES for SMTP Integrity, privacy and security in OPES for SMTP
draft-ietf-opes-smtp-security-01 draft-ietf-opes-smtp-security-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 26, 2007. This Internet-Draft will expire on June 18, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The Open Pluggable Edge Services (OPES) framework is application The Open Pluggable Edge Services (OPES) framework is application
agnostic. Application specific adaptations extend that framework. agnostic. Application specific adaptations extend that framework.
Previous work has focussed on HTTP and work for SMTP is in progress. Previous work has focussed on HTTP and work for SMTP is in progress.
skipping to change at page 2, line 14 skipping to change at page 2, line 14
requirements that must be considered when creating the "SMTP requirements that must be considered when creating the "SMTP
adaptation with OPES" document. adaptation with OPES" document.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Differences between unidirectional and bidirectional 2.1 Differences between unidirectional and bidirectional
application protocols . . . . . . . . . . . . . . . . . . 4 application protocols . . . . . . . . . . . . . . . . . . 4
2.2 Non-standardized SMTP adaptations at SMTP gateways . . . . 4 2.2 Non-standardized SMTP adaptations at SMTP gateways . . . . 4
2.3 Non-OPES issues of SMTP . . . . . . . . . . . . . . . . . 4 2.3 Non-OPES issues of SMTP . . . . . . . . . . . . . . . . . 5
2.4 Opportunities of OPES/SMTP to address some issues . . . . 5 2.4 Opportunities of OPES/SMTP to address some issues . . . . 5
2.5 Limitations of OPES in regards to fixing SMTP issues . . . 5 2.5 Limitations of OPES in regards to fixing SMTP issues . . . 5
3. Integrity, privacy and security considerations . . . . . . . . 6 3. Integrity, privacy and security considerations . . . . . . . . 7
3.1 Tracing info in OPES/SMTP . . . . . . . . . . . . . . . . 6 3.1 Tracing info in OPES/SMTP . . . . . . . . . . . . . . . . 7
3.2 Bypass in OPES/SMTP . . . . . . . . . . . . . . . . . . . 6 3.2 Bypass in OPES/SMTP . . . . . . . . . . . . . . . . . . . 7
3.3 Compatibility with end-to-end encryption and signatures . 7 3.3 Compatibility with Cryptographic Protection Mechanisms . . 8
4. Protocol requirements for OPES/SMTP . . . . . . . . . . . . . 8 4. Protocol requirements for OPES/SMTP . . . . . . . . . . . . . 10
5. IAB Considerations for OPES/SMTP . . . . . . . . . . . . . . . 9 5. IAB Considerations for OPES/SMTP . . . . . . . . . . . . . . . 11
5.1 IAB Consideration (2.1) One-Party Consent . . . . . . . . 9 5.1 IAB Consideration (2.1) One-Party Consent . . . . . . . . 11
5.2 IAB Consideration (2.2) IP-Layer Communications . . . . . 9 5.2 IAB Consideration (2.2) IP-Layer Communications . . . . . 11
5.3 IAB Consideration (3.1) Notification . . . . . . . . . . . 9 5.3 IAB Consideration (3.1) Notification . . . . . . . . . . . 11
5.4 IAB Consideration (3.2) Notification . . . . . . . . . . . 9 5.4 IAB Consideration (3.2) Notification . . . . . . . . . . . 11
5.5 IAB Consideration (3.3) Non-Blocking . . . . . . . . . . . 10 5.5 IAB Consideration (3.3) Non-Blocking . . . . . . . . . . . 12
5.6 IAB Consideration Application Layer Addresses (4.x) . . . 10 5.6 IAB Consideration Application Layer Addresses (4.x) . . . 12
5.7 IAB Consideration (5.1) Privacy . . . . . . . . . . . . . 10 5.7 IAB Consideration (5.1) Privacy . . . . . . . . . . . . . 12
5.8 IAB Consideration Encryption . . . . . . . . . . . . . . . 11 5.8 IAB Consideration Encryption . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1 Normative References . . . . . . . . . . . . . . . . . . . 13 7.1 Normative References . . . . . . . . . . . . . . . . . . . 15
7.2 Informative References . . . . . . . . . . . . . . . . . . 13 7.2 Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 14 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . 18
1. Terminology 1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. When used with document are to be interpreted as described in [1]. When used with
the normative meanings, these keywords will be all uppercase. the normative meanings, these keywords will be all uppercase.
Occurrences of these words in lowercase comprise normal prose usage, Occurrences of these words in lowercase comprise normal prose usage,
with no normative implications. with no normative implications.
2. Introduction 2. Introduction
Because OPES is a protocol that is built over application layer
transports, its security may depend on the specifics of the
transport. OPES designs are guided by the IAB considerations for
OPES document [2], and those considerations are revisited here in the
context of the SMTP protocol.
2.1 Differences between unidirectional and bidirectional application 2.1 Differences between unidirectional and bidirectional application
protocols protocols
The IAB listed considerations for Open Pluggable Edge Services (OPES) The IAB listed considerations for Open Pluggable Edge Services (OPES)
in [2] and OPES treatment of those considerations has been discussed in [2] and OPES treatment of those considerations has been discussed
in [3]. Both documents make use of HTTP as an example for the in [3]. Both documents make use of HTTP as an example for the
underlying protocol in OPES flows, and focus on web protocols that underlying protocol in OPES flows, and focus on web protocols that
have requests and responses in the classic form (client sends a have requests and responses in the classic form (client sends a
request to a server that replies with a response of the same protocol request to a server that replies with a response of the same protocol
within a single protocol transaction). within a single protocol transaction).
skipping to change at page 7, line 5 skipping to change at page 8, line 5
and only send the recipient a block notification plus either a direct and only send the recipient a block notification plus either a direct
link, or a digest notification with the ability to retrieve the link, or a digest notification with the ability to retrieve the
original message from quarantaine. original message from quarantaine.
OPES MUST implement methods to request a bypass but there cannot be a OPES MUST implement methods to request a bypass but there cannot be a
guarantee that the bypass request will be approved. The security guarantee that the bypass request will be approved. The security
needs of the receiver or the receiver's network may demand that needs of the receiver or the receiver's network may demand that
certain filters must not by bypassed (such as virus scanners for certain filters must not by bypassed (such as virus scanners for
example). In general, the receiver should be able to configure a example). In general, the receiver should be able to configure a
client centric OPES system, i.e. the receiver should be able to client centric OPES system, i.e. the receiver should be able to
indicate if he/she wants to receive a non-OPES version if the OPES indicate if he/she wants to receive a non-OPES version if it is
service would result in rejection of the email. available.
Bypass requests could be added to the mail message or within the SMTP Bypass requests could be added to the mail message or within the SMTP
dialog. Bypass request data added to the mail message cannot bypass dialog. Bypass request data added to the mail message cannot bypass
OPES services that operate on other SMTP dialog commands, which are OPES services that operate on other SMTP dialog commands, which are
sent before the mail message has been received (such as RCPT sent before the mail message has been received (such as RCPT
commands). commands).
Bypass request data sent at the beginning of a SMTP dialog may not Bypass request data sent at the beginning of a SMTP dialog may not
reach the OPES system if intermediate SMTP relays do not support reach the OPES system if intermediate SMTP relays do not support
those bypass request commands and don't forward that information. those bypass request commands and don't forward that information.
3.3 Compatibility with end-to-end encryption and signatures 3.3 Compatibility with Cryptographic Protection Mechanisms
End-to-end email encryption is a proven technology, although the Cryptography can be used to assure message privacy, to authenticate
majority of mails are still sent unencrypted. Encrypting and signing the originator of messages, and to detect message modification.
email messages is done on the content of the mail and would be There are standard methods for achieving some or all these
transparent to SMTP. Encrypted mail messages can either be used to protections for generic messages ([9], [10], [11]), and these can be
prevent OPES systems from inspecting or modifying the content, or it used to protect SMTP data without changing the SMTP protocol.
can be used as an explicit approval to filter the mail by the OPES
system, if keys for decryption of the message are made available to
the OPES system. Signing of mails can be used to trace whether
content has been changed by intermediates.
There are security risks associated with storing cryptographic keys The content of encrypted mail messages cannot be inspected by OPES
systems because only the intended recipient has the information
necessary for decryption. The IAB and others have suggested that
users might want to share that information with OPES systems, thus
permitting decryption by intermediates. For most cryptographic
systems that are compatible with email, this would require end users
to share their most valuable keys, in essence their "identities",
with OPES machines. Some key management systems, particularly those
which have centralized administrative control of keys, might have
trust models in which such sharing would be sensible and secure.
Once having decrypted the message, if the OPES box modifies the
content, it would be faced with the task of re-encrypting it in order
to maintain some semblance of "end-to-end" privacy.
If OPES/SMTP had a way to interact with end users on a per message
basis, it might be possible to communicate cryptographic key
information from individual messages to end users, have them compute
the message encrypting key for particular message, and to send that
back to the OPES box. This would perhaps ameliorate the need to
share a user's "master" message decrypting key with the OPES box.
This kind of communication has not been defined for OPES.
Message protection systems generally include some message integrity
mechanisms by which recipient can check for message modification that
may have occurred after the sender released the message. This
protection can be applied to encrypted or plaintext messages and can
be accomplished through either symmetric or asymmetric cryptography.
In the case of symmetric cryptography, the key sharing problem is
exactly similar to the encryption case discussed previously. If the
OPES box modified the content, then the message integrity (or
authentication) code would have to be re-calculated and included with
the modified message.
For asymmetric cryptography the situation is more complicated. The
message integrity is tied to the sender's public key, and although
anyone who can get the sender's public key can also check for message
modification, no one but the sender can compute the sender's
signature on a modified message. Thus, an OPES system could not
modify messages and have them appear to come from the purported
sender. The notion of sharing the sender's signing key with the OPES
system is unpalatable, because few trust models would be compatible
with sharing digital identities across organization boundaries.
However, if the OPES system doing the modification were under the
control of the sender's local administration, the sharing might be
sensible (as discussed for decryption, above).
OPES/SMTP systems could present modified content showing the modified
regions in a form that permits authentication of the original message
and authentication of the OPES modifications (assuming the OPES box
had a digital signature identity and key). One method for doing this
is outlined in [12], but to our knowledge this method is not in any
standard.
There are security risks associated with sharing cryptographic keys
that must be addressed by implementors. Because this is not a simple that must be addressed by implementors. Because this is not a simple
task, it is only suggested as an option, not as a requirement for task, it is not a requirement for OPES/SMTP.
OPES/SMTP.
4. Protocol requirements for OPES/SMTP 4. Protocol requirements for OPES/SMTP
In addition to other documents listing requirements for OPES, the In addition to other documents listing requirements for OPES, the
discussion in this document implies specific requirements for discussion in this document implies specific requirements for
designing and implementing SMTP adaptations with OPES: designing and implementing SMTP adaptations with OPES:
o OPES Systems MUST add tracing headers to mail messages o OPES Systems MUST add tracing headers to mail messages
o If an email message that has been accepted by an OPES system o If an email message that has been accepted by an OPES system
skipping to change at page 12, line 11 skipping to change at page 14, line 11
the ends" [2]. the ends" [2].
This has been discussed in Section 3.3. This has been discussed in Section 3.3.
6. Security Considerations 6. Security Considerations
The document itself discusses security considerations of OPES/SMTP. The document itself discusses security considerations of OPES/SMTP.
General security threats of OPES are described in Security Threats General security threats of OPES are described in Security Threats
for OPES [8] for OPES [8]
Section 3.3 (about compatibility with end-to-end encryption) mentions Section 3.3 (about compatibility with cryptographic protection
that an OPES system could be approved to inspect encrypted mails by mechanisms) mentions that an OPES system could eventually deal with
making keys available for decryption. It must be noted that an cryptographic keys. This raises security issues (such as
implementation of the decryption key handling raises security issues availability and storage of cryptographic keys) that must be
(such as availability and storage of cryptographic keys) that must be
addressed by the implementer. addressed by the implementer.
7. References 7. References
7.1 Normative References 7.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy
skipping to change at page 13, line 31 skipping to change at page 15, line 31
[4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001. April 2001.
[5] Rousskov, A. and M. Stecher, "HTTP Adaptation with Open [5] Rousskov, A. and M. Stecher, "HTTP Adaptation with Open
Pluggable Edge Services (OPES)", RFC 4236, November 2005. Pluggable Edge Services (OPES)", RFC 4236, November 2005.
[6] Stecher, M. and A. Barbir, "Open Pluggable Edge Services (OPES) [6] Stecher, M. and A. Barbir, "Open Pluggable Edge Services (OPES)
SMTP Use Cases", RFC 4496, May 2006. SMTP Use Cases", RFC 4496, May 2006.
[7] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An [7] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An
Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, Architecture for Open Pluggable Edge Services (OPES)",
August 2004. RFC 3835, August 2004.
[8] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. [8] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H.
Orman, "Security Threats and Risks for Open Pluggable Edge Orman, "Security Threats and Risks for Open Pluggable Edge
Services (OPES)", RFC 3837, August 2004. Services (OPES)", RFC 3837, August 2004.
[9] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME
Security with OpenPGP", RFC 3156, August 2001.
[10] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004.
[11] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002.
[12] Orman, H., "Data Integrity for Mildly Active Content",
Proceedings of the Third Annual International Workshop on
Active Middleware Services p.73, August 2001.
Author's Address Author's Address
Martin Stecher Martin Stecher
Secure Computing Corporation Secure Computing Corporation
Vattmannstr. 3 Vattmannstr. 3
33100 Paderborn 33100 Paderborn
Germany Germany
Email: martin.stecher@webwasher.com Email: martin.stecher@webwasher.com
URI: http://www.securecomputing.com/ URI: http://www.securecomputing.com/
Appendix A. Acknowledgements
Many thanks to everybody who provided input and feedback for this
document. Very special thanks to Hilarie Orman for her input and
suggestions, especially for the content of Section 3.3 (about
compatibility with cryptographic protection mechanisms).
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 15 change blocks. 
46 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/