[krbdev.mit.edu #8767] Remove incorrect KDC assertion

Greg Hudson via RT rt-comment at KRBDEV-PROD-APP-1.mit.edu
Thu Dec 20 16:37:02 EST 2018


Bug history:

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).


More information about the krb5-bugs mailing list