Generally we want KDC status strings to be concise, informative and follow
some common rules:

- All letters in the status string should be capitalized;
- the words in the status phrase are separated by underscore;
- abbreviations should be avoided.  Some acceptable "standard" acronyms
  are AS_REQ, TGS_REP etc.
- since in almost all cases KDC status is set on error, no need
  to state this fact as part of the status string;
- KDC status string should be an imperative phrase.

For example, "DECRYPT_SERVER_KEY".

This commit is to modify some KDC status messages to follow this format.

Even though KDC status messages are not standardized, it is possible that some
administrators use them in the Kerberos log file processing. Hence, the vast
majority of them are left unchanged pending further investigation (mostly,
feedback from the administrators).

My rework of the do_tgs_req.c patch introduced a null deref if
decode_krb5_tgs_req() failed.

ticket: 7802

Under some error conditions, the KDC would log "<unknown server>" for
the service principal because service principal information is not yet
available to the logging functions.  Set the appropriate variables
earlier.

do_as_req.c: After unparsing the client, immediately unparse the
server before searching for the client principal in the KDB.

do_tgs_req.c: Save a pointer to the client-requested service
principal, to make sure it gets logged if an error happens before
search_sprinc() successfully completes.

[tlyu@mit.edu: commit message; fix TGS to catch more error cases]

ticket: 7802
target_version: 1.12.1
tags: pullup

Their previous location - kdc_util.c - seems to be overloaded with
various helper functions. No code changes.

If a KDC serves multiple realms, certain requests can cause
setup_server_realm() to dereference a null pointer, crashing the KDC.

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

A related but more minor vulnerability requires authentication to
exploit, and is only present if a third-party KDC database module can
dereference a null pointer under certain conditions.

ticket: 7755 (new)
target_version: 1.12
tags: pullup

In ure.c, though k is a short, the literal 1 is of type 'int', and
so the operation 'k + 1' is performed at the (32-bit) width of int,
and therefore the "%d" format string is correct.

In accept_sec_context.c, the 'length' field of krb5_data is an
unsigned type, so checking for a negative value has no effect.

In net-server.c, the helper routine rtm_type_name() is only used
in code that is disabled with #if 0 conditionals; make the
definition also disabled in the same way to avoid warnings of an
unused function.

In kdc_authdata.c, equality checks in double parentheses elicit
a warning from clang.  The double-parentheses idiom is normally used
to indicate that an assignment is being performed, but the value of
the assignment is also to be used as the value for the conditional.
Since assignment and equality checking differ only by a single
character, clang considers this worthy of a warning.  Since the extra
set of parentheses is redundant and against style, it is correct to
remove them.

In several places (sim_server.c, dump.c, kdb5_destroy.c,
ovsec_kadmd.c), there are declarations of extern variables relating
to getopt() functionality that are now unused in the code.  Remove
these unused variables.

Per project http://k5wiki.kerberos.org/wiki/Projects/Audit

The purpose of this project is to create an Audit infrastructure to monitor
security related events on the KDC.

The following events are targeted in the initial version:
- startup and shutdown of the KDC;
- AS_REQ and TGS_REQ exchanges.  This includes client address and port, KDC
  request and request ID, KDC reply, primary and derived ticket and their
  ticket IDs, second ticket ID, cross-realm referral, was ticket renewed and
  validated, local policy violation and protocol constraints, and KDC status
  message.

Ticket ID is introduced to allow to link tickets to their initial TGT at any
stage of the Kerberos exchange. For the purpose of this project it is a private
to KDC ticket ID: each successfully created ticket is hashed and recorded
into audit log. The administrators can correlate the primary and derived
ticket IDs after the fact.

Request ID is a randomly generated alpha-numeric string. Using this ID an
administrator can easily correlate multiple audit events related to a single
request. It should be informative both in cases when the request is sent to
multiple KDCs, or to the same KDC multiple times.

For the purpose of testing and demo of the Audit, the JSON based modules are
implemented: "test" and "simple" audit modules respectively.
The file plugins/audit/j_dict.h is a dictionary used in this implememtations.

The new Audit system is build-time enabled and run-time pluggable.

[kaduk@mit.edu: remove potential KDC crashes, minor reordering]

ticket: 7712
target_version: 1.12

There's no need to use an intermediate variable to initialize the
contents of enc_tkt_reply.transited.

Instead of setting each field to zero individually (and misspelling NULL),
use memset and set the one field which is being initialized to a nonzero
value explicitly.