Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) RT-Send-CC: X-RT-Original-Encoding: iso-8859-1 Content-Length: 3834 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.