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

[Nathaniel McCallum <[e-mail]>]

On Thu, 2016-05-19 at 11:10 -0500, Nico Williams wrote:
> On Tue, May 17, 2016 at 12:25:10PM -0400, Jeffrey Altman wrote:
> > On 5/17/2016 11:49 AM, Nathaniel McCallum wrote:
> > > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-dis
> > > covery
> > > -02
> > > 
> > > I'd like to propose adoption of this draft:
> > > 
> > > 1. It is in the scope of the WG. This is an extension to the
> > > discovery
> > > methods already defined in RFC 4120.
> > > 
> > > 2. It is beneficial. It provides both speed improvments and
> > > additional
> > > functionality (discovery of MS-KKDCP proxies).
> > > 
> > > 3. It is small. It avoids defining new: DNS names, DNS semantics,
> > > URIs,
> > > or transport semantics. It simply combines the existing tools in
> > > a
> > > fairly obvious way.
> > > 
> > > Thoughts?
> > > 
> > 
> > Having read the draft I am totally unclear how it is implemented.
> > 
> >   _kerberos.REALM
> > 
> > is not a valid DNS URI record name.  To translate the URI
> 
> RFC7553 is Informational.  Clearly it's the most authoritative when
> describing the URI RR type's RDATA and their semantics.  But as for
> the
> RRset names, I think it's mistaken, and anyways, it's Informational
> (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

> >   https://host[:port][path]
> > 
> > to an URI record requires
> > 
> >  _kerberos._https.host
> > 
> > [...]
> 
> Problems with this:
> 
> a) if we're going to be pedantic, _https is not the sort of protocol
>    intended to go there (protocols running over IP are, so _tcp,
> _udp,
>    _sctp, ...);
> 
> b) plus we have *two* HTTP-based protocols, so how would we indicate
>    which protocol to use?
> 
> c) every additional transport for the KDC exchanges adds a (serial,
> as
>    implemented) DNS lookup for the clients -- this is a performance
>    disaster.
> 
> (c) is fatal.  We really need _kerberos.<REALM's domainname>. as the
> QName and, therefore, the RRset name.  One question, one answer set.
> 
> 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:
> 
>   krbtgt:<host>[:<port>]#proto=tcp
>   krbtgt:<host>[:<port>]#proto=udp
>   krbtgt:http[s]://<host>[:port][/path]#style=POST
>   krbtgt:http[s]://<host>[:port][/path]#style=GET
> 
> Or any variant of that that you might like, such as:
> 
>   krbtgttcp:<host>[:<port>]
>   krbtgtudp:<host>[:<port>]
>   krbtgtpost:http[s]://<host>[:port][/path]
>   krbtgtget:http[s]://<host>[:port][/path]

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.

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

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.