Subject: RE: [MSEC] Potential problem with Authentication key lengths

From: Euchner Martin <[email-masked]>
Date: Fri, 15 Apr 2005 09:25:24 +0200

Christian,

Many thanks for pointing out the error. You're correct in that the value of the MIKEY null encryption is indeed 0 as is specified in RFC 3830 section 6.2.

So the corrected first paragraph in section 4.2 of draft-ietf-msec-mikey-dhhmac-11.txt should now read:

DHHMAC SHALL apply this payload for conveying the HMAC result along with the indicated authentication algorithm. KEMAC when used in conjunction with DHHMAC SHALL not convey any encrypted data; thus Encr alg SHALL be set to 0 (NULL), Encr data len SHALL be set to 0 and Encr data SHALL be left empty. The AES key wrap method (see [23]) SHALL not be applied for DHHMAC.

Question to WG chair:

How can we best handle this correction appropriately, since dhhmac-11.txt has already entered the RFC editor's queue? 

Should I submit an update (dhhmac-12.txt) with that correction and let the RFC editor know?

Or should I instruct the RFC editor to make that particular correction on my behalf?

Martin.

Also in draft-ietf-msec-mikey-dhhmac-11 in section 4.2 it says that "KEMAC when used

     in conjunction with DHHMAC SHALL not convey any encrypted data;

     thus Encr alg SHALL be set to 2 (NULL), Encr data len SHALL be set"

In RFC 3830, the NULL for the encryption algorithm for a KEMAC payload is 0. The value 2 is for AES-KW-128.

Christian

_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec