Discussion of krb5_get_init_creds_password() behavior wasRe:problem with the kinit_prompter in kfw 2.5

[Ken Hornstein]

>Ken's not going to like the following comments very much.  If you have
>an admin_server line, that pretty much means you have an MIT KDC or
>have things misconfigured.  If you don't have a MIT KDC we recommend
>replacing the admin_server line with a kpasswd_server line.
>
>MIT does not support any mode where the KDC saves state across
>requests or where generating multiple requests is a problem.  When we
>considered this issue for 1.3 we explicitly considered the writable
>KDC DB mode and came to the conclusion that we'de always described
>that code path as a use at your own risk code path.  This is one of
>the risks you get for using that code.

Actually ... my problem isn't with the double request against the KDC,
particularly (although, it just seems kinda stupid ... and your answer
basically boils down to "we're going to send double request to the master
for no good reason").  I don't have a problem with insuring that the
request goes to the master, but in probably 90% of the realms out there,
the first KDC in the list _is_ the master.  Sending a second request to
the master seems inelegant and lazy.  Sure, everyone wants to be
sure that if there's a password incorrect, the request goes to the
master ... no one has argued otherwise.  But if you've sent a request
to the master _already_, I guess I can't see the gain of sending the
same request to the master _again_.

My problem is that it presents a poor user interaction with hardware
preauth.  Specifically, you end up double-prompted for a hardware
preauth token if the user entered either the password or token wrong.
There's not a protocol issue with sending the request twice, nor with
the preauth back-ends ... it's just that the UI is poor (and people
have been complaining about it).

Now, we've talked about rewriting the client library to solve this
problem with hardware preauth.  It would be a job and a half.  But
somehow, I don't see this as particularly realistic ... I mean, look
how much disagreement there is about changing the type of one argument
to an internal function.  I can't see a major rearchitecturing of
the library happening in my lifetime.

--Ken