Re: [kitten] Adoption of draft-mccallum-kitten-krb-service-discovery?

[Nico Williams <[e-mail]>]

On Thu, May 19, 2016 at 12:28:13PM -0400, Nathaniel McCallum wrote:
> > (though it once aimed for Proposed Standard; we might want to find
> > out why it ended up being Informational).
> 
> I have already inquired. I was informed that the change was made simply
> for the reason that all DNS RR type definitions are informational. To
> avoid a downreference, I was advised to reference IANA instead of the
> RFC:
> http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml

Thanks.

> > And if we're going to use URI, then we'll need a 'krbtgt' URI scheme
> > by which to express the four protocols we have (raw over TCP, raw
> > over UDP, HTTP MSFT-style, and HTTP Heimdal-style:
> 
> One reason to avoid "krbtgt" is that we are actually defining transport
> mechanisms for multiple protocols: kerberos and kpasswd, at a minimum.
> I suspect implementors will extract this to additional protocols.

On the contrary, that's all the more reason to want URI schemes for
Kerberos: we can then add additional URI schemes for the related
protocols (kpasswd, kadmin Heimdal flavor, kadmin MIT flavor, kadmin
Solaris flavor, admin via LDAP, and whatever else comes up).

> But in general, I don't care what the actual URIs look like.

Me either, as long as they can express the options we have to be able to
express.

> As you may have hinted, it may be worth considering implementing a URI
> for Heimdal's proxy. I left it off the current draft since there is no
> protocol definition; just some code.

Sure, but we can document it if need be.  The point is that we have more
than just three options to express, and if you include kpasswd and such,
we have more than four.  It's critical to be able to get at least the
KDCs with one DNS question (perhaps using EDNS0 or falling back on DNS
over TCP if the answers don't fit in a DNS UDP response).

Nico
--