Ticket History #8199: Only include one key in etype-info

Only include one key in etype-info

As described in RFC 6113 section 2.1, the KDC can choose a single
long-term key at the beginning of the preauth conversation based on
the request enctype list. Implement this change for the PA-ETYPE-INFO
and PA-ETYPE-INFO2 padata included in preauth hint lists, by selecting
the client key before checking padata, making the client keyblock
available in the preauth rock, and unifying the etype-info handlers to
use a single helper function for edata and AS-REP padata.

https://github.com/krb5/krb5/commit/385cd2d07983a89892dad1606e1a41a78066c6ec
Author: Greg Hudson <ghudson@mit.edu>
Commit: 385cd2d07983a89892dad1606e1a41a78066c6ec
Branch: master
src/kdc/do_as_req.c | 88 ++++++++++------
src/kdc/kdc_preauth.c | 269 +++++++++----------------------------------------
src/kdc/kdc_util.h | 1 +
3 files changed, 104 insertions(+), 254 deletions(-)

This change can cause interoperability problems with clients using
JDK 1.6.0_24 due to a bug which is fixed in 1.7 and 1.6.0_25:

https://bugs.openjdk.java.net/browse/JDK-6932525

The bug is that, in its second pre-authenticated request, the client
narrows its etypes field to the enctypes present in the ETYPE-
INFO/ETYPE-INFO2 pa-data of the PREAUTH_REQUIRED error, unnecessarily
limiting the set of negotiable session etypes.

Here is an example of the problem cropping up:

http://mailman.mit.edu/pipermail/krbdev/2015-December/012499.html

In this example, the problem occurs because des-cbc-md5 is negotiated
for preauth but normally cannot be used as the session enctype (due
to an old hardcoded policy stemming from an ancient interop issue).
The problem could also occur without single-DES if the server
principal has a restricted set of enctypes.

I don't think we need to revert our KDC behavior; the Java client bug
can also manifest with certain AD server configurations. I'm just
noting it here to make it easier to find in the future.