Subject: Fw: [Ipsec] I-D ACTION:draft-kelly-ipsec-ciph-sha2-00.txt

From: "Scott G. Kelly" <[email-masked]>
Date: Fri, 29 Sep 2006 13:01:24 -0400 (EDT)

Please review and comment on this draft. It's a revamped version of draft-ietf-ipsec-ciph-sha2-01.txt, resurrected at Russ's request.  

-----Forwarded Message-----
>From: [email-masked]
>Sent: Sep 29, 2006 12:22 PM
>To: IPsec WG <[email-masked]>
>Subject: [Ipsec] I-D ACTION:draft-kelly-ipsec-ciph-sha2-00.txt
>
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>	Title		: Using HMAC-SHA-256 With IPsec
>	Author(s)	: S. Kelly, S. Frankel
>	Filename	: draft-kelly-ipsec-ciph-sha2-00.txt
>	Pages		: 14
>	Date		: 2006-9-29
>
>
>    This specification describes the use of the SHA-256 algorithm in
>    conjunction with HMAC as a data origin authentication and integrity
>    verification mechanism for the IPsec AH, ESP, and IKEv2 protocols,
>    and also as a PRF for IKEv2.  Two output truncation lengths are
>    specified for data origin authentication and integrity verification
>    usage, with the corresponding algorithms designated as HMAC-SHA-256-
>    128 and HMAC-SHA-256-192.  No truncation is specified for PRF usage,
>    and the resulting algorithm is designated as HMAC-SHA-PRF-256.
>
>
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt
>
>To remove yourself from the I-D Announcement list, send a message to
>[email-masked] with the word unsubscribe in the body of
>the message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>to change your subscription settings.
>
>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-kelly-ipsec-ciph-sha2-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-kelly-ipsec-ciph-sha2-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.
>
>
>[The following attachment must be fetched by mail. Command-click the 
>URL below and send the resulting message to get the attachment.]
><mailto:[email-masked]?body=ENCODING%20mime%0D%0AFILE%20/internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt>
>[The following attachment must be fetched by ftp.  Command-click the 
>URL below to ask your ftp client to fetch it.]
><ftp://ftp.ietf.org/internet-drafts/draft-kelly-ipsec-ciph-sha2-00.txt>
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/i-d-announce
>
>_______________________________________________
>Ipsec mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ipsec

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 29 Sep 2006 16:27:53 -0400

On Fri, 29 Sep 2006 13:01:24 -0400 (EDT), "Scott G. Kelly"
<[email-masked]> wrote:

> Please review and comment on this draft. It's a revamped version of
> draft-ietf-ipsec-ciph-sha2-01.txt, resurrected at Russ's request.  

I found 2.1.1 + 2.1.2 confusing.  2.1.1 says you can't have keys of other
than length 256.  I might quarrel with that -- I'd definitely have used
SHOULD NOT instead of MUST NOT -- but 2.1.2 tells you what to do if your
key isn't 256 bits long.  I perceive no increase in security from padding
a short key with zeros, nor do I understand why it's better to do a
SHA-256 reduction on a long key before using it with HMAC rather than
simply using the longer key directly.  And the notion of a variable key
length function where the variable is constrained to exactly one value is
a bit strange.

You might want to cite RFC 4634 as an Informative reference, since it has
code, and 4231 since it also gives definitions and code points for other
uses of HMAC-SHA-256.

Stepping back a bit, I personally would rather see a single RFC describing
how to use a number of different hash functions with HMAC.  I could almost
use a set of text editor substitution patterns to change this draft from
SHA-256 to SHA-384 or SHA-512.  The core of such a document would be a
table listing acceptable key sizes and truncation sizes for each function
considered.  An appendix could list test vectors.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb