draft-ietf-tls-rsa-aes-gcm-01.txt		draft-ietf-tls-rsa-aes-gcm-02.txt
	TLS Working Group J. Salowey		TLS Working Group J. Salowey
	Internet-Draft A. Choudhury		Internet-Draft A. Choudhury
	Intended status: Standards Track D. McGrew		Intended status: Standards Track D. McGrew
	Expires: July 16, 2008 Cisco Systems, Inc.		Expires: August 10, 2008 Cisco Systems, Inc.
	January 13, 2008		February 7, 2008
	RSA based AES-GCM Cipher Suites for TLS		AES-GCM Cipher Suites for TLS
	draft-ietf-tls-rsa-aes-gcm-01		draft-ietf-tls-rsa-aes-gcm-02
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	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		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://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 July 16, 2008.		This Internet-Draft will expire on August 10, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	This memo describes the use of the Advanced Encryption Standard (AES)		This memo describes the use of the Advanced Encryption Standard (AES)
	in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)		in Galois/Counter Mode (GCM) as a Transport Layer Security (TLS)
	authenticated encryption operation. GCM provides both		authenticated encryption operation. GCM provides both
	confidentiality and data origin authentication, can be efficiently		confidentiality and data origin authentication, can be efficiently
	implemented in hardware for speeds of 10 gigabits per second and		implemented in hardware for speeds of 10 gigabits per second and
	above, and is also well-suited to software implementations. This		above, and is also well-suited to software implementations. This
	memo defines TLS ciphersuites that use AES-GCM with RSA.		memo defines TLS ciphersuites that use AES-GCM with RSA, DSS and
			Diffie-Hellman based key exchange mechanisms.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions Used In This Document . . . . . . . . . . . . . . . 3		2. Conventions Used In This Document . . . . . . . . . . . . . . . 3
	3. RSA Based AES-GCM Cipher Suites . . . . . . . . . . . . . . . . 3		3. AES-GCM Cipher Suites . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Recommendations for Multiple Cryptographic Processors . . . 4
	4. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. TLS Versions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
	6.1. Perfect Forward Secrecy . . . . . . . . . . . . . . . . . . 6		6.1. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 5
	6.2. Counter Reuse . . . . . . . . . . . . . . . . . . . . . . . 6		6.2. Recommendations for Multiple Encryption Processors . . . . 5
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 7		8.1. Normative References . . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . . 7		8.2. Informative References . . . . . . . . . . . . . . . . . . 7
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
	Intellectual Property and Copyright Statements . . . . . . . . . . 9		Intellectual Property and Copyright Statements . . . . . . . . . . 9
	1. Introduction		1. Introduction
	This document describes the use of AES [AES]in Galois Counter Mode		This document describes the use of AES [AES]in Galois Counter Mode
	(GCM) [GCM] (AES-GCM) with RSA based key exchange as a ciphersuite		(GCM) [GCM] (AES-GCM) with various key exchange mechanisms as a
	for TLS. This mechanism is not only efficient and secure, hardware		ciphersuite for TLS. AES-GCM is not only efficient and secure, but
	implementations can achieve high speeds with low cost and low		hardware implementations can achieve high speeds with low cost and
	latency, because the mode can be pipelined. Applications like		low latency, because the mode can be pipelined. Applications like
	CAPWAP, which uses DTLS, can benefit from the high-speed		CAPWAP, which uses DTLS, can benefit from the high-speed
	implementations when wireless termination points (WTPs) and		implementations when wireless termination points (WTPs) and
	controllers (ACs) have to meet requirements to support higher		controllers (ACs) have to meet requirements to support higher
	throughputs in the future. AES-GCM has been specified as a mode that		throughputs in the future. AES-GCM has been specified as a mode that
	can be used with IPsec ESP [RFC4106] and 802.1AE MAC Security		can be used with IPsec ESP [RFC4106] and 802.1AE MAC Security
	[IEEE8021AE]. It also is part of the NSA suite B ciphersuites for		[IEEE8021AE]. This document defines ciphersutes based on RSA, DSS
	TLS [I-D.rescorla-tls-suiteb]; however in order to meet Suite B		and Diffie-Hellman key exchanges; ECC based ciphersuites are defined
	requirements these ciphersuites require ECC base key exchange and TLS		in a separate document [I-D.ietf-tls-ecc-new-mac]. AES-GCM is an
	1.2. The ciphersuites defined in this document are based on RSA		authenticated encryption with associated data (AEAD) cipher, as
	which allows the use of AES-GCM in environments that have not		defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis]. The ciphersuites
	deployed ECC algorithms and do not need to meet NSA Suite B		defined in this draft may be used with Datagram TLS defined in
	requirements. AES-GCM is an authenticated encryption with associated		[RFC4347]. This memo uses GCM in a way similar to
	data (AEAD) cipher, as defined in TLS 1.2[I-D.ietf-tls-rfc4346-bis].
	The ciphersuites defined in this draft may be used with Datagram TLS
	defined in [RFC4347]. This memo uses GCM in a way similar to
	[I-D.ietf-tls-ecc-new-mac].		[I-D.ietf-tls-ecc-new-mac].
	2. Conventions Used In This Document		2. Conventions Used In This Document
	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 [RFC2119]		document are to be interpreted as described in [RFC2119]
	3. RSA Based AES-GCM Cipher Suites		3. AES-GCM Cipher Suites
	The following ciphersuites use the new authenticated encryption modes		The following ciphersuites use the new authenticated encryption modes
	defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:		defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]:
	CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}		CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
	CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}		CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
	CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}		CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
	CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}		CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
			CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
			CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
			CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
			CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
			CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
			CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
			CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
			CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
	These ciphersuites use the AES-GCM authenticated encryption with		These ciphersuites use the AES-GCM authenticated encryption with
	associated data (AEAD) algorithms AEAD_AES_128_GCM and		associated data (AEAD) algorithms AEAD_AES_128_GCM and
	AEAD_AES_256_GCM described in [I-D.mcgrew-auth-enc]. Note that this		AEAD_AES_256_GCM described in [RFC5116]. Note that each of these
	specification uses a 128-bit authentication tag with GCM. The		AEAD algorithms uses a 128-bit authentication tag with GCM. The
	"nonce" SHALL be 12 bytes long and it is "partially implicit" (see		"nonce" SHALL be 12 bytes long and it is "partially implicit" (see
	section 3.2.1 in [I-D.mcgrew-auth-enc]). Part of the nonce is		section 3.2.1 in [RFC5116]). Part of the nonce is generated as part
	generated as part of the handshake process and is static for the		of the handshake process and is static for the entire session and the
	entire session and part is carried in each packet.		other part is carried in each packet.
	Struct{		Struct{
	opaque salt[4];		opaque salt[4];
	opaque explicit_nonce_part[8];		opaque explicit_nonce_part[8];
	} GCMNonce		} GCMNonce
	The salt is the "implicit" part of the nonce and is not sent in the		The salt is the "implicit" part of the nonce and is not sent in the
	packet. It is either the client_write_IV if the client is sending or		packet. It is either the client_write_IV if the client is sending or
	the server_write_IV if the server is sending. These IVs SHALL be 4		the server_write_IV if the server is sending. These IVs SHALL be 4
	bytes long.		bytes long, therefore, for all the algorithms defined in this
			section, SecurityParameters.fixed_iv_length=4.
	The explicit_nonce_part is chosen by the sender and included in the		The explicit_nonce_part is chosen by the sender and included in the
	packet. Each value of the explicit_nonce_part MUST be distinct for		packet. Each value of the explicit_nonce_part MUST be distinct for
	each distinct invocation of GCM encrypt function for any fixed key.		each distinct invocation of GCM encrypt function for any fixed key.
	Failure to meet this uniqueness requirement can significantly degrade		Failure to meet this uniqueness requirement can significantly degrade
	security. The explicit_nonce_part is carried in the IV field of the		security. The explicit_nonce_part is carried in the IV field of the
	GenericAEADCipher structure. Therefore, for all the algorithms		GenericAEADCipher structure. For all the algorithms defined in this
	defined in this section, SecurityParameters.iv_length=8.		section, SecurityParameters.record_iv_length=8.
	In the case of TLS the explicit_nonce_part MAY be the 64-bit sequence		In the case of TLS the explicit_nonce_part MAY be the 64-bit sequence
	number. In the case of Datagram TLS [RFC4347] the		number. In the case of Datagram TLS [RFC4347] the
	explicit_nonce_part MAY be formed from the concatenation of the 16-		explicit_nonce_part MAY be formed from the concatenation of the 16-
	bit epoch with the 48-bit DTLS seq_num.		bit epoch with the 48-bit DTLS seq_num.
	The RSA and RSA-DHE key exchange is performed as defined in		The RSA, DHE_RSA, DH_RSA, DHE_DSS, DH_DSS, and DH_anon key exchanges
	[I-D.ietf-tls-rfc4346-bis].		are performed as defined in [I-D.ietf-tls-rfc4346-bis].
	The PRF algorithms SHALL be as follows:		The PRF algorithms SHALL be as follows:
	For TLS_RSA_WITH_AES_128_GCM_SHA256 and		For ciphersuites ending in _SHA256 the hash function is SHA256.
	TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 the hash function is SHA256.
	For TLS_RSA_WITH_AES_256_GCM_SHA384 and		For ciphersuites ending in _SHA384 the hash function is SHA384.
	TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 the hash function is SHA384.
	3.1. Recommendations for Multiple Cryptographic Processors		4. TLS Versions
			These ciphersuites make use of the authenticated encryption with
			additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis]. They
			MUST NOT be negotiated in older versions of TLS. Clients MUST NOT
			offer these cipher suites if they do not offer TLS 1.2 or later.
			Servers which select an earlier version of TLS MUST NOT select one of
			these cipher suites. Because TLS has no way for the client to
			indicate that it supports TLS 1.2 but not earlier, a non-compliant
			server might potentially negotiate TLS 1.1 or earlier and select one
			of the cipher suites in this document. Clients MUST check the TLS
			version and generate a fatal "illegal_parameter" alert if they detect
			an incorrect version.
			5. IANA Considerations
			IANA has assigned the following values for the ciphersuites defined
			in this draft:
			CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
			CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
			CipherSuite TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
			CipherSuite TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
			CipherSuite TLS_DH_RSA_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
			CipherSuite TLS_DH_RSA_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
			CipherSuite TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
			CipherSuite TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
			CipherSuite TLS_DH_DSS_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
			CipherSuite TLS_DH_DSS_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
			CipherSuite TLS_DH_anon_WITH_AES_128_GCM_SHA256 = {TBD,TBD}
			CipherSuite TLS_DH_anon_WITH_AES_256_GCM_SHA384 = {TBD,TBD}
			6. Security Considerations
			The security considerations in [I-D.ietf-tls-rfc4346-bis] apply to
			this document as well. The remainder of this section describes
			security considerations specific to the cipher suites described in
			this document.
			6.1. Counter Reuse
			AES-GCM security requires that the counter is never reused. The IV
			construction in Section 3 is designed to prevent counter reuse.
			6.2. Recommendations for Multiple Encryption Processors
	If multiple cryptographic processors are in use by the sender, then		If multiple cryptographic processors are in use by the sender, then
	the sender MUST ensure that each value of the explicit_nonce_part		the sender MUST ensure that, for a particular key, each value of the
	that is used by each processor is distinct. In this case each		explicit_nonce_part used with that key is distinct. In this case
	encryption processor SHOULD include in the explicit_nonce_part a a		each encryption processor SHOULD include in the explicit_nonce_part a
	fixed value that is distinct for each processor. The recommended		fixed value that is distinct for each processor. The recommended
	format is		format is
	explicit_nonce_part = FixedDistinct || Variable		explicit_nonce_part = FixedDistinct || Variable
	where the FixedDistinct field is distinct for each encryption		where the FixedDistinct field is distinct for each encryption
	processor, but is fixed for a given processor, and the Variable field		processor, but is fixed for a given processor, and the Variable field
	is distinct for each distinct nonce used by a particular encryption		is distinct for each distinct nonce used by a particular encryption
	processor. When this method is used, the FixedDistinct fields used		processor. When this method is used, the FixedDistinct fields used
	by the different processors MUST have the same length.		by the different processors MUST have the same length.
	In the terms of Figure 2 in [I-D.mcgrew-auth-enc], the Salt is the		In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Common
	Fixed-Common part of the nonce (it is fixed, and it is common across		part of the nonce (it is fixed, and it is common across all
	all encryption processors), the FixedDistinct field exactly		encryption processors), the FixedDistinct field exactly corresponds
	corresponds to the Fixed-Distinct field, and the Variable field		to the Fixed-Distinct field, and the Variable field corresponds to
	corresponds to the Counter field, and the explicit part exactly		the Counter field, and the explicit part exactly corresponds to the
	corresponds to the explicit_nonce_part.		explicit_nonce_part.
	For clarity, we provide an example for TLS in which there are two		For clarity, we provide an example for TLS in which there are two
	distinct encryption processors, each of which uses a one-byte		distinct encryption processors, each of which uses a one-byte
	FixedDistinct field:		FixedDistinct field:
	Salt = eedc68dc		Salt = eedc68dc
	FixedDistinct = 01 (for the first encryption processor)		FixedDistinct = 01 (for the first encryption processor)
	FixedDistinct = 02 (for the second encryption processor)		FixedDistinct = 02 (for the second encryption processor)
	The GCMnonces generated by the first encryption processor, and their		The GCMnonces generated by the first encryption processor, and their
	skipping to change at page 5, line 45		skipping to change at page 7, line 5
	The GCMnonces generated by the second encryption processor, and their		The GCMnonces generated by the second encryption processor, and their
	corresponding explicit_nonce_parts, are		corresponding explicit_nonce_parts, are
	GCMNonce explicit_nonce_part		GCMNonce explicit_nonce_part
	------------------------ ----------------------------		------------------------ ----------------------------
	eedc68dc0200000000000000 0200000000000000		eedc68dc0200000000000000 0200000000000000
	eedc68dc0200000000000001 0200000000000001		eedc68dc0200000000000001 0200000000000001
	eedc68dc0200000000000002 0200000000000002		eedc68dc0200000000000002 0200000000000002
	...		...
	4. TLS Versions
	These ciphersuites make use of the authenticated encryption with
	additional data defined in TLS 1.2 [I-D.ietf-tls-rfc4346-bis]. They
	MUST NOT be negotiated in older versions of TLS. Clients MUST NOT
	offer these cipher suites if they do not offer TLS 1.2 or later.
	Servers which select an earlier version of TLS MUST NOT select one of
	these cipher suites. Because TLS has no way for the client to
	indicate that it supports TLS 1.2 but not earlier, a non-compliant
	server might potentially negotiate TLS 1.1 or earlier and select one
	of the cipher suites in this document. Clients MUST check the TLS
	version and generate a fatal "illegal_parameter" alert if they detect
	an incorrect version.
	5. IANA Considerations
	IANA has assigned the following values for the ciphersuites defined
	in this draft:
	CipherSuite TLS_RSA_WITH_AES_128_GCM_SHA256 = {TBD1,TBD1}
	CipherSuite TLS_RSA_WITH_AES_256_GCM_SHA384 = {TBD2,TBD2}
	CipherSuite TLS_RSA_DHE_WITH_AES_128_GCM_SHA256 = {TBD3,TBD3}
	CipherSuite TLS_RSA_DHE_WITH_AES_256_GCM_SHA384 = {TBD4,TBD4}
	6. Security Considerations
	The security considerations in [I-D.ietf-tls-rfc4346-bis] apply to
	this document as well. The remainder of this section describes
	security considerations specific to the cipher suites described in
	this document.
	6.1. Perfect Forward Secrecy
	The perfect forward secrecy properties of RSA based TLS ciphersuites
	are discussed in the security analysis of [I-D.ietf-tls-rfc4346-bis].
	It should be noted that only the ephemeral Diffie-Hellman based
	ciphersuites (RSA_DHE) are capable of providing perfect forward
	secrecy.
	6.2. Counter Reuse
	AES-GCM security requires that the counter is never reused. The IV
	construction in Section 3 is designed to prevent counter reuse.
	7. Acknowledgements		7. Acknowledgements
	This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac].		This draft borrows heavily from [I-D.ietf-tls-ecc-new-mac]. The
			authors would like to thank Alex Lam and Pasi Eronen for providing
			useful comments during the review of this draft.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[AES] National Institute of Standards and Technology,		[AES] National Institute of Standards and Technology,
	"Specification for the Advanced Encryption Standard		"Specification for the Advanced Encryption Standard
	(AES)", FIPS 197, November 2001.		(AES)", FIPS 197, November 2001.
	[GCM] National Institute of Standards and Technology,		[GCM] National Institute of Standards and Technology,
	"Recommendation for Block Cipher Modes of Operation:		"Recommendation for Block Cipher Modes of Operation:
	Galois Counter Mode (GCM) for Confidentiality and		Galois Counter Mode (GCM) for Confidentiality and
	Authentication", SP 800-38D, April 2006.		Authentication", SP 800-38D, April 2006.
	[I-D.ietf-tls-rfc4346-bis]		[I-D.ietf-tls-rfc4346-bis]
	Dierks, T. and E. Rescorla, "The Transport Layer Security		Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-07		(TLS) Protocol Version 1.2", draft-ietf-tls-rfc4346-bis-08
	(work in progress), November 2007.		(work in progress), January 2008.
	[I-D.mcgrew-auth-enc]
	McGrew, D., "An Interface and Algorithms for Authenticated
	Encryption", draft-mcgrew-auth-enc-05 (work in progress),
	November 2007.
	[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.
	[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security", RFC 4347, April 2006.		Security", RFC 4347, April 2006.
			[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
			Encryption", RFC 5116, January 2008.
	8.2. Informative References		8.2. Informative References
	[I-D.ietf-tls-ecc-new-mac]		[I-D.ietf-tls-ecc-new-mac]
	Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-		Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
	256/384 and AES Galois Counter Mode",		256/384 and AES Galois Counter Mode",
	draft-ietf-tls-ecc-new-mac-02 (work in progress),		draft-ietf-tls-ecc-new-mac-02 (work in progress),
	December 2007.		December 2007.
	[I-D.rescorla-tls-suiteb]
	Salter, M. and E. Rescorla, "Suite B Cipher Suites for
	TLS", draft-rescorla-tls-suiteb-01 (work in progress),
	June 2007.
	[IEEE8021AE]		[IEEE8021AE]
	Institute of Electrical and Electronics Engineers, "Media		Institute of Electrical and Electronics Engineers, "Media
	Access Control Security", IEEE Standard 802.1AE,		Access Control Security", IEEE Standard 802.1AE,
	August 2006.		August 2006.
	[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode		[RFC4106] Viega, J. and D. McGrew, "The Use of Galois/Counter Mode
	(GCM) in IPsec Encapsulating Security Payload (ESP)",		(GCM) in IPsec Encapsulating Security Payload (ESP)",
	RFC 4106, June 2005.		RFC 4106, June 2005.
	Authors' Addresses		Authors' Addresses
End of changes. 31 change blocks.
	118 lines changed or deleted		115 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/