Ticket History #8681: False-positive replays in {mk,rd}_{cred,safe,priv}

Important Note: This only occurs when "forwardable=true" is specified.

In this testcase, ten unique client principals on the same host
(CLIENT0@MIT.EDU, CLIENT1@MIT.EDU, CLIENT3@MIT.EDU, CLIENT4@MIT.EDU,
etc) want to authenticate to the same service. This is a concurrency
test. There are ten threads, all clients attempt to connect
simultaneously. However, the majority of them fail to authenticate
because their request is erroneously detected as a replay attack in
krb5_rd_cred().

There are two problems that cause this bug to arise. (1) When building
the krb5_donotreplay replay struct in krb5_rd_cred, the client name is
constructed from the unique string "_forw" and the IP address.
Unfortunately, since the clients are all on the same host, the client
name will be the same for all ten clients, even if the principal names
are all unique. (2) Since all ten clients attempt to connect
simultaneously, the timestamp will be relatively similar. When I
debugged into krb5_rd_cred, replay.ctime was the same for all ten
clients. replay.cusec = 0 for all ten clients as well, which effectively
says all ten clients connected at the same time.

With these two reasons combined, all ten clients would be seen as the
same client and the replay cache would detect subsequent requests as a
replay attack.

Therefore, I propose to change how the client name is constructed.
Rather than just "forw_" and the IP address, make it so the client name
is a combination of the unique string, ip address, and the port number.
The port number would be unique between different clients on the same host.

I believe this problem applies to the replay records created by
krb5_mk_cred, krb5_rd_cred, krb5_mk_safe, krb5_rd_safe, krb5_mk_priv,
and krb5_rd_priv.

Mixing in the client name would not entirely fix the problem. Multiple
agents of the same client could create messages at the same time. For
AP exchanges, we found a way to add a hash of the encrypted
authenticator to the replay record. That should also work for _cred
and _priv, though not necessarily _safe as there is no confounder to
make the messages unique.