[2786] in Kerberos-V5-bugs

home help back first fref pref prev next nref lref last post

Re: krb5-libs/467: AFS string_to_key bounds problems...

daemon@ATHENA.MIT.EDU (Doug Engert)
Tue Sep 2 11:35:49 1997

Date: Tue, 2 Sep 1997 10:32:56 -0500
From: Doug Engert <DEEngert@anl.gov>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: deengert@anl.gov, "Theodore Y. Ts'o" <tytso@MIT.EDU>,
        Ezra Peisach <epeisach@MIT.EDU>, krb5-bugs@MIT.EDU,
        krb5-unassigned@rt-11.mit.edu, gnats-admin@rt-11.mit.edu,
        krb5-prs@rt-11.mit.edu
In-Reply-To: <199709010500.BAA14690@ginger.cmf.nrl.navy.mil>

Ken Hornstein writes:
 > >Here is another approach we have been using by proceeding the salt with
 > >AFS: 
 > 
 > The thing that bugs me about this patch (other than the line
 > wrapping, which makes it impossible to feed into patch :-) ) 

That was Netscape Mail sent from home which did me in. Sorry. I have
attached it again. 

 > is
 > that the database already _knows_ that the salt for this key uses
 > the AFS stringtokey algorithm ... and it's even communicated to
 > the client without any overloading!  (Well, okay, it's told via a
 > preauth hint ... but that's not even that bad).
 > I just kinda wish
 > there was a "salt algorithm" argument to krb5_stringtokey() , or
 > even a new DES-AFS encryption type which had all of the regular
 > DES function pointers but the right stringtokey algorithm.
 > 
 > I just hate overloading the salt via in-band data, I guess.

Note that the mode I sent was designed to work with the DCE security
server which does not know about AFS string2key, and does not have a
AFS preauth hint. But it does know how to store and sent the salt, and the
modified string2key code on the client in the MIT kinit can figure
out that it should use the AFS string2key.

The main point of sending the mode was that it avoids the null
terminated string problem by making sure there is a null on the end of
the string before calling the AFS string2key routine. This same
trick could be used in other places. 

 > 
 > --Ken

*** ,string2key.c       Tue Apr  9 17:47:24 1996
--- string2key.c        Tue Apr 29 17:26:35 1997
***************
*** 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);

-- 
 
 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444

home help back first fref pref prev next nref lref last post