Kerberos transport DNS record design

[Brandon Allbery]

As someone with admin experience with both MIT and (older versions of) Heimdal:

- MIT's propagation mechanisms are somewhat limited; either you do bulk propagation at set times, which leads to changes between those times not being seen in a timely fashion on the slave KDCs, or you can use incremental propagation which only works reliably with a relatively low change rate and is prone to stalling and eventually failure as the change rate increases.
 
- It took Heimdal quite a while to get its incremental propagation (iprop) to be reliable, but in reasonably recent versions iprop does not have the stability issues under moderate to high change rates that MIT's kiprop has. As such, iprop makes master KDC fallback unnecessary in most cases.

- For either one, using LDAP backend with its replication facilities makes fallback unnecessary.

-----Original Message-----
From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of Greg Hudson
Sent: Thursday, May 26, 2016 1:10 PM
To: Nathaniel McCallum <npmccallum at redhat.com>; krbdev at mit.edu
Subject: Re: Kerberos transport DNS record design

On 05/26/2016 12:24 PM, Nathaniel McCallum wrote:
> How likely is this failure from non-master KDCs due to synchronization 
> issues? Is this a real historical problem? Does this problem persist 
> today?

Any site with a non-trivial replication delay can be affected by this problem whenever users change their passwords.  It is a real historical problem, and it persists as a concern for the MIT KDC deployment.  I don't have a lot of visibility into other deployments, but we have received a request within the last few years to expand the master fallback to TGS requests.

> Does anyone else implement this logic?

I don't see any evidence that Heimdal implements it, so we may be the only one.  It's a legitimate question how Heimdal gets away with not implementing this fallback.  If you list your master KDC first in the KDC list, then the frequency of kinit failures after a password change goes way down, but I've measured as high as a 1% fallback rate in the MIT Kerberos deployment when the master KDC is operational.

I don't think we're currently in a position to simplify out this part of the initial creds design.  Complexity, once added, is hard to safely remove.

I forgot to comment on some parts of your initial reply:

> It is my preference to support a future migration to URI, even if we 
> grant that such a trasition is vanishingly unlikely.

The main cost here is registering one or more URI schemes, unless we decide to shoehorn our responses into existing schemes.  See RFC 7595 for the procedures involved.  It also makes the DNS responses slightly larger since the URI scheme (completely predictable if we register our
own) needs to appear in each record.

> Is there any value in having a single query return both kpasswd and 
> kadmin? If so, then I think separate schemes are desirable.

I don't think there is any value in including kpasswd and kadmin entries in the same record.  While we do fall back from kpasswd to port-changed kadmin when locating kpasswd servers, this is only a provision for realms with misconfigured DNS.
_______________________________________________
krbdev mailing list             krbdev at mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev