Subject: AS-REQ session key negotiation can fail with restricted etype list
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
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
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.
Download (untitled) 2.5k
This problem typically occurs when both of the following are true:
* A client makes an AS-REQ with an overly restrictive (for the session
key) set of etypes.
* The krbtgt/REALM principal has a small set of keys (perhaps just one
key), and no session_enctypes string attribute to override it.
Given that session_enctypes can be used to work around the problem, I am
now leaning towards documentation rather than a code change. The
proposed workaround assumes that the krbtgt service implicitly supports
all enctypes permitted by this KDC, rather than the set of enctypes
present in the key data (although the enctypes present in the key data
take priority). That assumption could make some problems more difficult
to diagnose in realms with mixed KDC versions. For example, if a realm
has a mix of 1.15 and 1.14 KDCs, and a client makes an AS-REQ with only
aes-sha2 enctypes in the etypes field, the 1.15 KDC might issue a ticket
that works with the 1.15 KDCs and not with the 1.14 KDCs. That would be
a lot more confusing than an ETYPE_NOSUPP error.
At a minimum, if we do add a workaround to the KDC, it should strictly
respect any session_enctypes attribute on the krbtgt/REALM entry.
Download (untitled) 1.1k