Re: [kitten] Kerberos Service Discovery using DNS

[Benjamin Kaduk <[e-mail]>]

On Wed, 11 Mar 2015, Nathaniel McCallum wrote:

> On Wed, 2015-03-11 at 12:05 -0400, Benjamin Kaduk wrote:
> > On Thu, 5 Mar 2015, Nathaniel McCallum wrote:
> >
> > > I have uploaded a new draft:
> > >
> > http://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-discovery/
> > >
> > > If you'd like to discuss it, reply to this message. :)
> >
> > I'm generally in favor of something like this.
> >
> > A few things that came to mind while reading it that have not
> > already been
> > raised:
> >
> > You cover kerberos and kpasswd, but not kadmin.  Any reason why?
> > (MIT's code does not currently support using DNS to locate an admin
> > server, but that's not a reason to reject adding it to a discovery
> > protocol in its own
> > right.)
>
> My understanding is that kadmin is a proprietary protocol and has not
> been standardized. If that is incorrect, I can certainly add it. Does
> it already have a standardized discovery protocol?

There are at least two different proprietary kadmin protocols.
SRV records for _kerberos-adm._tcp.[realm] are documented by both
MIT and Heimdal, and exist at many sites.  It looks like Heimdal doesn't
actually implement client support for them, either, though, judging by git
grep.  (The corresponding draft-ietf-cat-krb-dns-locate seems to have
withered and died.)

> > I'm uncertain that section 3 is necessary.  Section 7.2.3.1 of RFC
> > 4120 seems to just be saying "you can't make two kerberos realms
> > that differ only in case"; whatever case is used for the DNS query,
> > the response will
> > be the same.
>
> Do I understand you correctly to suggest that I simply remove section 3
> altogether and say nothing about realm-to-domain translation?

That's my suggestion.  I am not 100% confident that it is correct, though.

> > Section 5.1 calls out that the default path differs from that in [MS-
> > KKDCP].  It seems like some justification for this deviation should
> > be
> > offered, or the gratuitous difference removed.
>
> Good point. My justification is simply that the default provided by MS-
> KKDCP will confuse DNS admins.
>
> They will see a URI that looks like this:
>   https://kdc.foo.com
>
> They will expect this behavior from past experience:
>   https://kdc.foo.com/
>
> But they will actually get this behavior:
>   https://kdc.foo.com/KdcProxy
>
> Even if we were to use a different URI scheme, I think this behavior
> expectation mismatch will be pronounced.
>
> I suspect the use of /KdcProxy is really just an implementation
> detail. Its only appearance is in Section 2.1 and its meaning is
> rather vague. I would like some clarification from MS regarding this
> question.

I guess I am satisfied by Greg's response on this point.

-Ben