Branch for the Master Key Migration project

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@20822 dc483132-0cff-0310-8789-dd5450dbe970
First commit.  This project is not completely finished (the list_mkeys,
purge_mkeys, sync_stash and update_princ_encryption still need to be
written) so the purpose of this commit is to allow early review of the
addition of support for > 1 master key and the "active" master keylist.
This commit does not include any changes required to sync this level of
the branch with the current level of the trunk.  That will follow this
commit.

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21721 dc483132-0cff-0310-8789-dd5450dbe970
Merged with current trunk, no new function added.  Everything builds

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21722 dc483132-0cff-0310-8789-dd5450dbe970
Added kdb5_util list_mkeys command, cleaned up some code formatting
(removed hard tabs), added logic to add default actkvno tl_data when
creating a new mkey princ.

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21739 dc483132-0cff-0310-8789-dd5450dbe970
Fixed some compiler warning issues

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21743 dc483132-0cff-0310-8789-dd5450dbe970
Fixed several bugs discovered during initial debugging of KDB
creation.

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21755 dc483132-0cff-0310-8789-dd5450dbe970
Fixed several more places where type mismatches could cause corruption
with the encoding/decoding of the new TL data types.

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21756 dc483132-0cff-0310-8789-dd5450dbe970
Fixed the kdb5_util list_mkeys command (wasn't printing mkey info)

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21757 dc483132-0cff-0310-8789-dd5450dbe970
More bug fixes.  There were several bugs in the existing new commands.
At this point the add_mkey, use_mkey and list_mkeys commands appear to
work generally.  I've noticed however that specifying a non-default
enctype when using add_mkey and stashing the result (add_mkey -e
aes128-cts-hmac-sha1-96 -s) causes problems when the new mkey is fetched
from the stash file.  I'll fix this in another commit.

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21765 dc483132-0cff-0310-8789-dd5450dbe970
Made a change to the code reading the mkey stash to use the enctype
stored in the stash instead of overriding that with what is set in the
gobal parameter.  This allows a stashed mkey's enctype to differ from
the current mkey stored in the K/M princ.  I also updated
krb5_def_fetch_mkey_list() to avoid a crash when trying to decrypt data
encrypted with a des-cbc-crc key with a aes-128 key.

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21767 dc483132-0cff-0310-8789-dd5450dbe970
Merge with current head of trunk:
svn merge -r21722:HEAD svn+ssh://wfiveash@svn.mit.edu/krb5/trunk

Everything compiles.

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21769 dc483132-0cff-0310-8789-dd5450dbe970
Modified krb5_db_fetch_mkey() to use the enctype in the stash file.
After making this modification 917 dejagnu tests pass (did not see any
failures on my Solaris test system).

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21771 dc483132-0cff-0310-8789-dd5450dbe970
Fixed problem that was causing the src/tests/mkeystash_compat to fail

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21772 dc483132-0cff-0310-8789-dd5450dbe970
Change the name of the krb5_dbe_act_mkey_list function to
krb5_dbe_act_key_list to indicate it is a generic function of use on any
princ.  I also modified the process_tgs_req function to use the
master_keylist and look up the proper mkey when decrypting the server
key.

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21777 dc483132-0cff-0310-8789-dd5450dbe970
Merge with head of trunk.  Pulled in Ken's fix for db2 hash bug on
filesystems whose record size is > 64K.  All make check tests pass on my
Solaris test system using ZFS with recordsize=128K.

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21791 dc483132-0cff-0310-8789-dd5450dbe970
Work to address some of Ken's review comments.  This doesn't address all
of his issues so there will be a follow up commit.

The type krb5_keylist_node shouldn't go into krb5.hin, as it's not part of
the library (or any other) public API.  Maybe k5-int.h as a catch-all, if
there's not a more appropriate internal header?

    Done.

Can we avoid moving krb5_free_key_data_contents, which deals with a data
structure used only in the KDC-related libraries, into libkrb5 and
k5-int.h?  (Exception: The libkrb5 asn.1 code does encode/decode the data
structure and thus may allocate it.  But I think we can assume the same C
runtime for kadm5srv/kdb and krb5 libs, so it's kind of okay.  And the
asn.1 setup should be "modularized" at some point, so the ldap support can
move out into the ldap kdb plugin.)  I think it can probably go into
libkdb?

    Done.

If possible, k5-int.h shouldn't include kdb.h, so updating kdb.h doesn't
cause recompilation of (for example) all of the crypto library code.

    Done.

After printing "master keys for principal", if enctype_to_string fails, we
haven't set retval to the error code but use it anyways.  Later, asprintf
isn't checked for failure.

    Done.

Some cases of indentation not matching MIT style, in particular,
continuation lines in function calls being indented four columns instead of
indented to make function arguments line up.

    Done.

krb5_dbe_lookup_mkvno, krb5_dbe_lookup_mkey_aux, krb5_dbe_lookup_actkvno
need to verify lengths before decoding data.

    Done.

kdb5_add_mkey should use the "zap" macro on key data instead of memset
before directly freeing it; some compilers (one reference I found mentions
the Microsoft C++ .NET compiler) may optimize away scribbles over storage
about to be freed, leaving the values to be retained in core dumps or
uninitialized heap allocations, and "zap" is intended to be where we dump
any necessary hacks to defeat that.  Similarly for any other places where
key data is stored (e.g., within tl_data).

    Done.

krb5_dbe_update_actkvno (and probably elsewhere in our existing code): Note
that failure in realloc (NULL return when size is nonzero) leaves the old
storage un-freed.  So "x=realloc(x,sz)" is a good way to leak memory if
reallocation fails, since you no longer have a handle on the orignial "x".

    Done.

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21797 dc483132-0cff-0310-8789-dd5450dbe970
Namespace-protect get_key_data_kvno

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21800 dc483132-0cff-0310-8789-dd5450dbe970
Restore krb5_free_key_data_contents() as it was in
src/lib/kadm5/misc_free.c and rename the version of that function in
kdb5.c to krb5_dbe_free_key_data_contents.  Eventually this needs to be
consolidated somewhere.

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21802 dc483132-0cff-0310-8789-dd5450dbe970
Bah, forgot to remove the -lkdb5 dependency in the kadm5clnt
Makefile.in.

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21803 dc483132-0cff-0310-8789-dd5450dbe970
Revert an #include of <kdb.h> in kfree.c which stuck around after the
code which needed it moved away.

git-svn-id: svn://anonsvn.mit.edu/krb5/branches/mkey_migrate@21804 dc483132-0cff-0310-8789-dd5450dbe970