Don't require all enctypes in a keytab to be valid #952
Conversation
|
(I think this was overlooked because an intermediate design had the enctypes still present in the list, but with no operator functions. Hard to know, though.) |
|
We only needed krb5_c_enctype_compare() for single-DES enctypes, where we wanted to share key entries between des-cbc-crc, des-cbc-md4, and des-cbc-md5. Today even when we introduce a new enctype with the same encryption algorithm as an old one (like the aes-sha2 enctypes) we tweak the string-to-key so that we don't share keys. So this fix can just simplify the code to do an equality test on the enctype, and remove the coercion. As the PR currently stands, I think it could leave kerror as non-zero if there is a DES key in the final entry of the keytab. |
frozencemetery
force-pushed
the
kt-enctypes
branch
from
59f8bc2
to
8d9679a
Compare
|
Ah, good catch. Updated. |
|
I was suggesting to use the |
frozencemetery
force-pushed
the
kt-enctypes
branch
from
8d9679a
to
6dd19b0
Compare
|
Ah, thanks, got confused by the mention of |
frozencemetery
force-pushed
the
kt-enctypes
branch
3 times, most recently
from
1886113
to
1b0793d
Compare
krb5_ktfile_get_entry() used krb5_c_enctype_compare() to compare enctypes, in order to share keys between single-DES enctypes. As key-sharing between enctypes is no longer done and single-DES support has been removed, use a simple equality test to match the enctype. This fixes a bug where krb5_kt_get_entry() would error out if the keytab contained any entries with invalid enctypes (include single-DES entries, after commit fb2dada) even if a matching entry is found. [ghudson@mit.edu: rewrote commit message] ticket: 8808
When acquiring credentials using a keytab, krb5 examines each entry in
the keytab to check for a better match. Relax the check on enctypes so
that the presence of removed enctypes (like DES) in the keytab doesn't
cause failure in kinit.