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

[Greg Hudson]

On 11/18/2016 12:15 PM, Dameon Wagner wrote:
> 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?

No; we didn't expect the change to cause problems, and making it
configurable would have mostly defeated the purpose of making the change.

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

I agree that the Windows client is at fault.  The AS-REQ supported
enctype list is used to negotiate both the reply key and the ticket
session key.  If the client has a notion of what the reply key enctype
should be, it can put that enctype first, but it should not omit other
supported enctypes from the list.  We discovered this ourselves when
changing the behavior of kinit -k in MIT krb5 (see
http://krbdev.mit.edu/rt/Ticket/Display.html?id=2131 ).

Getting this fixed on the Microsoft end might be possible, but it's
certainly not likely to be the path of least resistance for you at this
time.  Unfortunately, neither backporting the 1.14 tgt rekeying fixes
nor forward-porting the 1.13 pa-etype-info2 behavior is likely to be
easy, so I can't offer a solution better than the ones you've already
determined.