[krbdev.mit.edu #9037] Race condition in krb5_set_password()

<URL: http://kerborg-prod-app-1.mit.edu/rt/Ticket/Display.html?id=9037 >

> But there is still a fallback to UDP and there will be even retransmits via
TCP

Will there actually be retransmits via TCP?  I think our sendto_kdc code only
tries TCP once per server, relying on the kernel to do retransmits within the
TCP stack.

However, if there are multiple admin servers, it may have one TCP request
going to each admin servers in parallel, which could lead to a replay error.

> The client calling krb5_set_password() will return with an error, but not
with
KRB5KRB_AP_ERR_REPEAT but with KRB5_KPASSWD_AUTHERROR because [...] has
"e-data: 0003" which is retrieved by get_error_edata() as error code
returned to the caller.

What code is actually returned by krb5_set_password() in this scenario?
  KRB5_KPASSWD_AUTHERROR isn't a com_err code, and should only be communicated
to the caller via *result_code.

> I can think of multiple ways how to solve it:

I'll have to think on this.  Abandoning UDP for the kpasswd client is
attractively simple.  But I don't know if we can safely assume that there are
no deployments which admit only UDP kpasswd.  Also, we'd still ideally want to
prevent sendto_kdc from trying TCP requests to multiple servers in parallel
for kpasswd requests.  (There's an argument for applying this pratice to all
kinds of requests, but in rare cases a KDC will ignore a Kerberos request in
order to make the client use a different KDC.  So we'd want to resume trying
other KDCs if we see the TCP connection closed with no reply.  That starts to
be complicated.)

Once we do fall back to UDP, we're in a bad situation, because there's no way
to recover from a lost UDP reply (ignoring AP_ERR_REPEAT will just lead to a
timeout).  This specific scenario can be mitigated by giving up on TCP once we
fall back to UDP, but not every scenario.