[krbdev.mit.edu #8519] AS-REQ session key negotiation can fail with restricted etype list

[Greg Hudson via RT]

An AS-REQ contains (in the KDC-REQ-BODY) an etype field containing "the 
desired encryption algorithm to be used in the response" (RFC 4120 
section 5.4.1).  The KDC must choose three keys for the response:

1. The reply key, which must be a key the client possesses or can 
compute.
2. The ticket session key, which must be of an enctype supported by the 
client and the server.
3. The ticket encryption key, which must be a key the server possesses.

The KDC-REQ-BODY etype list is used for the first and second keys, while 
the server's supported enctypes (either from its set of keys or a string 
attribute) is used for the second and third keys.

If a client possesses a limited set of possible reply keys, the 
implementor may restrict the etype field to the set of enctypes 
corresponding to those keys.  Heimdal does this when getting initial 
credentials with a keytab.  MIT krb5 briefly did this for kinit -k on the 
master branch between 1.10 and 1.11, but now sends all supported enctypes 
with the keytab key enctypes moved to the front (see issues 2131 and 
7190).  Based on http://mailman.mit.edu/pipermail/kerberos/2016-
November/021521.html it appears that Windows clients also do this: at 
login time they compute a key set from the password and ETYPE-INFO-2 
information, and then when refreshing tickets they send an etype list 
containing only the enctypes of those keys.

If a client does this, session key negotiation may fail if the server's 
supported enctypes (as determined by the KDC) do not intersect with the 
client's transmitted etype list.  The fault here likely belongs to the 
krb5 protocol or to the client, but with many Windows clients in the 
field exhibiting this behavior, our KDC should try to work around the 
issue.

The Windows interop case is exacerbated by the change in the MIT krb5 
1.14 KDC to send only one etype-info entry in AS-REPs (ticket 8199).  
With only one etype-info entry sent, the client computes only one reply 
key, and sends an even more restricted etype list for ticket refreshes 
than it did when talking to previous versions of the MIT krb5 KDC.

We briefly had a workaround in the KDC (from ticket 7190) which fell back 
to assuming that local TGT principals have support for all permitted 
enctypes.  The code for that workaround could be improved (it should not 
use the realm-global variable tgs_server), but the general idea should 
address most cases where this issue arises.  This workaround will not 
address AS-REQs where the server principal is different from the local 
krbtgt principal, but those cases should be rare.