Ticket History #7630: Make AS requests work with no client keys

Some preauth mechanisms, such as PKINIT and OTP, do not require a
client long-term key to work. Although our kadmin system does not
currently allow principal entries to exist without long-term keys, it
can be done with a custom KDB back end or an externally-maintained LDAP
KDB.

We need three changes to make this work properly:

* We should not offer encrypted timestamp or encrypted challenge as
preauth mechanisms if there are no client keys.

* If there are no client keys, we should not ship an empty etype-info or
etype-info2 list to the client. An empty list is prohibited by RFC 4120
for etype-info2 (there's a sequence length restriction in the ASN.1,
which we don't enforce in our ASN.1 code) and only serves to cause our
client code to error out prematurely.

* If the KDC cannot find a client long-term key while preparing the
reply, it should give preauth mechs a chance to replace the reply key
before erroring out.

Add kdcpreauth callback to check for client keys

Add a new have_client_keys callback to the kdcpreauth interface,
allowing modules to efficiently check whether the client DB entry has
any keys matching the request enctypes.

https://github.com/krb5/krb5/commit/e50482720a805ecd8c160e4a8f4a846e6327dca2
Author: Greg Hudson <ghudson@mit.edu>
Commit: e50482720a805ecd8c160e4a8f4a846e6327dca2
Branch: master
src/include/krb5/kdcpreauth_plugin.h | 8 ++++++++
src/kdc/kdc_preauth.c | 20 ++++++++++++++++++--
2 files changed, 26 insertions(+), 2 deletions(-)

Don't send empty etype info from KDC

RFC 4120 prohibits empty ETYPE-INFO2 sequences (though not ETYPE-INFO
sequences), and our client errors out if it sees an empty sequence of
either.

https://github.com/krb5/krb5/commit/ef700ee2cc1b33a06cd1e5c6c56ca7cfac8e67c5
Author: Greg Hudson <ghudson@mit.edu>
Commit: ef700ee2cc1b33a06cd1e5c6c56ca7cfac8e67c5
Branch: master
src/kdc/kdc_preauth.c | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)