Encrypted padata was introduced to the KDC by ticket 6313 with only
one use, return_svr_referral_data(). This function performed its own
allocation of the list, and accordingly verified with an assert()
that no code had previously populated the encrypted padata field.
Ticket 6563 added another use of encrypted padata,
kdc_make_s4u2self_rep(), without adjusting the original use to
accomodate existing encrypted padata. At this point an assertion
failure could only arise when returning a referral for an S4U2Self
request, because return_svr_referral_data() was only called on the
TGS path when issuing a referral.
Ticket 6595 and 6656 add a third use of encrypted padata, FAST
negotiation. An assertion remains in the new function
return_enc_padata() that no prior code has set encrypted padata, even
though the code (after the second ticket) uses add_pa_data_element()
instead of allocating a new list. Since return_enc_padata() is now
called unconditionally on the TGS path, the KDC will always abort if
kdc_make_s4u2self_rep() adds encrypted padata. This happens if the
TGT session key uses an older encrypted type (DES, DES3, or RC4).
krb5-bugs mailing list
[hidden email] https://mailman.mit.edu/mailman/listinfo/krb5-bugs