Subject: I-D ACTION:draft-ietf-ipsec-ikev2-algorithms-00.txt

From: [email-masked]
Date: Tue, 20 May 2003 07:26:54 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IP Security Protocol Working Group of the IETF.

	Title		: Cryptographic Algorithms for use in the Internet Key 
                          Exchange Version 2
	Author(s)	: J. Schiller
	Filename	: draft-ietf-ipsec-ikev2-algorithms-00.txt
	Pages		: 6
	Date		: 2003-5-19
	
The IPSec series of protocols makes use of various cryptographic
algorithms in order to provide security services. The Internet Key
Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to
negotiate which algorithms should be used in any even association.
However to ensure interoperability between disparate implementations it
is necessary to specify a set of mandatory to implement algorithms to
ensure at least one algorithm that all implementations will have
available. This document defines the current set of mandatory to
implement algorithms for use of IKEv2 as well as specifying algorithms
that should be implemented because they made be promoted to mandatory
at some future time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipsec-ikev2-algorithms-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Russ Housley <[email-masked]>
Date: Fri, 23 May 2003 11:33:13 -0400

I am glad to see that this draft was finally posted, but it does not 
reflect my recollection of the working group consensus prior to the San 
Francisco IETF meeting.

I am very pleaded to see SHOULD+, SHOULD-, and MUST-.  These provide 
important guidance to product planners.

In section 4.1.1 on IKEv2 Encrypted Payload Algorithms, I expected:

	MUST		Three-key Triple-DES in CBC mode
	SHOULD+	128-bit AES in CBC mode

In section 4.1.2, I expected no mention of elliptic curves.  The working 
group abandoned work in this area many months ago.  Also, I expected:

	MUST		1024
	SHOULD	1536
	SHOULD+	2048

In section  4.1.3 on IKEv2 Transfer Type 1 Algorithms, I expected two of 
the entries to have different requirements:

	MUST		ENCR_3DES (assuming that this is 3-key 3DES in CBC mode)
	SHOULD+	ENCR_AES_128_CBC

In section 4.1.4 on IKEv2 Transfer Type 2 Algorithms, I expected two of the 
entries to have different requirements:

	MAY		PRF_HMAC_MD5
	SHOULD	PRF_AES128_CBC

I also thought that we were going to define a shorthand way to configure 
different devices to use the same selections from the a la carte menu.  At 
a minimum, we should come up with a name for the collection of MUST algorithms.

Do others have different recollections and expectiations?

Russ

---

From: Stephen Kent <[email-masked]>
Date: Fri, 30 May 2003 09:46:45 -0400

At 11:33 AM -0400 5/23/03, Russ Housley wrote:
>reflect my recollection of the working group consensus prior to the 
>San Francisco IETF meeting.
>
>In section 4.1.2, I expected no mention of elliptic curves.  The 
>working group abandoned work in this area many months ago.  Also, I 
>expected:
>
>	MUST		1024
>	SHOULD	1536
>	SHOULD+	2048
>
>In section  4.1.3 on IKEv2 Transfer Type 1 Algorithms, I expected 
>two of the entries to have different requirements:
>
>In section 4.1.4 on IKEv2 Transfer Type 2 Algorithms, I expected two 
>of the entries to have different requirements:
>
>	MAY		PRF_HMAC_MD5
>	SHOULD	PRF_AES128_CBC
>
>I also thought that we were going to define a shorthand way to 
>configure different devices to use the same selections from the a la 
>carte menu.  At a minimum, we should come up with a name for the 
>collection of MUST algorithms.
>

Russ,

Your comments above match my recollection of what was agreed upon and 
documented in earlier drafts by Paul.

Steve

---

From: Barbara Fraser <[email-masked]>
Date: Fri, 30 May 2003 09:15:33 -0700

I agree. Jeff indicated in a conversation earlier this week that he is 
updating his draft accordingly.

thanks,
Barb

At 06:46 AM 5/30/2003, Stephen Kent wrote:
>>In section 4.1.4 on IKEv2 Transfer Type 2 Algorithms, I expected two of 
>>different devices to use the same selections from the a la carte 
>>menu.  At a minimum, we should come up with a name for the collection of 
>>MUST algorithms.
>>

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Fri, 30 May 2003 16:31:47 -0400

I just submitted a new version to the I-D Directory that I believe 
addresses these comments.

			-Jeff

Russ Housley wrote:
> different devices to use the same selections from the a la carte menu.  
> At a minimum, we should come up with a name for the collection of MUST 
> algorithms.
>