[7458] in Kerberos
Re: beta 6 -- enctype vs keytype
daemon@ATHENA.MIT.EDU (Sam Hartman)
Tue Jun 11 13:29:44 1996
To: michael shiplett <walrus@ans.net>
Cc: kerberos@MIT.EDU
From: Sam Hartman <hartmans@MIT.EDU>
Date: 11 Jun 1996 13:11:38 -0400
In-Reply-To: michael shiplett's message of 10 Jun 1996 17:10:25 -0400
OK, there are probably going to be several questions of this
form so I might as well try to explain things. Kerberos V5 has had
three different numbers to identify keys and encryption systems over
the years.
* ktype: a key type. All keys of the same crypto system should have
the same ktype. The only ktype used previous to Beta 5 is ktype 1, or
DES. (Beta 5 did things strangely, and is not really fully compatible
with either past or future versions of Kerberos. It's easier to
ignore it for this discussion.)
* etypes identified particular crypto systems like DES with
cypher-block chaining and a CRC checksum.
* enctypes combine an etype and a ktype. Basically, an enctype is an
etype, although the name was changed because it was no longer possible
for two enctypes to share a single ktype.
Basically, Kerberos developers realized a problem when they
tried to add support for multiple encryption systems like DES with CBC
and an MD5 checksum: in many places the over-the-wire protocol only
specified a ktype. Unfortunately, both des-cbc-crc and des-cbc-md5
use DES keys. Therefore, if a single ktype was proposed for all DES
keys, you wouldn't always know when to decrypt a message using
des-cbc-md5 and when to use des-cbc-crc. This complicated the code
significantly.
Clifford Neuman proposed a solution to this problem: require a
one-to-one correspondance between ktypes and etypes. This proposal
was discussed here and in other fora about a year ago, and the
Kerberos team agreed this was a reasonable solution. The term enctype
was coined to refer non-ambiguously to this new concep--a number
uniquely identifying a cryptosystem along with a key appropriate for
that cryptosystem.
If all you care about is the over the wire protocol, you can
stop now. However, the MIT implementation is somewhat more
complicated internally.
There are several DES-based cryptosystems inside Kerberos, and
it would be a significant waste of space to store keys for each of
these systems in the database and in keytabs when keys for all DES
systems are interchangable.
We decided to solve this with some magic in the datbase layer;
this magic was also moved into the keytab layer after it was found
that it needed to be there as well. Basically, a key for any of the
DES enctypes can be returned to satisfy a request for a key of any
other DES enctype.
To come full circle, there is now a proposal on the table
within the Kerberos development team to introduce a keytype to allow
the handling of DES keys to be generalized for keyed checksums and
tripple DES keys. If this proposal is adopted, keytypes will be a
property of crypto system entries in cryptoconf.c, not of keyblocks.
Also, they will be an internal convenience of the MIT implementation,
never sent over-the-wire or stored in databases.
I hope you aren't quite as confused as I was when I
tried to start debugging why the preliminary DES3 support sometimes
worked and sometimes didn't.
--Sam
