< draft-ietf-opes-smtp-security-02.txt   draft-ietf-opes-smtp-security-03.txt >
Open Pluggable Edge Services M. Stecher Open Pluggable Edge Services M. Stecher
Internet-Draft Secure Computing Internet-Draft Secure Computing
Expires: June 18, 2007 December 15, 2006 Expires: August 7, 2007 February 3, 2007
Integrity, privacy and security in OPES for SMTP Integrity, privacy and security in OPES for SMTP
draft-ietf-opes-smtp-security-02 draft-ietf-opes-smtp-security-03
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 June 18, 2007. This Internet-Draft will expire on August 7, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 focused on HTTP and work for SMTP is in progress.
These protocols differ fundamentally in the way data flows and it These protocols differ fundamentally in the way data flows and it
turns out that existing OPES requirements and IAB considerations for turns out that existing OPES requirements and IAB considerations for
OPES need to be reviewed with regards to how well they fit for SMTP OPES need to be reviewed with regards to how well they fit for SMTP
adaptation. This document analysis aspects about the integrity of adaptation. This document analyzes aspects about the integrity of
SMTP and mail message adaptation by OPES systems and privacy and SMTP and mail message adaptation by OPES systems and privacy and
security issues when the OPES framework is adapted to SMTP and lists security issues when the OPES framework is adapted to SMTP and lists
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.
The intent of this document is to capture this information before the
current OPES working group shuts down. This is to provide input for
subsequent working groups or individual contributors that may pick up
the OPES/SMTP work at a later date.
Table of Contents Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Differences between unidirectional and bidirectional 2.1. Differences between unidirectional and bidirectional
application protocols . . . . . . . . . . . . . . . . . . 4 application protocols . . . . . . . . . . . . . . . . . . 5
2.2 Non-standardized SMTP adaptations at SMTP gateways . . . . 4 2.2. Non-standardized SMTP adaptations at SMTP gateways . . . . 5
2.3 Non-OPES issues of SMTP . . . . . . . . . . . . . . . . . 5 2.3. Non-OPES issues of SMTP . . . . . . . . . . . . . . . . . 6
2.4 Opportunities of OPES/SMTP to address some issues . . . . 5 2.4. Opportunities of OPES/SMTP to address some issues . . . . 6
2.5 Limitations of OPES in regards to fixing SMTP issues . . . 5 2.5. Limitations of OPES in regards to fixing SMTP issues . . . 6
3. Integrity, privacy and security considerations . . . . . . . . 7 3. Integrity, privacy and security considerations . . . . . . . . 8
3.1 Tracing info in OPES/SMTP . . . . . . . . . . . . . . . . 7 3.1. Tracing info in OPES/SMTP . . . . . . . . . . . . . . . . 8
3.2 Bypass in OPES/SMTP . . . . . . . . . . . . . . . . . . . 7 3.2. Bypass in OPES/SMTP . . . . . . . . . . . . . . . . . . . 8
3.3 Compatibility with Cryptographic Protection Mechanisms . . 8 3.3. Compatibility with Cryptographic Protection Mechanisms . . 9
4. Protocol requirements for OPES/SMTP . . . . . . . . . . . . . 10 4. Protocol requirements for OPES/SMTP . . . . . . . . . . . . . 12
5. IAB Considerations for OPES/SMTP . . . . . . . . . . . . . . . 11 5. IAB Considerations for OPES/SMTP . . . . . . . . . . . . . . . 13
5.1 IAB Consideration (2.1) One-Party Consent . . . . . . . . 11 5.1. IAB Consideration (2.1) One-Party Consent . . . . . . . . 13
5.2 IAB Consideration (2.2) IP-Layer Communications . . . . . 11 5.2. IAB Consideration (2.2) IP-Layer Communications . . . . . 13
5.3 IAB Consideration (3.1) Notification . . . . . . . . . . . 11 5.3. IAB Consideration (3.1) Notification . . . . . . . . . . . 13
5.4 IAB Consideration (3.2) Notification . . . . . . . . . . . 11 5.4. IAB Consideration (3.2) Notification . . . . . . . . . . . 13
5.5 IAB Consideration (3.3) Non-Blocking . . . . . . . . . . . 12 5.5. IAB Consideration (3.3) Non-Blocking . . . . . . . . . . . 14
5.6 IAB Consideration Application Layer Addresses (4.x) . . . 12 5.6. IAB Consideration Application Layer Addresses (4.x) . . . 14
5.7 IAB Consideration (5.1) Privacy . . . . . . . . . . . . . 12 5.7. IAB Consideration (5.1) Privacy . . . . . . . . . . . . . 14
5.8 IAB Consideration Encryption . . . . . . . . . . . . . . . 13 5.8. IAB Consideration Encryption . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.1 Normative References . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2 Informative References . . . . . . . . . . . . . . . . . . 15 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
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 Because OPES is a protocol that is built over application layer
transports, its security may depend on the specifics of the transports, its security may depend on the specifics of the
transport. OPES designs are guided by the IAB considerations for transport. OPES designs are guided by the IAB considerations for
OPES document [2], and those considerations are revisited here in the OPES document [2], and those considerations are revisited here in the
context of the SMTP protocol. context of the SMTP protocol.
2.1 Differences between unidirectional and bidirectional application Section 3 of the OPES SMTP use cases document [6] maps some email and
protocols SMTP elements to OPES names that are used in this document.
2.1. Differences between unidirectional and bidirectional application
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).
RFC 3914 [3] already indicates that other protocols may not fit in RFC 3914 [3] already indicates that other protocols may not fit in
this context, for example in section 5.3: "Moreover, some application this context, for example in section 5.3: "Moreover, some application
protocols may not have explicit responses...". protocols may not have explicit responses...".
When using SMTP there are still client and server applications and When using SMTP there are still client and server applications, and
requests and responses handled within SMTP, but email messages are requests and responses handled within SMTP, but email messages are
sent by the data provider to the recipients (data consumers) without sent by the data provider to the recipients (data consumers) without
a previous request; on that abstraction layer, email delivery via a previous request. At that abstraction layer, email delivery via
SMTP is a unidirectional process and different from the previously SMTP is a unidirectional process and different from the previously
handled web protocols such as HTTP. For example: Bypass has been handled web protocols such as HTTP. For example: bypass has been
defined for OPES so far by allowing the data consumer to request an defined for OPES so far by the data consumer requesting an OPES
OPES bypass by adding information to the application protocol bypass by adding information to the application protocol request; the
request; the OPES system can then react on the bypass request in both OPES system can then react on the bypass request in both the
the application request and response. For SMTP, the data consumer application request and response. For SMTP, the data consumer (email
(email recipient) cannot request in-band that the OPES bypass recipient) cannot request in-band that the OPES bypass handling of
handling of his/her messages. his/her messages.
The IAB considerations need to be revisited and special requirements The IAB considerations need to be revisited and special requirements
may be needed for OPES handling of SMTP. may be needed for OPES handling of SMTP.
2.2 Non-standardized SMTP adaptations at SMTP gateways 2.2. Non-standardized SMTP adaptations at SMTP gateways
A large number of email filters are deployed at SMTP gateways today; A large number of email filters are deployed at SMTP gateways today;
in fact all usecases listed in "OPES SMTP Use Cases" [6] are already in fact all use cases listed in "OPES SMTP Use Cases" [6] are already
deployed, often in non standardized ways. This opens a number of deployed, often in non standardized ways. This opens a number of
integrity, privacy and security concerns that are not addressed, and integrity, privacy and security concerns that are not addressed, and
SMTP itself does not provide effective measures to detect and defend SMTP itself does not provide effective measures to detect and defend
against compromised implementations. against compromised implementations.
OPES will most likely not be able to solve these issues completely, OPES will most likely not be able to solve these issues completely,
but at least might be able to improve the situaton to some extent. but at least should be able to improve the situation to some extent.
2.3 Non-OPES issues of SMTP 2.3. Non-OPES issues of SMTP
The SMTP specifications [4] require that NDRs (Non Delivery Reports) The SMTP specifications [4] require that NDRs (Non Delivery Reports)
be sent to the originator of an undeliverable mail that has been be sent to the originator of an undeliverable mail that has been
accepted by an SMTP server. But it has become common practice for accepted by an SMTP server. But it has become common practice for
some sorts of mail (spam, worms) to be silently dropped without some sorts of mail (spam, worms) to be silently dropped without
sending an NDR, a violation of the MUST statement of SMTP (see sending an NDR, a violation of the MUST statement of SMTP (see
section 3.7 of [4]). While the user of a web protocol notices if a section 3.7 of [4]). While the user of a web protocol notices if a
resource cannot be fetched, neither the email sender nor email resource cannot be fetched, neither the email sender nor email
recipient may notice that an email was not delivered. These kind of recipient may notice that an email was not delivered. These kind of
issues already exist and are not introduced by OPES. issues already exist and are not introduced by OPES.
2.4 Opportunities of OPES/SMTP to address some issues 2.4. Opportunities of OPES/SMTP to address some issues
Adding SMTP adaptations with OPES allows us to define a standardized Adding SMTP adaptations with OPES allows us to define a standardized
way for SMTP gateway filtering, to offload filtering services to way for SMTP gateway filtering, to offload filtering services to
callout servers and address a number of the integrity, privacy and callout servers and address a number of the integrity, privacy and
security issues. OPES offers methods to add OPES tracing information security issues. OPES offers methods to add OPES tracing information
and to request bypass of filtering, and by that can make email and to request bypass of filtering, and by that can make email
gateway filtering a more reliable and standardized function. But gateway filtering a more reliable and standardized function. But
OPES won't make email delivery via SMTP a reliable communication. OPES won't make email delivery via SMTP a reliable communication.
2.5 Limitations of OPES in regards to fixing SMTP issues 2.5. Limitations of OPES in regards to fixing SMTP issues
The biggest concerns when adding OPES services to a network flow are The biggest concerns when adding OPES services to a network flow are
that compromised, misconfigured or faulty OPES systems may change that compromised, misconfigured or faulty OPES systems may change
messages in a way that the consumer can no longer read them or that messages in a way that the consumer can no longer read them or that
messages are not longer delivered at all. messages are no longer delivered at all.
Defining a standard way to mark mails that have been handled by OPES Defining a standard way to mark mails that have been handled by OPES
systems is fairly simple and does not require new techniques by SMTP systems is fairly simple and does not require new techniques by SMTP
gateways; they already today MUST leave tracing information by adding gateways; they already today MUST leave tracing information by adding
"Received" headers to mails. Therefore, recipients receiving broken "Received" headers to mails. Therefore, recipients receiving broken
mail have a fair chance of finding the compromised OPES system by mail have a fair chance of finding the compromised OPES system by
using the trace information. There is still no guarantee, as the using the trace information. There is still no guarantee, as the
email have been broken in a way that makes even the tracing email may have been broken in a way that makes even the tracing
information unreadable; but the chance will be even better than with information unreadable. But the chance will be even better than with
other protocols such as HTTP, because most email clients allow the other protocols such as HTTP, because most email clients allow the
user to display mail headers, while many browsers have no mechanism user to display mail headers, while many browsers have no mechanism
to show the HTTP headers that might include tracing info. to show the HTTP headers that might include tracing info.
Email that cannot be delivered because a compromised OPES system Email that cannot be delivered, because a compromised OPES system
prevented the delivery of legitimate mail, MUST result in a an NDR to prevented the delivery of legitimate mail, MUST result in a an NDR to
be sent to the originator of the mail according to the SMTP be sent to the originator of the mail according to the SMTP
specifications [4]. OPES should not be forced to fix the issue that specifications [4]. OPES should not be forced to fix the issue that
NDRs are not reliable over SMTP. NDRs are not reliable over SMTP.
3. Integrity, privacy and security considerations 3. Integrity, privacy and security considerations
3.1 Tracing info in OPES/SMTP 3.1. Tracing info in OPES/SMTP
Tracing is an important requirement for OPES systems. Tracing Tracing OPES operations is an important requirement for OPES systems.
information added to mails should follow a similar syntax and Tracing information added to email should follow a similar syntax and
structure to that defined for OPES/HTTP in HTTP Adaptation with Open structure to that defined for OPES/HTTP in HTTP Adaptation with Open
Pluggable Edge Services [5], and with the same guidelines as the SMTP Pluggable Edge Services [5], and with the same guidelines as the SMTP
specifications [4] define for the "Received" headers. specifications [4] define for the "Received" headers. (We do not
speficy here whether "Received" headers would be used to carry the
OPES information, or new trace headers should be defined, such as
OPES-System and OPES-Via.)
Trace information is then seen by mail recipients when the mails OPES/SMTP specifications defining tracing requirements MUST be
reach the recipient. Mail that cannot be delivered or that is compliant with the general OPES tracing requirements defined in OPES
blocked by the OPES service will either be rejected or cannot be Entities & End Points Communication [12], but MAY further restrict
delivered after it has been accepted by an SMTP server. In the those. For example, they might require: that the OPES processor must
latter case SMTP specifications [4] require that a NDR MUST be sent add tracing information for the OPES system before calling the first
to the originator; OPES requires that if a NDR is sent that the callout server; that it has to augment the tracing information with
report MUST also contain information about the OPES system so that additional data if necessary after the message returns from each
the sender gets informed. If an email is rejected, an OPES system service it is calling; and that it must ensure that the tracing
MUST also include trace data in the SMTP response so that the information has not been deleted by an OPES service before it
originator can find out why and where the mail was rejected. forwards the SMTP message.
3.2 Bypass in OPES/SMTP Trace information can then be seen by mail recipients when the mail
message reaches the recipient.
Mail that cannot be delivered or that is blocked by the OPES service
will either be rejected or cannot be delivered after it has been
accepted by an SMTP server. In the latter case SMTP specifications
[4] require that a NDR MUST be sent to the originator; OPES further
requires that a NDR generated due to OPES processing MUST also
contain information about the OPES system so that the sender gets
informed. If an email is rejected at the SMTP protocol level due to
OPES processing, an OPES system MUST also include trace data in the
SMTP response so that the originator can find out why and where the
mail was rejected.
3.2. Bypass in OPES/SMTP
If a mail message was rejected or could not be delivered (and a NDR If a mail message was rejected or could not be delivered (and a NDR
was sent), the originator of the message may want to bypass the OPES was sent), the originator of the message may want to bypass the OPES
system that blocked the message. system that blocked the message.
If the recipient of a message receives a mail with OPES trace If the recipient of a message receives a mail with OPES trace
information, he may want to receive a non-OPES version of the information, he may want to receive a non-OPES version of the
message. Although there is no direct in-band request from the message. Although there is no direct in-band request from the
recipient back to the OPES system, the recipient can contact the recipient back to the OPES system, the recipient can contact the
sender and ask her to send the message again and to add a bypass sender and ask her to send the message again and to add a bypass
request for the OPES system. request for the OPES system. Not all OPES systems will be allowed to
fulfill a bypass request according to their policy. For example,
malware scanners should not be bypassed. But other OPES services are
good candidates for bypass requests, such as language translation of
the email message. Translation could be bypassed after the recipient
has noticed that the translated result does not meet his/her
expectations and that the original message would be preferred.
An OPES system MAY also define out-of-band methods to request a An OPES system MAY also define out-of-band methods to request a
bypass, for example a web interface or an email message sent to it bypass, for example a web interface or an email message sent to the
that results in the creation of a white list entry for the sender/ server that results in the creation of a white list entry for the
recipient pair. Examples for these out-of-band methods are email sender/recipient pair. Examples for these out-of-band methods are
systems that keep a copy of the original email in a quarantaine queue email systems that keep a copy of the original email in a quarantine
and only send the recipient a block notification plus either a direct queue and only send the recipient a block notification plus either a
link, or a digest notification with the ability to retrieve the direct link or a digest notification, with the ability to retrieve
original message from quarantaine. the original message from quarantine. These out-of-band methods are
typically offered by spam filters today.
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 be bypassed (such as virus scanners). In
example). In general, the receiver should be able to configure a general, the receiver should be able to configure a client centric
client centric OPES system, i.e. the receiver should be able to OPES system, i.e. the receiver should be able to indicate if he/she
indicate if he/she wants to receive a non-OPES version if it is wants to receive a non-OPES version if it is available.
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 using an ESMTP extension as part of the SMTP
reach the OPES system if intermediate SMTP relays do not support dialog may not reach the OPES system if intermediate SMTP relays do
those bypass request commands and don't forward that information. not support those bypass request commands and don't forward that
information.
3.3 Compatibility with Cryptographic Protection Mechanisms 3.3. Compatibility with Cryptographic Protection Mechanisms
Cryptography can be used to assure message privacy, to authenticate Cryptography can be used to assure message privacy, to authenticate
the originator of messages, and to detect message modification. the originator of messages, and to detect message modification.
There are standard methods for achieving some or all these There are standard methods for achieving some or all these
protections for generic messages ([9], [10], [11]), and these can be protections for generic messages ([9], [10], [11]), and these can be
used to protect SMTP data without changing the SMTP protocol. used to protect SMTP data without changing the SMTP protocol.
The content of encrypted mail messages cannot be inspected by OPES The content of encrypted mail messages cannot be inspected by OPES
systems because only the intended recipient has the information systems because only the intended recipient has the information
necessary for decryption. The IAB and others have suggested that necessary for decryption. The IAB and others have suggested that
users might want to share that information with OPES systems, thus users might want to share that information with OPES systems, thus
permitting decryption by intermediates. For most cryptographic permitting decryption by intermediates. For most cryptographic
systems that are compatible with email, this would require end users systems that are compatible with email, this would require end users
to share their most valuable keys, in essence their "identities", to share their most valuable keys, in essence their "identities",
with OPES machines. Some key management systems, particularly those with OPES machines. Some key management systems, particularly those
which have centralized administrative control of keys, might have which have centralized administrative control of keys, might have
trust models in which such sharing would be sensible and secure. trust models in which such sharing would be sensible and secure.
Once having decrypted the message, if the OPES box modifies the After decrypting the message, an OPES box that modified the content
content, it would be faced with the task of re-encrypting it in order would be faced with the task of re-encrypting it in order to maintain
to maintain some semblance of "end-to-end" privacy. some semblance of "end-to-end" privacy.
If OPES/SMTP had a way to interact with end users on a per message If OPES/SMTP had a way to interact with end users on a per message
basis, it might be possible to communicate cryptographic key basis, it might be possible to communicate cryptographic key
information from individual messages to end users, have them compute information from individual messages to end users, have them compute
the message encrypting key for particular message, and to send that the message encrypting key for particular message, and to send that
back to the OPES box. This would perhaps ameliorate the need to back to the OPES box. This would perhaps ameliorate the need to
share a user's "master" message decrypting key with the OPES box. share a user's "master" message decrypting key with the OPES box.
This kind of communication has not been defined for OPES. This kind of communication has not been defined for OPES.
Message protection systems generally include some message integrity Message protection systems generally include some message integrity
skipping to change at page 9, line 29 skipping to change at page 11, line 5
system is unpalatable, because few trust models would be compatible system is unpalatable, because few trust models would be compatible
with sharing digital identities across organization boundaries. with sharing digital identities across organization boundaries.
However, if the OPES system doing the modification were under the However, if the OPES system doing the modification were under the
control of the sender's local administration, the sharing might be control of the sender's local administration, the sharing might be
sensible (as discussed for decryption, above). sensible (as discussed for decryption, above).
OPES/SMTP systems could present modified content showing the modified OPES/SMTP systems could present modified content showing the modified
regions in a form that permits authentication of the original message regions in a form that permits authentication of the original message
and authentication of the OPES modifications (assuming the OPES box and authentication of the OPES modifications (assuming the OPES box
had a digital signature identity and key). One method for doing this 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 is outlined in [13], but to our knowledge this method is not in any
standard. standard.
There are security risks associated with sharing cryptographic keys 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 implementers. Because this is not a simple
task, it is not a requirement for OPES/SMTP. task, it is not a requirement for 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
skipping to change at page 11, line 10 skipping to change at page 13, line 10
that can be included in mail messages. that can be included in mail messages.
o The OPES/SMTP specifications MUST define a bypass request option o The OPES/SMTP specifications MUST define a bypass request option
as an extension for SMTP dialogs. as an extension for SMTP dialogs.
5. IAB Considerations for OPES/SMTP 5. IAB Considerations for OPES/SMTP
This section lists the IAB considerations for OPES [2] and summarizes This section lists the IAB considerations for OPES [2] and summarizes
how OPES/SMTP addresses them. how OPES/SMTP addresses them.
5.1 IAB Consideration (2.1) One-Party Consent 5.1. IAB Consideration (2.1) One-Party Consent
The IAB recommends that all OPES services be explicitly authorized by The IAB recommends that all OPES services be explicitly authorized by
one of the application-layer end-hosts (that is, either the data one of the application-layer end-hosts (that is, either the data
consumer application or the data provider application). For OPES/ consumer application or the data provider application). For OPES/
SMTP this means consent of either the email message sender or the SMTP this means consent of either the email message sender or the
recipient. recipient.
The application agnostic architecture of OPES [7] requires that "OPES The application agnostic architecture of OPES [7] requires that "OPES
processors MUST be consented to by either the data consumer or data processors MUST be consented to by either the data consumer or data
provider application" (OPES processor is the email gateway for OPES/ provider application" (OPES processor is the email gateway for OPES/
SMTP). This cannot prevent the consent-less introduction of OPES SMTP). This cannot prevent the consent-less introduction of OPES
processors by incompliant OPES entities. processors by noncompliant OPES entities.
5.2 IAB Consideration (2.2) IP-Layer Communications 5.2. IAB Consideration (2.2) IP-Layer Communications
The IAB recommends that OPES processors must be explicitly addressed The IAB recommends that OPES processors must be explicitly addressed
at the IP layer by the end user (data consumer application). at the IP layer by the end user (data consumer application).
This requirement has been addressed by the architecture requirements This requirement has been addressed by the architecture requirements
in section 2.1 of [7] and has been further clarified in section 2.2 in section 2.1 of [7] and has been further clarified in section 2.2
of [3]. of [3].
5.3 IAB Consideration (3.1) Notification 5.3. IAB Consideration (3.1) Notification
"The overall OPES framework needs to assist content providers in "The overall OPES framework needs to assist content providers in
detecting and responding to client-centric actions by OPES detecting and responding to client-centric actions by OPES
intermediaries that are deemed inappropriate by the content provider" intermediaries that are deemed inappropriate by the content provider"
[2]. [2].
For OPES/SMTP this translates into assistance for the email message For OPES/SMTP this translates into assistance for the email message
sender to detect and respond to recipient-centric actions that are sender to detect and respond to recipient-centric actions that are
deemed inappropriate by the sender. deemed inappropriate by the sender.
This has been addressed in Section 3.1 and by the second tracing This has been addressed in Section 3.1 and by the second tracing
requirements in Section 4. As discussed in Section 2.3 OPES/SMTP requirements in Section 4. As discussed in Section 2.3 OPES/SMTP
cannot prevent that NDRs are not sent or get blocked before reaching cannot fix cases where NDRs are not sent or get blocked before
the sender of the original message. reaching the sender of the original message.
5.4 IAB Consideration (3.2) Notification 5.4. IAB Consideration (3.2) Notification
"The overall OPES framework should assist end users in detecting the "The overall OPES framework should assist end users in detecting the
behavior of OPES intermediaries, potentially allowing them to behavior of OPES intermediaries, potentially allowing them to
identify imperfect or compromised intermediaries" [2]. identify imperfect or compromised intermediaries" [2].
This is addressed in Section 3.1 and by the first tracing requirement This is addressed in Section 3.1 and by the first tracing requirement
in Section 4. It must be noted that some email systems do not make in Section 4. It must be noted that some email systems do not make
the email headers available to the end user although the headers the email headers available to the end user although the headers
belong to the payload that is transferred via SMTP. Building an OPES belong to the payload that is transferred via SMTP. Building an OPES
architecture with those email systems should be avoided or requires architecture with those email systems should be avoided or requires
that the tracing information is made available to the end users in a that the tracing information be made available to the end users in a
different way. different way.
5.5 IAB Consideration (3.3) Non-Blocking 5.5. IAB Consideration (3.3) Non-Blocking
"If there exists a "non-OPES" version of content available from the "If there exists a "non-OPES" version of content available from the
content provider, the OPES architecture must not prevent users from content provider, the OPES architecture must not prevent users from
retrieving this "non-OPES" version from the content provider" [2]. retrieving this "non-OPES" version from the content provider" [2].
For OPES/SMTP this has been discussed in Section 3.2 and is addressed For OPES/SMTP this has been discussed in Section 3.2 and is addressed
by the two bypass requirements of Section 4. by the two bypass requirements of Section 4.
5.6 IAB Consideration Application Layer Addresses (4.x) 5.6. IAB Consideration Application Layer Addresses (4.x)
While "most application layer addressing revolves around URIs" While "most application layer addressing revolves around URIs"
(section 8 of [2]), SMTP uses email addresses, for which the (section 8 of [2]), SMTP uses email addresses, for which the
considerations apply to some degree only. considerations only apply to some degree.
The SMTP use cases document [6] includes a use case for Mail The SMTP use cases document [6] includes a use case for Mail
Rerouting and Address Rewriting. Alias and email list address Rerouting and Address Rewriting. Alias and email list address
resolution are standard function of an email gateway described in resolution are standard functions of an email gateway described in
[4]. [4].
Translating the reference validity consideration regarding inter- and Translating the reference validity consideration regarding inter- and
intra-document reference validity to SMTP, OPES services mapping intra-document reference validity to SMTP, OPES services mapping
internal to external email addresses MUST ensure to properly map internal to external email addresses MUST ensure the proper mapping
addresses in all affected email headers. of addresses in all affected email headers.
5.7 IAB Consideration (5.1) Privacy 5.7. IAB Consideration (5.1) Privacy
This consideration recommends that the overall OPES framework must This consideration recommends that the overall OPES framework must
provide for mechanisms for end users to determine the privacy provide for mechanisms for end users to determine the privacy
policies of OPES intermediaries. policies that were used by OPES intermediaries.
The application agnostic part for OPES and has been discussed in The application agnostic part for OPES has been discussed in section
section 10 of [3]. Email specific trace information that will be 10 of [3]. Email specific trace information that will be added to
added to OPES/SMTP according to the requirements in Section 4 may OPES/SMTP according to the requirements in Section 4 may raise
raise additional privacy issues that MUST be added to the privacy additional privacy issues that MUST be added to the privacy policy
policy description of the OPES system. description of the OPES system.
5.8 IAB Consideration Encryption 5.8. IAB Consideration Encryption
"If OPES was compatible with end-to-end encryption, this would "If OPES was compatible with end-to-end encryption, this would
effectively ensure that OPES boxes would be restricted to ones that effectively ensure that OPES boxes would be restricted to ones that
are known, trusted, explicitly addressed at the IP layer, and are known, trusted, explicitly addressed at the IP layer, and
authorized (by the provision of decryption keys) by at least one of authorized (by the provision of decryption keys) by at least one of
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
skipping to change at page 15, line 5 skipping to change at page 17, line 5
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 cryptographic protection Section 3.3 (about compatibility with cryptographic protection
mechanisms) mentions that an OPES system could eventually deal with mechanisms) mentions that an OPES system could eventually deal with
cryptographic keys. This raises security issues (such as cryptographic keys. This raises security issues (such as
availability and storage of cryptographic keys) that must be availability and storage of cryptographic keys) that must be
addressed by the implementer. addressed by the implementer.
7. References 7. IANA Considerations
7.1 Normative References There are no IANA Considerations.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement RFC Editor: this section may be removed upon publication.
Levels", BCP 14, RFC 2119, March 1997.
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy 8. References
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[3] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services (OPES) 8.1. Normative References
Treatment of IAB Considerations", RFC 3914, October 2004.
7.2 Informative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002.
[3] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services
(OPES) Treatment of IAB Considerations", RFC 3914,
October 2004.
8.2. Informative References
[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.
skipping to change at page 15, line 48 skipping to change at page 18, line 49
[9] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME [9] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME
Security with OpenPGP", RFC 3156, August 2001. Security with OpenPGP", RFC 3156, August 2001.
[10] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, [10] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
July 2004. July 2004.
[11] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup [11] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275, Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002. March 2002.
[12] Orman, H., "Data Integrity for Mildly Active Content", [12] Barbir, A., "Open Pluggable Edge Services (OPES) Entities and
End Points Communication", RFC 3897, September 2004.
[13] Orman, H., "Data Integrity for Mildly Active Content",
Proceedings of the Third Annual International Workshop on Proceedings of the Third Annual International Workshop on
Active Middleware Services p.73, August 2001. Active Middleware Services p.73, August 2001.
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).
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 Full Copyright Statement
Many thanks to everybody who provided input and feedback for this Copyright (C) The IETF Trust (2007).
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 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, THE IETF TRUST 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.
Intellectual Property
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.
skipping to change at page 18, line 29 skipping to change at page 22, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 63 change blocks. 
148 lines changed or deleted 191 lines changed or added

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