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

From: [email-masked]
Date: Thu, 18 Dec 2003 15:30:37 -0500

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 Algorithm Implementation Requirements For ESP And AH
	Author(s)	: D. Eastlake 3rd
	Filename	: draft-ietf-ipsec-esp-ah-algorithms-00.txt
	Pages		: 9
	Date		: 2003-12-18
	
The IPSEC series of protocols makes use of various cryptographic
    algorithms in order to provide security services. The Encapsulating
    Security Payload (ESP) and the Authentication Header (AH) provide two
    mechanisms for protecting data being sent over an IPSEC Security
    Association (SA).  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 ESP and AH as
    well as specifying algorithms that should be implemented because they
    may be promoted to mandatory at some future time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-ah-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-esp-ah-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-esp-ah-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: chris stillson <[email-masked]>
Date: Thu, 18 Dec 2003 17:09:50 -0800

This draft bilds down to the following tables:

      Requirement    Encryption Algorithm
      -----------    --------------------
      MUST           NULL (1)
      MUST-          TripleDES-CBC [RFC 2451]
      SHOULD+        AES-CBC with 128-bit keys [RFC 3602]
      SHOULD         AES-CTR [AES-CTR]
      SHOULD NOT     DES-CBC [RFC 2405] (3)

      Requirement    Authentication Algorithm
      -----------    ------------------------
      MUST           HMAC-SHA1-96 [RFC 2404]
      MUST           NULL (1)
      SHOULD+        AES-XCBC-MAC-96 [RFC 3566]
      MAY            HMAC-MD5-96 [RFC 2403] (2)

      Requirement    Algorithm
      -----------    ---------
      MUST           HMAC-SHA1-96 [RFC 2404]
      SHOULD+        AES-XCBC-MAC-96 [RFC 3566]
      MAY            HMAC-MD5-96 [RFC 2403] (1)

The +/- distinction is splitting hairs. MUST/SHOULD/MAY are enough to
convey any distinctions. Also, although MD5 has some know problems,
the fact that it's faster than SHA1 and provides enough security for
most uses implies that it should be a "SHOULD", if not a "MUST"

Also, AES-CBC should be a "MUST". It is quickly becoming the standard
in the same way DES was, with a much higher throughput and degree of
security. DES-CBC should be a "MUST NOT", but people will want it so
we will have to provide it.

chris stillson
IPSEC crypto monkey
x82477

Note: Preceding comments written by an engineer. There is nothing
to read into them. He really has no hidden motives or agendas.

1.Right Understanding 2.Right Thoughts 3.Right Speech 4.Right Action 
5.Right Livelihood 6.Right Effort 7.Right Mindfulness 8.Right Concentration 
--Please inform author if he has forgotten about any of these

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 18 Dec 2003 18:15:44 -0800

At 5:09 PM -0800 12/18/03, chris stillson wrote:
>convey any distinctions.

Errrr, the WG already agreed to these when we moved 
draft-ietf-ipsec-ikev2-algorithms-04.txt out of the WG. The use in 
this draft seems identical (other than the gratuitous SHOULD NOT for 
DES).

>  Also, although MD5 has some know problems,

The fact is that MD5 doesn't have the strength of SHA-1 (128 bits vs 
160 bits). That is why SHA-1 is preferred in this context.

>Also, AES-CBC should be a "MUST".

This was discussed many times on the mailing list before WG last call 
on the main algorithms document. When they all go into IETF Last 
Call, you might want to bring it up again, but it would be a Really 
Bad Thing to have the AH and ESP document have different requirements 
than the algorithms document.

--Paul Hoffman, Director
--VPN Consortium