[krbdev.mit.edu #7033] krb5 1.10 KRB5_PADATA_ENC_TIMESTAMP isn't working

[Greg Hudson via RT]

Issue #7013 may be of interest.

The looping itself is fixed by #6430, which will be pulled up to 1.10.  
But that would just change the reported error in your scenario to 
"Preauth failed."  The real question is why, in your scenario, the 
client doesn't determine an as-key enctype when processing the KDC 
preauth-required error.

If this is a scenario which used to work, it's likely because the client 
used to default to the first requested enctype when doing encrypted 
timestamp.  But if the KDC isn't sending an etype-info2 with that 
enctype, it probably doesn't have a key to match against it, so that's 
kind of a fruitless default (and one we've never had for encrypted 
challenge).  I'd be very interested in knowing if there's a scenario 
where the default does actually cause authentication to succeed, and 
what kind of KDC is on the other end.