Enable KDC TCP listener by default

Make the KDC default to listening on TCP.

ticket: 6731
target_version: 1.13
tags: pullup
Document KDC TCP listener change

Update documentation to reflect the change in the default KDC TCP
listener behavior, new in 1.13.

ticket: 6731
target_version: 1.13
tags: pullup
Fix ksu crash in cases where it obtains the TGT

In order to allow ksu to use any locally-present service key for
verifying creds, the previous change to ksu switched from using a
retrieved or obtained TGT to fetch creds for the local "host" service,
and then passing those creds to krb5_verify_init_creds(), to passing the
retrieved TGT directly to krb5_verify_init_creds().

It did not take care to retrieve the TGT from the temporary ccache if it
had obtained them, and in those cases it would attempt to verify NULL
creds.

Modify the krb5_get_tkt_via_passwd() function to call
krb5_get_init_creds_password(), to pass back the freshly-obtained creds,
to take a "krb5_get_init_creds_opt" pointer instead of a locally-defined
options structure, and rename it to ksu_get_tgt_via_passwd().

ticket: 8015 (new)
target_version: 1.13
tags: pullup
Restore providing password TGTs for the ksu target

The use of "stored" was originally for marking whether or not creds
had been found in the source cache and copied to the target. If it was
false, the obtain-a-TGT-using-a-password path would be triggered and
it would populate the target ccache directly.

When the intermediate cache was introduced (in commit dccc80a), the
variable started marking whether or not creds had been copied to the
intermediate cache, and this was then used to decide whether or not to
copy creds to the target cache.

The obtain-a-TGT-using-a-password path began storing its creds in the
temporary cache as well, but neglected to set the flag so that the
creds would be copied to the target cache later, so the target ccache
would never be created and populated with the newly-obtained TGT.

ticket: 8016 (new)
target_version: 1.13
tags: pullup
Work around replay cache creation race

If two processes try to initialize the same replay cache at the same
time, krb5_rc_io_creat can race between unlink and open, leading to a
KRB5_RC_IO_PERM error.  When this happens, make the losing process
retry so that it can continue.

This does not solve the replay cache creation race, nor is that the
only replay cache race issue.  It simply prevents the race from
causing a spurious failure.

ticket: 3498
target_version: 1.13
tags: pullup
Fix krb5 gss_acquire_cred_impersonate_name crash

If gss_acquire_cred_impersonate_name is called using an
impersonator_cred_handle acquired with GSS_C_ACCEPT, we could
dereference null fields of the cred handle and crash.  Fix this by
checking the impersonator_cred_handle usage and returning
GSS_S_NO_CRED if it isn't what we expect, just as we do in
init_sec_context.

Based on a patch from Solly Ross <sross@redhat.com>.

ticket: 8017 (new)
target_version: 1.13
tags: pullup
Return only new keys in randkey [CVE-2014-5351]

In kadmind's randkey operation, if a client specifies the keepold
flag, do not include the preserved old keys in the response.

CVE-2014-5351:

An authenticated remote attacker can retrieve the current keys for a
service principal when generating a new set of keys for that
principal.  The attacker needs to be authenticated as a user who has
the elevated privilege for randomizing the keys of other principals.

Normally, when a Kerberos administrator randomizes the keys of a
service principal, kadmind returns only the new keys.  This prevents
an administrator who lacks legitimate privileged access to a service
from forging tickets to authenticate to that service.  If the
"keepold" flag to the kadmin randkey RPC operation is true, kadmind
retains the old keys in the KDC database as intended, but also
unexpectedly returns the old keys to the client, which exposes the
service to ticket forgery attacks from the administrator.

A mitigating factor is that legitimate clients of the affected service
will start failing to authenticate to the service once they begin to
receive service tickets encrypted in the new keys.  The affected
service will be unable to decrypt the newly issued tickets, possibly
alerting the legitimate administrator of the affected service.

CVSSv2: AV:N/AC:H/Au:S/C:P/I:N/A:N/E:POC/RL:OF/RC:C

[tlyu@mit.edu: CVE description and CVSS score]

ticket: 8018 (new)
target_version: 1.13
tags: pullup