Kerberos transport DNS record design

[Nathaniel McCallum]

On Wed, 2016-05-25 at 17:48 -0400, Greg Hudson wrote:
> Currently we can map from a Kerberos realm name to the TCP and/or UDP
> addresses of a KDC, kpasswd, or kadmind server.  Several of us have
> been
> discussing how to best extend that mechanism to include MS-KKDCP, and
> at
> the same time minimize the number of DNS lookups required to contact
> a
> realm without configuration.
> 
> We had been planning to use the URI record type, but after a recent
> round of discussion, we don't think it's likely that popular DNS
> hosting
> providers will allow customers to create URI records (since it seems
> like no one else is using them).  Some middle-boxes would also block
> DNS
> queries for URI records.  That problem would be even worse if we
> create
> a new record type.  So, we are planning to use the TXT record
> type.  It
> seems unlikely that we can standardize on a TXT record through the
> IETF
> (except perhaps as an informational RFC), but it seems like the only
> deployable option for individuals and small organizations.
> 
> If we use the TXT record type, we have to define the payload format,
> which is the primary subject of this thread.  The payload must
> communicate:
> 
> * Priority, because DNS records are unordered
> * Transport type--currently one of TCP, UDP, and MS-KKDCP
> * For the TCP and UDP types, the hostname and optional port
> * For the MS-KKDCP type, the proxy URL
> 
> The format must be extensible to future transport types, including
> ones that use TCP, UDP, or HTTP in different ways.  Examples could
> include Heimdal's HTTP proxy protocol or RFC 6251 (Kerberos over
> TLS).
> 
> That leaves a lot of questions:
> 
> * Do we want to include weights as well as priorities?  I think
> weights
>   are unnecessary complexity, even just as an optional field in the
>   format, but I seem to be in the minority.

It is my strong preference to include weight so that implementations
which already have weight processing logic can utilize this
information. MIT does not need to support it unless clear justification
presents itself.

> * Do we want to include master KDCs in the same query as normal KDCs,
> or
>   should they be in a separate record?  (Master KDCs are used as a
>   fallback by the MIT client code when we receive a KDC error which
>   could have resulted from out-of-date data due to propagation
> delays.)
> 
>   - If we do communicate master KDCs in the same record, should it be
>     possible to exclude a master KDC from the normal server list (so
>     that it is only contacted if a normal KDC returns an error), or
> is
>     it sufficient to be able to assign master KDCs a low priority?

If the only reason to specify a master KDC is as a last-ditch fallback,
then priority should be sufficient.

> * Do we want to make our payload isomorphic to the URI payload, in
>   anticipation of migrating to the URI record type in the future?  I
>   would argue that such a migration is vanishingly unlikely.  If we
> go
>   this way, the payload contains a priority, a weight, and a URI, so
> we
>   have to encode everything but the priority inside a URI, opening a
>   bunch of other inter-related questions:

It is my preference to support a future migration to URI, even if we
grant that such a trasition is vanishingly unlikely. Doing so adds no
additional burden to our implementation since we already have to
process a URI for KKDCP. Put short, we will have to write a parser for
whatever format we use. Thus, I think our default should be to use a
URI format unless there is a compelling reason not to.

>   - Should we register a new URI scheme to represent TCP and UDP
>     transports, or use the unregistered tcp: and udp: schemes as some
>     other applications have done?
>
>   - Should we use a new URI scheme (probably the same one as above)
> for
>     MS-KKDCP, or should we just use the https: URI of the proxy?

I do not have any strong preference for the format. Something like this
might work:

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

>   - If we do create new URI schemes, should we use use separate
> schemes
>     for krb5/kpasswd/kadmin, or use the same scheme since we already
>     know the application protocol going in?

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

>   - Should we use fragment identifiers (#suffix) to indicate master-
> ness
>     and/or the transport type, or should we use a prefix?

It is my preference to avoid fragments. Colon separation logic can't be
reused for fragments, so we just add an additional parsing burden. I'd
like to avoid this complexity.

> * At the bikeshed level, what should we use as a separator between
>   fields?  Is it more convenient for DNS administrators if we avoid
>   using whitespace as a separator?

As I said above, we already have to parse a URI for KKDCP, let's resuse
this parsing logic. I'm against whitespace separators for this reason.