[1025] in Kerberos_V5_Development
Status of multiple encryption types.
daemon@ATHENA.MIT.EDU (Sam Hartman)
Sat Mar 16 00:15:52 1996
To: krbdev@MIT.EDU
From: hartmans@MIT.EDU (Sam Hartman)
Date: 16 Mar 1996 00:14:17 -0500
I had a discussion with Richard and we now both understand
what the code is currently doing well enough to predict all past
behavior and for several tests I tried to work as I expected them to
do so. Ironically, the major problems are related to the DES keys,
and not multiple cryptosystem support; I.E. it works better if you
are using DES3 and DES-crc than if you use DES-MD5 and DES-CRC.
Certain aspects of this behavior *must* be fixed before the Cygnus
ship date even if single-encryption type support is going to work
correctly. I will provide a summary at the end.
First, here is how things work now:
* The database code (kdb5_dbe_search_enctype) will treat all requests for DES keys (DES-CBC-CRC,
DES-CBC-MD5, DES-CBC-MD4, DES-RAW) as requests for DES-CBC-CRC. In
addition, any of these enctypes stored in the database are treated as
DES-CBC-CRC. OK, fine, so everything should work with the kdc, at
least, right?
Unfortunately, the code fragment returns a pointer into a
db_entry structure, so it cannot change the the keytype in the
key_type array to the same type key as the user requested. This
means that when the ticket is contstructed and returned, the ticket
I.E. no matter what you request, you will get whatever is stored in
the database.
This problem could be fixed by modifying the
db_entryto have the keytype that the user actually requested. This
would work, and it might be the most reasonable fix for this code with
minimal design impact. However, the design is broken and fixing it
might be reasonable.
* Not everything that should use kdb5_dbe_find_enctype actually
does. As I touched code, I converted it to this this interface, but I
suspect both kadmind and kdb5_edit have vestiges of the broken code.
In general, whenever code does a for loop on the keydata array of a
database entry, something is wrong. The code that does not use
kdb5_dbe_search_enctype may behave unpredictably or just randomly
fail.
* The keytabcode doesn't deal with the situation where one DES
key is requested, but that particular cryptosystem is not the one
listed in the keytab. In general, this isn't really a problem, except
when a client requests a particular enctype. For example, if I have a
v5srvtab with a DES_CBC_MD5 host key and I use telnet to connect to
the host, the telnet client will specifically request a DES_CBC_CRC
key to make sure it gets a DES key for encryption. In this case,
assuming the database code above is fixed, the keytab code needs to be
able to know that it can use the DES_CBC_MD5 key instead of the
DES_CBC_CRC key. (That, or the srvtab extraction should be fixed. I
suspect fixing the keytab code will be more reasonable.)
* The kadmind and kadmind.v4 code don't pay attension to the
kdc.conf file. So, they tend to to convert keys from DES-CBC-CRC to
DES-CBC-MD5 with the default config files. This combined with the
first problem makes the srvtabs get out of sync with the database.This
caused Richard's primary problems.
* Finally, I was confused about the assumption that
multiple enctypes were only handled if the database was DES_CBC_CRC.
None of my code actually cares much about this assumption, so it
should work fine even once the database correctly treats all DES keys
the same.Richard understood things the same way Ted did--that all
single DES keys should be treated the same by the database routines.
The code appears to try to do this, and the using code appears to
assume that the kdb5_dbe_search_enctype code treats DES keys the
same. I.E. The only design bug I know of so far is the database
routine returning a pointer into the db_entry and not changing the
keytype to match the key the user requested.
Changes in the next two weeks
It is important that the configuration files not refer to
anything besides DES_CBC_CRC. If you use anything else, you will have
problems with loading v4 databases. You may wish to make sure the
user cannot overide this setting.Basically, if you only use one type
of key, and never allow overiding of this, it should work. (I suspect
it will work if you use one DES key and one DES3 key, but I suspect
you don't want to try this out on your customers.) You should also
remove everything from the default AS_ENCTYPES in the context;
currently, there is no configuration file option for the this. A
configuration file option for default-as-enctypes should be created
eventually, as it will be important for testing multiple enctype
support.
I will try and send out a test plan later this weekend.
--Sam
