issue with preauth processing

[Sam Hartman]

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