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

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Nathaniel McCallum-5
https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery
-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?

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman-2
On 5/17/2016 11:49 AM, Nathaniel McCallum wrote:

> https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery
> -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

  https://host[:port][path]

to an URI record requires

 _kerberos._https.host

not

 _kerberos.host

DNS URI records according to RFC 7553 work just like DNS SRV records in
that they require both a service name and a protocol name.  Switching to
URI records does not solve the problem of multiple DNS queries.

To find a KDC that supports https, use the DNS SRV record

  _kerberos._https.REALM

registering additional service types such as "kpasswd" can be done but
the fact is implementations such as Heimdal already perform SRV lookups for

 _kpasswd,_tcp.REALM and _kpasswd._udp.REALM

Can you make a case for something that DNS URI records provides that DNS
SRV records do not?

The introduction of DNS URI records will only mean that in practice that
Kerberos client libraries will need to issue the DNS URI queries in
addition to the existing DNS SRV records.

Jeffrey Altman






_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Rick van Rein (OpenFortress)
Hi,

I agree mostly with Jeffrey, but have some additional remarks / thoughts.

> _kerberos.REALM
>
> is not a valid DNS URI record name. To translate the URI
>
Yes, the RFC wants it to be of the form _server._transport, however

> https://host[:port][path]
>
> to an URI record requires
>
> _kerberos._https.host

where is _https defined as a transport?  RFC 7553 gives examples with
_http._tcp -- I've always wondered to deal with _https and especially
how to add semantics on top of it, so I certainly like the scheme, but
is this format defined anywhere?  For SRV, I though transports were
limited to TCP, UDP, SCTP -- so not even TLS, let alone HTTPS?

Nathaniel, I think what you are actually trying to do is to describe
HTTPS as a tunneling technique, right?  Since this type of tunnel is
designed to participate in the rope-pulling contest between application
desires and (perhaps misguided) firewall configurations, it might be
expected that new tunnels would be topped on as time passes.  Clients
would need to keep up, but keep the older solutions working as well.  So
instead, I would rather have some sort of a redirection to a somewhat
general tunnel descriptor as a general discovery outcome when looking
for a "direct" service description.  This would service many
applications in the same manner.

> registering additional service types such as "kpasswd" can be done but
> the fact is implementations such as Heimdal already perform SRV
> lookups for
>
> _kpasswd,_tcp.REALM and _kpasswd._udp.REALM
>
> Can you make a case for something that DNS URI records provides that DNS
> SRV records do not?
>
It should outweigh having to do both forever and ever, indeed.  And
needing to add even more when other tunneling techniques arrive.

I hope this helps!


Cheers,
 -Rick

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nathaniel McCallum-5
In reply to this post by Jeffrey Altman-2
On Tue, 2016-05-17 at 12:25 -0400, Jeffrey Altman wrote:

> On 5/17/2016 11:49 AM, Nathaniel McCallum wrote:
> > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-disco
> > very
> > -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
>
>   https://host[:port][path]
>
> to an URI record requires
>
>  _kerberos._https.host
>
> not
>
>  _kerberos.host

It doesn't actually require this. It just gives examples.

> DNS URI records according to RFC 7553 work just like DNS SRV records
> in
> that they require both a service name and a protocol name.  Switching
> to
> URI records does not solve the problem of multiple DNS queries.
>
> To find a KDC that supports https, use the DNS SRV record
>
>   _kerberos._https.REALM

_https isn't a thing. You'd have to do something like: _http._tls._tcp.

> registering additional service types such as "kpasswd" can be done
> but
> the fact is implementations such as Heimdal already perform SRV
> lookups for
>
>  _kpasswd,_tcp.REALM and _kpasswd._udp.REALM

At the cost of one DNS query per transport. Further, administrators
have no control over the weights or priorties between transports. My
draft provides this.

> Can you make a case for something that DNS URI records provides that
> DNS
> SRV records do not?

Yes. MS-KKDCP requires a path. SRV records cannot provide a path.

> The introduction of DNS URI records will only mean that in practice
> that
> Kerberos client libraries will need to issue the DNS URI queries in
> addition to the existing DNS SRV records.

We will need to add at least one more DNS query to support MS-KKDCP
(two if we have to treat http and https as separate queries). This is
unavoidable. While it is true that this will result in a 50% increase
in DNS queries, using my URI scheme means that a simple administrator
configuration can turn this 50% increase into a 50% decrease in queries
over the existing implementations. This is a win.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nathaniel McCallum-5
In reply to this post by Rick van Rein (OpenFortress)
On Tue, 2016-05-17 at 22:26 +0200, Rick van Rein wrote:

> Hi,
>
> I agree mostly with Jeffrey, but have some additional remarks /
> thoughts.
>
> > _kerberos.REALM
> >
> > is not a valid DNS URI record name. To translate the URI
> >
> Yes, the RFC wants it to be of the form _server._transport, however
>
> > https://host[:port][path]
> >
> > to an URI record requires
> >
> > _kerberos._https.host
>
> where is _https defined as a transport?  RFC 7553 gives examples with
> _http._tcp -- I've always wondered to deal with _https and especially
> how to add semantics on top of it, so I certainly like the scheme,
> but
> is this format defined anywhere?  For SRV, I though transports were
> limited to TCP, UDP, SCTP -- so not even TLS, let alone HTTPS?
>
> Nathaniel, I think what you are actually trying to do is to describe
> HTTPS as a tunneling technique, right?  Since this type of tunnel is
> designed to participate in the rope-pulling contest between
> application
> desires and (perhaps misguided) firewall configurations, it might be
> expected that new tunnels would be topped on as time passes.

Yes, this is possible: new tunnels may appear over time.

> Clients
> would need to keep up, but keep the older solutions working as
> well.  So
> instead, I would rather have some sort of a redirection to a somewhat
> general tunnel descriptor as a general discovery outcome when looking
> for a "direct" service description.  This would service many
> applications in the same manner.

How does the "general tunnel descriptor" help in the case of Kerberos
tunnelling where the tunnel protocols are Kerberos-specific?

The desire for abstraction here just adds complexity without any
benefit of reusability. OTOH, new Kerberos tunnelling protocols can
just get new URIs. In fact, this is already explicitly allowable in the
existing draft. So the system, as defined is perfectly flexible to new
situations in the future.

One advantage to the URI approach is that weights and priorities can be
used to appropriately transition between transports; something that is
not currently possible.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman-2
In reply to this post by Nathaniel McCallum-5
On 5/17/2016 4:43 PM, Nathaniel McCallum wrote:
> We will need to add at least one more DNS query to support MS-KKDCP
> (two if we have to treat http and https as separate queries). This is
> unavoidable. While it is true that this will result in a 50% increase
> in DNS queries, using my URI scheme means that a simple administrator
> configuration can turn this 50% increase into a 50% decrease in queries
> over the existing implementations. This is a win.

As an implementer I can tell you that it would be more than a decade
before I would ever be able to remove existing lookup methods and
possibly even longer than that.

As a deployer of a realm I can tell you that I have no control over
updates of Kerberos libraries in the clients.  Clients are deployed long
after the 10 year lifetimes of the operating systems and new features
such as this are not backported into prior OS distributions.
As such I would be unable to rely upon URI as a replacement for SRV for
more than 10 years.  I would be required to publish both URI and and SRV
lookup records forever.

You have described a reason why URI lookups are necessary for MS-KKDCP.
Please restrict your draft to that case.

Sincerely,

Jeffrey Altman


_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Nathaniel McCallum-5
On Tue, 2016-05-17 at 17:08 -0400, Jeffrey Altman wrote:

> On 5/17/2016 4:43 PM, Nathaniel McCallum wrote:
> > We will need to add at least one more DNS query to support MS-KKDCP
> > (two if we have to treat http and https as separate queries). This
> > is
> > unavoidable. While it is true that this will result in a 50%
> > increase
> > in DNS queries, using my URI scheme means that a simple
> > administrator
> > configuration can turn this 50% increase into a 50% decrease in
> > queries
> > over the existing implementations. This is a win.
>
> As an implementer I can tell you that it would be more than a decade
> before I would ever be able to remove existing lookup methods and
> possibly even longer than that.

I'm also an implementer. And I can tell you that when you remove the
code doesn't matter. All that matters is what happens at runtime. And
if we offer admins a way to cut their Kerberos DNS requests in half,
they'll take it.

> As a deployer of a realm I can tell you that I have no control over
> updates of Kerberos libraries in the clients.  Clients are deployed
> long
> after the 10 year lifetimes of the operating systems and new features
> such as this are not backported into prior OS distributions.
> As such I would be unable to rely upon URI as a replacement for SRV
> for
> more than 10 years.  I would be required to publish both URI and and
> SRV
> lookup records forever.

Agreed. But who cares? Clients that support the new method get
increased speed and functionality. Clients that don't, get the same
behavior they always had. The only cost for this on the DNS-side of the
equasion is an additional record -- one which we need anyway.

> You have described a reason why URI lookups are necessary for MS-
> KKDCP.
> Please restrict your draft to that case.

I've described a reason why a URI record lookup is requied for MS-
KKDCP. However, I've also described a system which presents a 50%
reduction in DNS lookups. I don't see any reason to neglect this second
feature.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Altman-2
On 5/17/2016 5:26 PM, Nathaniel McCallum wrote:
>
> I've described a reason why a URI record lookup is requied for MS-
> KKDCP. However, I've also described a system which presents a 50%
> reduction in DNS lookups. I don't see any reason to neglect this second
> feature.

And when the DNS URI record is not published or cannot be queried the
Kerberos library will have a 50% increase in the number of DNS lookups.
Not only does the library have to query for DNS URI but it still must
query for the DNS SRV records.

I will also point out that a large number of the DNS hosting providers
do not support URI records and many of the DNS proxy servers do not
support them either.   As a result there is no ability for DNS URI
records to be published and the queries are will be blocked.

Sincerely,

Jeffrey Altman




_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten

smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Kaduk-2
In reply to this post by Nathaniel McCallum-5
On Tue, 17 May 2016, Nathaniel McCallum wrote:

> https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery
> -02
>
> I'd like to propose adoption of this draft:

The chairs are tracking this document and expect it to eventually become a
working group document.  However, as I implied in our previous discussion
(off-list), there are a lot of existing WG documents that are not moving
very fast, and it seems unhealthy to keep a lot of documents around in
such a state.  It would be better to finish off (or formally abandon) some
existing documents before we start trying to take on new work.

I also noted that "adding [Kerberos] bits to the DNS always seems harder
than one expects", which seems borne out by the discussion triggered by
your message.

-Ben

P.S. If someone wanted to help clear out the pile of existing WG
documents, draft-ietf-kitten-gssapi-extensions-iana,
draft-ietf-kitten-rfc5653bis, or draft-ietf-kitten-krb-auth-indicator
would be fine places to start.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

t.p.
----- Original Message -----
From: "Benjamin Kaduk" <[hidden email]>
To: "Nathaniel McCallum" <[hidden email]>
Cc: <[hidden email]>
Sent: Wednesday, May 18, 2016 6:10 AM
> On Tue, 17 May 2016, Nathaniel McCallum wrote:
>
> >
https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery
> > -02
> >
> > I'd like to propose adoption of this draft:
>
> The chairs are tracking this document and expect it to eventually
become a
> working group document.  However, as I implied in our previous
discussion
> (off-list), there are a lot of existing WG documents that are not
moving
> very fast, and it seems unhealthy to keep a lot of documents around in
> such a state.  It would be better to finish off (or formally abandon)
some
> existing documents before we start trying to take on new work.
>
> I also noted that "adding [Kerberos] bits to the DNS always seems
harder
> than one expects", which seems borne out by the discussion triggered
by
> your message.
>
> -Ben
>
> P.S. If someone wanted to help clear out the pile of existing WG
> documents, draft-ietf-kitten-gssapi-extensions-iana,
> draft-ietf-kitten-rfc5653bis, or draft-ietf-kitten-krb-auth-indicator
> would be fine places to start.

P.P.S.

Perhaps you should operate a one-in one-out policy.  If an author has an
I-D gathering dust in the expired pile, then they should resolve that -
advance it, bin it - before an adoption call is made for another I-D by
them  Authors with a track record of producing RFC might be given a
bigger pile of tokens for their leaky bucket.

Just a thought.

Tom Petch

> _______________________________________________
> Kitten mailing list
> [hidden email]
> https://www.ietf.org/mailman/listinfo/kitten

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nathaniel McCallum-5
In reply to this post by Jeffrey Altman-2
On Tue, 2016-05-17 at 20:36 -0400, Jeffrey Altman wrote:

> On 5/17/2016 5:26 PM, Nathaniel McCallum wrote:
> >
> > I've described a reason why a URI record lookup is requied for MS-
> > KKDCP. However, I've also described a system which presents a 50%
> > reduction in DNS lookups. I don't see any reason to neglect this
> > second
> > feature.
>
> And when the DNS URI record is not published or cannot be queried the
> Kerberos library will have a 50% increase in the number of DNS
> lookups.
> Not only does the library have to query for DNS URI but it still must
> query for the DNS SRV records.

This is, indeed, the trade-off to a longer-term improvement. As I said
before, the property that makes this trade-off acceptable (IMHO) is
that the DNS administrator can solve this problem. This performance
trade-off creates an incentive for administrators to move to the new
system.

I'm very open to alternative designs. But we've been having this
conversation for more than a year now and, while lots of alternatives
have been proposed, all of them were abandoned by their proposers after
due consideration.

Here is a basic summary of the ideas proposed (please remind me if I've missed any):

1. A new, Kerberos-specific RR type.
2. (Ab)using TXT; same semantics as the current draft.
3. (Ab)using TXT; same semantics as RFC4120 - KKDCP only.
4. Using SRV with a default path.


#1 was dismissed as generally having the effect of ghettoizing the discovery mechanism. Servers wouldn't implement it. Neither would administrative interfaces. It also has all the same drawbacks as the current draft.

#2 is the exact same proposal as the existing draft, just using TXT records. Its main advantage over the current draft is that we don't need to depend on the URI record type. However, using the TXT record like this is controversial (to say the least).

#3 is the simplist solution: just define a TXT record for KKDCP only. This record would work in parallel to the existing SRV records and would only indicate the location of the KKDCP proxy. The downside is that this adds an additional query just for KKDCP. Future tunnels may add more queries. Also, it doesn't allow for weights/priorities between protocols.

#4 proposes to define an SRV record for KKDCP. This would carry the understanding that the default path (/KdcProxy) would always be used. This is basically a hack and is extremely inflexible. It would mean, in many cases, that the KKDCP proxy couldn't be integrated directly into existing infrastructure.

Notice that in all of the options we require an additional DNS query.
This is unavoidable.

#3 and #4 do not provide any opportunity for speedup. This means that
KKDCP users will have to wait for two DNS timeouts in order to get
connectivity. I find this property unacceptable. #1 and #2 have the
potential for speedups, with exactly the same semantics as the current
draft. But they each have significant drawbacks as well.

The current draft seems to me the best balance of all the options.

1. It uses a standard RR type. While the use of URI may be somewhat
controversial, it seems to me less problematic than either of the
alternatives (a custom RR type or TXT).

2. It does add an additional DNS query; but this can be avoided if DNS
configuration is updated. This is the best case scenario considering an
extra query will be required in all options.

3. It provides the ability to use weights/priorities between protocols.

> I will also point out that a large number of the DNS hosting
> providers
> do not support URI records and many of the DNS proxy servers do not
> support them either.   As a result there is no ability for DNS URI
> records to be published and the queries are will be blocked.

On the MIT krb5 call this week, I argued this very point against #1
(above). What I argued is that it will be easier to get hosting
providers to add support for URI than for some Kerberos-specific type.
If hosting providers were the only consideration, then TXT would be a
no-brainer here. However, there are also standardization
considerations. If the general consensus is that standardizing on TXT
won't present any difficulty, I would be more than happy to switch to
this option.

If you have any alternative, more creative, solutions, I'm all ears.
If, after this explanation, you agree that our solution is the best
balance of all the concerns, I am also open to suggestions for
improvements in the implementation.

It is my hope that we can agree upon the contours of the problem and
devise a solution that is acceptable to everyone.

Nathaniel

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nathaniel McCallum-5
In reply to this post by Benjamin Kaduk-2
On Wed, 2016-05-18 at 01:10 -0400, Benjamin Kaduk wrote:

> On Tue, 17 May 2016, Nathaniel McCallum wrote:
>
> > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-disco
> very
> > -02
> >
> > I'd like to propose adoption of this draft:
>
> The chairs are tracking this document and expect it to eventually
> become a
> working group document.  However, as I implied in our previous
> discussion
> (off-list), there are a lot of existing WG documents that are not
> moving
> very fast, and it seems unhealthy to keep a lot of documents around
> in
> such a state.  It would be better to finish off (or formally abandon)
> some
> existing documents before we start trying to take on new work.

Understandable. However, a timeline would also be helpful. This draft
is already more than a year old and has only seen minor changes.

> I also noted that "adding [Kerberos] bits to the DNS always seems
> harder
> than one expects", which seems borne out by the discussion triggered
> by
> your message.

Well, I take this discussion as just a rehash of the conversations that
happened last year; just with new interlocutors. None of the input
variables have changed and we are, I think, ending up with exactly the
same conclusions.

> P.S. If someone wanted to help clear out the pile of existing WG
> documents, draft-ietf-kitten-gssapi-extensions-iana,
> draft-ietf-kitten-rfc5653bis, or draft-ietf-kitten-krb-auth-indicator
> would be fine places to start.

I have requested WGLC for draft-ietf-kitten-krb-auth-indicator.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nathaniel McCallum-5
In reply to this post by t.p.
On Wed, 2016-05-18 at 09:26 +0100, tom p. wrote:

> ----- Original Message -----
> From: "Benjamin Kaduk" <[hidden email]>
> To: "Nathaniel McCallum" <[hidden email]>
> Cc: <[hidden email]>
> Sent: Wednesday, May 18, 2016 6:10 AM
> > On Tue, 17 May 2016, Nathaniel McCallum wrote:
> >
> > >
> https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discove
> ry
> > > -02
> > >
> > > I'd like to propose adoption of this draft:
> >
> > The chairs are tracking this document and expect it to eventually
> become a
> > working group document.  However, as I implied in our previous
> discussion
> > (off-list), there are a lot of existing WG documents that are not
> moving
> > very fast, and it seems unhealthy to keep a lot of documents around
> > in
> > such a state.  It would be better to finish off (or formally
> > abandon)
> some
> > existing documents before we start trying to take on new work.
> >
> > I also noted that "adding [Kerberos] bits to the DNS always seems
> harder
> > than one expects", which seems borne out by the discussion
> > triggered
> by
> > your message.
> >
> > -Ben
> >
> > P.S. If someone wanted to help clear out the pile of existing WG
> > documents, draft-ietf-kitten-gssapi-extensions-iana,
> > draft-ietf-kitten-rfc5653bis, or draft-ietf-kitten-krb-auth-
> > indicator
> > would be fine places to start.
>
> P.P.S.
>
> Perhaps you should operate a one-in one-out policy.  If an author has
> an
> I-D gathering dust in the expired pile, then they should resolve that
> -
> advance it, bin it - before an adoption call is made for another I-D
> by
> them  Authors with a track record of producing RFC might be given a
> bigger pile of tokens for their leaky bucket.

I'm fine with this so long as the author gets to choose the priority.
For instance, I have three drafts. Two of them are small (auth-ind,
service-discovery) and one of them is large (spake-preauth). This order
is also my priority. However, I'd hate to have spake-preauth be pulled
in first and have it block the smaller drafts for years.

Nathaniel

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
In reply to this post by Jeffrey Altman-2
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-discovery
> > -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).

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

> Can you make a case for something that DNS URI records provides that DNS
> SRV records do not?

Yes.  See above.

> The introduction of DNS URI records will only mean that in practice that
> Kerberos client libraries will need to issue the DNS URI queries in
> addition to the existing DNS SRV records.

Yes, but they should try URI queries first so as to create an incentive
to publish those (because that will be faster, because it will be just
one query instead of three or four).

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
In reply to this post by Nathaniel McCallum-5
On Tue, May 17, 2016 at 11:49:23AM -0400, Nathaniel McCallum wrote:

> https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-discovery
> -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?

 - If we use the URI RR type (and maybe even if we don't), we'll need a
   krbtgt URI scheme, as we have four different options to express,
   including two over HTTP: raw over TCP, raw over UDP, HTTP w/ POST,
   HTTP w/ GET.

 - We should find out why RFC7553 ended up being Informational.  There
   may be some important lessons in that.

 - Perhaps we should have our own RR type.  In principle it's easy to
   add them, but:

 - You've mentioned that many DNS hosters don't have UIs or support for
   URI RRs.  This needs more research.  If adding support for new RR
   types is impossible because of this, then the DNS community at the
   IETF should be asked to address this, and we might need to use TXT
   RRs instead.

   Using TXT RRs is frowned upon, and we'd never get an RFC on the
   Standards track using them today, but if the DNS community confirms
   that adding new RR types is much harder than previously thought, then
   TXT RRs will have to become the DNS extension mechanism to use
   instead of new RR types.

   Ideally we could get the DNS hosters to support arbitrary RR types.
   Yes, there is also a UI issue (see below), but it's manageable.

 - If new RR types are the answer, then the DNS community needs to do
   something about UIs.  For example, there could be an XML schema
   defining RR types' RDATA contents and UI elements.  Then implementors
   could automatically translate those to code to implement UIs for new
   RR types.

 - Can you research whether the DNS community at the IETF has addressed
   these issues before?

   If they have not, then we'll have to bring this up to them.

   If they have, what was the outcome?  Have conditions in the market
   changed?  Should the IETF review these issues again?

 - Can you ask some DNS hosters to inveigh as to whether they would be
   willing to add arbitrary new RR types?  (Presumably with a UI that
   requires the user to paste base64-/hex-encoded RDATA.)

   I think this research will be very valuable in reviewing this
   document, and perhaps using alternative designs (e.g., defining a new
   RR type, or using TXT, or updating RFC7553 and perhaps promoting it
   to Proposed Standard).

 - You might want to seek several ADs' input on this early.  The DNS
   issues here seem very real, and dealing with them may require help
   from the ADs.  The WG chairs might help with this.

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nathaniel McCallum-5
In reply to this post by Nico Williams
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.

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
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
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nathaniel McCallum-5
In reply to this post by Nico Williams
On Thu, 2016-05-19 at 11:25 -0500, Nico Williams wrote:

> On Tue, May 17, 2016 at 11:49:23AM -0400, Nathaniel McCallum wrote:
> > https://tools.ietf.org/html/draft-mccallum-kitten-krb-service-disco
> > very
> > -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?
>
>  - If we use the URI RR type (and maybe even if we don't), we'll need
> a
>    krbtgt URI scheme, as we have four different options to express,
>    including two over HTTP: raw over TCP, raw over UDP, HTTP w/ POST,
>    HTTP w/ GET.

Agreed to a URI scheme.

However, HTTP w/ GET is undefined and only exists in one codebase. It
also has some real idempotency and space limitation drawbacks.

In contrast, MS-KKDCP (HTTP w/ POST) has a protocol definition and is
implemented by multiple vendors without the above drawbacks.

>  - We should find out why RFC7553 ended up being
> Informational.  There
>    may be some important lessons in that.

The authors of RFC 7553 told me that informational should be considered
normal for RR type definitions. The authoritative record is IANA and
should be referenced instead of the informational RFC.

>  - Perhaps we should have our own RR type.  In principle it's easy to
>    add them, but:
>
>  - You've mentioned that many DNS hosters don't have UIs or support
> for
>    URI RRs.  This needs more research.  If adding support for new RR
>    types is impossible because of this, then the DNS community at the
>    IETF should be asked to address this, and we might need to use TXT
>    RRs instead.
>
>    Using TXT RRs is frowned upon, and we'd never get an RFC on the
>    Standards track using them today, but if the DNS community
> confirms
>    that adding new RR types is much harder than previously thought,
> then
>    TXT RRs will have to become the DNS extension mechanism to use
>    instead of new RR types.
>
>    Ideally we could get the DNS hosters to support arbitrary RR
> types.
>    Yes, there is also a UI issue (see below), but it's manageable.
>
>  - If new RR types are the answer, then the DNS community needs to do
>    something about UIs.  For example, there could be an XML schema
>    defining RR types' RDATA contents and UI elements.  Then
> implementors
>    could automatically translate those to code to implement UIs for
> new
>    RR types.
>
>  - Can you research whether the DNS community at the IETF has
> addressed
>    these issues before?
>
>    If they have not, then we'll have to bring this up to them.
>
>    If they have, what was the outcome?  Have conditions in the market
>    changed?  Should the IETF review these issues again?

Yes. I'm working on this now. However, I'm less sure that UX designers
will be keen to back a "generic record" interface. I do think it will
be possible to get buy-in for URI records.

>  - Can you ask some DNS hosters to inveigh as to whether they would
> be
>    willing to add arbitrary new RR types?  (Presumably with a UI that
>    requires the user to paste base64-/hex-encoded RDATA.)
>
>    I think this research will be very valuable in reviewing this
>    document, and perhaps using alternative designs (e.g., defining a
> new
>    RR type, or using TXT, or updating RFC7553 and perhaps promoting
> it
>    to Proposed Standard).

I plan to ask some of the providers I know.

>  - You might want to seek several ADs' input on this early.  The DNS
>    issues here seem very real, and dealing with them may require help
>    from the ADs.  The WG chairs might help with this.

+1

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
On Thu, May 19, 2016 at 12:47:17PM -0400, Nathaniel McCallum wrote:
> Agreed to a URI scheme.
>
> However, HTTP w/ GET is undefined and only exists in one codebase. It
> also has some real idempotency and space limitation drawbacks.

Idempotency is not an issue (the KDC exchanges are idempotent, with the
sole exception of account lockout on N incorrect passwords, which is and
always has been a very bad idea and which will not be relevant in any
way once we have PAKE), but the URI size limitations are real.

But this is a distraction.  The point is that we have enough options to
express, and that's why we need a URI scheme.

> > - Can you research whether the DNS community at the IETF has
> >   addressed these issues before?
> >
> >   If they have not, then we'll have to bring this up to them.
> >
> >   If they have, what was the outcome?  Have conditions in the market
> >   changed?  Should the IETF review these issues again?
>
> Yes. I'm working on this now. However, I'm less sure that UX designers
> will be keen to back a "generic record" interface. I do think it will
> be possible to get buy-in for URI records.

That seems probable, yes.

> > - Can you ask some DNS hosters to inveigh as to whether they would
> >   be willing to add arbitrary new RR types?  (Presumably with a UI
> >   that requires the user to paste base64-/hex-encoded RDATA.)
> >
> >   I think this research will be very valuable in reviewing this
> >   document, and perhaps using alternative designs (e.g., defining a
> >   new RR type, or using TXT, or updating RFC7553 and perhaps
> >   promoting it to Proposed Standard).
>
> I plan to ask some of the providers I know.

Thanks,

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
Reply | Threaded
Open this post in threaded view
|

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

Nico Williams
In reply to this post by Jeffrey Altman-2
On Tue, May 17, 2016 at 08:36:04PM -0400, Jeffrey Altman wrote:
> And when the DNS URI record is not published or cannot be queried the
> Kerberos library will have a 50% increase in the number of DNS lookups.

That's a feature: the feature that will drive adoption :)

Of course, some clients might have an option to not do this, but still,
if you want fast, zero-conf discovery, you'll want to publish the URI
RRs.

Nico
--

_______________________________________________
Kitten mailing list
[hidden email]
https://www.ietf.org/mailman/listinfo/kitten
12