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

From: [email-masked]
Date: Fri, 29 Sep 2006 09:22:37 -0700

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

ained 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

---

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

Hi Steve,

Thanks for the quick and detailed review.  Responses inline...

>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.

Part of the confusion probably derives from trying to combine PRF functionality into the same doc with authentication/integrity functionality (the latter of which was already in the doc), yet maintain differing requirements for the keys. Maybe that was a mistake. The intent was that for integrity/auth, you have to use a fixed length, as RFC2104 explicitly recommends against shorter keys, and this lanuage is consistent with RFC2403 and the other HMAC RFCs.

We added the PRF support after that text was written (rather than writing a separate doc), and in the interest of flexibility, chose to allow variable length keys.  I'm wondering now if that was a mistake, and we should have had a single position on key sizes. That would definitely simplify things.

As for padding short keys, it certainly adds no security. It is there to explicitly tell implementors what to do (so they don't instead hash the key, and use the output). It's called out for the sake of interoperability. 

As for using longer keys, I see now that I misread this line in 2104:

"Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC."

'B' refers to the block size (in this case, 512 bits), but I was thinking of 256 bits, in which case you would simply hash the key and use the output. Definitely my mistake, and I will fix this in the next rev.

>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.

Okay.

>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.

Russ just mentioned that NSA-B requires SHA-384 support, and I was looking at the draft to see if that could be cleanly dropped in - this might be one way to do it.  If there is general support for this approach, we can look at what it would take to re-spin the doc.

Thanks again for the review,

Scott