KRB5KDC_ERR_ETYPE_NOSUPP and enctype negotiation in mixed windows environments

[Benjamin Kaduk]

On Wed, 1 Oct 2014, Ben H wrote:

> I honestly believe that this is more of a bug/design problem in AD.  When
> the 2008 DC forwards the client request to the 2003 DC, it doesn't
> negotiate a separate exchange to include enctypes or new keys - it simply
> sends the client packet onto the DC only changing the Network and DLL
> addresses.  In essence, the 2008 DC assumes that since the client was able
> to negotiate AES with it, that some other KDC should also be able to speak
> AES, without even asking.

That's roughly along the lines of what I was thinking.

> I'll admit I have worked almost exclusively with AD KDCs, though I have
> worked with MIT clients as well.  It seems to me from my reading of MIT
> documentation that an MIT client and KDC will generally use the same
> enctype for both the session keys and the TGT/TGS.  With AD it isn't
> uncommon to see a TGT in RC4 format, but AES session keys negotiated.

Well, a TGT is a ticket just like a service ticket, and has both a session
key and a ticket-encrypting key asssociated with it.  I assume you mean
that the session key and ticket-encrypting key are both RC4 when you say
that the TGT is "in RC4 format".

The KDC in general is charged with producing a session key that is usable
by both the client and the service; the client sends a list of supported
enctypes in its request, so the KDC has that knowledge at hand, but the
MIT KDC has to infer what enctypes are supported by the service's Kerberos
implementation from the current key list for that service.  The KDC will
pick the strongest key that it can, so in the normal case where the client
supports all the enctypes, the strongest enctype "supported by" the
service will be selected for both the session key and the
ticket-encrypting key.  If the client only supports a subset of enctypes,
then the session key will be of a different enctype than the
ticket-encrypting key, regardless of whether for a TGT or a service
ticket.  (To make things confusing, the MIT client has two different knobs
in krb5.conf for configuring the list of enctypes set for AS-REQs and
TGS-REQs, default_tkt_enctypes and default_tgs_enctypes, respectively,
whose names also add to the confusion.)

There is not a generic rule in the MIT KDC that gives special treatment
for the enctypes of TGTs, as it is assumed that the realm administrator
will not add an enctype to the krbtgt principal's key until all KDCs in
the realm support that enctype.

> This (re)negotiation capability described in my link:
>
> "This means that a Vista/Win7 client will initially attempt to use AES when
> talking to a Domain Controller during the Kerberos pre-authentication
> stage, Windows Server 2003 DC‘s on the other hand don‘t support using AES
> with Kerberos which is why they log the event and ask the client to try
> again with one of algorithms the DC supports (which usually ends up as RC4)"
>
> Seems to me a poor design decision on MS from the perspective of
> inter-operability as it lends itself to other design decisions which can
> use a "fall-back" instead of fool proof design.

The quoted text doesn't give me enough information to see what Microsoft
is doing on the Kerberos protocol level, so I can't really comment more
about it.

-Ben

> On Wed, Oct 1, 2014 at 12:45 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:
>
> > On Tue, 30 Sep 2014, Ben H wrote:
> >
> > > Just discovered an issue in an environment with mixed Win 2003 and 2008
> > R2
> > > servers that I'm surprised I haven't seen before, nor can find much of
> > > anybody reporting it previously.
> >
> > I would expect that people are trying to migrate off of Win 2003, since it
> > goes EoL on July 14, 2015 (less than a year away).
> >
> > > So the "issue" from a behavioral standpoint is that the Window's Kerberos
> > > implementation appears to be able to re-negotiate a lower/different
> > > encryption type when presented with ETYPE_NOSUPP, but the MIT
> > > implementation does not seem to do this.
> >
> > I believe that this MIT behavior is deliberate/intentional, in that do not
> > generally retry/fallback on KDC requests other than retransmits or
> > fallback to master to try and cope with password changes.  (I exclude
> > trying different transport protocols from considerations.)
> >
> > > This can be solved, to the best of my knowledge, by doing one of the
> > > following:
> > > 1) Move the PDC role to a system that supports AES encyption.
> > > 2) Disable AES encryption entirely - either on the 2008 KDCs, or on the
> > MIT
> > > clients
> >
> > I believe that either of these will eliminate the failure scenario you
> > have described.  But there may be other tradeoffs...
> >
> > > Neither of these solutions are necessarily attainable in a given
> > > environment.
> > >
> > > It would seem the least impactful change might be to remove AES from
> > > default_tkt_enctypes and/or permitted_enctypes.  However, this would mean
> > > that AES can never be used.
> > > Since some of the DCs (2008+) do support AES session keys, we are in
> > > essence weakening some of our potential exchanges.
> > >
> > > Is there something else that should be happening that isn't on my MIT
> > > clients regarding re-negotiating an enctype?  Is there a configuration
> > > settings that might help?
> >
> > My own opinion is that this is an error in the KDC/realm configuration, in
> > that the administrator has created (presumably unknowingly) a situation
> > where a KDC claims to support an encryption type but then doesn't actually
> > fully support it (when it is proxying requests to a PDC that doesn't
> > support it).  I'm not really convinced that there's a need to add more
> > complexity to the client to work around a misconfigured realm.  (I don't
> > think there are any existing knobs that would help other than the blanket
> > disabling of AES you already know about.)
> >
> > > Is this a behavioral difference that is well known and, if so, are there
> > > any plans to allow it to behave more like a Window's system in this
> > > scenario to allow a more robust behavior?
> >
> > I don't think there are plans along this line.  Note that your "more
> > robust behavior" may well be someone else's "insecure behavior".
> >
> > (Also, we have talked about deprecating the arcfour enctype entirely for
> > kerberos; I expect to see that happen within the next few years.)
> >
> > -Ben
> >
>