Skip Menu |

Subject: LDAP key data decoder ignores salt type if salt value is empty
In 1.11, we made the ASN.1 decoder table-driven. For the LDAP KrbKeySet
decoder, there was no easy way to make the decoder set the key_data_ver
and key_data_kvno fields of krb5_key_data, so we handled it in
asn1_decode_sequence_of_keys (a function in the LDAP KDB module) after
the fact. At the moment we set key_data_ver to 2 if key_data_length[1]
is non-zero, and to 1 otherwise. This is not correct; a salt type may
be present without a salt value. If a non-zero salt type is present
with no salt value, we will erroneously treat the key as having the
default salt.

Experimentally, we seem to currently store salt values along with all of
the non-default salt types, even though the salt value is ignored by
krb5_dbe_compute_salt for all salt types except SALTTYPE_SPECIAL. So at
least for entries we currently generate, the only visible impact of this
bug is just to ignore the v4 salt type (because it comes with an empty
salt). Entries generated by earlier versions might have other non-
default salt types ignored; I haven't done that analysis yet.
Fixed along with issue #7919 by commit