< draft-korhonen-dime-e2e-security-01.txt		draft-korhonen-dime-e2e-security-02.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: April 25, 2013 October 22, 2012		Expires: January 16, 2014 July 15, 2013
	Diameter End-to-End Security: Keyed Message Digests, Digital Signatures,		Diameter AVP Level Security: Keyed Message Digests, Digital Signatures,
	and Encryption		and Encryption
	draft-korhonen-dime-e2e-security-01.txt		draft-korhonen-dime-e2e-security-02.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
	application, thus is applicable only for newly defined applications.		application, thus is applicable only for newly defined applications.
	Terminology		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
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	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 April 25, 2013.		This Internet-Draft will expire on January 16, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Solution description . . . . . . . . . . . . . . . . . . . . . 5		2. Solution description . . . . . . . . . . . . . . . . . . . . 3
	2.1. Integrity protection of AVPs . . . . . . . . . . . . . . . 5		2.1. Integrity protection of AVPs . . . . . . . . . . . . . . 3
	2.2. Confidentiality protection of AVPs . . . . . . . . . . . . 8		2.2. Confidentiality protection of AVPs . . . . . . . . . . . 6
	2.3. Definition of the 'End Point' . . . . . . . . . . . . . . 9		2.3. Definition of the 'End Point' . . . . . . . . . . . . . . 7
	3. AVP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 10		3. AVP Encoding . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Signed-Data AVP . . . . . . . . . . . . . . . . . . . . . 10		3.1. Signed-Data AVP . . . . . . . . . . . . . . . . . . . . . 7
	3.2. JWS-Header AVP . . . . . . . . . . . . . . . . . . . . . . 10		3.2. JWS-Header AVP . . . . . . . . . . . . . . . . . . . . . 8
	3.3. Header-Parameters AVP . . . . . . . . . . . . . . . . . . 10		3.3. Header-Parameters AVP . . . . . . . . . . . . . . . . . . 8
	3.4. JWS-AVP-Payload AVP . . . . . . . . . . . . . . . . . . . 10		3.4. JWS-AVP-Payload AVP . . . . . . . . . . . . . . . . . . . 8
	3.5. JWS-Signature AVP . . . . . . . . . . . . . . . . . . . . 11		3.5. JWS-Signature AVP . . . . . . . . . . . . . . . . . . . . 8
	3.6. Encrypted-Data AVP . . . . . . . . . . . . . . . . . . . . 11		3.6. Encrypted-Data AVP . . . . . . . . . . . . . . . . . . . 9
	3.7. JWE-Header AVP . . . . . . . . . . . . . . . . . . . . . . 11		3.7. JWE-Header AVP . . . . . . . . . . . . . . . . . . . . . 9
	3.8. JWE-Enc-Key AVP . . . . . . . . . . . . . . . . . . . . . 11		3.8. JWE-Enc-Key AVP . . . . . . . . . . . . . . . . . . . . . 9
	3.9. JWE-Init-Vec AVP . . . . . . . . . . . . . . . . . . . . . 11		3.9. JWE-Init-Vec AVP . . . . . . . . . . . . . . . . . . . . 9
	3.10. JWE-AVP-Ciphertext AVP . . . . . . . . . . . . . . . . . . 12		3.10. JWE-AVP-Ciphertext AVP . . . . . . . . . . . . . . . . . 9
	4. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 13		4. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . 10
	4.1. Transient Failures . . . . . . . . . . . . . . . . . . . . 13		4.1. Transient Failures . . . . . . . . . . . . . . . . . . . 10
	4.2. Permanent Failures . . . . . . . . . . . . . . . . . . . . 13		4.2. Permanent Failures . . . . . . . . . . . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 15		6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 17		8.1. Normative References . . . . . . . . . . . . . . . . . . 11
	8.2. Informational References . . . . . . . . . . . . . . . . . 17		8.2. Informational References . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
	1. Introduction		1. Introduction
	The Diameter base protocol [I-D.ietf-dime-rfc3588bis] leverages IPsec		The Diameter base protocol [RFC6733] leverages IPsec and TLS for
	and TLS for mutual authentication between neighboring Diameter nodes		mutual authentication between neighboring Diameter nodes and for
	and for channel security offering data origin authentication,		channel security offering data origin authentication, integrity and
	integrity and confidentiality protection. The Diameter base		confidentiality protection. The Diameter base protocol, however,
	protocol, however, also defines Diameter agents, namely Relay Agents,		also defines Diameter agents, namely Relay Agents, Proxy Agents,
	Proxy Agents, Redirect Agents, and Translation Agents.		Redirect Agents, and Translation Agents.
	Relay Agents are Diameter agents that accept requests and route		Relay Agents are Diameter agents that accept requests and route
	messages to other Diameter nodes based on information found in the		messages to other Diameter nodes based on information found in the
	messages. Since Relays do not perform any application level		messages. Since Relays do not perform any application level
	processing, they provide relaying services for all Diameter		processing, they provide relaying services for all Diameter
	applications.		applications.
	Similarly to Relays, Proxy Agents route Diameter messages using the		Similarly to Relays, Proxy Agents route Diameter messages using the
	Diameter routing table. However, they differ since they modify		Diameter routing table. However, they differ since they modify
	messages to implement policy enforcement.		messages to implement policy enforcement.
	skipping to change at page 5, line 28 ¶		skipping to change at page 4, line 16 ¶
	same hash algorithm of the cryptographic algorithm indicated in the		same hash algorithm of the cryptographic algorithm indicated in the
	JWS Header.		JWS Header.
	Although the solution relies on the JSON, the encoding into Diameter		Although the solution relies on the JSON, the encoding into Diameter
	AVPs differ from the text based encoding of the JSON objects.		AVPs differ from the text based encoding of the JSON objects.
	Specifically, none of of the JWS Header, JWS Payload or JWS Signature		Specifically, none of of the JWS Header, JWS Payload or JWS Signature
	are not BASE64 encoded but are processed in their plaintext or binary		are not BASE64 encoded but are processed in their plaintext or binary
	representation formats. For example, the JWS Header is encoded in		representation formats. For example, the JWS Header is encoded in
	its plaintext format into the Header-Parameters AVP:		its plaintext format into the Header-Parameters AVP:
	{		{ "typ":"JWT",
	"typ":"JWT",
	"alg":"HS256",		"alg":"HS256",
	"kid":"abc123"		"kid":"abc123"
	}		}
	The JWS Payload and the JWS Signature hashes and AVP Code values are		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 in their binary format as octets, not in textual or BASE64
	encoded formats. Sections 3.4 and Section 3.5 describe the encodings		encoded formats. Sections 3.4 and 3.5 describe the encodings of the
	of the needed AVPs.		needed AVPs.
	To package a set of AVPs for signing, each AVP octet representation		To package a set of AVPs for signing, each AVP octet representation
	to be protected are first individually hashed and encoded into the		to be protected are first individually hashed and encoded into the
	"JSON object" with its four octets AVP code number. The entire AVP		"JSON object" with its four octets AVP code number. The entire AVP
	MUST be input to the hash calculation, from the first byte of the AVP		MUST be input to the hash calculation, from the first byte of the AVP
	code to the last byte of the AVP data, including all other fields,		code to the last byte of the AVP data, including all other fields,
	length, reserved/flags, and optional vendor IDs, and padding. The		length, reserved/flags, and optional vendor IDs, and padding. The
	AVP MUST be input to the hash calculation in network byte order.		AVP MUST be input to the hash calculation in network byte order.
	The JWS Signature is calculated over the entire JWS Payloads and then		The JWS Signature is calculated over the entire JWS Payloads and then
	skipping to change at page 6, line 43 ¶		skipping to change at page 5, line 33 ¶
	...		...
	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):
	The JWS Header used in this example is:		JWS Header encoded as such in JWS-Header AVP:
	{"typ":"JWT",		{"typ":"JWT",
	"alg":"HS256",		"alg":"HS256",
	"kid":"abc123"		"kid":"abc123"
	}		}
	Signed-Data Grouped AVP:
	0x00000nnn // Signed-Data code 'nnn'
	0x000000a8 // Flags=0, Length=168 (8+49+3+28+28+28+24)
	JWS Header encoded into the JWS-Header AVP:
	0x00000xxx // JWS-Header code 'xxx'		0x00000xxx // JWS-Header code 'xxx'
	0x00000031 // Flags=0, Length=49		0x00000034 // Flags=0, Length=52
	'{"typ":"JWT","alg":"HS256","kid":"abc123"}' // 41		'{"typ":"JWT","alg":"HS256","kid":"abc123"}' // 41
	0x00,0x00,0x00 // 3 octets padding		0x00,0x00,0x00 // 3 octets padding
	JWS Payload encoded into three JWS-AVP-Payload AVPs:		JWS Payload encoded into three JWS-AVP-Payload AVPs:
	0xca8362ed,0x69a32ffb
	0x9092ca98,0x745239da
	0x6960af73,0x6386bc38
	0x407e518b,0xe4760548
	0x00000zzz // JWS-AVP-Payload code 'zzz' <--+		0x00000zzz // JWS-AVP-Payload code 'zzz' <--+
	0x0000002c // Flags=0, Length=28 |		0x0000001c // Flags=0, Length=28 |
	0x00000107 // 263, Session-Id, 4 octets s		0x00000107 // 263, Session-Id, 4 octets s
	0xca8362ed,0x69a32ffb // 256 bits hash of i		0x9d0e0495 // hash of Session-Id, 128 bits i
	0x9092ca98,0x745239da // Session-id g		0xba8c0312 g
	0x6960af73,0x6386bc38 n		0xb6274c52 n
	0x407e518b,0xe4760548 a		0x7d51a048 a
	t		t
	0x00000zzz // JWS-AVP-Payload code 'zzz' u		0x00000zzz // JWS-AVP-Payload code 'zzz' u
	0x0000002c // Flags=0, Length=28 r		0x0000001c // Flags=0, Length=28 r
	0x00000108 // 264, Origin-Host, 4 octets e		0x00000108 // 264, Origin-Host, 4 octets e
	0x64b52a15,0xa75a8157 // 256 bits hash of |		0x39ca88ff // hash of Origin-Host, 128 bits |
	0x151993a6,0xb9839866 // Origin-Realm c		0xaa5a6ff9 c
	0x3b94afa3,0x85568552 o		0x029ed95b o
	0x46602ccc,0x3f9d9a77 v		0xa534e028 v
	e		e
	0x00000zzz // JWS-AVP-Payload code 'zzz' r		0x00000zzz // JWS-AVP-Payload code 'zzz' r
	0x0000002c // Flags=0, Length=28 a		0x0000001c // Flags=0, Length=28 a
	0x00000128 // 296, Origin-Realm, 4 octets g		0x00000128 // 296, Origin-Realm, 4 octets g
	0x3c7c0b17,0x4a1c58d0 // 256 bits hash of e		0x202730ac // hash of Origin-Realm, 128 bits e
	0xdc2844a3,0x28580385 // Origin-Realm |		0xa6e3a180 |
	0x25eb08b0,0xeb20c941 // |		0x2f44a633 |
	0xcd52f74c,0xf55ae9ab // <--+		0xf250f6fe <--+
	JWS Signature encoded into the JWS-Signature AVP:		JWS Signature encoded into the JWS-Signature AVP:
	0x00000yyy // JWS-Signature code 'yyy'		0x00000yyy // JWS-Signature code 'yyy'
	0x00000028 // Flags=0, Length=24		0x00000018 // Flags=0, Length=24
	0x70ec221e,0xe0300ec1,0xb7ce968d,0x6ec6ad9e		0xaabbccdd,0xddeeff00,0x11223344,0x55667788
	0x8afbe983,0x2b0e331c,0x2e1f51ac,0xf9af0188
	Example JWS Header, Payload and Signature		Example JWS Header, Payload and Signature
	2.2. Confidentiality protection of AVPs		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
	four parts: the JWE Header, the JWE Encrypted Key, the JWE		four parts: the JWE Header, the JWE Encrypted Key, the JWE
	Initialization Vector and the JWE Ciphertext. The four parts are		Initialization Vector and the JWE Ciphertext. The four parts are
	represented as the concatenation of the encoded strings in that		represented as the concatenation of the encoded strings in that
	skipping to change at page 14, line 6 ¶		skipping to change at page 11, line 4 ¶
	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 (TBD14)		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.
	5. 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 TBD1 3.1 Grouped |		|Signed-Data TBD1 3.1 Grouped |
	|JWS-Header TBD2 3.2 Grouped |		|JWS-Header TBD2 3.x Grouped |
	|JWS-AVP-Paylaod TBD3 3.4 OctetString |		|JWS-AVP-Paylaod TBD3 3.x OctetString |
	|JSW-Signature TBD4 3.5 OctetString |		|JSW-Signature TBD4 3.x OctetString |
	|Header-Parameters TBD5 3.3 UTF8String |		|Header-Parameters TBD5 3.x UTF8String |
	|Encrypted-Data TBD6 3.6 Grouped |		|Encrypted-Data TBD6 3.x Grouped |
	|JWE-Header TBD7 3.7 Grouped |		|JWE-Header TBD7 3.x Grouped |
	|JWE-Enc-Key TBD8 3.8 OctetString |		|JWE-Enc-Key TBD8 3.x OctetString |
	|JWE-Init-Vec TBD9 3.9 OctetString |		|JWE-Init-Vec TBD9 3.x OctetString |
	|JWE-AVP-Ciphertext TBD10 3.10 OctetString |		|JWE-AVP-Ciphertext TBD10 3.x OctetString |
	+------------------------------------------------------------------+		+------------------------------------------------------------------+
	This specification additionally defines a few Result-Code AVP values,		This specification additionally defines a few Result-Code AVP values,
	see Section 4.		see Section 4.
	6. 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.
	skipping to change at page 17, line 9 ¶		skipping to change at page 11, line 45 ¶
	7. Acknowledgements		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.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-dime-rfc3588bis]
	Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
	"Diameter Base Protocol", draft-ietf-dime-rfc3588bis-34
	(work in progress), June 2012.
	[I-D.ietf-jose-json-web-encryption]		[I-D.ietf-jose-json-web-encryption]
	Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web		Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web
	Encryption (JWE)", draft-ietf-jose-json-web-encryption-06		Encryption (JWE)", draft-ietf-jose-json-web-encryption-12
	(work in progress), October 2012.		(work in progress), July 2013.
	[I-D.ietf-jose-json-web-signature]		[I-D.ietf-jose-json-web-signature]
	Jones, M., Bradley, J., and N. Sakimura, "JSON Web		Jones, M., Bradley, J., and N. Sakimura, "JSON Web
	Signature (JWS)", draft-ietf-jose-json-web-signature-06		Signature (JWS)", draft-ietf-jose-json-web-signature-12
	(work in progress), October 2012.		(work in progress), July 2013.
	[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.
			[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
			"Diameter Base Protocol", RFC 6733, October 2012.
	8.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.
End of changes. 27 change blocks.
	93 lines changed or deleted		77 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/