Open Pluggable Edge Services M. Stecher
Internet-Draft Secure Computing
Expires: November 23, 2006 May 22, 2006
Integrity, privacy and security in OPES for SMTP
draft-ietf-opes-smtp-security-00
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.
This Internet-Draft will expire on November 23, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Open Pluggable Edge Services (OPES) framework is application
agnostic. Application specific adaptations extend that framework.
Previous work has focussed on HTTP and work for SMTP is in progress.
These protocols differ fundamentally in the way data flows and it
turns out that existing OPES requirements and IAB considerations for
OPES need to be reviewed with regards to how well they fit for SMTP
adaptation. This document analysis aspects about the integrity of
SMTP and mail message adaptation by OPES systems and privacy and
security issues when the OPES framework is adapted to SMTP and lists
Stecher Expires November 23, 2006 [Page 1]
Internet-Draft OPES/SMTP security May 2006
requirements that must be considered when creating the "SMTP
adaptation with OPES" document.
Table of Contents
1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Differences between unidirectional and bidirectional
application protocols . . . . . . . . . . . . . . . . . . 4
2.2 Non standardized SMTP adaptations at SMTP gateways . . . . 4
2.3 Non-OPES issues of SMTP . . . . . . . . . . . . . . . . . 4
2.4 Opportunities of OPES/SMTP to address some issues . . . . 5
2.5 Limitations of OPES in regards to fixing SMTP issues . . . 5
3. Integrity, privacy and security considerations . . . . . . . . 6
3.1 Tracing info in OPES/SMTP . . . . . . . . . . . . . . . . 6
3.2 Bypass in OPES/SMTP . . . . . . . . . . . . . . . . . . . 6
3.3 Compatibility with end-to-end encryption . . . . . . . . . 7
4. Requirements for OPES/SMTP . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Normative References . . . . . . . . . . . . . . . . . . . 10
6.2 Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 11
Stecher Expires November 23, 2006 [Page 2]
Internet-Draft OPES/SMTP security May 2006
1. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. When used with
the normative meanings, these keywords will be all uppercase.
Occurrences of these words in lowercase comprise normal prose usage,
with no normative implications.
Stecher Expires November 23, 2006 [Page 3]
Internet-Draft OPES/SMTP security May 2006
2. Introduction
2.1 Differences between unidirectional and bidirectional application
protocols
The IAB listed considerations for Open Pluggable Edge Services (OPES)
in [2] and OPES treatment of those considerations has been discussed
in [3]. Both documents make use of HTTP as an example for the
underlying protocol in OPES flows and focus on web protocols that
have requests and responses in the classic form (client sends request
to server that replies with a response of the same protocol within a
single protocol transaction).
RFC 3914 [3] already indicates that other protocols may not fit in
this context, for example in section 5.3: "Moreover, some application
protocols may not have explicit responses...".
When using SMTP there are still client and server applications and
requests and responses handled within SMTP, but email messages are
sent by the data provider to the recipients (data consumers) without
a previous request; on that abstraction layer, email delivery via
SMTP is a unidirectional process and different from the previously
handled web protocols such as HTTP. For example: Bypass has been
defined for OPES so far by allowing the data consumer to request an
OPES bypass by adding information to the application protocol
request; the OPES system can then react on the bypass request in both
the application request and response; for SMTP the data consumer
(email recipient) cannot request in-band the OPES bypass of his
messages.
The IAB considerations need to be revisited and special requirements
may be needed for OPES handling of SMTP.
2.2 Non standardized SMTP adaptations at SMTP gateways
A large number of email filters is deployed at SMTP gateways today;
in fact all usecases listed in "OPES SMTP Use Cases" [6] are already
deployed, often in non standardized ways. This opens a number of
integrity, privacy and security concerns that are not addressed and
SMTP itself does not provide effective measures to detect and defend
against compromised implementations.
OPES will most likely not be able to solve these issues completly but
at least might be able to improve the situaton to some extend.
2.3 Non-OPES issues of SMTP
The SMTP specifications [4] require that NDRs (Non Delivery Reports)
Stecher Expires November 23, 2006 [Page 4]
Internet-Draft OPES/SMTP security May 2006
are sent to the originator of an undeliverable mail that has been
accepted by an SMTP server. But it became common practice that some
sort of mail (spam, worms) is silently dropped without sending an NDR
in violation of that MUST statement of SMTP (see 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 recipient may notice that
an email was not delivered. These kind of issues already exist and
are not introduced by OPES.
2.4 Opportunities of OPES/SMTP to address some issues
Adding SMTP adaptations with OPES, allows to define a standardized
way for SMTP gateway filtering, to offload filtering services to
callout servers and address a number of the integrity, privacy and
security issues. OPES offers methods to add OPES tracing information
and to request bypass of filtering and by that can make email gateway
filtering a more reliable and standardized function. But OPES won't
make email delivery via SMTP a reliable communication.
2.5 Limitations of OPES in regards to fixing SMTP issues
The biggest concerns when adding OPES services to a network flow are
that compromised OPES systems may change messages in a way that the
consumer cannot longer read them or that messages are not longer
delivered at all.
Defining a standard way to mark mails that are handled by OPES
systems is fairly simple and does not require new techniques by SMTP
gateways that already today MUST leave tracing information by adding
"Received" headers to mails. Therefore, recipients receiving broken
mail have a fair chance to find the compromised OPES system by using
the trace information. There is still no guarantee as the email may
be broken in a way that makes even the tracing information
unreadable; but the chance will be even better than with other
protocols such as HTTP because most email clients allow the user to
display mail headers while many browsers have no instrument to show
the HTTP headers that may include tracing info.
Email that cannot be delivered because a compromised OPES system
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
specifications [4]. OPES should not be forced to fix the issue that
NDRs are no reliable medium of SMTP.
Stecher Expires November 23, 2006 [Page 5]
Internet-Draft OPES/SMTP security May 2006
3. Integrity, privacy and security considerations
3.1 Tracing info in OPES/SMTP
Tracing is an important requirement for OPES systems. Tracing
information added to mails, following a similar syntax and structure
as defined for OPES/HTTP in HTTP Adaptation with Open Pluggable Edge
Services [5] and with the same guidelines as the SMTP specifications
[4] define for the "Received" headers.
Trace information is then seen by mail recipients when the mails
reach 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 requires that if a NDR is sent that report
MUST also contain information about the OPES system so that the
sender gets informed. If an email is rejected, an OPES system MUST
also include trace data to 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 was rejected or could not be delivered (and a NDR was
sent), the originator of the message may want to bypass the OPES
system that blocked the message.
If the recipient of a message receives a mail with OPES trace
information, he may want to receive a non-OPES version of the
message. Although there is no direct in-band request from 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
request for the OPES system.
An OPES system MAY also define out-of-band methods to request a
bypass, for example a web interface or an email sent to itself which
results in the creation of a white list entry for the sender/
recipient pair. Examples for these out-of-band methods are email
systems that keep a copy of the original email in a quarantaine queue
and only send the recipient a block notification plus either a direct
link or a digest notification with the ability to retrieve the
original message from quarantaine.
OPES MUST implement methods to request a bypass but there cannot be a
guarantee that the bypass request will be approved. The security
needs of the receiver or the receiver's network may demand that
certain filters must not by bypassed (such as virus scanners for
example). In general, the receiver should be able to configure a
Stecher Expires November 23, 2006 [Page 6]
Internet-Draft OPES/SMTP security May 2006
client centric OPES system, i.e. the receiver should be able to
indicate if she wants to receive a non-OPES version if the OPES
service would result in rejection of the email.
Bypass requests could be added to the mail message or within the SMTP
dialog. Bypass request data added to the mail message cannot bypass
OPES services that operate on other SMTP dialog commands, which are
sent before the mail message has been received (such as RCPT
commands).
Bypass request data sent at the beginning of a SMTP dialog may not
reach the OPES system if intermediate SMTP relays do not support
those bypass request commands and don't forward that information.
3.3 Compatibility with end-to-end encryption
End-to-end email encryption is a proven technology although still the
majority of mails are sent unencrypted. Encrpyting and signing email
is done on the content of mails and transparent for SMTP. Encrypted
mails can either be used to prevent OPES systems to inspect or modify
the content or it 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
which must be addressed by implementors. Beause this is not a simple
task, it is only suggested as an option, not as a requirement for
OPES/SMTP.
Stecher Expires November 23, 2006 [Page 7]
Internet-Draft OPES/SMTP security May 2006
4. Requirements for OPES/SMTP
In addition to other documents listing requirements for OPES, the
discussion in this document implies specific requirements for
designing and implementing SMTP adaptations with OPES:
o OPES Systems MUST add tracing headers to mail messages
o If an email that has been accepted by an OPES system cannot be
delivered, the non delivery report MUST include trace information
of the OPES system.
o OPES/SMTP MUST define a bypass request option that can be included
in mail messages
o OPES/SMTP MUST define a bypass request option as an extension for
SMTP dialogs
Stecher Expires November 23, 2006 [Page 8]
Internet-Draft OPES/SMTP security May 2006
5. Security Considerations
The document itself discusses security considerations of OPES/SMTP.
Section 3.3 about compatibility with end-to-end encryption mentions
that an OPES system could be approved to inspect encrypted mails by
making keys available for decryption. It must be noted that an
implementation of the decryption key handling raises security issues
(such as availability and storage of cryptographic keys) that must be
addressed by the implementer.
Stecher Expires November 23, 2006 [Page 9]
Internet-Draft OPES/SMTP security May 2006
6. References
6.1 Normative 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.
6.2 Informative References
[4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[5] Rousskov, A. and M. Stecher, "HTTP Adaptation with Open
Pluggable Edge Services (OPES)", RFC 4236, November 2005.
[6] Stecher, M. and A. Barbir, "Open Pluggable Edge Services (OPES)
SMTP Use Cases", RFC 4496, May 2006.
Author's Address
Martin Stecher
Secure Computing Corporation
Vattmannstr. 3
33100 Paderborn
Germany
Email: martin.stecher@webwasher.com
URI: http://www.securecomputing.com/
Stecher Expires November 23, 2006 [Page 10]
Internet-Draft OPES/SMTP security May 2006
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
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
Funding for the RFC Editor function is currently provided by the
Internet Society.
Stecher Expires November 23, 2006 [Page 11]
