draft-ietf-opes-smtp-security-00.txt   draft-ietf-opes-smtp-security-01.txt 
Open Pluggable Edge Services M. Stecher Open Pluggable Edge Services M. Stecher
Internet-Draft Secure Computing Internet-Draft Secure Computing
Expires: November 23, 2006 May 22, 2006 Expires: March 26, 2007 September 22, 2006
Integrity, privacy and security in OPES for SMTP Integrity, privacy and security in OPES for SMTP
draft-ietf-opes-smtp-security-00 draft-ietf-opes-smtp-security-01
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 November 23, 2006. This Internet-Draft will expire on March 26, 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 13 skipping to change at page 2, line 13
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.
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 . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . 6
3.1 Tracing info in OPES/SMTP . . . . . . . . . . . . . . . . 6 3.1 Tracing info in OPES/SMTP . . . . . . . . . . . . . . . . 6
3.2 Bypass in OPES/SMTP . . . . . . . . . . . . . . . . . . . 6 3.2 Bypass in OPES/SMTP . . . . . . . . . . . . . . . . . . . 6
3.3 Compatibility with end-to-end encryption . . . . . . . . . 7 3.3 Compatibility with end-to-end encryption and signatures . 7
4. Requirements for OPES/SMTP . . . . . . . . . . . . . . . . . . 8 4. Protocol requirements for OPES/SMTP . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. IAB Considerations for OPES/SMTP . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1 IAB Consideration (2.1) One-Party Consent . . . . . . . . 9
6.1 Normative References . . . . . . . . . . . . . . . . . . . 10 5.2 IAB Consideration (2.2) IP-Layer Communications . . . . . 9
6.2 Informative References . . . . . . . . . . . . . . . . . . 10 5.3 IAB Consideration (3.1) Notification . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 5.4 IAB Consideration (3.2) Notification . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 11 5.5 IAB Consideration (3.3) Non-Blocking . . . . . . . . . . . 10
5.6 IAB Consideration Application Layer Addresses (4.x) . . . 10
5.7 IAB Consideration (5.1) Privacy . . . . . . . . . . . . . 10
5.8 IAB Consideration Encryption . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1 Normative References . . . . . . . . . . . . . . . . . . . 13
7.2 Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 14
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
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 request have requests and responses in the classic form (client sends a
to server that replies with a response of the same protocol within a request to a server that replies with a response of the same protocol
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; on 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 allowing the data consumer to request an
OPES bypass by adding information to the application protocol OPES bypass by adding information to the application protocol
request; the OPES system can then react on the bypass request in both request; the OPES system can then react on the bypass request in both
the application request and response; for SMTP the data consumer the application request and response. For SMTP, the data consumer
(email recipient) cannot request in-band the OPES bypass of his (email recipient) cannot request in-band that the OPES bypass
messages. handling of 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 is 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 usecases 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 completly but OPES will most likely not be able to solve these issues completely,
at least might be able to improve the situaton to some extend. but at least might be able to improve the situaton 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)
are 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 became common practice that some accepted by an SMTP server. But it has become common practice for
sort of mail (spam, worms) is silently dropped without sending an NDR some sorts of mail (spam, worms) to be silently dropped without
in violation of that MUST statement of SMTP (see section 3.7 of [4]). sending an NDR, a violation of the MUST statement of SMTP (see
While the user of a web protocol notices if a resource cannot be section 3.7 of [4]). While the user of a web protocol notices if a
fetched, neither the email sender nor email recipient may notice that resource cannot be fetched, neither the email sender nor email
an email was not delivered. These kind of issues already exist and recipient may notice that an email was not delivered. These kind of
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 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 gateway and to request bypass of filtering, and by that can make email
filtering a more reliable and standardized function. But OPES won't gateway filtering a more reliable and standardized function. But
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 OPES systems may change messages in a way that the that compromised, misconfigured or faulty OPES systems may change
consumer cannot longer read them or that messages are not longer messages in a way that the consumer can no longer read them or that
delivered at all. messages are not longer delivered at all.
Defining a standard way to mark mails that are 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 that 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 to find the compromised OPES system by using mail have a fair chance of finding the compromised OPES system by
the trace information. There is still no guarantee as the email may using the trace information. There is still no guarantee, as the
be broken in a way that makes even the tracing information email have been broken in a way that makes even the tracing
unreadable; but the chance will be even better than with other information unreadable; but the chance will be even better than with
protocols such as HTTP because most email clients allow the user to other protocols such as HTTP, because most email clients allow the
display mail headers while many browsers have no instrument to show user to display mail headers, while many browsers have no mechanism
the HTTP headers that may 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 no reliable medium of 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 is an important requirement for OPES systems. Tracing
information added to mails, following a similar syntax and structure information added to mails should follow a similar syntax and
as defined for OPES/HTTP in HTTP Adaptation with Open Pluggable Edge structure to that defined for OPES/HTTP in HTTP Adaptation with Open
Services [5] and with the same guidelines as the SMTP specifications Pluggable Edge Services [5], and with the same guidelines as the SMTP
[4] define for the "Received" headers. specifications [4] define for the "Received" headers.
Trace information is then seen by mail recipients when the mails Trace information is then seen by mail recipients when the mails
reach the recipient. Mail that cannot be delivered or that is reach the recipient. Mail that cannot be delivered or that is
blocked by the OPES service will either be rejected or cannot be blocked by the OPES service will either be rejected or cannot be
delivered after it has been accepted by an SMTP server. In the delivered after it has been accepted by an SMTP server. In the
latter case SMTP specifications [4] require that a NDR MUST be sent 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 to the originator; OPES requires that if a NDR is sent that the
MUST also contain information about the OPES system so that the report MUST also contain information about the OPES system so that
sender gets informed. If an email is rejected, an OPES system MUST the sender gets informed. If an email is rejected, an OPES system
also include trace data to the SMTP response so that the originator MUST also include trace data in the SMTP response so that the
can find out why and where the mail was rejected. originator can find out why and where the mail was rejected.
3.2 Bypass in OPES/SMTP 3.2 Bypass in OPES/SMTP
If a mail was rejected or could not be delivered (and a NDR was If a mail message was rejected or could not be delivered (and a NDR
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.
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 sent to itself which bypass, for example a web interface or an email message sent to it
results in the creation of a white list entry for the sender/ that results in the creation of a white list entry for the sender/
recipient pair. Examples for these out-of-band methods are email recipient pair. Examples for these out-of-band methods are email
systems that keep a copy of the original email in a quarantaine queue 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 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 she wants to receive a non-OPES version if the OPES indicate if he/she wants to receive a non-OPES version if the OPES
service would result in rejection of the email. service would result in rejection of the email.
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 3.3 Compatibility with end-to-end encryption and signatures
End-to-end email encryption is a proven technology although still the End-to-end email encryption is a proven technology, although the
majority of mails are sent unencrypted. Encrpyting and signing email majority of mails are still sent unencrypted. Encrypting and signing
is done on the content of mails and transparent for SMTP. Encrypted email messages is done on the content of the mail and would be
mails can either be used to prevent OPES systems to inspect or modify transparent to SMTP. Encrypted mail messages can either be used to
the content or it can be used as an explicit approval to filter the prevent OPES systems from inspecting or modifying the content, or it
mail by the OPES system, if keys for decryption of the message are can be used as an explicit approval to filter the mail by the OPES
made available to the OPES system. Signing of mails can be used to system, if keys for decryption of the message are made available to
trace whether content has been changed by intermediates. 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 There are security risks associated with storing cryptographic keys
which must be addressed by implementors. Beause 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 only suggested as an option, not as a requirement for
OPES/SMTP. OPES/SMTP.
4. 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 that has been accepted by an OPES system cannot be o If an email message that has been accepted by an OPES system
delivered, the non delivery report MUST include trace information cannot be delivered, the non delivery report MUST include trace
of the OPES system. information of the OPES system.
o OPES/SMTP MUST define a bypass request option that can be included o The OPES/SMTP specifications MUST define a bypass request option
in mail messages that can be included in mail messages.
o OPES/SMTP MUST define a bypass request option as an extension for o The OPES/SMTP specifications MUST define a bypass request option
SMTP dialogs as an extension for SMTP dialogs.
5. Security Considerations 5. IAB Considerations for OPES/SMTP
This section lists the IAB considerations for OPES [2] and summarizes
how OPES/SMTP addresses them.
5.1 IAB Consideration (2.1) One-Party Consent
The IAB recommends that all OPES services be explicitly authorized by
one of the application-layer end-hosts (that is, either the data
consumer application or the data provider application). For OPES/
SMTP this means consent of either the email message sender or the
recipient.
The application agnostic architecture of OPES [7] requires that "OPES
processors MUST be consented to by either the data consumer or data
provider application" (OPES processor is the email gateway for OPES/
SMTP). This cannot prevent the consent-less introduction of OPES
processors by incompliant OPES entities.
5.2 IAB Consideration (2.2) IP-Layer Communications
The IAB recommends that OPES processors must be explicitly addressed
at the IP layer by the end user (data consumer application).
This requirement has been addressed by the architecture requirements
in section 2.1 of [7] and has been further clarified in section 2.2
of [3].
5.3 IAB Consideration (3.1) Notification
"The overall OPES framework needs to assist content providers in
detecting and responding to client-centric actions by OPES
intermediaries that are deemed inappropriate by the content provider"
[2].
For OPES/SMTP this translates into assistance for the email message
sender to detect and respond to recipient-centric actions that are
deemed inappropriate by the sender.
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
cannot prevent that NDRs are not sent or get blocked before reaching
the sender of the original message.
5.4 IAB Consideration (3.2) Notification
"The overall OPES framework should assist end users in detecting the
behavior of OPES intermediaries, potentially allowing them to
identify imperfect or compromised intermediaries" [2].
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
the email headers available to the end user although the headers
belong to the payload that is transferred via SMTP. Building an OPES
architecture with those email systems should be avoided or requires
that the tracing information is made available to the end users in a
different way.
5.5 IAB Consideration (3.3) Non-Blocking
"If there exists a "non-OPES" version of content available from the
content provider, the OPES architecture must not prevent users from
retrieving this "non-OPES" version from the content provider" [2].
For OPES/SMTP this has been discussed in Section 3.2 and is addressed
by the two bypass requirements of Section 4.
5.6 IAB Consideration Application Layer Addresses (4.x)
While "most application layer addressing revolves around URIs"
(section 8 of [2]), SMTP uses email addresses, for which the
considerations apply to some degree only.
The SMTP use cases document [6] includes a use case for Mail
Rerouting and Address Rewriting. Alias and email list address
resolution are standard function of an email gateway described in
[4].
Translating the reference validity consideration regarding inter- and
intra-document reference validity to SMTP, OPES services mapping
internal to external email addresses MUST ensure to properly map
addresses in all affected email headers.
5.7 IAB Consideration (5.1) Privacy
This consideration recommends that the overall OPES framework must
provide for mechanisms for end users to determine the privacy
policies of OPES intermediaries.
The application agnostic part for OPES and has been discussed in
section 10 of [3]. Email specific trace information that will be
added to OPES/SMTP according to the requirements in Section 4 may
raise additional privacy issues that MUST be added to the privacy
policy description of the OPES system.
5.8 IAB Consideration Encryption
"If OPES was compatible with end-to-end encryption, this would
effectively ensure that OPES boxes would be restricted to ones that
are known, trusted, explicitly addressed at the IP layer, and
authorized (by the provision of decryption keys) by at least one of
the ends" [2].
This has been discussed in Section 3.3.
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
for OPES [8]
Section 3.3 about compatibility with end-to-end encryption mentions Section 3.3 (about compatibility with end-to-end encryption) mentions
that an OPES system could be approved to inspect encrypted mails by that an OPES system could be approved to inspect encrypted mails by
making keys available for decryption. It must be noted that an making keys available for decryption. It must be noted that an
implementation of the decryption key handling raises security issues implementation of the decryption key handling raises security issues
(such as 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.
6. References 7. References
6.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
Considerations for Open Pluggable Edge Services", RFC 3238, Considerations for Open Pluggable Edge Services", RFC 3238,
January 2002. January 2002.
[3] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services (OPES) [3] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services (OPES)
Treatment of IAB Considerations", RFC 3914, October 2004. Treatment of IAB Considerations", RFC 3914, October 2004.
6.2 Informative References 7.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.
[7] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An
Architecture for Open Pluggable Edge Services (OPES)", RFC 3835,
August 2004.
[8] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H.
Orman, "Security Threats and Risks for Open Pluggable Edge
Services (OPES)", RFC 3837, August 2004.
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/
 End of changes. 40 change blocks. 
88 lines changed or deleted 213 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/