KRB5KDC_ERR_ETYPE_NOSUPP and enctype negotiation in mixed windows environments

Benjamin Kaduk kaduk at MIT.EDU
Wed Oct 1 13:45:07 EDT 2014


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


More information about the Kerberos mailing list