< draft-tschofenig-dime-e2e-sec-req-00.txt		draft-tschofenig-dime-e2e-sec-req-01.txt >
	DIME H. Tschofenig, Ed.		DIME H. Tschofenig, Ed.
	Internet-Draft Nokia Siemens Networks		Internet-Draft Nokia Siemens Networks
	Intended status: Standards Track J. Korhonen		Intended status: Standards Track J. Korhonen
	Expires: August 22, 2013 Renesas Mobile		Expires: January 16, 2014 Renesas Mobile
	G. Zorn		G. Zorn
	Network Zen		Network Zen
	February 18, 2013		K. Pillay
			Oracle Communications
			July 15, 2013
	Diameter AVP Level Security: Requirements and Scenarios		Diameter AVP Level Security: Scenarios and Requirements
	draft-tschofenig-dime-e2e-sec-req-00.txt		draft-tschofenig-dime-e2e-sec-req-01.txt
	Abstract		Abstract
	This specification discusses requirements for providing Diameter		This specification discusses requirements for providing Diameter
	security at the level of individual Attribute Value Pairs.		security at the level of individual Attribute Value Pairs.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on August 22, 2013.		This Internet-Draft will expire on January 16, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 10		8.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . . 10		8.2. Informative References . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	The Diameter Base specification [1] offers security protection		The Diameter Base specification [2] offers security protection
	between neighboring Diameter peers and mandates that either TLS (for		between neighboring Diameter peers and mandates that either TLS (for
	TCP), DTLS (for SCTP), or IPsec is used. These security protocols		TCP), DTLS (for SCTP), or IPsec is used. These security protocols
	offer a wide range of security properties, including entity		offer a wide range of security properties, including entity
	authentication, data-origin authentication, integrity,		authentication, data-origin authentication, integrity,
	confidentiality protection and replay protection. They also support		confidentiality protection and replay protection. They also support
	a large number of cryptographic algorithms, algorithm negotiation,		a large number of cryptographic algorithms, algorithm negotiation,
	and different types of credentials.		and different types of credentials.
	The need to also offer additional security protection of AVPs between		The need to also offer additional security protection of AVPs between
	non-neighboring Diameter nodes was recognized very early in the work		non-neighboring Diameter nodes was recognized very early in the work
	skipping to change at page 3, line 29 ¶		skipping to change at page 2, line 45 ¶
	Cryptographic Message Syntax (CMS) [3]. Due to lack of deployment		Cryptographic Message Syntax (CMS) [3]. Due to lack of deployment
	interest at that time (and the complexity of the developed solution)		interest at that time (and the complexity of the developed solution)
	the specification was, however, never completed.		the specification was, however, never completed.
	In the meanwhile Diameter had received a lot of deployment interest		In the meanwhile Diameter had received a lot of deployment interest
	from the cellular operator community and because of the		from the cellular operator community and because of the
	sophistication of those deployments the need for protecting Diameter		sophistication of those deployments the need for protecting Diameter
	AVPs between non-neighboring nodes re-surfaced. Since early 2000		AVPs between non-neighboring nodes re-surfaced. Since early 2000
	(when the work on [3] was discontinued) the Internet community had		(when the work on [3] was discontinued) the Internet community had
	seen advances in cryptographic algorithms (for example, authenticated		seen advances in cryptographic algorithms (for example, authenticated
	encryption algorithms were developed) and new requirements emerged.		encryption algorithms were developed) and new security building
			blocks were developed.
	This document collects requirements for developing a solution to		This document collects requirements for developing a solution to
	protect Diameter AVPs.		protect Diameter AVPs.
	2. Terminology		2. Terminology
	The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT',		The key words '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
	specification are to be interpreted as described in [2].		specification are to be interpreted as described in [1].
	This document re-uses terminology from the Diameter base		This document re-uses terminology from the Diameter base
	specification [1].		specification [2].
	3. Use Case		3. Use Case
	Consider the following use case shown in Figure 1. A Diameter client		Consider the following use case shown in Figure 1 where a a Diameter
	interacts with a Diameter server through two Diameter proxies. The		client wants to interact with its home Diameter server in the
	Diameter client and the Diameter Proxy A belong to the same realm,		example.com realm. The visited domain the Diameter client is
	example.com.		attached to makes use of a AAA interconnection provider, shown as AAA
			Broker in our example. While both the administrators of the visited
			as well as the home domain are likely to main a business relationship
			with the intermediate AAA broker network they may want to ensure that
			certain Diameter AVPs are not sent in the clear or are integrity
			protected. Note that the security services are likely offered
			between Diameter Proxy A and Diameter Proxy D for ease of deployment.
			Proxy A may act on behalf of the Diameter client and Diameter Proxy D
			acts on behalf of Diameter Server X and Y it serves.
	****************************		+oooooooooooooooooo+ +====================+
	*		| | | |
	Realm: Example.com *		| | | |
	+--------+ +--------+ * +--------+ +--------+		+--------+ +--------+ +--------+ +--------+
	|Diameter| |Diameter| * |Diameter| |Diameter|		|Diameter| |Diameter| |Diameter| |Diameter|
	|Client +------+Proxy A +-*------+Proxy B +--------+Server |		|Client +------+Proxy A +--------+Proxy B +--------+Proxy C |----+
	+--------+ +--------+ * +--------+ +--------+		+--------+ +--------+ +--------+ +--------+ |
	^ * ^		| | | | |
	. End-to-End * Security Protection .		| Visited Domain | | AAA Broker | |
	+......................*.............................+		+oooooooooooooooooo+ +====================+ |
	*		|
	****************************		|
			|
			+\\\\\\\\\\\\\\\\\\\\+ |
			+--------+ Example.com | |
			|Diameter| | |
			|Server X+--+ +--------+ |
			+--------+ | |Diameter| |
			+--------+ +---------+Proxy D |----+
			|Diameter| | +--------+
			|Server Y+--+ |
			+--------+ Home Domain |
			+////////////////////+
	Figure 1: Example Diameter Deployment Setup.		Figure 1: Example Diameter Deployment Setup.
	The Diameter AVPs are protected end-to-end, from the Diameter client		Based on Figure 1 the following use cases can be differentiated. AVP
	to the Diameter server, as shown in Figure 1 with the dotted line.		refers to an unprotected AVP and {AVP}k refers to an AVP that
			experiences security protection without further distinguishing
			between integrity and confidentiality protection.
	Other use cases are possible as well. For example, Diameter Proxy A		In the first scenario, shown in Figure 2, end-to-end security
	could act on behalf of the Diameter clients in the example.com realm.		protection is provided between the Diameter client and the Diameter
	In a general case, however, encryption of AVPs between arbitrary		server. Diameter AVPs exchanged between these two Diameter nodes are
	Diameter nodes can be challenging since it is upfront not know what		protected.
	Diameter nodes a message will traverse.
	QUESTION: Which scenarios should be supported? Should the focus		+--------+ +--------+
	be on the protection of selected Diameter AVPs between the		|Diameter| AVP, {AVP}k |Diameter|
	Diameter client to the Diameter server only?		|Client +-----------------........... -------------------+Server |
			+--------+ +--------+
			Figure 2: End-to-End Diameter AVP Security Protection.
			In the second scenario, shown in Figure 3, a Diameter proxy acts on
			behalf of the Diameter client with regard to security protection. It
			applies security protection to outgoing Diameter AVPs and verifies
			incoming AVPs.
			+--------+ +--------+ +--------+
			|Diameter| AVP |Diameter| AVP, {AVP}k |Diameter|
			|Client +-----+Proxy A +---------- .......... -----------+Server |
			+--------+ +--------+ +--------+
			Figure 3: Middle-to-End Diameter AVP Security Protection.
			In the third scenario shown in Figure 4 a Diameter proxy acts on
			behalf of the Diameter server.
			+--------+ +--------+ +--------+
			|Diameter| AVP, {AVP}k |Diameter| AVP |Diameter|
			|Client +-----------------........... ----+Proxy D +-----+Server |
			+--------+ +--------+ +--------+
			Figure 4: End-to-Middle Diameter AVP Security Protection.
			The forth and final scenario (see Figure 5) is a combination of the
			end-to-middle and the middle-to-end scenario shown in Figure 4 and in
			Figure 3. From a deployment point of view this scenario is easier to
			accomplish for two reasons: First, Diameter clients and Diameter
			servers remain unmodified. This ensures that no modifications are
			needed to the installed Diameter infrastructure. Second, key
			management is also simplified since fewer number of key pairs need to
			be negotiated and provisioned.
			+--------+ +--------+ +--------+ +--------+
			|Diameter| AVP |Diameter| AVP, {AVP}k |Diameter| AVP |Diameter|
			|Client +-----+Proxy A +-- .......... ----+Proxy D +-----+Server |
			+--------+ +--------+ +--------+ +--------+
			Figure 5: Middle-to-Middle Diameter AVP Security Protection.
			Various security threats are mitigated by selectively applying
			security protection for individual Diameter AVPs. Without protection
			there is the possibility for password sniffing, confidentiality
			violation, AVP insertion, deletion or modification. Additionally,
			applying digital signature offers non-repudiation capabilities; a
			feature not yet available in todays Diameter deployment.
			Modification of certain Diameter AVPs may not necessarily be the act
			of malicious behavior but could also be the result of
			misconfiguration. An over-aggressively configured firewalling
			Diameter proxy may also remove certain AVPs. In most cases data
			origin authentication and integrity protection of AVPs will provide
			most benefits for existing deployments with minimal overhead and
			(potentially) operating in a full-backwards compatible manner.
	4. Requirements		4. Requirements
	Requirement #1: Solutions MUST support an extensible set of		Requirement #1: Solutions MUST support an extensible set of
	cryptographic algorithms.		cryptographic algorithms.
	Motivation: Crypto-agility is the ability of a protocol to		Motivation: Crypto-agility is the ability of a protocol to
	adapt to evolving cryptographic algorithms and security		adapt to evolving cryptographic algorithms and security
	requirements. This may include the provision of a modular		requirements. This may include the provision of a modular
	mechanism to allow cryptographic algorithms to be updated		mechanism to allow cryptographic algorithms to be updated
	without substantial disruption to deployed implementations.		without substantial disruption to deployed implementations.
	Requirement #2: Solutions MUST support confidentiality, integrity,		Requirement #2: Solutions MUST support confidentiality, integrity,
	and data-origin authentication.		and data-origin authentication. Solutions for integrity
			protection MUST work in a backwards-compatible way with existing
			Diameter applications.
	QUESTION: Should solutions for integrity protection work in a		Requirement #3: Solutions MUST support replay protection. Any
	backwards-compatible way with existing Diameter applications?		Diameter node has an access to network time and thus can
	Should the list of integrity protected AVP be indicated in the		synchronise their clocks.
	protected payload itself?
	Requirement #3: Solutions MUST support replay protection.		Requirement #4: Solutions MUST support the ability to delegate
			security functionality to another entity
	QUESTION: Should replay protection be based on timestamps		Motivation: As described in Section 3 the ability to let a
	(i.e., assume synchronized clocks in Diameter networks)?		Diameter proxy to perform security services on behalf of all
			clients within the same administrative domain is important for
			incremental deployability. The same applies to the other
			communication side where a load balancer terminates security
			services for the servers it interfaces.
	Requirement #4: Solutions MUST be able to selectively apply their		Requirement #5: Solutions MUST be able to selectively apply their
	cryptographic protection to certain Diameter AVPs.		cryptographic protection to certain Diameter AVPs.
	Requirement #5: Solutions MUST recommend a mandatory-to-implement		Motivation: Some Diameter applications assume that certain AVPs
			are added, removed, or modified by intermediaries. As such, it
			may be necessary to apply security protection selectively.
			Requirement #6: Solutions MUST recommend a mandatory-to-implement
	cryptographic algorithm.		cryptographic algorithm.
	Requirement #6: QUESTION: Should we support symmetric keys and / or		Motivation: For interoperability purposes it is beneficial to
	also asymmetric keys?		have a mandatory-to-implement cryptographic algorithm specified
			(unless profiles for specific usage environments specify
			otherwise).
	Requirement #7: QUESTION: Should requirements for dynamic key		Requirement #7: Solutions MUST support symmetric keys and asymmetric
	management be included in this document as well?		keys.
	Requirement #8: QUESTION: Should statically provisioned keys be		Motivation: Symmetric and asymmetric cryptographic algorithms
	supported?		provide different security services. Asymmetric algorithms,
			for example, allow non-repudiation services to be offered.
	Requirement #9: QUESTION: Should solutions allow the provisioning		Requirement #8: A solution for dynamic key management has to be
	of long-term shared symmetric credentials via a command-line		provided. It is assumed that no "new" key management protocol
	interface / text file?		needs to be developed; instead existing ones are re-used, if at
			all possible. Rekeying could be triggered by (a) management
			actions and (b) expiring keying material.
			Requirement #9: The ability to statically provisioned keys
			(symmetric as well as asymmetric keys) has to be supported to
			simplify management for small-scale deployments that typically do
			not have a backend network management infastructure.
			Requirement #10: Capability/Policy Discovery: This document talks
			about selectively protecting Diameter AVPs between different
			Diameter nodes. A Diameter node has to be configured such that it
			applies security protection to a certain number of AVPs. A number
			of policy related questions arise: What keying material should be
			used so that the intended recipient is also able to verify it?
			What AVPs shall be protected so that the result is not rejected by
			the recipient? In case of confidentiality protection the Diameter
			node encrypting AVPs needs to know ahead of time what other node
			is intended to decrypt them. Should the list of integrity
			protected AVP be indicated in the protected payload itself (or is
			it known based on out-of-band information)? Is this policy /
			capability information assumed to be established out-of-band
			(manually) or is there a protocol mechanism to distribute this
			information?
			Requirement #11: Command-Line Support: Should solutions allow the
			provisioning of long-term shared symmetric credentials via a
			command-line interface / text file? This allows easier management
			for small-scale deployments.
	5. Security Considerations		5. Security Considerations
	This entire document focused on the discussion of new functionality		This entire document focused on the discussion of new functionality
	for securing Diameter AVPs end-to-end.		for securing Diameter AVPs selectively between non-neighboring nodes.
	6. IANA Considerations		6. IANA Considerations
	This document does not require actions by IANA.		This document does not require actions by IANA.
	7. Acknowledgments		7. Acknowledgments
	We would like to thank Guenther Horn for his review comments.		We would like to thank Guenther Horn for his review comments.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[1] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter		[1] Bradner, S., "Key words for use in RFCs to Indicate
	Base Protocol", RFC 6733, October 2012.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[2] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
	Levels", BCP 14, RFC 2119, March 1997.		"Diameter Base Protocol", RFC 6733, October 2012.
	8.2. Informative References		8.2. Informative References
	[3] Calhoun, P., Farrell, S., and W. Bulley, "Diameter CMS Security		[3] Calhoun, P., Farrell, S., and W. Bulley, "Diameter CMS
	Application", draft-ietf-aaa-diameter-cms-sec-04 (work in		Security Application", draft-ietf-aaa-diameter-cms-sec-04
	progress), March 2002.		(work in progress), March 2002.
	Authors' Addresses		Authors' Addresses
	Hannes Tschofenig (editor)		Hannes Tschofenig (editor)
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Phone: +358 (50) 4871445		Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
	Jouni Korhonen		Jouni Korhonen
	Renesas Mobile		Renesas Mobile
	Porkkalankatu 24		Porkkalankatu 24
	Helsinki 00180		Helsinki 00180
	Finland		Finland
	Email: jouni.nospam@gmail.com		Email: jouni.nospam@gmail.com
	Glen Zorn		Glen Zorn
	Network Zen		Network Zen
	227/358 Thanon Sanphawut		227/358 Thanon Sanphawut
	Bang Na Bangkok 10260		Bang Na Bangkok 10260
	Thailand		Thailand
	Email: glenzorn@gmail.com		Email: glenzorn@gmail.com
			Kervin Pillay
			Oracle Communications
			100 Crosby Drive
			Bedford, Massachusettes 01730
			USA
			Email: kervin.pillay@oracle.com
End of changes. 33 change blocks.
	80 lines changed or deleted		199 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/