Subject: [MSEC] Potential problem with Authentication key lengths

From: "Christian Beaulieu" <[email-masked]>
Date: Wed, 13 Apr 2005 11:54:01 -0400

In section 4.2.4 of RFC 3830, it is stated that "authentication key size
SHOULD be equal to the size of the hash

   function's output (e.g., for HMAC-SHA-1, a 160-bit authentication key

   is used)" 

This means that there is nothing stopping an implementation from using a
key length different from 160 bits. The problem that arises from this is
that there is no way for 2 peers to know which size of authentication
key the other is using.

Shouldn't the authentication key size be a MUST rather than a SHOULD?

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

---

From: Mats Näslund <[email-masked]>
Date: Wed, 13 Apr 2005 20:00:45 +0200

Hi Christian,

Note that Section 4.2.4 of RFC 3830 specifies general requirements on
the functions (and also extensions to MIKEY).

Section 6.2 on the other hand specifies the exact profile used. And as
you may see, RFC3830 only supports the full length, 160 bits output.

So, the SHOULD in section 4.2.4 is to be seen as guideline for those who
like to specify new authentication profiles for MIKEY. Sect 6.2, OTOH,
is a specification of the current profile.

Best,

/Mats + MIKEY team

Christian Beaulieu wrote:

> In section 4.2.4 of RFC 3830, it is stated that “authentication key size 
>    is used)”
> Shouldn’t the authentication key size be a MUST rather than a SHOULD?
> 
>  
> 
> “KEMAC when used
>      thus Encr alg SHALL be set to 2 (NULL), Encr data len SHALL be set”
> 
>  
>

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 13 Apr 2005 14:51:31 -0700

Hi,

There are two separate topics: Auth key length and MAC length.

I know MAC truncation is acceptable in some cases (pl. see CFRG 
archive), but don't think specifying key length can be arbitrary, 
especially less than the block size, is a good idea.  In fact, 2104 says 
that "The key for HMAC can be of any length (keys longer than B bytes 
are first hashed using H).  However, less than L bytes is strongly 
discouraged as it would decrease the security strength of the function."

L = 20 for SHA-1 as specified elsewhere in that RFC.  2104 is 
informational so that might be the strongest terminology Ran et. al. 
could use.

So, I think MUST is more appropriate in Sec 4.2.4 of 3830, as in "Key 
length MUST be equal to or greater than the block size"  (I think block 
size is more appropriate since it is conceivable that MIKEY might be 
used with cipher-based MAC algorithms in addition to hash-based ones).

best,
Lakshminath
(My opinion as a WG contributor)

Mats Näslund wrote:

>> In section 4.2.4 of RFC 3830, it is stated that “authentication key 
>> size SHOULD be equal to the size of the hash
>>
>> This means that there is nothing stopping an implementation from 
>> using a key length different from 160 bits. The problem that arises 
>> from this is that there is no way for 2 peers to know which size of 
>> authentication key the other is using.
>>
>>  
>>
>> In RFC 3830, the NULL for the encryption algorithm for a KEMAC 
>> payload is 0. The value 2 is for AES-KW-128.
>>
>>  
>>
>>  
>>
>> Christian
>>
>