You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kerby@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2016/01/08 13:09:53 UTC
Cheskum types
Hi,
as I'm reviewing the ChecksumType enum, I think there is a bit of work
to do here.
This enum is a copy of the krb5.hin file, which is a bit old. I was able
to find most of the RFCs where the various checksums are defined, mostly
RFC 3961, but some other RFC are also in use (RFC 3962, RFC 4757 updated
by RFC 6649).
1 CRC32 /** Defined in RFC 3961, section 6.1.3 */
2 RSA_MD4 /** Defined in RFC 3961, section 6.1.2 */
3 RSA_MD4_DES /** Defined in RFC 3961, section 6.2.5 */
4 DES_CBC ???
4 DES_MAC /** Defined in RFC 3961, section 6.2.7 */
5 DES_MAC_K undefined
6 RSA_MD4_DES_K undefined
7 RSA_MD5 /** Defined in RFC 3961, section 6.1.1 */
8 RSA_MD5_DES /** Defined in RFC 3961, section 6.2.4 */
9 RSA_MD5_DES3 undefined
9 NIST_SHA ???
12 HMAC_SHA1_DES3 /** Defined in RFC 3961, section 6.3 */
12 HMAC_SHA1_DES3_KD same
15 HMAC_SHA1_96_AES128 /** Defined in RFC 3962, section 7 */
16 HMAC_SHA1_96_AES256 /** Defined in RFC 3962, section 7 */
17 CMAC_CAMELLIA128 /** Defined in RFC 6803, section 9 */
18 CMAC_CAMELLIA256 /** Defined in RFC 6803, section 9 */
//Microsoft netlogon cksumtype
-137 MD5_HMAC_ARCFOUR
//Microsoft md5 hmac cksumtype
-138 HMAC_MD5_ARCFOUR /** Defined in RFC 4757, section 4 */
-138 HMAC_MD5_ENC /** Defined in RFC 4757, section 4 */
-138 HMAC_MD5_RC4 /** Defined in RFC 4757, section 4 */
So here, we have two things : the MD5_HMAC_ARCFOUR checkusm type is for
an old M$ Protocol (NT 4.0) and I'm not sure we should use it, and the
RFC 6649 proposes to deprecate checksum type CRC32(1), RSA-MD4(2),
RSA-MD4-DES(3), DES-MAC(4), DES-MAC-K(5), RSA-MD4-DES-K(6), RSA-MD5-DES(8).
What should we do regarding those recent recommandations ?
RE: Cheskum types
Posted by "Zheng, Kai" <ka...@intel.com>.
Ah right, good point! That's why these enc/checksum types were still made out even we know they're deprecated already. Yeah we would deprecate them, not retire or total abandon them. I believe we need some sort of work to revisit this field considering such things. Enc/checksum types are used in various places where they need to be configurable. Different places need different level of secure or strength of encryption and checksum types. Your suggestion sounds good to me, configurable, and also API allowing to set on demand.
Regards,
Kai
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Friday, January 08, 2016 10:33 PM
To: kerby@directory.apache.org
Subject: Re: Cheskum types
Le 08/01/16 14:42, Zheng, Kai a écrit :
> Yeah, we need to catch up with latest updates in this aspect and deprecate some of encryption and checksum types for security considerations. I think this can done prior to 1.0.0, aligning with both MIT Kerberos and Oracle Java.
The question here is : do we want to guarantee a sort of backward compatibility with old (and unsecure) Kerberos implementation ?
One option would be to add some configuration element that enable the deprecated Checksum type on demand. That would be totally insane, but you never know what users have to deal with, especially in big companies or administrations ;-)
For instance, in France, one airport was shutdown for half a day at the end of last year because one system was running on a ... windows 3.1 computer !!!
(http://arstechnica.com/information-technology/2015/11/failed-windows-3-1-system-blamed-for-taking-out-paris-airport/).
Have fun ;-)
Re: Cheskum types
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 08/01/16 14:42, Zheng, Kai a écrit :
> Yeah, we need to catch up with latest updates in this aspect and deprecate some of encryption and checksum types for security considerations. I think this can done prior to 1.0.0, aligning with both MIT Kerberos and Oracle Java.
The question here is : do we want to guarantee a sort of backward
compatibility with old (and unsecure) Kerberos implementation ?
One option would be to add some configuration element that enable the
deprecated Checksum type on demand. That would be totally insane, but
you never know what users have to deal with, especially in big companies
or administrations ;-)
For instance, in France, one airport was shutdown for half a day at the
end of last year because one system was running on a ... windows 3.1
computer !!!
(http://arstechnica.com/information-technology/2015/11/failed-windows-3-1-system-blamed-for-taking-out-paris-airport/).
Have fun ;-)
RE: Cheskum types
Posted by "Zheng, Kai" <ka...@intel.com>.
Yeah, we need to catch up with latest updates in this aspect and deprecate some of encryption and checksum types for security considerations. I think this can done prior to 1.0.0, aligning with both MIT Kerberos and Oracle Java.
Regards,
Kai
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Friday, January 08, 2016 8:10 PM
To: kerby@directory.apache.org
Subject: Cheskum types
Hi,
as I'm reviewing the ChecksumType enum, I think there is a bit of work to do here.
This enum is a copy of the krb5.hin file, which is a bit old. I was able to find most of the RFCs where the various checksums are defined, mostly RFC 3961, but some other RFC are also in use (RFC 3962, RFC 4757 updated by RFC 6649).
1 CRC32 /** Defined in RFC 3961, section 6.1.3 */
2 RSA_MD4 /** Defined in RFC 3961, section 6.1.2 */
3 RSA_MD4_DES /** Defined in RFC 3961, section 6.2.5 */
4 DES_CBC ???
4 DES_MAC /** Defined in RFC 3961, section 6.2.7 */
5 DES_MAC_K undefined
6 RSA_MD4_DES_K undefined
7 RSA_MD5 /** Defined in RFC 3961, section 6.1.1 */
8 RSA_MD5_DES /** Defined in RFC 3961, section 6.2.4 */
9 RSA_MD5_DES3 undefined
9 NIST_SHA ???
12 HMAC_SHA1_DES3 /** Defined in RFC 3961, section 6.3 */
12 HMAC_SHA1_DES3_KD same
15 HMAC_SHA1_96_AES128 /** Defined in RFC 3962, section 7 */
16 HMAC_SHA1_96_AES256 /** Defined in RFC 3962, section 7 */
17 CMAC_CAMELLIA128 /** Defined in RFC 6803, section 9 */
18 CMAC_CAMELLIA256 /** Defined in RFC 6803, section 9 */
//Microsoft netlogon cksumtype
-137 MD5_HMAC_ARCFOUR
//Microsoft md5 hmac cksumtype
-138 HMAC_MD5_ARCFOUR /** Defined in RFC 4757, section 4 */
-138 HMAC_MD5_ENC /** Defined in RFC 4757, section 4 */
-138 HMAC_MD5_RC4 /** Defined in RFC 4757, section 4 */
So here, we have two things : the MD5_HMAC_ARCFOUR checkusm type is for an old M$ Protocol (NT 4.0) and I'm not sure we should use it, and the RFC 6649 proposes to deprecate checksum type CRC32(1), RSA-MD4(2), RSA-MD4-DES(3), DES-MAC(4), DES-MAC-K(5), RSA-MD4-DES-K(6), RSA-MD5-DES(8).
What should we do regarding those recent recommandations ?