Kerberos transport DNS record design

[Nathaniel McCallum]

On Thu, 2016-05-26 at 13:10 -0400, Greg Hudson wrote:
> 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.

Agreed. Would MIT consider it sufficient to do a secondary lookup in
this case? A secondary record could have the same format as the primary
record. The cost for this is, of course, a secondary lookup. However,
this only happens in the failure case.

> 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.

Well, I'm not sure we need to register it soley for the purposes of an
informational draft. I suspect we'd only need to register if we tried
to push a URI draft through. But you and I already consider this
"vanishingly unlikely."

> 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.

We are only talking about seven bytes ("krbkdc:") since all the other
contents of the record are required in some form. I'm fine with
removing this if people don't see a value in it. We can always add the
scheme should a serious effort behind the URI record appear.

> > 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.

So then my preference is to avoid a separate scheme.

======================================================================

MIT implements the followin SRV record lookups:
    _kerberos-master.REALM
    _kerberos-adm.REALM
    _kerberos.REALM
    _kpasswd.REALM
    _krb524.REALM

Heimdal supports the following service lookup plugin types:
    locate_service_master_kdc
    locate_service_kadmin
    locate_service_kdc
    locate_service_kpasswd
    locate_service_krb524

However, Heimdal only appears to implement a _kerberos.REALM SRV lookup
internally. Heimdal contains a reference to _kadmin.REALM in an in-tree 
copy of a previous attempt at a DNS discovery draft, however, this was
change to "_kerberos-adm" in a subsequent version of the draft:
https://tools.ietf.org/html/draft-ietf-krb-wg-krb-dns-locate-03

It thus seems to me like there is large agreement between MIT and
Heimdal. Thus, I propose the following:

1. Implement all the record names that MIT already supports as TXT.
Using exactly the same semantics that MIT already implements (i.e.
ignoring the weight parameter).

2. Make the format of the TXT record:

    priority:weight:udp:host[:port]
    priority:weight:tcp:host[:port]
    priority:weight:tls:host[:port]
    priority:weight:kkdcp:http://host[:port][/path]
    priority:weight:kkdcp:https://host[:port][/path]

This is isomorphic with the URI record with the exception of a missing
scheme, which could be added later should the desire to use URI emerge.
It also avoids the problem of defining a URI scheme now. I think we can
get away with this by noting that this format isn't technically a URI
even though it closely resembles one.

Thoughts?