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
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.
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.