encryption algorithm used by kerberos

[Tim Alsop]

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:hartmans at mit.edu] 
Sent: 15 November 2003 01:09
To: Kent_Wu at trendmicro.com
Cc: kerberos at mit.edu
Subject: Re: encryption algorithm used by kerberos

>>>>> "Kent" ==   <Kent_Wu at trendmicro.com> 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           Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos