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 <>< <>< <>< <>< <>< <>< ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
