< draft-ietf-ipsec-ikev2-algorithms-04.txt		draft-ietf-ipsec-ikev2-algorithms-05.txt >
	IPSEC Working Group Jeffrey I. Schiller		IPSEC Working Group Jeffrey I. Schiller
	INTERNET-DRAFT		INTERNET-DRAFT
	draft-ietf-ipsec-ikev2-algorithms-04.txt September 2003		draft-ietf-ipsec-ikev2-algorithms-05.txt April 2004
	Cryptographic Algorithms for use in the		Cryptographic Algorithms for use in the
	Internet Key Exchange Version 2		Internet Key Exchange Version 2
	<draft-ietf-ipsec-ikev2-algorithms-04.txt>		<draft-ietf-ipsec-ikev2-algorithms-05.txt>
	Status of this Memo		Status of this Memo
	This document is a submission by the IPSEC Working Group of the		This document is a submission by the IPSEC Working Group of the
	Internet Engineering Task Force (IETF). Comments should be submitted		Internet Engineering Task Force (IETF). Comments should be submitted
	to the ipsec@lists.tislabs.com mailing list.		to the ipsec@lists.tislabs.com mailing list.
	Distribution of this memo is unlimited.		Distribution of this memo is unlimited.
	This document is an Internet Draft and is in full conformance with all		This document is an Internet Draft and is in full conformance with all
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	"1id-abstracts.txt" listing contained in the Internet Drafts Shadow		"1id-abstracts.txt" listing contained in the Internet Drafts Shadow
	Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),		Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
	munnari.oz.au (Australia), ds.internic.net (US East Coast), or		munnari.oz.au (Australia), ds.internic.net (US East Coast), or
	ftp.isi.edu (US West Coast).		ftp.isi.edu (US West Coast).
	1. Abstract		1. Abstract
	The IPSec series of protocols makes use of various cryptographic		The IPSec series of protocols makes use of various cryptographic
	algorithms in order to provide security services. The Internet Key		algorithms in order to provide security services. The Internet Key
	Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to		Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to
	negotiate which algorithms should be used in any even association.		negotiate which algorithms should be used in any given association.
	However to ensure interoperability between disparate implementations it		However to ensure interoperability between disparate implementations it
	is necessary to specify a set of mandatory to implement algorithms to		is necessary to specify a set of mandatory-to-implement algorithms to
	ensure at least one algorithm that all implementations will have		ensure at least one algorithm that all implementations will have
	available. This document defines the current set of mandatory to		available. This document defines the current set of algorithms that are
	implement algorithms for use of IKEv2 as well as specifying algorithms		mandatory to implement as part of IKEv2, as well as algorithms that
	that should be implemented because they made be promoted to mandatory		should be implemented because they may be promoted to mandatory at some
	at some future time.		future time.
	2. Introduction		2. Introduction
	The Internet Key Exchange protocol provides for the negotiation of		The Internet Key Exchange protocol provides for the negotiation of
	cryptographic algorithms between both end points of a cryptographic		cryptographic algorithms between both end points of a cryptographic
	Draft-ietf-ipsec-ikev2-algorithms-04.txt September 2003
	association. Different implementations of IPSec and IKE may provide		association. Different implementations of IPSec and IKE may provide
	different algorithms. However the IETF desires that all implementations		different algorithms. However the IETF desires that all implementations
	should have some way to interoperate. This requires that some set of		should have some way to interoperate. In particular,
	algorithms be specified as "mandatory to implement."		this requires that IKE define a set of mandatory-to-implement
			algorithms, since IKE itself uses such algorithms as part of its own
			negotiations. This requires that some set of algorithms be specified
			as "mandatory-to-implement" for IKE.
	The nature of cryptography is that new algorithms surface continuously		The nature of cryptography is that new algorithms surface continuously
	and existing algorithms are continuously attacked. An algorithm		and existing algorithms are continuously attacked. An algorithm
	believed to be strong today may be demonstrated to be weak tomorrow.		believed to be strong today may be demonstrated to be weak tomorrow.
	Given this, the choice of mandatory to implement algorithm should be		Given this, the choice of mandatory-to-implement algorithm should be
	conservative so as to minimize the likelihood of it being compromised		conservative so as to minimize the likelihood of it being compromised
	quickly. Thought should also be given to performance considerations as		quickly. Thought should also be given to performance considerations as
	many uses of IPSec will be in environments where performance is a		many uses of IPSec will be in environments where performance is a
	concern.		concern.
	Finally we need to recognize that the mandatory to implement		Finally we need to recognize that the mandatory-to-implement
	algorithm(s) may need to change over time to adapt to the changing		algorithm(s) may need to change over time to adapt to the changing
	world. For this reason the selection of mandatory to implement		world. For this reason the selection of mandatory-to-implement
	algorithms was removed from the main IKEv2 specification and placed in		algorithms was removed from the main IKEv2 specification and placed in
	this document. As the choice of algorithm changes, only this document		this document. As the choice of algorithm changes, only this document
	should need to be updated.		should need to be updated.
	Ideally the mandatory to implement algorithm of tomorrow should already		Ideally the mandatory-to-implement algorithm of tomorrow should already
	be available in most implementations of IPSec by the time it is made		be available in most implementations of IPSec by the time it is made
	mandatory. To facilitate this we will attempt to identify those		mandatory. To facilitate this we will attempt to identify those
	algorithms (that are known today) in this document. There is no		algorithms (that are known today) in this document. There is no
	guarantee that the algorithms we believe today may be mandatory in the		guarantee that the algorithms we believe today may be mandatory in the
	future will in fact become so. All algorithms known today are subject		future will in fact become so. All algorithms known today are subject
	to cryptographic attack, and may be broken.		to cryptographic attack, and may be broken.
	3. Requirements Terminology		3. Requirements Terminology
	Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and		Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
	"MAY" that appear in this document are to be interpreted as described		"MAY" that appear in this document are to be interpreted as described
	in [RFC2119].		in [RFC2119].
	In addition we will define some additional terms here:		In addition we will define some additional terms here:
	SHOULD+ This term means the same as SHOULD. However it is		SHOULD+ This term means the same as SHOULD. However it is
	likely that an algorithm marked as SHOULD+ will be		likely that an algorithm marked as SHOULD+ will be
	promoted at some future time to be a MUST		promoted at some future time to be a MUST.
	SHOULD- This terms means the same as SHOULD. However an		SHOULD- This terms means the same as SHOULD. However an
	algorithm marked as SHOULD- may be deprecated to a		algorithm marked as SHOULD- may be deprecated to a
	MAY in a future version of this document.		MAY in a future version of this document.
	Draft-ietf-ipsec-ikev2-algorithms-04.txt September 2003
	MUST- This term means the same as MUST. However we		MUST- This term means the same as MUST. However we
	expect at some point that this algorithm will no		expect at some point that this algorithm will no
	longer be a MUST in a future document. Although		longer be a MUST in a future document. Although
	its status will be determined at a later time, it		its status will be determined at a later time, it
	is reasonable to expect that if a future revision		is reasonable to expect that if a future revision
	of a document alters the status of a MUST-		of a document alters the status of a MUST-
	algorithm, it will remain at least a SHOULD or a		algorithm, it will remain at least a SHOULD or a
	SHOULD-.		SHOULD-.
	4. Algorithm Selection		4. Algorithm Selection
	4.1. IKEv2 Algorithm Selection		4.1. IKEv2 Algorithm Selection
	4.1.1. Encrypted Payload Algorithms		4.1.1. Encrypted Payload Algorithms
	The IKEv2 Encrypted Payload requires both a confidentiality algorithm		The IKEv2 Encrypted Payload requires both a confidentiality algorithm
	and an integrity algorithm.		and an integrity algorithm.
	For Confidentiality 3DES-CBC is a MUST implement and AES-128-CBC is a		For confidentiality, implementations MUST implement 3DES-CBC and
	SHOULD+. For integrity HMAC-SHA1 is a MUST implement.		SHOULD+ implement AES-128-CBC. For integrity, HMAC-SHA1 MUST be
			implemented.
	4.1.2. Diffie-Hellman Groups		4.1.2. Diffie-Hellman Groups
	There are several MODP groups that are defined for use in IKEv2. They		There are several MODP groups that are defined for use in IKEv2. They
	are defined in both the IKEv2 base document and in the MODP extensions		are defined in both the IKEv2 base document and in the MODP extensions
	document. They are identified by group number. Any groups not listed		document. They are identified by group number. Any groups not listed
	here are considered as MAY implement.		here are considered as "MAY be implemented".
	Group Number Bit Length Status Defined		Group Number Bit Length Status Defined
	2 1024 MUST [RFC2409]		2 1024 MODP Group MUST- [RFC2409]
	5 1536 SHOULD [RFC3526]
	14 2048 MODP Group SHOULD+ [RFC3526]		14 2048 MODP Group SHOULD+ [RFC3526]
	4.1.3. IKEv2 Transform Type 1 Algorithms		4.1.3. IKEv2 Transform Type 1 Algorithms
	IKEv2 Defines several possible algorithms for Transfer Type 1		IKEv2 Defines several possible algorithms for Transfer Type 1
	(encryption). These are defined below with their implementation status		(encryption). These are defined below with their implementation status.
	Draft-ietf-ipsec-ikev2-algorithms-04.txt September 2003
	Name Number Defined In Status		Name Number Defined In Status
	RESERVED 0		RESERVED 0
	ENCR_3DES 3 [RFC2451] MUST		ENCR_3DES 3 [RFC2451] MUST-
	ENCR_NULL 11 [RFC2410] MAY		ENCR_NULL 11 [RFC2410] MAY
	ENCR_AES_CBC 12 [AES-CBC] SHOULD+		ENCR_AES_CBC 12 [AES-CBC] SHOULD+
	ENCR_AES_CTR 13 [AES-CTR] SHOULD		ENCR_AES_CTR 13 [AES-CTR] SHOULD
	4.1.4. IKEv2 Transform Type 2 Algorithms		4.1.4. IKEv2 Transform Type 2 Algorithms
	Transfer Type 2 Algorithms are pseudo-random functions used to generate		Transfer Type 2 Algorithms are pseudo-random functions used to generate
	random values when needed.		random values when needed.
	Name Number Defined In Status		Name Number Defined In Status
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+		AUTH_AES_XCBC_96 5 [AES-MAC] SHOULD+
	5. Security Considerations		5. Security Considerations
	The security of cryptographic based systems depends on both the		The security of cryptographic based systems depends on both the
	strength of the cryptographic algorithms chosen, the strength of the		strength of the cryptographic algorithms chosen, the strength of the
	keys used with those algorithms and the engineering of the protocol		keys used with those algorithms and the engineering of the protocol
	used by the system to ensure that there are no non-cryptographic ways		used by the system to ensure that there are no non-cryptographic ways
	to bypass the security of the overall system.		to bypass the security of the overall system.
	Draft-ietf-ipsec-ikev2-algorithms-04.txt September 2003
	This document concerns itself with the selection of cryptographic		This document concerns itself with the selection of cryptographic
	algorithms for the use of IKEv2, specifically with the selection of		algorithms for the use of IKEv2, specifically with the selection of
	"Mandatory to Implement" algorithms. The algorithms identified in this		"mandatory-to-implement" algorithms. The algorithms identified in this
	document as MUST implement or SHOULD implement are not known to be		document as "MUST implement" or "SHOULD implement" are not known to be
	broken at the current time and cryptographic research so far leads us		broken at the current time and cryptographic research so far leads us
	to believe that they will likely remain secure into the foreseeable		to believe that they will likely remain secure into the foreseeable
	future. However, this isn't necessarily forever. We would therefore		future. However, this isn't necessarily forever. We would therefore
	expect that new revisions of this document will be issued from time to		expect that new revisions of this document will be issued from time to
	time that reflect the current best practice in this area.		time that reflect the current best practice in this area.
	6. IANA Considerations		6. IANA Considerations
	This document does not define any new registries nor elements in		This document does not define any new registries nor elements in
	existing registries. Values given here for various algorithms are		existing registries. Values given here for various algorithms are
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 5 ¶
	[AESPRF] P. Hoffman, "The AES-XCBC-PRF-128 algorithm for IKE",		[AESPRF] P. Hoffman, "The AES-XCBC-PRF-128 algorithm for IKE",
	<draft-hoffman-ipsec-aes-prf-00.txt>, 2003		<draft-hoffman-ipsec-aes-prf-00.txt>, 2003
	[RFC2403] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP		[RFC2403] C. Madson, R. Glenn, "The Use of HMAC-MD5-96 within ESP
	and AH", RFC2403, 1998		and AH", RFC2403, 1998
	[RFC2404] C. Madson, R. Glenn, "The Use of HMAC-SHA-1-96 within ESP		[RFC2404] C. Madson, R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
	and AH", RFC2404, 1998		and AH", RFC2404, 1998
	[AES-MAC] S. Frankel,H. Herbert, "The AES-XCBC-MAC-96 Algorithm and		[AES-MAC] S. Frankel,H. Herbert, "The AES-XCBC-MAC-96 Algorithm and
	Its Use With IPsec", <draft-ietf-ipsec-ciph-aes-xcbc-mac-		Its Use With IPsec", <draft-ietf-ipsec-ciph-aes-xcbc-mac-
	04.txt>, 2003		04.txt>, 2003
	Draft-ietf-ipsec-ikev2-algorithms-04.txt September 2003
	8. Author's Contact Information		8. Author's Contact Information
	Jeffrey I. Schiller		Jeffrey I. Schiller
	Massachusetts Institute of Technology		Massachusetts Institute of Technology
	Room W92-190		Room W92-190
	77 Massachusetts Avenue		77 Massachusetts Avenue
	Cambridge, MA 02139-4307		Cambridge, MA 02139-4307
	USA		USA
	Phone: +1 (617) 253-0161		Phone: +1 (617) 253-0161
	E-mail: jis@mit.edu		E-mail: jis@mit.edu
	9. Full Copyright Statement		9. Full Copyright Statement
	"Copyright (C) The Internet Society (2003). All Rights Reserved.		"Copyright (C) The Internet Society (2004). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it or		others, and derivative works that comment on or otherwise explain it or
	assist in its implementation may be prepared, copied, published and		assist in its implementation may be prepared, copied, published and
	distributed, in whole or in part, without restriction of any kind,		distributed, in whole or in part, without restriction of any kind,
	provided that the above copyright notice and this paragraph are		provided that the above copyright notice and this paragraph are
	included on all such copies and derivative works. However, this		included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing the		document itself may not be modified in any way, such as by removing the
	copyright notice or references to the Internet Society or other		copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of developing		Internet organizations, except as needed for the purpose of developing
End of changes. 22 change blocks.
	34 lines changed or deleted		28 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/