issue with preauth processing
hartmans at MIT.EDU
Thu Oct 29 10:40:19 EDT 2009
>>>>> "ghudson" == ghudson <ghudson at MIT.EDU> writes:
>> Basically, the question is whether we take that gic option call
>> as an optimization or security constraint. Most people who
>> have used it in the past have been looking for an optimization.
ghudson> When I first read this, I took it as reasonable, but on
ghudson> reconsideration I'm not sure.
ghudson> My understanding is that prior to 1.7, we never continued
ghudson> after PREAUTH_FAILED, so anyone calling
ghudson> krb5_get_init_creds_opt_set_preauth_list was getting both
ghudson> an optimization and a restriction. So, even if people
ghudson> were "looking for" an optimization, that's not what we
ghudson> were getting. I would say that 1.7 introduced an
ghudson> incompatible change to that API. If that's correct, then
ghudson> the most correct thing to do is (1) fix that in 1.7.1,
ghudson> and (2) add a new API for optimistic preauth.
Well, it's a bit more complicated than that. 1.6.3 will retry if it
gets a PREAUTH_REQUIRED error. I think with the preauth methods
shipped with 1.6.3 and most KDCs I'm familiar with, that tends not to
happen. So, I think your description of what happened is more or less correct.
I'm not sure I actually agree with you that the API change is
incompatible. It depends on what the callers of that API thought the
interface was. Certainly if we had API documentation and the API was
documented as optimistic, then it would not be an incompatible change;
if it was documented as a restriction then it would be. The 1.7
change breaks some code and makes some code work better.
However I agree with your fix.
More information about the krbdev