< draft-ietf-opes-threats-02.txt		draft-ietf-opes-threats-03.txt >
	Network Working Group A. Barbir		Network Working Group A. Barbir
	Internet-Draft Nortel Networks		Internet-Draft Nortel Networks
	Expires: August 11, 2003 O. Batuner		Expires: June 7, 2004 O. Batuner
	Independent consultant		Independent consultant
	B. Srinivas		B. Srinivas
	Nokia		Nokia
	M. Hofmann		M. Hofmann
	Bell Labs/Lucent Technologies		Bell Labs/Lucent Technologies
	H. Orman		H. Orman
	Purple Streak Development		Purple Streak Development
	February 10, 2003		December 8, 2003
	Security Threats and Risks for OPES		Security Threats and Risks for OPES
	draft-ietf-opes-threats-02		draft-ietf-opes-threats-03
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	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 other		Task Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 http://		The list of current Internet-Drafts can be accessed at http://
	www.ietf.org/ietf/1id-abstracts.txt.		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 August 11, 2003.		This Internet-Draft will expire on June 7, 2004.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2003). All Rights Reserved.		Copyright (C) The Internet Society (2003). All Rights Reserved.
	Abstract		Abstract
	The document investigates the security threats associated with OPES.		The document investigates the security threats associated with OPES.
	The effects of security threats on the underlying architecture are		The effects of security threats on the underlying architecture are
	discussed. The main goal of this document is threat discovery and		discussed. The main goal of this document is threat discovery and
	skipping to change at page 2, line 20 ¶		skipping to change at page 2, line 20 ¶
	2.1.1 Connection-Flow Denial-of-Service (DoS) . . . . . . . . . 6		2.1.1 Connection-Flow Denial-of-Service (DoS) . . . . . . . . . 6
	2.1.2 Threats to network robustness . . . . . . . . . . . . . . 7		2.1.2 Threats to network robustness . . . . . . . . . . . . . . 7
	2.2 OPES Flow Application Level Threats . . . . . . . . . . . 7		2.2 OPES Flow Application Level Threats . . . . . . . . . . . 7
	2.2.1 Unauthorized OPES entities . . . . . . . . . . . . . . . . 7		2.2.1 Unauthorized OPES entities . . . . . . . . . . . . . . . . 7
	2.2.2 Unauthorized actions of legitimate OPES entities . . . . . 7		2.2.2 Unauthorized actions of legitimate OPES entities . . . . . 7
	2.2.3 Unwanted content transformations . . . . . . . . . . . . . 8		2.2.3 Unwanted content transformations . . . . . . . . . . . . . 8
	2.2.4 Corrupted content . . . . . . . . . . . . . . . . . . . . 8		2.2.4 Corrupted content . . . . . . . . . . . . . . . . . . . . 8
	2.2.5 Threats to message structure integrity . . . . . . . . . . 8		2.2.5 Threats to message structure integrity . . . . . . . . . . 8
	2.2.6 Granularity of protection . . . . . . . . . . . . . . . . 9		2.2.6 Granularity of protection . . . . . . . . . . . . . . . . 9
	2.2.7 Risks of hop-by-hop protection . . . . . . . . . . . . . . 9		2.2.7 Risks of hop-by-hop protection . . . . . . . . . . . . . . 9
	2.2.8 Threats to integrity of complex data . . . . . . . . . . . 10		2.2.8 Threats to integrity of complex data . . . . . . . . . . . 9
	2.2.9 Denial of Service (DoS) . . . . . . . . . . . . . . . . . 10		2.2.9 Denial of Service (DoS) . . . . . . . . . . . . . . . . . 9
	2.2.10 Tracing and notification information . . . . . . . . . . . 10		2.2.10 Tracing and notification information . . . . . . . . . . . 10
	2.2.11 Unauthenticated Communication in OPES Flow . . . . . . . . 10		2.2.11 Unauthenticated Communication in OPES Flow . . . . . . . . 10
	3. Threats to out-of-band data . . . . . . . . . . . . . . . 11		3. Threats to out-of-band data . . . . . . . . . . . . . . . 11
	3.1 Threats that endanger the OPES data flow . . . . . . . . . 11		3.1 Threats that endanger the OPES data flow . . . . . . . . . 11
	3.2 Inaccurate Accounting Information . . . . . . . . . . . . 11		3.2 Inaccurate Accounting Information . . . . . . . . . . . . 11
	3.3 OPES service request repudiation . . . . . . . . . . . . . 12		3.3 OPES service request repudiation . . . . . . . . . . . . . 12
	3.4 Inconsistent privacy policy . . . . . . . . . . . . . . . 12		3.4 Inconsistent privacy policy . . . . . . . . . . . . . . . 12
	3.5 Exposure of privacy preferences . . . . . . . . . . . . . 12		3.5 Exposure of privacy preferences . . . . . . . . . . . . . 12
	3.6 Exposure of security settings . . . . . . . . . . . . . . 12		3.6 Exposure of security settings . . . . . . . . . . . . . . 12
	3.7 Improper enforcement of privacy and security policy . . . 13		3.7 Improper enforcement of privacy and security policy . . . 13
	skipping to change at page 9, line 27 ¶		skipping to change at page 9, line 27 ¶
	or to automatically detect policy violations.		or to automatically detect policy violations.
	A fine-grained policy language should be devised, and it could be		A fine-grained policy language should be devised, and it could be
	enforced using digital signatures. This would avoid the problems		enforced using digital signatures. This would avoid the problems
	inherent in hop-by-hop data integrity measures (see next section).		inherent in hop-by-hop data integrity measures (see next section).
	2.2.7 Risks of hop-by-hop protection		2.2.7 Risks of hop-by-hop protection
	OPES services cannot be applied to data protected with end-to-end		OPES services cannot be applied to data protected with end-to-end
	encryption methods because, by definition, the decryption key cannot		encryption methods because, by definition, the decryption key cannot
	be shared with OPES processors. This means that if the endpoint		be shared with OPES processors. This means that if the endpoint
	policies permit OPES services, the data must either be transmitted		policies permit OPES services, the data must either be transmitted
	without confidentiality protections or else with an alternative to		without confidentiality protections or an alternative model to
	end-to-end encryption: hop-by-hop encryption. In the latter case, all		end-to-end (hop-by-hop) encryption be developed. Extending the
	the parties in the OPES processing path must understand the		end-to-end encryption model is out of scope of this work. In this
	encryption requirement and negotiate encrypted connections with their		work security is end-to-end. OPES services cannot be performed if
	OPES partners.		endpoints need security.
	Hop-by-hop protection is less effective than end-to-end protection,
	because any processor in the path which shares a cryptographic key,
	can violate the confidentiality or integrity of the data without
	detection.
	If a pair of processors in the delivery path use weak cryptography or
	manage keys poorly, there is a danger of data leakage. For this
	reason, different cryptographic keys should be used for each leg of
	the data stream.
	Even if the data is not confidential, one might desire some checks on
	data integrity, to avoid modifications by unauthorized parties. The
	comments above apply to the use of end-to-end integrity, if it is
	based on shared-key cryptography. Again, it should be possible to
	use hop-by-hop data integrity to protect data as it moves between
	protection domains.
	Currently there is no method to signal hop-by-hop encryption or
	integrity requirements. Either this must be added to the application
	protocol, or OPES must define its own signaling protocol, or all OPES
	traffic MUST ALWAYS be encrypted.
	2.2.8 Threats to integrity of complex data		2.2.8 Threats to integrity of complex data
	The OPES system may violate data integrity by applying inconsistent		The OPES system may violate data integrity by applying inconsistent
	transformations to interrelated data objects or references within the		transformations to interrelated data objects or references within the
	data object. Problems may range from a broken reference structure		data object. Problems may range from a broken reference structure
	(modified/missing targets, references to wrong locations or missing		(modified/missing targets, references to wrong locations or missing
	documents) to deliberate replacement/deletion/insertion of links that		documents) to deliberate replacement/deletion/insertion of links that
	violate intentions of the content provider.		violate intentions of the content provider.
	skipping to change at page 12, line 20 ¶		skipping to change at page 12, line 20 ¶
	incorrect resource management and DoS by artificial resource		incorrect resource management and DoS by artificial resource
	starvation.		starvation.
	3.3 OPES service request repudiation		3.3 OPES service request repudiation
	An entity (producer or consumer) makes an authorized request and		An entity (producer or consumer) makes an authorized request and
	claim, later, that it did not make that request. As a result an OPES		claim, later, that it did not make that request. As a result an OPES
	entity may be held liable for unauthorized changes to the data flow,		entity may be held liable for unauthorized changes to the data flow,
	or will be unable to receive compensation for a service.		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 request that this service is required and
	there SHOULD be a clear course of action on the behalf of all		there should be a clear course of action on the behalf of all
	parties. This action SHOULD have a request, and SHOULD have an		parties. This action should have a request, and should have an
	action, and SHOULD have a means of repudiation of the request, and		action, and should have a means of repudiation of the request, and
	SHOULD have a means to specify the effect of the action.		should have a means to specify the effect of the action.
	3.4 Inconsistent privacy policy		3.4 Inconsistent privacy policy
	The OPES entities may have privacy policies that are not consistent		The OPES entities may have privacy policies that are not consistent
	with the data consumer application or content provider application.		with the data consumer application or content provider application.
	Privacy related problems may be further complicated if OPES entities,		Privacy related problems may be further complicated if OPES entities,
	content providers and end users belong to different jurisdictions		content providers and end users belong to different jurisdictions
	with different requirements and different levels of legal protection.		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		As a result the end user may not be aware that he or she does not
	skipping to change at page 20, line 7 ¶		skipping to change at page 20, line 7 ¶
	The limited permissions granted above are perpetual and will not be		The limited permissions granted above are perpetual and will not be
	revoked by the Internet Society or its successors or assignees.		revoked by the Internet Society or its successors or assignees.
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Acknowledgement		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes. 9 change blocks.
	40 lines changed or deleted		18 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/