3

At its base, Kerberos isn't an overly complicated protocol. I have also already successfully configured a server to accept Kerberos authentications via SPNEGO HTTP headers. I'm new in this area though, so maybe I have just overlooked something...

The confusing part of Kerberos and their implementations is the optional reverse DNS lookup of server's hostname made by clients before they send the resulting SPN to KDC in order to obtain a ticket for the server / application identified by that SPN. As a result, clients may either use the originally requested hostname (this may be an alias - CNAME), OR the reverse-looked up name of the IP-address-owning server in the resulting SPN. This complicates Kerberos setups greatly.

The Kerberos specification (RFC 4120) seems to prefer avoiding the reverse lookup (also referred to as "canonicalization"):

1.3. Choosing a Principal with Which to Communicate

...

Implementation note: Many current implementations do some degree of
canonicalization of the provided service name, often using DNS even
though it creates security problems. However, there is no
consistency among implementations as to whether the service name is
case folded to lowercase or whether reverse resolution is used. To
maximize interoperability and security, applications SHOULD provide
security mechanisms with names that result from folding the user-
entered name to lowercase without performing any other modifications
or canonicalization.

For example, the widespread MIT Kerberos implementation gives an option to disable the reverse lookup and there are even several scenarios suggesting when the reverse lookup should be disabled, in their documentation. On the other side, in Windows the reverse lookup seems to be pretty much hard-coded (see a related question Globally disable reverse DNS lookup for Kerberos on Windows?).

The problem is that the reverse lookups not only break the usage of server aliases (CNAMES), but their optional-ity can cause really unexpected and unstable behavior when different programs on the same machine decide to handle it differently. Like for example when Fiddler makes Kerberos authentication work. And from my tests, the current Firefox, unlike Chrome or IE, even rejects to send Keberos token to a server if requested hostname and hostname looked up by a used Kerberos client library don't match.

So here comes the question: Why is there this mostly problematic default behavior of Kerberos clients? Is there any real benefit nowadays from doing the reverse lookups, other than to maybe get FQDN of a server when FQDN isn't supplied, or to be "backwards-compatible"? Isn't the identity of the called server somewhat confirmed by the widespread usage of SSL anyway?

A bonus question: No new standard coping with this Kerberos "quirk" on the way?

Community
  • 1
Petr Bodnár
  • 159
  • 1
  • 5
  • There’s a good article somewhere (not MS) about using canonicalisation to ensure single host address / SPN, to avoid the burden of having to support the all calling parties’ arbitrary aliases. That concept is the closest thing I’ve seen to a purpose for the canonicalisation, but it doesn’t address why it’s optional or even not preferred. – Chalky Oct 24 '20 at 19:21
  • @Chalky, thanks for your feedback. It seems like no one, maybe from the authors (MS?) themselves, really understand the purpose. I wonder what it means "to avoid the burden of having to support the all calling parties’ arbitrary aliases" - I can't see any burden myself here. Maybe you could try to explain? – Petr Bodnár Oct 24 '20 at 19:35
  • Note that from what I've seen, there is usually just one hostname (possibly CNAME alias) used for a target application running on a server that needs to be registered in Kerberos (AD). That's why I can't see the problem in here. – Petr Bodnár Oct 24 '20 at 19:43
  • 1
    Ah, sorry, the burden of having to create/support multiple SPNs. I agree, a service should ideally have a single address, but web farm etc proxies don’t always help us in this area, and I suspect it all fell into the too-hard basket and not canonicalising became the easier path. – Chalky Oct 24 '20 at 19:56

2 Answers2

2

I've always assumed it's to break CNAMES.

Chalky
  • 141
  • 4
  • I have just edited my question, so that it is more clear for newcomers. I can confirm that the reverse lookups "break CNAMES". But the question is about why they even exist... – Petr Bodnár Oct 24 '20 at 19:15
  • 1
    To be honest, from my experience with MIT Kerberos (non-AD), it always seemed to _help_ with using CNAMEs more than break them. It meant the host only ever needed a single SPN for a particular service even if it was known under multiple names. – user1686 Oct 29 '20 at 06:46
0

I guess this is probably the reason why my keberoized application works well out of Windows box (with only a SPN of the CNAME), however need another SPN of the hostname for the application to run out of Unix.

Jackie
  • 101
  • 2