Option for multiple PA-ETYPE-INFO(2)-ENTRY (old behaviour)

[Dameon Wagner]

Afternoon all,

During a recent upgrade of our KDCs (to 1.14 we've backported to
debian jessie), we stumbled across a behavioural change related to
rfc6113, and have ended up downgrading to the 1.12 that's in jessie's
stable repository.

The change we're seeing is that in krb5-1.12 a
KDC_ERR_PREAUTH_REQUIRED message would include pa-data with a list of
supported PA-ETYPE-INFO2-ENTRY items, for each supported enctype.  In
krb5-1.14, only a single PA-ETYPE-INFO2-ENTRY.  This relates to commit
385cd2d07983a89892dad1606e1a41a78066c6ec (at [0]), and the following
bit of rfc6113:

"KDC implementations MAY choose to offer only one key in the PA-ETYPE-
INFO2 element.  Since the KDC already knows the client's list of
supported enctypes from the request, no interoperability problems are
created by choosing a single possible reply key.  This way, the KDC
implementation avoids the complexity of treating the reply key as a
set."

Before I explain why I think we're seeing issues, it might be simplest
if I first ask:  Is there a configuration option that we can set to
use the "old behaviour", and have multiple PA-ETYPE-INFO2-ENTRY items
returned?  I've hunted a bit through the commit logs and code, but C
isn't my mother tongue, so it's quite possible missed it if it's
there.

On to the issue we're seeing: it appears that Windows clients appear
to authenticate successfully first time round (AS_REQ,
KDC_ERR_PREAUTH_REQUIRED, AS_REQ, AS_REP), and happily go on to
successful TGS_REQs.

At some later point (see [*]) the client sends another AS_REQ to our
KDC, but this time the process fails with KDC_ERR_ETYPE_NOSUPP, and
indeed looking at packet dumps shows that it's sending a reduced set
of enctypes in the AS_REQ, compared to the original (and successful)
pair of AS_REQs.  Tracing through things a little I can see that the
list of enctypes includes only a standard set of RC4 types (that
Windows appears to always include), and AES256.

In cases where, as an unlikely but simple example, the realm's krbtgt
has only AES128, and the client's principal has AES256, this appears
to always fail on the subsequent AS_REQs when the initial
KDC_ERR_PREAUTH_REQUIRED pa-data structure only includes a single
PA-ETYPE-INFO2-ENTRY for AES256.  In that case the Windows client
appears to completely forget all other enctypes except the one
returned in the pa-data (_and_ all those crufty RC4 types, probably
for some legacy reason), rather than defaulting to a list of enctypes
it supports (or is configured to support).

Clearly, in this example, because the client is asking effectively for
AES256, and the krbtgt only has AES128, the KDC correctly responds
with KDC_ERR_ETYPE_NOSUPP.  My gut feel is that the Windows client
code is at fault for not AS_REQ'ing with it's full set of supported
enctypes in later attempts, but the chances of getting that fixed are
... shall we say very small?

We're in a bit of a viciously circular problem as we want to re-key
our krbtgt, but we've had to roll-back previous attempts after seeing
issues with delegated credentials -- an issue which is apparently
solved in 1.14 (one of my colleagues has tested this half to death).
But it seems that we can't upgrade to 1.14 without upsetting lots of
Windows clients -- which itself would be solved by re-keying, and
around we go again...

We might just have to bite the bullet with regards to the delegated
credential issue, but I thought it was worth asking the brain-trust
here for ideas first.

Cheers.

Dameon.

[0](https://github.com/krb5/krb5/commit/385cd2d07983a89892dad1606e1a41a78066c6ec)

[*] Just after TGS_REQ'ing it's AD DC for a domain file server.  The
    Windows client is a domain member, authenticating against our MIT
    KDC, using a one-way cross-realm trust, not sure if that's
    relevant, but thought it was worth mentioning just in case.

-- 
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
Dr. Dameon Wagner, Systems Development and Support
IT Services, University of Oxford
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><