Sam Hartman wrote: > * Cibersafe supports a 3DES incompatible with the rest of the world
This is not strictly true, especially considering the many PacketCable and CableHome implementations on the market and their use of the same 3DES cipher suite as the CyberSafe products. To clarify this I have provided a more complete list of 'modern' Kerberos implementations to avoid any miss-interpretation of Sam's reference to this : MIT - 3DES with HMAC/SHA1 digest - AES - RC4 with HMAC Heimdal - 3DES with HMAC/SHA1 digest - AES - RC4 with HMAC Microsoft - RC4 with HMAC CyberSafe (www.cybersafe.ltd.uk) - 3DES with MD5 digest - RC4 with HMAC (available very soon ...) - AES (available very soon ...) IPFonix (www.ipfonix.com) - 3DES with MD5 digest (The requirement for 3DES with MD5 digest is documented on page 62 of PacketCable security specification) Jungo (http://www.jungo.com/openrg/rgcablehome.html) - 3DES with MD5 digest (Uses similar security standards as PacketCable) Summary: With the large number of vendors involved in PacketCable/CableHome (there are too many to list here) it is clear that the 3DES cipher with MD5 digest (as supported by CyberSafe) is here to stay for a very long time. Today, with RC4 support many of the above Kerberos implementations can work well with with Microsoft AD, however the long term desire is for all implementations to use AES as a default/preference instead of RC4. Currently there is no standard for AES with GSS-API/SSPI - this is currently being progressed within IETF Kerberos WG. The DES algorithm is often used instead of RC4 when Microsoft AD is used in conjunction with a non-Microsoft Kerberos product because when a principal is extracted from AD using the Microsoft ktpass.exe tool this tool makes the assumption that a DES-CBC-MD5 key is required. So, today there is no easy way to extract a key from AD into a key table with an RC4 key type ... I am sure this will change in the future, to make use of algorithms stronger than DES easier in a mixed Microsoft / non-Microsoft Kerberos environment. When the standards are ready I am sure AES will become more common and the implementations of 3DES with different message digest algorithms will then become less of an interoperability issue than today. Many consider that DES3 with a SHA1/HMAC digest is in fact stronger than RC4 with HMAC, currently used as default by Microsoft - yet another reason for every implementation to use AES as the preference when this is possible in the future. Thanks, Tim. -----Original Message----- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: 15 November 2003 01:09 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: encryption algorithm used by kerberos >>>>> "Kent" == <[EMAIL PROTECTED]> writes: Kent> Hi, In the kerberos authentication process, it does Kent> encryption a lot to guarantee the security. Hoever from the Kent> materials I read it seems it's using DES encryption method Kent> behind it which is not considered safe anymore, so are we Kent> going to use a more advanced algorithm or we've done that Kent> already? All of the modern Kerberos implementations support things stronger than DES: * MIT supports 3DES, AES and RC4 * Heimdal supports 3DES, [AES] and RC4 * Microsoft supports RC4 * Cibersafe supports a 3DES incompatible with the rest of the world I'm not sure if the Heimdal AES support is in the 0.6 release or just on the mainline. Note that all the AES support is slightly incomplete particularlyl dealing with GSSAPI. Active efforts are trying to fix this. ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
