doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc3837.txt b/doc/rfc/rfc3837.txt
new file mode 100644
index 0000000..7d87c75
--- /dev/null
+++ b/doc/rfc/rfc3837.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                          A. Barbir
+Request for Comments: 3837                               Nortel Networks
+Category: Informational                                       O. Batuner
+                                                  Independent consultant
+                                                             B. Srinivas
+                                                                   Nokia
+                                                              M. Hofmann
+                                           Bell Labs/Lucent Technologies
+                                                                H. Orman
+                                               Purple Streak Development
+                                                             August 2004
+
+
+   Security Threats and Risks for Open Pluggable Edge Services (OPES)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   The document investigates the security threats associated with the
+   Open Pluggable Edge Services (OPES) and discusses the effects of
+   security threats on the underlying architecture.  The main goal of
+   this document is threat discovery and analysis.  The document does
+   not specify or recommend any solutions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                      [Page 1]
+
+RFC 3837               Security Threats for OPES             August 2004
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  OPES Data Flow Threats . . . . . . . . . . . . . . . . . . . .  4
+       2.1.  OPES Flow Network Level Threats  . . . . . . . . . . . .  5
+             2.1.1.  Connection-Flow Denial-of-Service (DoS). . . . .  6
+             2.1.2.  Threats to Network Robustness. . . . . . . . . .  6
+       2.2.  OPES Flow Application Level Threats. . . . . . . . . . .  6
+             2.2.1.  Unauthorized OPES Entities . . . . . . . . . . .  6
+             2.2.2.  Unauthorized Actions of legitimate OPES Entities  7
+             2.2.3.  Unwanted Content Transformations . . . . . . . .  7
+             2.2.4.  Corrupted Content  . . . . . . . . . . . . . . .  7
+             2.2.5.  Threats to Message Structure Integrity . . . . .  8
+             2.2.6.  Granularity of Protection  . . . . . . . . . . .  8
+             2.2.7.  Risks of Hop-by-Hop Protection . . . . . . . . .  8
+             2.2.8.  Threats to Integrity of Complex Data . . . . . .  8
+             2.2.9.  Denial of Service (DoS)  . . . . . . . . . . . .  9
+             2.2.10. Tracing and Notification Information . . . . . .  9
+             2.2.11. Unauthenticated Communication in OPES Flow . . .  9
+   3.  Threats to Out-of-Band Data  . . . . . . . . . . . . . . . . .  9
+       3.1.  Threats that Endanger the OPES Data Flow . . . . . . . . 10
+       3.2.  Inaccurate Accounting Information  . . . . . . . . . . . 10
+       3.3.  OPES Service Request Repudiation . . . . . . . . . . . . 11
+       3.4.  Inconsistent Privacy Policy  . . . . . . . . . . . . . . 11
+       3.5.  Exposure of Privacy Preferences  . . . . . . . . . . . . 11
+       3.6.  Exposure of Security Settings  . . . . . . . . . . . . . 11
+       3.7.  Improper Enforcement of Privacy and Security Policy  . . 11
+       3.8.  DoS Attacks  . . . . . . . . . . . . . . . . . . . . . . 12
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
+       5.1.  Normative References . . . . . . . . . . . . . . . . . . 12
+       5.2.  Informative References . . . . . . . . . . . . . . . . . 12
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
+   7.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
+   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14
+
+1.  Introduction
+
+   The Open Pluggable Edge Services (OPES) [1] architecture enables
+   cooperative application services (OPES services) between a data
+   provider, a data consumer, and zero or more OPES processors.  The
+   application services under consideration analyze and possibly
+   transform application-level messages exchanged between the data
+   provider and the data consumer.  The OPES processor can distribute
+   the responsibility of service execution by communicating and
+   collaborating with one or more remote callout servers.  The details
+   of the OPES architecture can be found in [1].
+
+
+
+
+Barbir, et al.               Informational                      [Page 2]
+
+RFC 3837               Security Threats for OPES             August 2004
+
+
+   Security threats with respect to OPES can be viewed from different
+   angles.  There are security risks that affect content consumer
+   applications, and those that affect the data provider applications.
+   These threats affect the quality and integrity of data that the
+   applications either produce or consume.  On the other hand, the
+   security risks can also be categorized into trust within the system
+   (i.e., OPES service providers) and protection of the system from
+   threats imposed by outsiders such as hackers and attackers.  Insiders
+   are those parties that are part of the OPES system.  Outsiders are
+   those entities that are not participating in the OPES system.
+
+   It must be noted that not everyone in an OPES delivery path is
+   equally trusted.  Each OPES administrative trust domain must protect
+   itself from all outsiders.  Furthermore, it may have a limited trust
+   relationship with another OPES administrative domain for certain
+   purposes.
+
+   OPES service providers must use authentication as the basis for
+   building trust relationships between administrative domains.
+   Insiders can intentionally or unintentionally inflict harm and damage
+   on the data consumer and data provider applications.  This can be
+   through bad system configuration, execution of bad software or, if
+   their networks are compromised, by inside or outside hackers.
+
+   Depending on the deployment scenario, the trust within the OPES
+   system is based on a set of transitive trust relationships between
+   the data provider application, the OPES entities, and the data
+   consumer application.  Threats to OPES entities can be at the OPES
+   flow level and/or at the network level.
+
+   In considering threats to the OPES system, the document will follow a
+   threat analysis model that identifies the threats from the
+   perspective of how they will affect the data consumer and the data
+   provider applications.
+
+   The main goal of this document is threat discovery and analysis.  The
+   document does not specify or recommend any solutions.
+
+   It is important to mention that the OPES architecture has many
+   similarities with other so called overlay networks, specifically web
+   caches and content delivery networks (CDN) (see [2], [4]).  This
+   document focuses on threats that are introduced by the existence of
+   the OPES processor and callout servers.  Security threats specific to
+   content services that do not use the OPES architecture are considered
+   out-of-scope of this document.  However, this document can be used as
+   input when considering security implications for web caches and CDNs.
+
+
+
+
+
+Barbir, et al.               Informational                      [Page 3]
+
+RFC 3837               Security Threats for OPES             August 2004
+
+
+   The document is organized as follows: Section 2 discusses threats to
+   OPES data flow on the network and application level, section 3
+   discusses threats to other parts of the system, and section 4
+   discusses security considerations.
+
+2. OPES Data Flow Threats
+
+   Threats to the OPES data flow can affect the data consumer and data
+   provider applications.  At the OPES flow level, threats can occur at
+   Policy Enforcement Points, and Policy Decision Points [3], and along
+   the OPES flow path where network elements are used to process the
+   data.
+
+   A serious problem is posed by the very fact that the OPES
+   architecture is based on widely adopted protocols (HTTP is used as an
+   example).  The architecture document specifically requires that "the
+   presence of an OPES processor in the data request/response flow SHALL
+   NOT interfere with the operations of non-OPES aware clients and
+   servers".  This greatly facilitates OPES' deployment, but on the
+   other hand a vast majority of clients (browsers) will not be able to
+   exploit any safeguards added as base protocol extensions.
+
+   For the usual data consumer, who might have questions such as (Where
+   does this content come from? Can I get it another way? What is the
+   difference? Is it legitimate?).  Even if there are facilities and
+   technical expertise present to pursue these questions, such thorough
+   examination of each result is prohibitively expensive in terms of
+   time and effort.  OPES-aware content providers may try to protect
+   themselves by adding verification scripts and special page
+   structures.  OPES-aware end users may use special tools.  In all
+   other cases (non-OPES aware clients and servers) protection will rely
+   on monitoring services and investigation of occasionally discovered
+   anomalies.
+
+   An OPES system poses a special danger as a possible base for
+   classical man-in-the-middle attacks.  One of the reasons why such
+   attacks are relatively rare is the difficulty in finding an
+   appropriate base: a combination of a traffic interception point
+   controlling a large flow of data and an application codebase running
+   on a high-performance hardware with sufficient performance to analyze
+   and possibly modify all passing data.  An OPES processor meets this
+   definition.  This calls for special attention to protection measures
+   at all levels of the system.
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                      [Page 4]
+
+RFC 3837               Security Threats for OPES             August 2004
+
+
+   Any compromise of an OPES processor or remote callout server can have
+   a ripple effect on the integrity of the affected OPES services across
+   all service providers that use the service.  To mitigate this threat,
+   appropriate security procedures and tools (e.g., a firewall) should
+   be applied.
+
+   Specific threats can exist at the network level and at the OPES data
+   flow level.
+
+2.1.  OPES Flow Network Level Threats
+
+   OPES processor and callout servers are susceptible to network level
+   attacks from outsiders or from the networks of other OPES service
+   providers (i.e., if the network of a contracted OPES service is
+   compromised).
+
+   The OPES architecture is based on common application protocols that
+   do not provide strong guarantees of privacy, authentication, or
+   integrity.  The IAB considerations [4] require that the IP address of
+   an OPES processor be accessible to data consumer applications at the
+   IP addressing level.  This requirement limits the ability of service
+   providers to position the OPES processor behind firewalls and may
+   expose the OPES processor and remote callout servers to network level
+   attacks.  For example, the use of TCP/IP as a network level protocol
+   makes OPES processors subject to many known attacks, such as IP
+   spoofing and session stealing.
+
+   The OPES system is also susceptible to a number of security threats
+   that are commonly associated with network infrastructure.  These
+   threats include snooping, denial of service, sabotage, vandalism,
+   industrial espionage, and theft of service.
+
+   There are best practice solutions to mitigate network level threats.
+   It is recommended that the security of the OPES entities at the
+   network level be enhanced using known techniques and methods that
+   minimize the risks of IP spoofing, snooping, denial of service, and
+   session stealing.
+
+   At the OPES Flow level, connection-level security between the OPES
+   processor and callout servers is an important consideration.  For
+   example, it is possible to spoof the OPES processor or the remote
+   callout server.  There are threats to data confidentiality between
+   the OPES processor and the remote callout server in an OPES flow.
+
+   The next subsections cover possible DoS attacks on an OPES processor,
+   remote callout server or data consumer application, and network
+   robustness.
+
+
+
+
+Barbir, et al.               Informational                      [Page 5]
+
+RFC 3837               Security Threats for OPES             August 2004
+
+
+2.1.1.  Connection-Flow Denial-of-Service (DoS)
+
+   OPES processors, callout servers, and data consumer applications can
+   be vulnerable to DoS attacks.  DoS attacks can be of various types.
+   One example of a DoS attack is the overloading of OPES processors or
+   callout servers by spurious service requests issued by a malicious
+   node, which denies the legal data traffic the necessary resources to
+   render service.  The resources include CPU cycles, memory, network
+   interfaces, etc.  A Denial-of-Service attack can be selective,
+   generic, or random in terms of which communication streams are
+   affected.
+
+   Distributed DoS is also possible when an attacker successfully
+   directs multiple nodes over the network to initiate spurious service
+   requests to an OPES processor (or callout server) simultaneously.
+
+2.1.2.  Threats to Network Robustness
+
+   If OPES implementation violates end-to-end addressing principles, it
+   could endanger the Internet infrastructure by complicating routing
+   and connection management.  If it does not use flow-control
+   principles for managing connections, or if it interferes with end-
+   to-end flow control of connections that it did not originate, then it
+   could cause Internet congestion.
+
+   An implementation that violates the IAB requirement of explicit IP
+   level addressing (for example, by adding OPES functional capabilities
+   to an interception proxy) may defeat some of the protective
+   mechanisms and safeguards built into the OPES architecture.
+
+2.2.  OPES Flow Application Level Threats
+
+   At the content level, threats to the OPES system can come from
+   outsiders or insiders.  The threat from outsiders is frequently
+   intentional.  Threats from insiders can be intentional or accidental.
+   Accidents may result from programming or configuration errors that
+   result in bad system behavior.
+
+   Application level problems and threats to the OPES systems are
+   discussed below:
+
+2.2.1.  Unauthorized OPES Entities
+
+   Although one party authorization is mandated by the OPES
+   architecture, such authorization occurs out-of-band.  Discovering the
+   presence of an OPES entity and verifying authorization requires
+   special actions and may present a problem.
+
+
+
+
+Barbir, et al.               Informational                      [Page 6]
+
+RFC 3837               Security Threats for OPES             August 2004
+
+
+   Adding notification and authorization information to the data
+   messages (by using base protocol extensions) may help, especially if
+   the data consumer's software is aware of such extensions.
+
+2.2.2.  Unauthorized Actions of Legitimate OPES Entities
+
+   According to the OPES architecture, the authorization is not tightly
+   coupled with specific rules and procedures triggered by the rules.
+   Even if a requirement to approve each particular rule and procedure
+   was set, it looks at least impractical, if not impossible, to request
+   such permission from the end user.  Authorization granularity extends
+   to transformation classes, but not to individual rules or
+   transformations.  The actual rules and triggered procedures may
+   (maliciously or due to a programming error) perform actions that they
+   are not authorized for.
+
+2.2.3.  Unwanted Content Transformations
+
+   An authorized OPES service may perform actions that do not adhere to
+   the expectations of the party that gave the authorization for the
+   service.  Examples may include ad flooding by a local ad insertion
+   service or use of inappropriate policy by a content filtering
+   service.
+
+   On the other hand, an OPES entity acting on behalf of one party may
+   perform transformations that another party deems inappropriate.
+   Examples may include replacing ads initially inserted by the content
+   provider or applying filtering transformations that change the
+   meaning of the text.
+
+2.2.4.  Corrupted Content
+
+   The OPES system may deliver outdated or otherwise distorted
+   information due to programming problems or as a result of malicious
+   attacks.  For example, a compromised server, instead of performing an
+   OPES service, may inject bogus content.  Such an action may be an act
+   of cyber-vandalism (including virus injection) or intentional
+   distribution of misleading information (such as manipulations with
+   financial data).
+
+   A compromised OPES server or malicious entity in the data flow may
+   introduce changes specifically intended to cause improper actions in
+   the OPES server or callout server.  These changes may be in the
+   message body, headers, or both.  This type of threat is discussed in
+   more detail below.
+
+
+
+
+
+
+Barbir, et al.               Informational                      [Page 7]
+
+RFC 3837               Security Threats for OPES             August 2004
+
+
+2.2.5.  Threats to Message Structure Integrity
+
+   An OPES server may add, remove, or delete certain headers in a
+   request and/or response message (for example, to implement additional
+   privacy protection or assist in content filtering).  Such changes may
+   violate end-to-end integrity requirements or defeat services that use
+   information provided in such headers (for example, some local
+   filtering services or reference-based services).
+
+2.2.6.  Granularity of Protection
+
+   OPES services have implicit permission to modify content.  However,
+   the permissions generally apply only to portions of the content, for
+   example, URL's between particular HTML tags, text in headlines, or
+   URL's matching particular patterns.  In order to express such
+   policies, one must be able to refer to portions of messages and to
+   detect modifications to message parts.
+
+   Because there is currently very little support for policies that are
+   expressed in terms of message parts, it will be difficult to
+   attribute any particular modification to a particular OPES processor,
+   or to automatically detect policy violations.
+
+   A fine-grained policy language should be devised, and it could be
+   enforced using digital signatures.  This would avoid the problems
+   inherent in hop-by-hop data integrity measures (see next section).
+
+2.2.7.  Risks of Hop-by-Hop Protection
+
+   Generally, OPES services cannot be applied to data protected with
+   end-to-end encryption methods because the decryption key cannot be
+   shared with OPES processors without compromising the intended
+   confidentiality of the data.  This means that if the endpoint
+   policies permit OPES services, the data must either be transmitted
+   without confidentiality protections or an alternative model to end-
+   to-end encryption must be developed, one in which the confidentiality
+   is guaranteed hop-by-hop.  Extending the end-to-end encryption model
+   is out of scope of this work.
+
+   OPES services that modify data are incompatible with end-to-end
+   integrity protection methods, and this work will not attempt to
+   define hop-by-hop integrity protection methods.
+
+2.2.8.  Threats to Integrity of Complex Data
+
+   The OPES system may violate data integrity by applying inconsistent
+   transformations to interrelated data objects or references within the
+   data object.  Problems may range from a broken reference structure
+
+
+
+Barbir, et al.               Informational                      [Page 8]
+
+RFC 3837               Security Threats for OPES             August 2004
+
+
+   (modified/missing targets, references to wrong locations or missing
+   documents) to deliberate replacement/deletion/insertion of links that
+   violate intentions of the content provider.
+
+2.2.9.  Denial of Service (DoS)
+
+   The data consumer application may not be able to access data if the
+   OPES system fails for any reason.
+
+   A malicious or malfunctioning node may be able to block all traffic.
+   The data traffic destined for the OPES processor (or callout server)
+   may not be able to use the services of the OPES device.  The DoS may
+   be achieved by preventing the data traffic from reaching the
+   processor or the callout server.
+
+2.2.10.  Tracing and Notification Information
+
+   Inadequate or vulnerable implementation of the tracing and
+   notification mechanisms may defeat safeguards built into the OPES
+   architecture.
+
+   Tracing and notification facilities may become a target of malicious
+   attack.  Such an attack may create problems in discovering and
+   stopping other attacks.
+
+   The absence of a standard for tracing and notification information
+   may present an additional problem.  This information is produced and
+   consumed by the independent entities (OPES servers/user agents/
+   content provider facilities).  This calls for a set of standards
+   related to each base protocol in use.
+
+2.2.11.  Unauthenticated Communication in OPES Flow
+
+   There are risks and threats that could arise from unauthenticated
+   communication between the OPES server and callout servers.  Lack of
+   use of strong authentication between OPES processors and callout
+   servers may open security holes whereby DoS and other types of
+   attacks (see sections [2 and 3]) can be performed.
+
+3.  Threats to Out-of-Band Data
+
+   The OPES architecture separates a data flow from a control
+   information flow (loading rulesets, trust establishment, tracing,
+   policy propagation, etc.).  There are certain requirements set for
+   the latter, but no specific mechanism is prescribed.  This gives more
+   flexibility for implementations, but creates more burden for
+   implementers and potential customers to ensure that each specific
+
+
+
+
+Barbir, et al.               Informational                      [Page 9]
+
+RFC 3837               Security Threats for OPES             August 2004
+
+
+   implementation meets all requirements for data security, entity
+   authentication, and action authorization.
+
+   In addition to performing correct actions on the OPES data flow, any
+   OPES implementation has to provide an adequate mechanism to satisfy
+   requirements for out-of-band data and signaling information
+   integrity.
+
+   Whatever the specific mechanism may be, it inevitably becomes subject
+   to multiple security threats and possible attacks.  The way the
+   threats and attacks may be realized depends on implementation
+   specifics but the resulting harm generally falls into two categories:
+   threats to OPES data flow and threats to data integrity.
+
+   The specific threats are:
+
+3.1.  Threats that Endanger the OPES Data Flow
+
+   Any weakness in the implementation of a security, authentication, or
+   authorization mechanism may open the door to the attacks described in
+   section 2.
+
+   An OPES system implementation should address all these threats and
+   prove its robustness and ability to withstand malicious attacks or
+   networking and programming problems.
+
+3.2.  Inaccurate Accounting Information
+
+   Collecting and reporting accurate accounting data may be vital when
+   OPES servers are used to extend a business model of a content
+   provider, service provider, or as a basis for third party service.
+   The ability to collect and process accounting data is an important
+   part of OPES' system functionality.  This functionality may be
+   challenged by distortion or destruction of base accounting data
+   (usually logs), processed accounting data, accounting parameters, and
+   reporting configuration.
+
+   As a result a data consumer may be inappropriately charged for
+   viewing content that was not successfully delivered, or a content
+   provider or independent OPES services provider may not be compensated
+   for the services performed.
+
+   The OPES system may use accounting information to distribute
+   resources between different consumers or limit resource usage by a
+   specific consumer.  In this case an attack on the accounting system
+   (by distortion of data or issuing false configuration commands) may
+   result in incorrect resource management and DoS by artificial
+   resource starvation.
+
+
+
+Barbir, et al.               Informational                     [Page 10]
+
+RFC 3837               Security Threats for OPES             August 2004
+
+
+3.3.  OPES Service Request Repudiation
+
+   An entity (producer or consumer) might make an authorized request and
+   later claim that it did not make that request.  As a result, an OPES
+   entity may be held liable for unauthorized changes to the data flow,
+   or will be unable to receive compensation for a service.
+
+   There should be a clear request that this service is required and
+   there should be a clear course of action on behalf of all parties.
+   This action should have a request, an action, a non-repudiable means
+   of verifying the request, and a means of specifying the effect of the
+   action.
+
+3.4.  Inconsistent Privacy Policy
+
+   The OPES entities may have privacy policies that are not consistent
+   with the data consumer application or content provider application.
+
+   Privacy related problems may be further complicated if OPES entities,
+   content providers, and end users belong to different jurisdictions
+   with different requirements and different levels of legal protection.
+   As a result, the end user may not be aware that he or she does not
+   have the expected legal protection.  The content provider may be
+   exposed to legal risks due to a  failure to comply with regulations
+   of which he is not even aware.
+
+3.5.  Exposure of Privacy Preferences
+
+   The OPES system may inadvertently or maliciously expose end user
+   privacy settings and requirements.
+
+3.6.  Exposure of Security Settings
+
+   There are risks that the OPES system may expose end user security
+   settings when handling the request and responses.  The user data must
+   be handled as sensitive system information and protected against
+   accidental and deliberate disclosure.
+
+3.7.  Improper Enforcement of Privacy and Security Policy
+
+   OPES entities are part of the content distribution system and as such
+   take on certain obligations to support security and privacy policies
+   mandated by the content producer and/or end user.  However there is a
+   danger that these policies are not properly implemented and enforced.
+   The data consumer application may not be aware that its protections
+   are no longer in effect.
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 11]
+
+RFC 3837               Security Threats for OPES             August 2004
+
+
+   There is also the possibility of security and privacy leaks due to
+   the accidental misconfiguration or, due to misunderstanding what
+   rules are in effect for a particular user or request.
+
+   Privacy and security related parts of the systems can be targeted by
+   malicious attacks and the ability to withstand such attacks is of
+   paramount importance.
+
+3.8.  DoS Attacks
+
+   DoS attacks can be of various types.  One type of DoS attack takes
+   effect by overloading the client.  For example, an intruder can
+   direct an OPES processor to issue numerous responses to a client.
+   There is also additional DoS risk from a rule misconfiguration that
+   would have the OPES processor ignore a data consumer application.
+
+4.  Security Considerations
+
+   This document discusses multiple security and privacy issues related
+   to the OPES services.
+
+5.  References
+
+5.1.  Normative References
+
+   [1]  Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An
+        Architecture for Open Pluggable Edge Services (OPES)", RFC 3835,
+        August 2004.
+
+   [2]  Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and R.
+        Penno, "OPES Use Cases and Deployment Scenarios", RFC 3752,
+        April 2004.
+
+   [3] Barbir, A., Batuner, O., Beck, A., Chan, T., and H. Orman,
+        "Policy, Authorization, and Enforcement Requirements of Open
+        Pluggable Edge Services (OPES)", RFC 3838, August 2004.
+
+5.2.  Informative References
+
+   [4]  Floyd, S. and L. Daigle, "IAB Architectural and Policy
+        Considerations for Open Pluggable Edge Services", RFC 3238,
+        January 2002.
+
+6.  Acknowledgements
+
+   Many thanks to T. Chan (Nokia) and A. Beck (Lucent).
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 12]
+
+RFC 3837               Security Threats for OPES             August 2004
+
+
+7.  Authors' Addresses
+
+   Abbie Barbir
+   Nortel Networks
+   3500 Carling Avenue
+   Nepean, Ontario  K2H 8E9
+   Canada
+
+   Phone: +1 613 763 5229
+   EMail: abbieb@nortelnetworks.com
+
+
+   Oskar Batuner
+   Independent consultant
+
+   EMail: batuner@attbi.com
+
+
+   Bindignavile Srinivas
+   Nokia
+   5 Wayside Road
+   Burlington, MA  01803
+   USA
+
+   EMail: bindignavile.srinivas@nokia.com
+
+
+   Markus Hofmann
+   Bell Labs/Lucent Technologies
+   Room 4F-513
+   101 Crawfords Corner Road
+   Holmdel, NJ  07733
+   US
+
+   Phone: +1 732 332 5983
+   EMail: hofmann@bell-labs.com
+
+
+   Hilarie Orman
+   Purple Streak Development
+
+   EMail: ho@alum.mit.edu
+
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 13]
+
+RFC 3837               Security Threats for OPES             August 2004
+
+
+8.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  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 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
+   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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Barbir, et al.               Informational                     [Page 14]
+