[krbdev.mit.edu #2545] AFS string_to_key broken for passwords > 8 chars

[Greg Hudson via RT]

Some archaeology on the evolution of this and related bugs:

* 1.0-beta6: etype-info support is added, but is only returned in the 
preauth hint list (not AS replies) and is only used by the client 
preauth system after a preauth-required error (not to decrypt AS 
replies).

AFS string-to-key support is also added.  It is communicated with the 
afs3-salt padata type and a null-terminated salt.  The client reacts by 
setting a salt->length of -1.  mit_des_string_to_key_int recognizes this 
and calls mit_afs_string_to_key, which (unsafely) assumes that the salt 
is null-terminated.

AFS keys do not appear to work with etype-info (no type information is 
communicated), which means AFS keys probably don't work with preauth at 
this point.

* 1.1: the get_init_creds system is added.  The corresponding rewritten 
preauth system (preauth2.c) uses the same logic to handle the hint list 
and the AS reply, but appears to have no etype-info support (so it uses 
pw-salt/afs3-salt in both the hint list and the AS reply).

* 1.1.1: preauth2.c gains etype-info support, preferring it over pw-
salt/afs3-salt, in order to work around a 1.0 KDC bug in the generation 
of pw-salt in the preauth hint list.  This is the first time etype-info 
is used by the client when decrypting AS replies (but the KDC isn't 
sending etype-info in AS replies, so AFS keys still mostly work in 
practice).

* 1.2.6: a hack is added to truncate the salt at '@' for 
interoperability with Heimdal.

* 1.3: etype-info2 support is added to the client and KDC.  preauth2.c 
prefers etype-info2 over etype-info.  etype-info is suppressed if newer 
enctypes (which basically means AES) are present in the request.  etype-
info2 is returned in the AS reply as well as the hint list, but etype-
info is still never returned there.  etype-info2 tags AFS keys using 
s2kparams (it does not null-terminate the salt value).  
krb5int_des_string_to_key recognizes the s2kparams and calls 
mit_afs_string_to_key.  mit_afs_string_to_key is fixed to use salt-
>length.  Along this new code path, there is no '@' hack and no 
assumption of null-terminated salt values.  AFS keys probably work with 
preauth at this point (given a 1.3 KDC and client).

The old AFS trap door in mit_des_string_to_key_int still exists, still 
has the '@' hack, and is still used if the AS reply contains no etype-
info2.  It sets a length on the salt value passed to 
mit_afs_string_to_key, but still assumes a null-terminated salt value 
when doing so.

krb5_data's length element changes from int to unsigned int in this 
release, and a constant SALT_TYPE_AFS_LENGTH (equal to UINT_MAX) 
replaces the use of -1 in salt->length.

* 1.4.3: the KDC starts including etype-info in AS replies, if no newer 
enctype is requested, in order to better conform with RFC 4120 (#3207).  
Since etype-info doesn't tag AFS keys, 1.1.1 through 1.2.8 clients break 
with AFS keys.  This is reported in #3456 with a candidate patch to 
avoid sending etype-info for AFS keys, but the patch is not taken.  (It 
may still be a good idea, although the interop issue is almost certainly 
moot by now.)

Nothing has really changed since then.  I believe AFS keys work along 
all code paths assuming that afs3-salt padata values come with null 
termination (true of all MIT KDC versions), but that code path on the 
client is still unsafe.

I would speculate that this particular bug report pertains to a Heimdal 
KDC which was sending afs3-salt padata values with (1) no null 
terminator, (2) no '@' in the salt, and (3) a salt (realm) longer than 
eight bytes.  When the password is eight bytes or less, only the first 
eight bytes of the salt are used and everything works.  When the 
password is more than eight bytes, the full salt is used, with some 
trailing garbage due to the lack of a null terminator.