Network Working Group B.S. Srinivas
Internet Draft T. Chan
Expires: December 2002 Nokia
File: draft-srinivas-opes-threats-00.txt
June 2002
Security Threats and Risks for Open Pluggable Edge Services
draft-srinivas-opes-threats-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119].
1. Abstract
This Internet Draft is an attempt to define the security threats
against the OPES protocol. In addition to the threats, the effects
of such security threats on the underlying architecture as well as
the requirements of a security solution to mitigate such threats are
discussed. The threats and requirements identified herein and the
document should be considered as work in progress.
Internet Draft Security Threats for OPES June 2002
2. Introduction
The data stream flowing between a content provider and one or more
content consumers may be in need of modifications as a function of
the needs of the consumer, the constraints of her/his device,
her/his geographical location and numerous other factors. These
modifications to the traditional scenario (see Figure 1) are
engineered by means of other application entities. The functions
that we have in mind include language translation, virus scanning,
bit-rate reduction in compliance with limited bandwidth
availability, and many others (see Figure 2).
------------ ------------
| | /----------------\ | |
| Content | \ / \ \ | Content |
| Provider |--------/ IP \----------| Consumer |
| | / \ Network / / | |
------------ \ / ------------
\----------------/
Figure 1: Traditional non-OPES scenario
------------
| |
| Content |
| Provider |
| |
------------
| |
|
/-|- -|----\
/ | \
--------/ | | \---|
| | |
| IP n/w | | | ------------
| ---------------| | | Callout |
| | OPES | |---------------------| Server |
| | Intermediary | |- - - - - - - - - - -| |
| | | | ------------
| ---------------- |
| | | |
--------\ | /-----
\ | | /
\-|------/
| | ------ Content flow
------------ - - - Signaling flow
| |
| Content |
| Consumer |
| |
------------
Figure 2:OPES Network Architecture
Srinivas, Chan Expires December 2002 [Page 2]
Internet Draft Security Threats for OPES June 2002
Either the application entities, referred to in the preceding text,
may be collocated with either of the two ends of the data stream or
it may be a discrete entity situated elsewhere within the network.
The last scenario comprises a data stream scenario, which is
referred to as Open Pluggable Edge Services (OPES). Several such
provisioning scenarios are described in [OPES-SCENE].
The document discusses several additional security threats, which
the data stream might be exposed to owing to the presence of a
discrete entity, the OPES intermediary (and call-out servers [OPES-
CALLOUT], if any), that provides the needed modification services.
Here by data stream, we imply both the content stream as well as the
signaling stream (to indicate the desired transformation). As
illustrated in Figure 2, the content stream flows from the content
provider to the OPES intermediary, which may further be forwarded to
a call-out server and returned, then finally delivered to the
content consumer after all the desired transformations are
performed. The signaling information (or transformation requests)
can originate from either the Content provider or consumer.
Moreover, the OPES intermediary may send transformation requests to
call-out servers as well. Attacks related to the signaling stream
and content stream may have different results and need to be
considered separately.
New functionality when added to a networking architecture invariably
creates new possibilities for tampering with some signaling
communications, as well as user data traffic. In other words,
various forms of protection including physical and/or programmatic
means are lowered, resulting in new security vulnerabilities. In
addition to the threats, the document also presents the impacts of
these threats as well as the requirements of the security solutions
to mitigate such threats.
Notice that the security threats corresponding to a content/services
delivery system without an OPES intermediary, as depicted in Figure
1, is considered out-of-scope and therefore will not be discussed in
this document. This document only focuses on threats that are
introduced by the existence of the OPES intermediary and call-out
servers.
The document is organized as follows: Section 3 discusses the
security threats introduced by the OPES functionality. Section 4
discusses the Intellectual Property rights issues if any.
3. Threats
With the incorporation of an additional application entity namely
the OPES intermediary, despite its operation on the data flow
between the content producer and consumer being authorized, a new
site for exposure to threats from malicious entities is introduced.
A whole array of threats, their effects and the suggested security
solutions are discussed herein. The threats discussed are congruent
with the security considerations raised in [RFC3238].
Srinivas, Chan Expires December 2002 [Page 3]
Internet Draft Security Threats for OPES June 2002
In the traditional non-OPES scenario, the communicating end-points
(the content producer and consumer) have a direct one-to-one
association between them (see Figure 1). This direct association is
broken by the existence of OPES intermediaries or callout servers.
The secure operation of protocols, typically, depends on assumptions
regarding the identity of the endpoints and the continuity of
communication between them. The operation of OPES itself has
security implications and risks.
3.1. OPES device false registration/deregistration
Threat: In the event of the OPES intermediary being absent, a false
registration / deregistration could be sent by a malicious node on
behalf of the non-existent OPES intermediary.
Effect: A false registration / deregistration would result in the
end-system traffic being hijacked by the malicious node. The traffic
is then eavesdropped on by the attacker. Moreover, unwanted or
malicious transformation of the data traffic would occur.
Alternatively, the malicious node may simply refuse to forward the
data traffic to the content consumer, resulting in a Denial-of-
Service attack.
Solution: Either of the end-points MUST authenticate and authorize
the OPES intermediary before directing any traffic to it. The
content consumer MUST NOT accept any (modified) traffic, which has
been transformed by an unauthenticated or unauthorized entity.
3.2. OPES device spoofing
Threat: A malicious node could send false information about an
intermediate device masquerading as an OPES device. Alternatively,
despite the presence of a genuine OPES device which has been
authenticated, the actual data transformation could be performed in
a malicious call-out server.
Effect: Similar to the previous case, the malicious device would be
able to eavesdrop on all traffic (both data and signaling) between
the end-systems. In addition, unexpected and undesirable data
transformation by the malicious intermediary or call-out server
would result. For example, the malicious node could force the
consumer or producer to use the services of a malicious OPES
intermediary, which renders very expensive transformation services.
Finally, a malicious OPES intermediary may refuse to forward the
traffic, resulting in a Denial-of-Service attack.
Solution: The OPES intermediary device and the associated call-out
server (if any) MUST be authenticated and authorized before any
messages are sent through it. Notice that the transformation MAY
Srinivas, Chan Expires December 2002 [Page 4]
Internet Draft Security Threats for OPES June 2002
require more than one call-out server, in which case, all of them
need to be authenticated.
3.3. Malicious node performs a replay attack
Threat: A malicious node could passively eavesdrop on one of the
communication channels and replay the recorded message (signaling or
data) later. The signaling request from either the producer or the
consumer to the OPES intermediary is open to such a kind of replay
attack. Alternatively, a malicious nodethat serves as the OPES
intermediary for two distinct data flows could replay the message
from one data flow onto another.
Effect: False or spurious action is performed by the OPES device or
call-out server. A false transformation could be performed by the
OPES device by replaying a transformation request issued by the
consumer on a previous occasion. In addition, the transformed
content could be replayed to the consumer as genuine content.
Solution: Care, in the form of sequence numbers, or other
techniques, MUST be taken to prevent replay attacks. Authentication
of OPES intermediaries is required such that malicious OPES devices
will not be used, thereby reducing the possibility of content
replay.
3.4. Re-establishing end-device - OPES device security during failover
Threat: End-device (producer or consumer) fails over from OPES
intermediary A to OPES intermediary B. A trust relationship between
the end-device and A will not automatically translate into the same
relationship existing between the end-device and B.
Effect: If there was a trust relationship involving a security
context between the end-device and A, the equivalent trust
relationship between the end-device and B will not exist in the
event of a failover from A to B. The assumption of such a trust
relationship opens up security holes for malicious OPES
intermediaries to perform all kinds of attacks.
Solution: Either notify the application when failover occurs so that
the application MAY take appropriate action to establish a trust
relationship between the end-device and B or reestablish the
security context transparently.
3.5. Message Integrity
Threat: Message flow through the OPES device is corrupted. By being
corrupted, the implication is that, a message, which has been
subject to unauthorized modification prior to the OPES intermediary,
is inputted into the OPES intermediary (or call-out server). The
modification can be on the signaling information related to the
actions the OPES device needs to perform; or it can be on the
contents that need to be transformed.
Srinivas, Chan Expires December 2002 [Page 5]
Internet Draft Security Threats for OPES June 2002
Effect: Corrupted information is received which causes the OPES
device to either transform the content in a wrong way, or transform
the wrong content, generating a wrong output.
Solution: Integrity mechanism is needed to protect both the actions
specified as well as the contents of all the OPES messages. These
could include hashing functions, for instance.
3.6. Data Confidentiality
Threat: An eavesdropper is typically capable of snooping on fields
within messages in transit. Using various eavesdropping techniques,
he may be able to garner various kinds of information including
topology/location/IP addresses etc. that may not be desirable to
divulge. He also may be able to eavesdrop on the content messages
being delivered to the consumer. The delivery of the shared
encryption keys to the OPES intermediary is subject to the threat of
being eavesdropped on by a malicious entity.
Effect: Information that session participants or an administrator do
not wish to divulge is divulged. If shared encryption keys are
compromised during key distribution, attackers will be able to
decrypt encrypted content.
Solution: Data confidentiality service MUST be provisioned using
various kinds of encryption. This could be carried out using either
a shared key or PKI, for instance. Special care needs to be taken in
the delivery of the key information to the OPES intermediary and the
callout server (if present).
3.7. Denial-of-Service (DoS)
Threat: A hostile or malicious node MAY be able to block all traffic
on an unprotected link. The data traffic destined for the OPES
intermediary (or call-out 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 intermediary or the call-out
server. Alternatively, the intermediary or the call-out server can
be overloaded 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. In addition, a malicious node that successfully
spoofs as an OPES intermediary (or call-out server) can launch DoS
attacks simply by not forwarding the legitimate traffic to the
content consumers. A Denial-of-Service attack can be selective,
generic or random in terms of which communication streams are
affected [MIP-DOS].
Distributed DoS is also possible when an attacker successfully
directs multiple nodes over the network to initiate spurious service
requests to an OPES intermediary (or call-out server) simultaneously
MIP-DOS].
Srinivas, Chan Expires December 2002 [Page 6]
Internet Draft Security Threats for OPES June 2002
Effect: Legal data traffic is unable to acquire the services of the
OPES intermediary (or call-out server) to achieve the desired
transformation.
Solution: Malicious data traffic emanating from particular suspect
ports or IP addresses SHOULD be denied access to the OPES
intermediary.
3.8.Authorized entity later repudiates a request
Threat: An entity (producer or consumer) that is authorized to make
a certain request of the OPES intermediary claims, later, that it
did not make that request.
Effect: The entity that repudiates a valid request for
transformation by the OPES intermediary MAY be held liable for asked
for changes to the data flow.
Requirement: Non-repudiation of requests for transformation of a
data flow by an OPES intermediary or a call-out server needs to be
provided. This could be accomplished by, for instance, use of
private keys in encrypting the request for a transformation service.
4. Intellectual Property Rights
The authors are not aware of any intellectual property right issues
pertaining to this document.
5. References
[OPES-SCENE] McHenry, S., et. al, "OPES Scenarios and Use Cases",
Internet-Draft TBD, May 2002.
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC
3238, January 2002.
[OPES-CALLOUT] Beck, A., et. al, "Requirements for OPES Callout
Protocols," work in progress, May 2002, <draft-ietf-opes-
protocol-reqs-00>.
[MIP-DOS] Nikander, P., et. al, "Threat Models introduced by Mobile
IPv6 and Requirements for Security in Mobile IPv6", work in progress,
December 2001, <draft-team-mobileip-mipv6-sec-reqts-00.txt>.
6. Authors' Addresses
Bindignavile S. Srinivas
Tat Chan
Nokia Research Center
Srinivas, Chan Expires December 2002 [Page 7]
Internet Draft Security Threats for OPES June 2002
5 Wayside Road
Burlington, MA 01803
USA
Email: {bindignavile.srinivas,tat.chan}@nokia.com
1. Abstract........................................................1
2. Introduction....................................................2
3. Threats.........................................................3
3.1. OPES device false registration/deregistration..............4
3.2. OPES device spoofing.......................................4
3.3. Malicious node performs a replay attack....................5
3.4. Re-establishing end-device - OPES device security during
failover........................................................5
3.5. Message Integrity..........................................5
3.6. Data Confidentiality.......................................6
3.7. Denial-of-Service (DoS)....................................6
3.8. Authorized entity later repudiates a request...............7
4. Intellectual Property Rights....................................7
5. References......................................................7
6. Authors' Addresses..............................................7
Full Copyright Statement...........................................8
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Srinivas, Chan Expires December 2002 [Page 8]
Internet Draft Security Threats for OPES June 2002
Funding for the RFC Editor function is currently provided by the
Internet Society.
Srinivas, Chan Expires December 2002 [Page 9]