Single-DES in krbtgt/REALM key

[Russ Allbery]

Greg Hudson <ghudson at MIT.EDU> writes:
> On 08/21/2013 04:35 PM, Russ Allbery wrote:

>> That doesn't mean that they require DES; if the KDC no longer supports
>> issuing DES service keys for the principal they're trying to get a
>> service ticket for, they happily (and transparently) fall back to RC4.

> Do you mean that the Java application makes multiple AS requests with
> different enctype preference lists until one succeeds, or it makes one
> AS request with a preference list in backwards order like {des rc4
> maybe-other-stuff...}?

It looks like they make multiple AS requests with different enctype
preference lists.  For example, here's output from (Heimdal) KDC logs for
one of our current Java applications:

AS-REQ service/account-app-acct-webapps4 at stanford.edu from IPv4:171.67.215.56 for krbtgt/stanford.edu at stanford.edu
Client sent patypes: encrypted-timestamp
Looking for PKINIT pa-data -- service/account-app-acct-webapps4 at stanford.edu
Looking for ENC-TS pa-data -- service/account-app-acct-webapps4 at stanford.edu
ENC-TS Pre-authentication succeeded -- service/account-app-acct-webapps4 at stanford.edu using arcfour-hmac-md5
AS-REQ authtime: 2013-08-20T23:48:32 starttime: unset endtime: 2013-08-22T00:48:32 renew till: unset
Client supported enctypes: arcfour-hmac-md5, using arcfour-hmac-md5/aes256-cts-hmac-sha1-96

The client has long-term 3DES and AES keys as well.  When it had DES keys,
you'd see the same, except with des-cbc-crc instead of arcfour-hmac-md5.

It seems like remarkably broken behavior to me.

(Oddly, however I do *not* see an earlier failed request with only DES in
the enctype list.  I'm not sure why not.  Maybe it figures that out in the
initial non-preauth request?  Heimdal doesn't log enctype preferences for
that request.)

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>