[2170] in Kerberos-V5-bugs
Using AFS String_to_key with K5 beta 6
daemon@ATHENA.MIT.EDU (Doug Engert)
Tue Aug 20 11:49:13 1996
Date: Tue, 20 Aug 1996 10:47:37 -0500
From: Doug Engert <DEEngert@anl.gov>
To: krb5-bugs@MIT.EDU
Cc: <mullan_s@apollo.hp.com>, <rsalz@osf.org>, <dave_stephenson@transarc.com>,
<authtf@es.net>
I would like to make a suggestion which would simplify the migration
for AFS sites to Kerberos 5.
I see that the K5b6 has a afsstring2key.c routine which is only called
from the string2key.c. In string2key.c the comments refer to "cheating"
by calling the afstring2key.c if the salt length is -1. The use of a
-1 for a salt length may have many other consequences, and
ramifications to the code in different places.
I would like to suggest an additional method of "cheating" be added, so if
the salt starts with the string "AFS:" that the rest of the string is
interpreted as the AFS salt, and the afsstring2key.c be called.
This method is transparent to the rest of the code which deals with
salts, such as preauthentication.
I am using a DCE security server as the KDC, and have successfully
copied keys from our AFS cell "anl.gov" to the DCE security registry
in our DCE cell, "dce.anl.gov". Unlike the K5 database, the DCE
security registry allows the salt to be stored in the entry, and can
be anything, including "AFS:anl.gov".
This presents a nice migration path from AFS to DCE, even when
the realm/cell names differ. The keys can be copied, and users do not
have to change their passwords during the conversion.
If the K5 database also contained the salt, rather then just a salt
type, it could also handle realm name changes as well. (You may want
to consider this for a future version of K5.)
I am then able with the attached code to use K5 kinit with this
entry. The preauthentication passes back the salt to be used, and the
string2key.c calls afsstring2key.c
I have also suggested that future versions of DCE also include this
change to the string2key.c and the inclusion of the afsstring2key.c
As for a straight K4 to K5/DCE conversion, I have also sucessfully
added a entry to the DCE security registry with a zero lenght
salt. i.e. the K4 type salt. The K5 kinit without any modifications
can use this entry.
But I uncovered a bug in DCE is this area which is being fixed. It
does not test correctly for a zero length salt, so the dce_login fails
to use it. So when this is fixed a conversion from a K4 to DCE should
be easy.
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444 <New Area Code 8/3/96>
PGP Key fingerprint = 20 2B 0C 78 43 8A 9C A6 29 F7 A3 6D 5E 30 A6 7F
*** ,string2key.c Tue Apr 9 17:47:24 1996
--- string2key.c Tue Aug 20 10:28:49 1996
***************
*** 78,83 ****
--- 78,104 ----
key = keyblock->contents;
if (salt) {
+ /* ANL Change */
+ /* we can store AFS keys in DCE, and set the salt such that
+ * it is preceeded by AFS:
+ * If so, pass the rest of the salt to the afs_string_to_key
+ * But it is cheating, and expecting the salt.data to be a
+ * null terminated string. This may not be the case from DCE.
+ */
+ if ((salt->length >= 4) && !memcmp(salt->data,"AFS:",4)) {
+ krb5_data afssalt;
+ krb5_error_code ret;
+ afssalt.length = salt->length - 4;
+ afssalt.data = (char*)malloc(afssalt.length+1);
+ if (!afssalt.data)
+ return(ENOMEM);
+ memcpy(afssalt.data,salt->data + 4,afssalt.length);
+ afssalt.data[afssalt.length] = '\0'; /* make it a string */
+ ret = mit_afs_string_to_key (eblock, keyblock, data, &afssalt);
+ free(afssalt.data);
+ return(ret);
+ } else
+ /* end of ANL change */
if (salt->length == -1) {
/* cheat and do AFS string2key instead */
return mit_afs_string_to_key (eblock, keyblock, data, salt);
