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

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

Petr Spacek
On 19.5.2016 18:47, Nathaniel McCallum wrote:

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

Any new RR type will be in worse position than URI because of reasons you
stated below.


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

Oh yes, this is my plan for some time already but it always gets lower
priority than something else ... I would not wait for it :-)

More importantly, there was literally no usage & demand for the URI record up
to now. Adding new RR types to UI is trivial as soon as you have justification
for the management, so the demand could simply solve the UI problem for the
URI RR type.

>>  - 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.)

We have a standard for Handling of Unknown DNS RR Types:
https://tools.ietf.org/html/rfc3597

It says that RDATA for unknown types should be typed in using hexadecimal
notation:
https://tools.ietf.org/html/rfc3597#section-5

Also, some servers/services simply lack UI (e.g. Windows Server 2003) but
allow adding the record using standard DNS UPDATE protocol RFC 2136, which is
also behavior mandated by RFC 3597.

Petr Spacek  @  Red Hat


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

Petr Spacek
In reply to this post by Nathaniel McCallum-5
On 17.5.2016 22:43, Nathaniel McCallum wrote:

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

More importantly, SRV records did not have any way to specify protocol so
_proto label was only way to convey the information.

In contrary, URI can convey information about protocol/scheme and thus
artificial requirement for _proto label does not make sense.

Also, RFC 2782's Applicability Statement clearly states that SRV records
should be used only for applications which have own RFC describing its semantics.

Considering URI vs. SRV properties mentioned above and the requirement for
separate RFC, I think that Nathaniel's usage of URI records is justified and
legal.

Petr^2 Spacek

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

Nico Williams
In reply to this post by Petr Spacek
On Fri, May 20, 2016 at 09:26:42AM +0200, Petr Spacek wrote:
> On 19.5.2016 18:47, Nathaniel McCallum wrote:
> > On Thu, 2016-05-19 at 11:25 -0500, Nico Williams wrote:
> >>  - Perhaps we should have our own RR type.  In principle it's easy to
> >>    add them, but:
>
> Any new RR type will be in worse position than URI because of reasons you
> stated below.

Exactly.

> >>  - 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.
>
> Oh yes, this is my plan for some time already but it always gets lower
> priority than something else ... I would not wait for it :-)

Er, OK, how do we help you implement it?  :)

> More importantly, there was literally no usage & demand for the URI
> record up to now. Adding new RR types to UI is trivial as soon as you
> have justification for the management, so the demand could simply
> solve the UI problem for the URI RR type.

Well, I hope so!  The UI for URI is going to be very similar to the UI
for SRV.

A machine-readable description of what the UI should be for each RR type
would have made this problem a non-problem, and might yet.

> >>  - 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.)
>
> We have a standard for Handling of Unknown DNS RR Types:
> https://tools.ietf.org/html/rfc3597
>
> It says that RDATA for unknown types should be typed in using hexadecimal
> notation:
> https://tools.ietf.org/html/rfc3597#section-5

Thanks.

> Also, some servers/services simply lack UI (e.g. Windows Server 2003)
> but allow adding the record using standard DNS UPDATE protocol RFC
> 2136, which is also behavior mandated by RFC 3597.

That's nice, but the services that Nathaniel is concerned about probably
don't support DNS UPDATEs.

That's another thing.  Implementations that support DNS UPDATE often
don't have useful authorization models, leading enterprises often to
having to write proxies [that invariably do not themselves speak DNS
UPDATE].  I'm not sure that a standard can help there, but I think it
might.  One idea would be to associate authorization attributes to each
RR type and RRset name pattern so that the DNS server could evaluate the
DNS UPDATE client's authorization to perform a given operation.  E.g.,
the owner(s) of a given domainname (should ownership and/or ACLs be
expressible within DNS?) might get to manage associated SRV RRsets, and
maybe (subject to site-local policy) add/delete CNAMEs pointing to that
name, but maybe not modify the A/AAAA RRsets -- the "associated" bit
would be nice if it were expressed in a standard, while which operations
are allowed should be locally expressible based on simple labels for
each association, say.

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 Petr Spacek
On Fri, May 20, 2016 at 09:37:36AM +0200, Petr Spacek wrote:

> On 17.5.2016 22:43, Nathaniel McCallum wrote:
> > On Tue, 2016-05-17 at 12:25 -0400, Jeffrey Altman wrote:
> >> On 5/17/2016 11:49 AM, Nathaniel McCallum wrote:
> >> 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
> >
> > It doesn't actually require this. It just gives examples.

It doesn't have any normative language about it, so I agree.  But
worryingly, section 4.1 says that "[t]he URI owner name is subject to
special conventions."  I wouldn't want to be told late in the game that
this made this section normative!  (It can't, since normative language
is used elsewhere, its non-use here seems clearly definitive to me.)

> More importantly, SRV records did not have any way to specify protocol so
> _proto label was only way to convey the information.
>
> In contrary, URI can convey information about protocol/scheme and thus
> artificial requirement for _proto label does not make sense.

Yes, this should seem obvious to all.  So why did section 4 even mention
protocols??

> Also, RFC 2782's Applicability Statement clearly states that SRV
> records should be used only for applications which have own RFC
> describing its semantics.
>
> Considering URI vs. SRV properties mentioned above and the requirement
> for separate RFC, I think that Nathaniel's usage of URI records is
> justified and legal.

Thanks.

I'm in favor of adopting this document and the use of the URI RR type,
with one URI RRset per-realm, not one per-{realm, protocol}, and with a
URI scheme or two by which to express all those things that we need to.

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?

Petr Spacek
In reply to this post by Nico Williams
On 20.5.2016 17:06, Nico Williams wrote:

> On Fri, May 20, 2016 at 09:26:42AM +0200, Petr Spacek wrote:
>> On 19.5.2016 18:47, Nathaniel McCallum wrote:
>>> On Thu, 2016-05-19 at 11:25 -0500, Nico Williams wrote:
>>>>  - Perhaps we should have our own RR type.  In principle it's easy to
>>>>    add them, but:
>>
>> Any new RR type will be in worse position than URI because of reasons you
>> stated below.
>
> Exactly.

For the record, opinions of DNS gurus from dnsop list can be found in dnsop
archives:
http://www.ietf.org/mail-archive/web/dnsop/current/msg17526.html

Message
http://www.ietf.org/mail-archive/web/dnsop/current/msg17527.html
indicates that it might be possible to standardize TXT if you try it.

Message
http://www.ietf.org/mail-archive/web/dnsop/current/msg17534.html
argues that URI is good enough and that TXT is a bad practice.

Pick an answer which suits you the best :-)


>
>>>>  - 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.
>>
>> Oh yes, this is my plan for some time already but it always gets lower
>> priority than something else ... I would not wait for it :-)
>
> Er, OK, how do we help you implement it?  :)

Personally I think that this can be solved by some clever usage of an existing
bidirectional language + some metadata.

My experience with Augeas shows that it works quite well and that people
ironed out a lot of details and difficult corner cases so might be worth
investigating this direction.


If you do not like bidirectional languages look at
https://datatracker.ietf.org/doc/draft-levine-dnsextlang/
and implement it :-)

Have a nice day!

Petr Spacek  @  Red Hat


>> More importantly, there was literally no usage & demand for the URI
>> record up to now. Adding new RR types to UI is trivial as soon as you
>> have justification for the management, so the demand could simply
>> solve the UI problem for the URI RR type.
>
> Well, I hope so!  The UI for URI is going to be very similar to the UI
> for SRV.
>
> A machine-readable description of what the UI should be for each RR type
> would have made this problem a non-problem, and might yet.
>
>>>>  - 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.)
>>
>> We have a standard for Handling of Unknown DNS RR Types:
>> https://tools.ietf.org/html/rfc3597
>>
>> It says that RDATA for unknown types should be typed in using hexadecimal
>> notation:
>> https://tools.ietf.org/html/rfc3597#section-5
>
> Thanks.
>
>> Also, some servers/services simply lack UI (e.g. Windows Server 2003)
>> but allow adding the record using standard DNS UPDATE protocol RFC
>> 2136, which is also behavior mandated by RFC 3597.
>
> That's nice, but the services that Nathaniel is concerned about probably
> don't support DNS UPDATEs.
>
> That's another thing.  Implementations that support DNS UPDATE often
> don't have useful authorization models, leading enterprises often to
> having to write proxies [that invariably do not themselves speak DNS
> UPDATE].  I'm not sure that a standard can help there, but I think it
> might.  One idea would be to associate authorization attributes to each
> RR type and RRset name pattern so that the DNS server could evaluate the
> DNS UPDATE client's authorization to perform a given operation.  E.g.,
> the owner(s) of a given domainname (should ownership and/or ACLs be
> expressible within DNS?) might get to manage associated SRV RRsets, and
> maybe (subject to site-local policy) add/delete CNAMEs pointing to that
> name, but maybe not modify the A/AAAA RRsets -- the "associated" bit
> would be nice if it were expressed in a standard, while which operations
> are allowed should be locally expressible based on simple labels for
> each association, say.
>
> Nico
>


--
Petr Spacek  @  Red Hat

_______________________________________________
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 Wed, Jun 01, 2016 at 12:46:18PM +0200, Petr Spacek wrote:
> On 20.5.2016 17:06, Nico Williams wrote:
> > Er, OK, how do we help you implement it?  :)
>
> Personally I think that this can be solved by some clever usage of an existing
> bidirectional language + some metadata.

I'm not sure what you mean.  "Bi-directional language", to me, refers to
natural languages where writing is done in two directions.

> My experience with Augeas shows that it works quite well and that people
> ironed out a lot of details and difficult corner cases so might be worth
> investigating this direction.

The configuration editing tool??

> If you do not like bidirectional languages look at
> https://datatracker.ietf.org/doc/draft-levine-dnsextlang/
> and implement it :-)

My preference would be to use XML (I know, I know[*]), mostly because
people could (and almost certainly would) then write XSLs to generate
client- and maybe server-side code for dealing with unknown RR types.

Mostly you just need to generate a tiny bit of HTML and JavaScript to
present a UI specific to any given RR type, type-check user inputs,
provide help bubbles and such, format the RDATA with valid
user inputs, and produce hex-encoded RDATA that the server can then use
(the server doesn't need to validate the RDATA, but it could do that
too, also with generated code).

[*] XSLT is what makes XML tolerable and even desirable for this task.

I suppose one would have to... design an XML schema for this, write an
I-D and sample XSLs, submit, and see if dnsop has interest.  I don't
have the cycles for 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?

Petr Spacek
In reply to this post by Petr Spacek
On 1.6.2016 12:46, Petr Spacek wrote:

> On 20.5.2016 17:06, Nico Williams wrote:
>> > On Fri, May 20, 2016 at 09:26:42AM +0200, Petr Spacek wrote:
>>> >> On 19.5.2016 18:47, Nathaniel McCallum wrote:
>>>> >>> On Thu, 2016-05-19 at 11:25 -0500, Nico Williams wrote:
>>>>> >>>>  - Perhaps we should have our own RR type.  In principle it's easy to
>>>>> >>>>    add them, but:
>>> >>
>>> >> Any new RR type will be in worse position than URI because of reasons you
>>> >> stated below.
>> >
>> > Exactly.
> For the record, opinions of DNS gurus from dnsop list can be found in dnsop
> archives:
> http://www.ietf.org/mail-archive/web/dnsop/current/msg17526.html
>
> Message
> http://www.ietf.org/mail-archive/web/dnsop/current/msg17527.html
> indicates that it might be possible to standardize TXT if you try it.
>
> Message
> http://www.ietf.org/mail-archive/web/dnsop/current/msg17534.html
> argues that URI is good enough and that TXT is a bad practice.
>
> Pick an answer which suits you the best :-)

BTW the discussion continues on krbdev mailing list and wiki, for some reason
people there gave up on kitten...

http://mailman.mit.edu/pipermail/krbdev/2016-June/012605.html

--
Petr Spacek  @  Red Hat

_______________________________________________
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?

Petr Spacek
In reply to this post by Nico Williams
On 2.6.2016 19:21, Nico Williams wrote:
> On Wed, Jun 01, 2016 at 12:46:18PM +0200, Petr Spacek wrote:
>> On 20.5.2016 17:06, Nico Williams wrote:
>>> Er, OK, how do we help you implement it?  :)
>>
>> Personally I think that this can be solved by some clever usage of an existing
>> bidirectional language + some metadata.
>
> I'm not sure what you mean.  "Bi-directional language", to me, refers to
> natural languages where writing is done in two directions.

I'm sorry for being terse but the long answer is here:
https://www.cis.upenn.edu/~bcpierce/papers/lenses-etapsslides.pdf

"Need to find a way of deriving both functions from a single
description" (of RR type in our case).

Of course the description could be encoded in any format. The main point is
that this conversion should be based on very solid theory to eliminate risk of
encode()/decode() inconsistencies.


>> My experience with Augeas shows that it works quite well and that people
>> ironed out a lot of details and difficult corner cases so might be worth
>> investigating this direction.
>
> The configuration editing tool??
Yes, Augeas is using an bidirectional language.


>> If you do not like bidirectional languages look at
>> https://datatracker.ietf.org/doc/draft-levine-dnsextlang/
>> and implement it :-)
>
> My preference would be to use XML (I know, I know[*]), mostly because
> people could (and almost certainly would) then write XSLs to generate
> client- and maybe server-side code for dealing with unknown RR types.
>
> Mostly you just need to generate a tiny bit of HTML and JavaScript to
> present a UI specific to any given RR type, type-check user inputs,
> provide help bubbles and such, format the RDATA with valid
> user inputs, and produce hex-encoded RDATA that the server can then use
> (the server doesn't need to validate the RDATA, but it could do that
> too, also with generated code).
>
> [*] XSLT is what makes XML tolerable and even desirable for this task.
>
> I suppose one would have to... design an XML schema for this, write an
> I-D and sample XSLs, submit, and see if dnsop has interest.  I don't
> have the cycles for this :(

I share the same problem :-(

--
Petr Spacek  @  Red Hat

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