< draft-korhonen-dime-e2e-security-00.txt		draft-korhonen-dime-e2e-security-01.txt >
	DIME J. Korhonen		DIME J. Korhonen
	Internet-Draft H. Tschofenig		Internet-Draft H. Tschofenig
	Intended status: Standards Track Nokia Siemens Networks		Intended status: Standards Track Nokia Siemens Networks
	Expires: September 6, 2012 March 5, 2012		Expires: April 25, 2013 October 22, 2012
	Diameter End-to-End Security: Keyed Message Digests, Digital Signatures,		Diameter End-to-End Security: Keyed Message Digests, Digital Signatures,
	and Encryption		and Encryption
	draft-korhonen-dime-e2e-security-00.txt		draft-korhonen-dime-e2e-security-01.txt
	Abstract		Abstract
	This document defines an extension for end to end authentication,		This document defines an extension for end to end authentication,
	integrity and confidentiality protection of Diameter Attribute Value		integrity and confidentiality protection of Diameter Attribute Value
	Pairs. The solutions focuses on protecting Diameter Attribute Value		Pairs. The solutions focuses on protecting Diameter Attribute Value
	Pairs and leaves the key distribution solution to a separate		Pairs and leaves the key distribution solution to a separate
	specification. The integrity protection can be introduced in a		specification. The integrity protection can be introduced in a
	backward compatible manner to existing application. The		backward compatible manner to existing application. The
	confidentiality protection requires an explicit support from an		confidentiality protection requires an explicit support from an
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	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 September 6, 2012.		This Internet-Draft will expire on April 25, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. AVP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Solution description . . . . . . . . . . . . . . . . . . . . . 5
	2.1. Signed-Data AVP . . . . . . . . . . . . . . . . . . . . . 5		2.1. Integrity protection of AVPs . . . . . . . . . . . . . . . 5
	2.2. Encrypted-Data AVP . . . . . . . . . . . . . . . . . . . . 8		2.2. Confidentiality protection of AVPs . . . . . . . . . . . . 8
	3. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 9		2.3. Definition of the 'End Point' . . . . . . . . . . . . . . 9
	3.1. Transient Failures . . . . . . . . . . . . . . . . . . . . 9		3. AVP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.2. Permanent Failures . . . . . . . . . . . . . . . . . . . . 9		3.1. Signed-Data AVP . . . . . . . . . . . . . . . . . . . . . 10
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		3.2. JWS-Header AVP . . . . . . . . . . . . . . . . . . . . . . 10
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 11		3.3. Header-Parameters AVP . . . . . . . . . . . . . . . . . . 10
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		3.4. JWS-AVP-Payload AVP . . . . . . . . . . . . . . . . . . . 10
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		3.5. JWS-Signature AVP . . . . . . . . . . . . . . . . . . . . 11
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 13		3.6. Encrypted-Data AVP . . . . . . . . . . . . . . . . . . . . 11
	7.2. Informational References . . . . . . . . . . . . . . . . . 13		3.7. JWE-Header AVP . . . . . . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14		3.8. JWE-Enc-Key AVP . . . . . . . . . . . . . . . . . . . . . 11
			3.9. JWE-Init-Vec AVP . . . . . . . . . . . . . . . . . . . . . 11
			3.10. JWE-AVP-Ciphertext AVP . . . . . . . . . . . . . . . . . . 12
			4. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 13
			4.1. Transient Failures . . . . . . . . . . . . . . . . . . . . 13
			4.2. Permanent Failures . . . . . . . . . . . . . . . . . . . . 13
			5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
			6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
			7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
			8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
			8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
			8.2. Informational References . . . . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The Diameter base protocol [I-D.ietf-dime-rfc3588bis] leverages IPsec		The Diameter base protocol [I-D.ietf-dime-rfc3588bis] leverages IPsec
	and TLS for mutual authentication between neighboring Diameter nodes		and TLS for mutual authentication between neighboring Diameter nodes
	and for channel security offering data origin authentication,		and for channel security offering data origin authentication,
	integrity and confidentiality protection. The Diameter base		integrity and confidentiality protection. The Diameter base
	protocol, however, also defines Diameter agents, namely Relay Agents,		protocol, however, also defines Diameter agents, namely Relay Agents,
	Proxy Agents, Redirect Agents, and Translation Agents.		Proxy Agents, Redirect Agents, and Translation Agents.
	skipping to change at page 4, line 36 ¶		skipping to change at page 4, line 36 ¶
	directly, they do not modify messages. Redirect Agents do not have		directly, they do not modify messages. Redirect Agents do not have
	negative impacts on end-to-end security and are therefore not		negative impacts on end-to-end security and are therefore not
	considered in this document.		considered in this document.
	A Translation Agent is a device that provides translation between two		A Translation Agent is a device that provides translation between two
	protocols. To offer end-to-end security across different protocol		protocols. To offer end-to-end security across different protocol
	requires the ability to convey and process the AVPs defined in this		requires the ability to convey and process the AVPs defined in this
	document by both end points. Since such support is very likely not		document by both end points. Since such support is very likely not
	available this document does not cover this functionality.		available this document does not cover this functionality.
	This Diameter extension specifies how AVP authentication, integrity		The Diameter extension defined in this document specifies how AVP
	and confidentiality protection can be offered using either symmetric		authentication, integrity and confidentiality protection can be
	or asymmetric cryptography. As a solution mechanism Javascript		offered using either symmetric or asymmetric cryptography. As a
	Object Signing and Encryption (JOSE) is utilized. JOSE offers a		solution mechanism is derived form Javascript Object Signing and
	simple encoding with small set of features ideal for the purpose of		Encryption (JOSE). JOSE offers a simple encoding with small set of
	Diameter.		features ideal for the purpose of Diameter. This document further
			defines a binary efficient coding of JOSE objects.
	This document focuses on protecting Diameter AVP and leaves the key		This document focuses on protecting Diameter AVP and leaves the key
	distribution solution to a separate specification. To offer the		distribution solution to a separate specification, which most likely
	functionality two AVPs are defined: Signed-Data and Encrypted-Data.		is going to be a specific key exchange application. To offer the
			functionality two grouped AVPs are defined: Signed-Data and
	2. AVP Encoding		Encrypted-Data. The respective JOSE objects are transported within
			these two AVPs.
	2.1. Signed-Data AVP		2. Solution description
	The Signed-Data AVP (AVP Code TBD) is of type OctetString and		2.1. Integrity protection of AVPs
	utilizes the JSON Web signature (JWS) mechanism defined in
	[I-D.ietf-jose-json-web-signature].
	JWS represents digitally signed or HMACed content using JSON data		JWS represents digitally signed or HMACed content using JSON data
	structures. The representation in [I-D.ietf-jose-json-web-signature]		structures. The representation in [I-D.ietf-jose-json-web-signature]
	consists of three parts: the JWS Header, the JWS Payload, and the JWS		consists of three parts: the JWS Header, the JWS Payload, and the JWS
	Signature. The three parts are represented as the concatenation of		Signature. The three parts are represented as the concatenation of
	the encoded strings in that order, with the three strings being		the encoded strings in that order, with the three strings being
	separated by period ('.') characters. For the JWS Payload we define		separated by period ('.') characters. For the JWS Payload one would
	a new JSON object that contains an array of AVP code number and a		define a new JSON object that contains an array of AVP code number
	hash of AVP pairs. The JWS Signature then covers the all APVs to be		and a hash of AVP pairs. The JWS Signature then covers the all APVs
	signed or HMACed. Both JWS Payload and signature MUST use the same		to be signed or HMACed. Both JWS Payload and signature MUST use the
	hash algorithm of the cryptographic algorithm indicated in the JWS		same hash algorithm of the cryptographic algorithm indicated in the
	Header.		JWS Header.
	To package a set of AVPs for signing, each AVP octet representation		Although the solution relies on the JSON, the encoding into Diameter
	to be protected are first individually hashed and encoded into the		AVPs differ from the text based encoding of the JSON objects.
	JSON object with its AVP code number, as shown in Figure 1:		Specifically, none of of the JWS Header, JWS Payload or JWS Signature
			are not BASE64 encoded but are processed in their plaintext or binary
			representation formats. For example, the JWS Header is encoded in
			its plaintext format into the Header-Parameters AVP:
	{ "avp":		{
	[		"typ":"JWT",
	{"code" : 123,		"alg":"HS256",
	"hash": "NzY0YjIwYTgyNjE1NjYzNzBkMjExZTUyZmQwNTA5Njc="		"kid":"abc123"
	},
	{"code" : 321,
	"hash": "OWQ3NjMyNzViNGVmNjQzMGVmNTg4Y2JjMDRiNzU5OGY="
	}
	]
	}		}
	Figure 1: Example JWS Payload		The JWS Payload and the JWS Signature hashes and AVP Code values are
			encoded in their binary format as octets, not in textual or BASE64
			encoded formats. Sections 3.4 and Section 3.5 describe the encodings
			of the needed AVPs.
	The entire AVP MUST be input to the hash calculation, from the first		To package a set of AVPs for signing, each AVP octet representation
	byte of the AVP code to the last byte of the AVP data, including all		to be protected are first individually hashed and encoded into the
	other fields, length, reserved/flags, and optional vendor IDs, and		"JSON object" with its four octets AVP code number. The entire AVP
	padding. The AVP MUST be input to the hash calculation in network		MUST be input to the hash calculation, from the first byte of the AVP
	byte order. The "code" in the Figure 1 is an integer value		code to the last byte of the AVP data, including all other fields,
	containing the AVP code number, and the "hash" is the Base64 encoded		length, reserved/flags, and optional vendor IDs, and padding. The
	hash of the AVP.		AVP MUST be input to the hash calculation in network byte order.
	The JWS Signature is calculated over the entire JWS Payload and then		The JWS Signature is calculated over the entire JWS Payloads and then
	the all three JWS parts are placed in the Signed-Data AVP. There can		the all three JWS parts are placed in the Signed-Data AVP. There can
	be multiple Signed-Data AVPs in a Diameter message. The AVP code in		be multiple Signed-Data AVPs in a Diameter message. The AVP code in
	the JWS Payload is to indicate which AVP this hash possibly refers		the JWS Payload is to indicate which AVP this hash possibly refers
	to. If there are multiple instances of the same AVP in the Diameter		to. If there are multiple instances of the same AVP in the Diameter
	message, there is no other way than make the verification against all		message, there is no other way than make the verification against all
	of those. It is possible that the message sender only hashed one AVP		of those. It is possible that the message sender only hashed one AVP
	of the same type and, therefore, the receiver MUST verify the hash		of the same type and, therefore, the receiver MUST verify the hash
	against all occurrences of the AVP of the same code number. Such		against all occurrences of the AVP of the same code number. Such
	flexibility is added there to allow reordering of the AVPs and		flexibility is added there to allow reordering of the AVPs and
	addition or deletion of new AVPs by intermediating agents.		addition or deletion of new AVPs by intermediating agents.
	If a receiver detects errors with the processing of the Signed-Data		If a receiver detects errors with the processing of the Signed-Data
	AVP it MAY return one of the errors defined in Section 3. If a		AVP it MAY return one of the errors defined in Section 4. If a
	receiver does not find any AVP the Signed-Data AVP has a signature		receiver does not find any AVP the Signed-Data AVP has a signature
	for, it MAY also return one of the errors defined in Section 3.		for, it MAY also return one of the errors defined in Section 4.
	When AVPs are to be both encrypted and signed, the Encrypted-Data AVP		When AVPs are to be both encrypted and signed, the Encrypted-Data AVP
	MUST be created first. This means that signing is "outside"		MUST be created first. This means that signing is "outside"
	encryption.		encryption.
	Here is an example: Imagine the following AVPs from the QoS-Resources		Here is an example: Imagine the following AVPs from the QoS-Resources
	AVP in the QoS-Install Request (defined in RFC 5866 [RFC5866] message		AVP in the QoS-Install Request (defined in RFC 5866 [RFC5866] message
	shall be signed. The resulting example message has the following		shall be signed. The resulting example message has the following
	structure:		structure:
	<QoS-Install-Request> ::= < Diameter Header: 327, REQ, PXY >		<QoS-Install-Request> ::= < Diameter Header: 327, REQ, PXY >
	< Session-Id >		< Session-Id >
	{ Auth-Application-Id }		{ Auth-Application-Id }
	{ Origin-Host }		{ Origin-Host }
	{ Origin-Realm }		{ Origin-Realm }
	{ Destination-Realm }		{ Destination-Realm }
	{ Auth-Request-Type }		{ Auth-Request-Type }
	[ Signed-Data ]		[ Signed-Data ]
	* [ QoS-Resources ]		* [ QoS-Resources ]
	...		...
	Example Diameter Message with Signed-Data AVP		Example Diameter Message with Signed-Data AVP
	The Signed-Data AVP in this example may contain a JWS Header that		The Signed-Data AVP in this example may contain a JWS Header that
	indicates the use of the HMAC SHA-256 algorithm with the key id		indicates the use of the HMAC SHA-256 algorithm with the key id
	'abc123'. The protected AVPs are Session-Id, Origin-Host and Origin-		'abc123'. The protected AVPs are Session-Id, Origin-Host and Origin-
	Realm. The calculated HMAC SHA-256 values are for example purposes		Realm. The calculated HMAC SHA-256 values are for example purposes
	only (i.e., are not real):		only (i.e., are not real):
	JWS Header:		The JWS Header used in this example is:
	{ "typ":"JWT",		{"typ":"JWT",
	"alg":"HS256",		"alg":"HS256",
	"kid":"abc123"		"kid":"abc123"
	}		}
	JWS Payload:		Signed-Data Grouped AVP:
	{ "avp":		0x00000nnn // Signed-Data code 'nnn'
	[		0x000000a8 // Flags=0, Length=168 (8+49+3+28+28+28+24)
	{"code" : 263, // Session-Id
	"hash": "OWQwZTA0OTViYThjMDMxMmI2Mjc0YzUyN2Q1MWEwNDg="
	},
	{"code" : 264, // Origin-Host
	"hash": "MzljYTg4ZmZhYTVhNmZmOTAyOWVkOTViYTUzNGUwMjg="
	},
	{"code" : 296, // Origin-Realm
	"hash": "MjAyNzMwYWNhNmUzYTE4MDJmNDRhNjMzZjI1MGY2ZmU="
	}
	]
	}
	JWS Signature:		JWS Header encoded into the JWS-Header AVP:
	"wv3yJxyrhYJkCcDjK63elFkEvAV9dsSUNBf5Cu1ref8="		0x00000xxx // JWS-Header code 'xxx'
			0x00000031 // Flags=0, Length=49
			'{"typ":"JWT","alg":"HS256","kid":"abc123"}' // 41
			0x00,0x00,0x00 // 3 octets padding
	Combined example JWS (with line breaks for display		JWS Payload encoded into three JWS-AVP-Payload AVPs:
	purposes only):
	eyAgInR5cCI6IkpXVCIsDQogICAgImFsZyI6IkhTMjU2IiwNCiAgICAia2l		0xca8362ed,0x69a32ffb
	kIjoiYWJjMTIzIg0KfQ==		0x9092ca98,0x745239da
	.		0x6960af73,0x6386bc38
	eyAiYXZwIjoNCiAgIFsNCiAgICAgeyJjb2RlIiA6IDI2MywgICAgICAvLyB		0x407e518b,0xe4760548
	TZXNzaW9uLUlkDQogICAgICAiaGFzaCI6ICJPV1F3WlRBME9UVmlZVGhqTU
	RNeE1tSTJNamMwWXpVeU4yUTFNV0V3TkRnPSINCiAgICAgfSwNCiAgICAge
	yJjb2RlIiA6IDI2NCwgICAgICAvLyBPcmlnaW4tSG9zdA0KICAgICAgImhh
	c2giOiAiTXpsallUZzRabVpoWVRWaE5tWm1PVEF5T1dWa09UVmlZVFV6Tkd
	Vd01qZz0iDQogICAgIH0sDQogICAgIHsiY29kZSIgOiAyOTYsICAgICAgLy
	8gT3JpZ2luLVJlYWxtDQogICAgICAiaGFzaCI6ICJNakF5TnpNd1lXTmhOb
	VV6WVRFNE1ESm1ORFJoTmpNelpqSTFNR1kyWm1VPSINCiAgICAgfQ0KICAg
	XQ0KIH0=
	.
	wv3yJxyrhYJkCcDjK63elFkEvAV9dsSUNBf5Cu1ref8=
			0x00000zzz // JWS-AVP-Payload code 'zzz' <--+
			0x0000002c // Flags=0, Length=28 |
			0x00000107 // 263, Session-Id, 4 octets s
			0xca8362ed,0x69a32ffb // 256 bits hash of i
			0x9092ca98,0x745239da // Session-id g
			0x6960af73,0x6386bc38 n
			0x407e518b,0xe4760548 a
			t
			0x00000zzz // JWS-AVP-Payload code 'zzz' u
			0x0000002c // Flags=0, Length=28 r
			0x00000108 // 264, Origin-Host, 4 octets e
			0x64b52a15,0xa75a8157 // 256 bits hash of |
			0x151993a6,0xb9839866 // Origin-Realm c
			0x3b94afa3,0x85568552 o
			0x46602ccc,0x3f9d9a77 v
			e
			0x00000zzz // JWS-AVP-Payload code 'zzz' r
			0x0000002c // Flags=0, Length=28 a
			0x00000128 // 296, Origin-Realm, 4 octets g
			0x3c7c0b17,0x4a1c58d0 // 256 bits hash of e
			0xdc2844a3,0x28580385 // Origin-Realm |
			0x25eb08b0,0xeb20c941 // |
			0xcd52f74c,0xf55ae9ab // <--+
			JWS Signature encoded into the JWS-Signature AVP:
			0x00000yyy // JWS-Signature code 'yyy'
			0x00000028 // Flags=0, Length=24
			0x70ec221e,0xe0300ec1,0xb7ce968d,0x6ec6ad9e
			0x8afbe983,0x2b0e331c,0x2e1f51ac,0xf9af0188
	Example JWS Header, Payload and Signature		Example JWS Header, Payload and Signature
	2.2. Encrypted-Data AVP		2.2. Confidentiality protection of AVPs
	The Encrypted-Data AVP (AVP Code TBD) is of type OctetString and		The Encrypted-Data AVP (AVP Code TBD) is of type OctetString and
	contains the JSON Web Encryption (JWE)		contains the JSON Web Encryption (JWE)
	[I-D.ietf-jose-json-web-encryption] data structure and consists of		[I-D.ietf-jose-json-web-encryption] data structure and consists of
	three parts: the JWE Header, the JWE Encrypted Key, and the JWE		four parts: the JWE Header, the JWE Encrypted Key, the JWE
	Ciphertext. The three parts are represented as the concatenation of		Initialization Vector and the JWE Ciphertext. The four parts are
	the encoded strings in that order, with the three strings being		represented as the concatenation of the encoded strings in that
	separated by period ('.') characters. JWE does not add a content		order, with the three strings being separated by period ('.')
	integrity check if not provided by the underlying encryption		characters. JWE does not add a content integrity check if not
	algorithm.		provided by the underlying encryption algorithm.
			Although the solution relies on the JSON, the encoding into Diameter
			AVPs differ from the text based encoding of the JSON objects.
			Specifically, none of of the the JWE Header, the JWE Encrypted Key,
			the JWE Initialization Vector and the JWE Ciphertext are not BASE64
			encoded but are processed in their plaintext or binary representation
			formats. The concept follows what was already described in
			Section 2.1.
	A single AVP or an entire list of AVPs MUST be input to the		A single AVP or an entire list of AVPs MUST be input to the
	encryption process, from the first byte of the AVP code to the last		encryption process, from the first byte of the AVP code to the last
	byte of the AVP data, including all other fields, length, reserved/		byte of the AVP data, including all other fields, length, reserved/
	flags, and optional vendor IDs, and padding. The AVP MUST be input		flags, and optional vendor IDs, and padding. The AVP MUST be input
	to the encryption process in network byte order, and the encryptor is		to the encryption process in network byte order, and the encryptor is
	free to order AVPs whatever way it chooses. When AVPs are to be both		free to order AVPs whatever way it chooses. When AVPs are to be both
	encrypted and authenticated, the Encrypted-Data AVP MUST be created		encrypted and authenticated, the Encrypted-Data AVP MUST be created
	first.		first.
	skipping to change at page 8, line 43 ¶		skipping to change at page 9, line 4 ¶
	receiving Diameter server without any indication to the sender that		receiving Diameter server without any indication to the sender that
	they have not been processes. Worse, in the second case when the		they have not been processes. Worse, in the second case when the
	encrypted AVPs are mandatory to be processed then the receiving		encrypted AVPs are mandatory to be processed then the receiving
	Diameter node will return an error that may not inform the sender		Diameter node will return an error that may not inform the sender
	about the failure to decrypt the Encrypted-Data AVP. Consequently,		about the failure to decrypt the Encrypted-Data AVP. Consequently,
	the usage of the Encrypted-Data AVP may require changes to the ABNF		the usage of the Encrypted-Data AVP may require changes to the ABNF
	definition of a Diameter application.		definition of a Diameter application.
	If a receiver detects that the contents of the Encrypted-Data AVP is		If a receiver detects that the contents of the Encrypted-Data AVP is
	invalid, it SHOULD return the new Result-Code AVP value defined in		invalid, it SHOULD return the new Result-Code AVP value defined in
	Section 3.		Section 4.
	3. Result-Code AVP Values		2.3. Definition of the 'End Point'
			Although this specification claims to introduce the end-to-end
			security into Diameter, the definition who actually is the 'end
			point' is not obvious. The 'end point' does not need to be the
			original Diameter request or answer originator but the Diameter node
			that inserts the Signed-Data or the Encrypted-Data AVPs into the
			Diameter message. The node can be the request or answer originator
			or a proxy agent. Use of proxy agents doing the 'end-to-end'
			security on behalf of other nodes mimics the deployments where site-
			to-site VPNs are used.
			3. AVP Encoding
			3.1. Signed-Data AVP
			The Signed-Data AVP (AVP Code TBD1) is of type Grouped and utilizes
			the JSON Web signature (JWS) mechanism defined in
			[I-D.ietf-jose-json-web-signature]. The JWS payload is then encoded
			into the Signed-Data AVP:
			Signed-Data ::= < AVP Header: TBD1 >
			{ JWS-Header }
			* { JWS-AVP-Payload }
			{ JWS-Signature }
			* [ AVP ]
			3.2. JWS-Header AVP
			The JWS-Header AVP (AVP Code TBD2) is of type UTF8String and contains
			the JSON Web Signature Header. The contents of the AVP follow the
			rules for the header found in [I-D.ietf-jose-json-web-signature],
			which implies the required IANA registries are also defined by JSON
			documents.
			JWS-Header ::= < AVP Header: TBD2 >
			{ Header-Parameters }
			* [ AVP ]
			The "alg" is the only REQUIRED Header Parameter for the signature
			purposes. The "typ" and "kid" Header Parameters are also
			RECOMMENDED.
			3.3. Header-Parameters AVP
			The Header-Parameters AVP (AVP Code TBD3) is of type UTF8String and
			contains the JSON Header Parameter Name and its value as described in
			[I-D.ietf-jose-json-web-signature]. The encoding (textual) also
			follows [I-D.ietf-jose-json-web-signature]. Differing from the JSON
			specifications the parameter names and values are not BASE64 encoded
			but in their original UTF-8 representation format.
			3.4. JWS-AVP-Payload AVP
			The JWS-AVP-Payload AVP (AVP Code TBD4) is of type OctetString and
			contains both an AVP Code and a hash of the entire AVP identified by
			the AVP Code. The first four octets contain the AVP Code in a
			network byte order followed by the hash octets. The length of the
			hash octets depends on the used hash algorithm.
			3.5. JWS-Signature AVP
			The JWS-Signature AVP (AVP Code TBD5) is of type OctetString and
			contains the signature calculated over the array of complete JWS-AVP-
			Payload AVPs (including AVP header fields etc) in the order they
			appear in the Signed-Data AVP. The length of the signature octets
			depends on the used signature algorithm.
			3.6. Encrypted-Data AVP
			The Encrypted-Data AVP (AVP Code TBD6) is of type Grouped and
			utilizes the JSON Web Encryption (JWE) mechanism defined in
			[I-D.ietf-jose-json-web-encryption]. The JWE payload is then encoded
			into the Encrypted-Data AVP:
			Encrypted-Data ::= < AVP Header: TBD1 >
			{ JWE-Header }
			{ JWE-Enc-Key }
			[ JWE-Init-Vec ]
			{ JWE-AVP-Ciphertext }
			* [ AVP ]
			3.7. JWE-Header AVP
			The JWE-Header AVP (AVP Code TBD7) is of type UTF8String and contains
			the JSON Web Encryption Header. The contents of the AVP follow the
			rules for the header found in [I-D.ietf-jose-json-web-encryption],
			which implies the required IANA registries are also defined by JSON
			documents.
			JWE-Header ::= < AVP Header: TBD7 >
			{ Header-Parameters }
			* [ AVP ]
			The "alg" and "enc" are the REQUIRED Header Parameter for the
			encryption purposes. The "typ" and "kid" Header Parameters are also
			RECOMMENDED.
			3.8. JWE-Enc-Key AVP
			The JWE-Enc-Key AVP (AVP Code TBD8) is of type OctetString and
			contains the JWE Encrypted Key in its binary format.
			3.9. JWE-Init-Vec AVP
			The JWE-Init-Vec AVP (AVP Code TBD9) is of type OctetString and
			contains the JWE Initialization Vector in its binary format.
			3.10. JWE-AVP-Ciphertext AVP
			The JWE-AVP-Ciphertext AVP (AVP Code TBD10) is of type OctetString
			and contains the encrypted AVPs. The encrypted AVPs are first
			concatenated into one large plaintext octet blob and then encrypted
			as a whole. The length of the ciphertext depends on the used
			algorithm and encrypted AVPs. The plaintext to be encrypted is never
			BASE64 encoded but MAY be compressed if a "zip" parameter was
			included in the JWE Header.
			4. Result-Code AVP Values
	This section defines new Diameter result code values for usage with		This section defines new Diameter result code values for usage with
	Diameter applications.		Diameter applications.
	3.1. Transient Failures		4.1. Transient Failures
	Errors that fall within the transient failures category are used to		Errors that fall within the transient failures category are used to
	inform a peer that the request could not be satisfied at the time it		inform a peer that the request could not be satisfied at the time it
	was received, but MAY be able to satisfy the request in the future.		was received, but MAY be able to satisfy the request in the future.
	DIAMETER_KEY_UNKNOWN (TBD)		DIAMETER_KEY_UNKNOWN (TBD11)
	This error code is returned when a Signed-Data or an Encrypted-		This error code is returned when a Signed-Data or an Encrypted-
	Data AVP is received that was generated using a key that cannot be		Data AVP is received that was generated using a key that cannot be
	found in the key store. This error may, for example, be caused if		found in the key store. This error may, for example, be caused if
	one of the endpoints of an end-to-end security association lost a		one of the endpoints of an end-to-end security association lost a
	previously agreed upon key, perhaps as a result of a reboot. To		previously agreed upon key, perhaps as a result of a reboot. To
	recover a new end-to-end key establishment procedure may need to		recover a new end-to-end key establishment procedure may need to
	be invoked.		be invoked.
	3.2. Permanent Failures		DIAMETER_HEADER_NAME_ERROR (TBD12)
			This error code is returned when a Header Parameter Name is not
			understood in the JWS-Header AVP or in the JWE-Header AVP.
			4.2. Permanent Failures
	Errors that fall within the permanent failures category are used to		Errors that fall within the permanent failures category are used to
	inform the peer that the request failed, and should not be attempted		inform the peer that the request failed, and should not be attempted
	again.		again.
	DIAMETER_DECRYPTION_ERROR (TBD)		DIAMETER_DECRYPTION_ERROR (TBD13)
	This error code is returned when an Encrypted-Data AVP is received		This error code is returned when an Encrypted-Data AVP is received
	and the decryption fails for an unknown reason.		and the decryption fails for an unknown reason.
	DIAMETER_SIGNATURE_ERROR (TBD)		DIAMETER_SIGNATURE_ERROR (TBD14)
	This error code is returned when a Signed-Data AVP is received and		This error code is returned when a Signed-Data AVP is received and
	the verification fails for an unknown reason.		the verification fails for an unknown reason.
	4. IANA Considerations		5. IANA Considerations
	IANA is requested to allocate AVP codes for the following AVPs:		IANA is requested to allocate AVP codes for the following AVPs:
	+------------------------------------------------------------------+		+------------------------------------------------------------------+
	| AVP Section |		| AVP Section |
	|AVP Name Code Defined Data Type |		|AVP Name Code Defined Data Type |
	+------------------------------------------------------------------+		+------------------------------------------------------------------+
	|Signed-Data TBD 3.1 OctetString |		|Signed-Data TBD1 3.1 Grouped |
	|Encrypted-Data TBD 3.2 OctetString |		|JWS-Header TBD2 3.2 Grouped |
			|JWS-AVP-Paylaod TBD3 3.4 OctetString |
			|JSW-Signature TBD4 3.5 OctetString |
			|Header-Parameters TBD5 3.3 UTF8String |
			|Encrypted-Data TBD6 3.6 Grouped |
			|JWE-Header TBD7 3.7 Grouped |
			|JWE-Enc-Key TBD8 3.8 OctetString |
			|JWE-Init-Vec TBD9 3.9 OctetString |
			|JWE-AVP-Ciphertext TBD10 3.10 OctetString |
	+------------------------------------------------------------------+		+------------------------------------------------------------------+
	This specification additionally defines a few Result-Code AVP values,		This specification additionally defines a few Result-Code AVP values,
	see Section 3.		see Section 4.
	5. Security Considerations		6. Security Considerations
	The purpose of this document is to offer end-to-end security		The purpose of this document is to offer end-to-end security
	mechanisms for calculating keyed message digest, for signing, and for		mechanisms for calculating keyed message digest, for signing, and for
	encryption of Diameter AVPs.		encryption of Diameter AVPs.
	6. Acknowledgements		An intermediate Diameter agent that for a reason or other reorders
			the AVPs within the Signed-Data AVP may cause the signature
			verification fail even if no AVP was actually tampered.
			7. Acknowledgements
	We would like to thank the authors of [I-D.ietf-aaa-diameter-e2e-sec]		We would like to thank the authors of [I-D.ietf-aaa-diameter-e2e-sec]
	for their work on CMS end-to-end security for Diameter. Their		for their work on CMS end-to-end security for Diameter. Their
	document inspired us.		document inspired us.
	7. References		8. References
	7.1. Normative References		8.1. Normative References
	[I-D.ietf-dime-rfc3588bis]		[I-D.ietf-dime-rfc3588bis]
	Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,		Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
	"Diameter Base Protocol", draft-ietf-dime-rfc3588bis-29		"Diameter Base Protocol", draft-ietf-dime-rfc3588bis-34
	(work in progress), August 2011.		(work in progress), June 2012.
	[I-D.ietf-jose-json-web-encryption]		[I-D.ietf-jose-json-web-encryption]
	Hildebrand, J., Rescorla, E., and M. Jones, "JSON Web		Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web
	Encryption (JWE)", draft-ietf-jose-json-web-encryption-00		Encryption (JWE)", draft-ietf-jose-json-web-encryption-06
	(work in progress), January 2012.		(work in progress), October 2012.
	[I-D.ietf-jose-json-web-signature]		[I-D.ietf-jose-json-web-signature]
	Sakimura, N., Jones, M., and J. Bradley, "JSON Web		Jones, M., Bradley, J., and N. Sakimura, "JSON Web
	Signature (JWS)", draft-ietf-jose-json-web-signature-00		Signature (JWS)", draft-ietf-jose-json-web-signature-06
	(work in progress), January 2012.		(work in progress), October 2012.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	7.2. Informational References		8.2. Informational References
	[I-D.ietf-aaa-diameter-e2e-sec]		[I-D.ietf-aaa-diameter-e2e-sec]
	Calhoun, P., "Diameter End-2-End Security Extension",		Calhoun, P., "Diameter End-2-End Security Extension",
	2001.		2001.
	[RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A.,		[RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A.,
	and G. Zorn, "Diameter Quality-of-Service Application",		and G. Zorn, "Diameter Quality-of-Service Application",
	RFC 5866, May 2010.		RFC 5866, May 2010.
	Authors' Addresses		Authors' Addresses
End of changes. 47 change blocks.
	138 lines changed or deleted		305 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/