Avoiding "KDC has no support for encryption type while getting initial credentials" by pinning selected KDC

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Avoiding "KDC has no support for encryption type while getting initial credentials" by pinning selected KDC

Osipov, Michael
Hi folks,

we are experiencing an issue where we don't know this is a bug or missing
feature in MIT Kerberos. I tend to a bug.

We have a headless service which relies on a client keytab to perform some
HTTP calls from within a C application with libcurl. Once in a while these
calls fail due to: "KDC has no support for encryption type while getting
initial credentials".

The keytab contains three keys for one principal: RC4, AES128, AES256.
Our home realm is backed up by 80 to 100 KDCs of various Windows Server
versions, not all support AES. KDC lookups rely on DNS only and we do
not intend to hardcode them in krb5.conf.

While analyzing this issue we noticed that for each and every KDC call
MIT Kerberos uses another KDC instead of pinning the first one which has
responded to the library. In this specific case, MIT Kerberos advertises
AES256, AES128, etc. in AS-REQ and the KDC responds with PREAUTH_REQUIRED,
PA-ENCTYPE-INFO2: AES256. The next AS-REQ goes again to another KDC which
unfortunately does *not* support AES256, hence responding with ERR_ETYPE_NOSUPP.

I would expect MIT Kerberos to pin the first working KDC because some
Information has been negotiated already but send to a completely different
KDC. This is annoying because I would expect the communication between client
and server is predictable.

I know this cannot be configured currently but is this possible to implement
without big hassle?

The issue has been verified with versions 1.13.1 and 1.14.3 on various
platforms. Wireshark dumps can be send privately.

Best regards,

Michael Osipov


________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding "KDC has no support for encryption type while getting initial credentials" by pinning selected KDC

Greg Hudson
On 08/17/2016 08:51 AM, Osipov, Michael wrote:
> The keytab contains three keys for one principal: RC4, AES128, AES256.
> Our home realm is backed up by 80 to 100 KDCs of various Windows Server
> versions, not all support AES. KDC lookups rely on DNS only and we do
> not intend to hardcode them in krb5.conf.

I do not know a lot about administering Active Directory, but I thought
the usual practice here was to configure the newer AD servers to behave
as if they were of the least common denominator version.

> I would expect MIT Kerberos to pin the first working KDC because some
> Information has been negotiated already but send to a completely different
> KDC. This is annoying because I would expect the communication between client
> and server is predictable.

The Kerberos authentication protocol is intended to be stateless; if
different requests during an AS exchange go to different KDCs, that is
supposed to work.  We have talked about preferring the previously chosen
KDC during an AS exchange (mostly for the sake of marginal preauth
mechanism implementations), but I think the code changes necessary to
implement that properly would be extensive.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: Avoiding "KDC has no support for encryption type while getting initial credentials" by pinning selected KDC

Wilper, Ross
If it is Active Directory that you are talking about here, I would be focusing on upgrading the DCs that are still running unsupported operating systems. There are no currently supported versions of Windows that cannot support AES128 and AES256.

You could turn off the AES enctypes in all DCs using group policy and work around this, but that brings its own set of security risks, though none as scary as running Windows 2000/2003.

-Ross

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Greg Hudson
Sent: Wednesday, August 17, 2016 8:20 AM
To: Osipov, Michael; [hidden email]
Subject: Re: Avoiding "KDC has no support for encryption type while getting initial credentials" by pinning selected KDC

On 08/17/2016 08:51 AM, Osipov, Michael wrote:
> The keytab contains three keys for one principal: RC4, AES128, AES256.
> Our home realm is backed up by 80 to 100 KDCs of various Windows
> Server versions, not all support AES. KDC lookups rely on DNS only and
> we do not intend to hardcode them in krb5.conf.

I do not know a lot about administering Active Directory, but I thought the usual practice here was to configure the newer AD servers to behave as if they were of the least common denominator version.

> I would expect MIT Kerberos to pin the first working KDC because some
> Information has been negotiated already but send to a completely
> different KDC. This is annoying because I would expect the
> communication between client and server is predictable.

The Kerberos authentication protocol is intended to be stateless; if different requests during an AS exchange go to different KDCs, that is supposed to work.  We have talked about preferring the previously chosen KDC during an AS exchange (mostly for the sake of marginal preauth mechanism implementations), but I think the code changes necessary to implement that properly would be extensive.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Avoiding "KDC has no support for encryption type while getting initial credentials" by pinning selected KDC

Todd Grayson
In reply to this post by Greg Hudson
Michael,

This does not fix your issue, its more for clarification of discussion.

The "domain functional level" should be dictating the behavior of the
aggregate AD environment. You can control the preference for encryption
type in the krb5.conf's [libdefaults] enctype
settings (default_tgs_enctypes,  permitted_enctypes, default_tkt_enctypes).

Consider the following might offer some possible workarounds?

As I understand it; kerberos will use the provided encryption types based
on order presented from the config.... so if you have a subset of services
and users that need everything negotiated with rc4-hmac as the preferred
encryption type, you would make sure that was listed first in the client
config.

The important thing to remember is use the naming presented in the enctypes
reference table from the krb5.conf / kdc.conf MIT docs (or enctype groups)
or the settings are ignored.

http://web.mit.edu/kerberos/krb5-1.13/doc/admin/conf_files/krb5_conf.html#libdefaults
http://web.mit.edu/kerberos/krb5-1.13/doc/admin/conf_files/kdc_conf.html#encryption-types

*If Java is in the mix you have to limit enctypes to whats supported under
the JGSS as well.

http://docs.oracle.com/javase/8/docs/technotes/guides/security/jgss/jgss-api-mechanism.html


On Wed, Aug 17, 2016 at 9:19 AM, Greg Hudson <[hidden email]> wrote:

> On 08/17/2016 08:51 AM, Osipov, Michael wrote:
> > The keytab contains three keys for one principal: RC4, AES128, AES256.
> > Our home realm is backed up by 80 to 100 KDCs of various Windows Server
> > versions, not all support AES. KDC lookups rely on DNS only and we do
> > not intend to hardcode them in krb5.conf.
>
> I do not know a lot about administering Active Directory, but I thought
> the usual practice here was to configure the newer AD servers to behave
> as if they were of the least common denominator version.
>
> > I would expect MIT Kerberos to pin the first working KDC because some
> > Information has been negotiated already but send to a completely
> different
> > KDC. This is annoying because I would expect the communication between
> client
> > and server is predictable.
>
> The Kerberos authentication protocol is intended to be stateless; if
> different requests during an AS exchange go to different KDCs, that is
> supposed to work.  We have talked about preferring the previously chosen
> KDC during an AS exchange (mostly for the sake of marginal preauth
> mechanism implementations), but I think the code changes necessary to
> implement that properly would be extensive.
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>



--
Todd Grayson
Business Operations Manager
Customer Operations Engineering
Security SME
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: Avoiding "KDC has no support for encryption type while getting initial credentials" by pinning selected KDC

Osipov, Michael
In reply to this post by Greg Hudson
> On 08/17/2016 08:51 AM, Osipov, Michael wrote:
> > The keytab contains three keys for one principal: RC4, AES128, AES256.
> > Our home realm is backed up by 80 to 100 KDCs of various Windows Server
> > versions, not all support AES. KDC lookups rely on DNS only and we do
> > not intend to hardcode them in krb5.conf.
>
> I do not know a lot about administering Active Directory, but I thought
> the usual practice here was to configure the newer AD servers to behave
> as if they were of the least common denominator version.

This would actually lower the security of the entire system. Windows to
Windows avoids hopping by locating the closest working DC and uses it
as long as possible. Such a case should never happen.
 

> > I would expect MIT Kerberos to pin the first working KDC because some
> > Information has been negotiated already but send to a completely
> different
> > KDC. This is annoying because I would expect the communication between
> client
> > and server is predictable.
>
> The Kerberos authentication protocol is intended to be stateless; if
> different requests during an AS exchange go to different KDCs, that is
> supposed to work.  We have talked about preferring the previously chosen
> KDC during an AS exchange (mostly for the sake of marginal preauth
> mechanism implementations), but I think the code changes necessary to
> implement that properly would be extensive.

Pity :-( What is your general advice. The network is out of my control.

Michael

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: Avoiding "KDC has no support for encryption type while getting initial credentials" by pinning selected KDC

Osipov, Michael
In reply to this post by Todd Grayson
Hi Todd,

> Michael,
>
> This does not fix your issue, its more for clarification of discussion.
>
> The "domain functional level" should be dictating the behavior of the
> aggregate AD environment. You can control the preference for encryption
> type in the krb5.conf's [libdefaults] enctype settings
> (default_tgs_enctypes,  permitted_enctypes, default_tkt_enctypes).

The forest functional level is at 2 (Windows Server 2003) while
domain is at 4 (Windows Server 2008 R2).

I'd like to avoid fiddling with the enctypes on all machines because this
is a rare case.



________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

RE: Avoiding "KDC has no support for encryption type while getting initial credentials" by pinning selected KDC

Osipov, Michael
In reply to this post by Wilper, Ross
> If it is Active Directory that you are talking about here, I would be
> focusing on upgrading the DCs that are still running unsupported operating
> systems. There are no currently supported versions of Windows that cannot
> support AES128 and AES256.
>
> You could turn off the AES enctypes in all DCs using group policy and work
> around this, but that brings its own set of security risks, though none as
> scary as running Windows 2000/2003.

Well, the forest has grown over the years, my company has 350 000 employees
with the largest AD installation on the planet. All is mixed and I have no
control over, I am an ant in the pile.

It ultimately means that I have to wait until the forest level will be raised
4 and up.

Michael

> -----Original Message-----
> From: [hidden email] [mailto:[hidden email]] On Behalf
> Of Greg Hudson
> Sent: Wednesday, August 17, 2016 8:20 AM
> To: Osipov, Michael; [hidden email]
> Subject: Re: Avoiding "KDC has no support for encryption type while
> getting initial credentials" by pinning selected KDC
>
> On 08/17/2016 08:51 AM, Osipov, Michael wrote:
> > The keytab contains three keys for one principal: RC4, AES128, AES256.
> > Our home realm is backed up by 80 to 100 KDCs of various Windows
> > Server versions, not all support AES. KDC lookups rely on DNS only and
> > we do not intend to hardcode them in krb5.conf.
>
> I do not know a lot about administering Active Directory, but I thought
> the usual practice here was to configure the newer AD servers to behave as
> if they were of the least common denominator version.
>
> > I would expect MIT Kerberos to pin the first working KDC because some
> > Information has been negotiated already but send to a completely
> > different KDC. This is annoying because I would expect the
> > communication between client and server is predictable.
>
> The Kerberos authentication protocol is intended to be stateless; if
> different requests during an AS exchange go to different KDCs, that is
> supposed to work.  We have talked about preferring the previously chosen
> KDC during an AS exchange (mostly for the sake of marginal preauth
> mechanism implementations), but I think the code changes necessary to
> implement that properly would be extensive.
> ________________________________________________
> Kerberos mailing list           [hidden email]
> https://mailman.mit.edu/mailman/listinfo/kerberos

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos