Subject: [kitten] Finding Kerberos Realm Descriptors in secure DNS

From: Rick van Rein <[email-masked]>
Date: Mon, 14 Sep 2015 10:35:54 +0200

Hello,

On DNSEXT, I’m discussing a new DNS record named “KREALM”, proposed here
before, to resolve things in secure DNS that the Kerberos specs didn’t
trust to put into DNS in the past. The thread can be found at
http://www.ietf.org/mail-archive/web/dnsext/current/threads.html#13822
and the I-D itself is located at
https://tools.ietf.org/html/draft-vanrein-dnstxt-krb1

Where SRV records to kerberos’ own services are secure because they rely
on sharing a secret, and the mapping of DNS-style realm names to
case-insensitive DNS names has been standardised (ignore case, don’t
define two realms that only differ in case), there is no good option yet
to come from a DNS name to a realm name; not form a realm's DNS name
back to the realm name and not from a service's hostname to a realm
name. This is what KREALM tries to establish, using DNSSEC to provide
authenticity.

Think of service descriptions to find the realm for
HTTP/www.example.com, like

_http.www.example.com. IN KREALM “realm” “EXAMPLE.COM”
_http.www.example.com. IN KREALM "service" "HTTP"

(when not found, searches move upward in the DNS tree but not beyond the
zone apex; the I-D specifies an efficient, DNS-folk-agreeable way of
doing this)

but also think of realm descriptive information like

example.com. IN KREALM "realm" "EXAMPLE.COM"
example.com. IN KREALM "admin" "john/[email-masked]"
example.com. IN KREALM "admin.uri" "http://www.example.com/contact.html"
example.com. IN KREALM "admin.uri"
"ldap://ldap.example.com/?cn=John+Smith,dc=example,dc=com"
example.com. IN KREALM "admin.cert" "admcert.example.com."
admcert.example.com. IN CERT ...

Now, the question surfaces what use cases of KREALM records could exist.
I’ve identified three or four:

 1.

    Kerberos client (or his KDC) knows service name + hostname, and
    wants to find a realm name

 2.

    Kerberos node wants to find the case-sensitive realm name for a DNS
    name, in a secure manner

 3. Kerberos node wants to find automatic validation information for a
    realm administrator (principal name)
 4. Kerberos node wants to find manual contact information for a realm
    administrator (perhaps through a URI and/or CERT record with an
    X.509 or PGP certificate)
 5. (optional) Kerberos client wants to perform service discovery under
    a realm and/or at a DNS name

Based on these, I should be able to formulate the keys and search
patterns for the data. I am aware that the keys will be vital for trust
in the information found!

If you have anything to add (or remove) then please let me know!
Everything will be setup to be extensible, and there should be non
reason why an admin would be forced to comply to a use case for their
services if they don’t want to, of course.

-Rick

​

---

From: Nico Williams <[email-masked]>
Date: Mon, 14 Sep 2015 10:11:16 -0500

> _http.www.example.com. IN KREALM "service" "HTTP"

Why call it KREALM if it can be used to find things other than Kerberos
realm names?

Why use this to find service names?  The app knows the service name.  (I
know of no app that doesn't.  Further, I don't know how one would say "I
don't know the service name, figure it out" in GSS (though we could
define "@foo.example" to mean that for GSS_C_NT_HOSTBASED_SERVICE), and
finally, expecting "[email-masked]" in GSS to become
HTTP/foo.example@EXAMPLE in Kerberos would fail on older
implementations, thus why would one?

(For better or worse, GSS apps are now stuck using "HTTP" as the service
name for HTTP.)

(For things like MSFT SQL Server, a discoverable service name could
have been useful had the service name discovery process included the
service's port number as an input, but that's a very odd thing.  Putting
the port number into the service name would have been plenty good enough
in actuality.)

> (when not found, searches move upward in the DNS tree but not beyond
> the zone apex; the I-D specifies an efficient, DNS-folk-agreeable way
> of doing this)

I'll have to look.

> but also think of realm descriptive information like

See my first question above.

> admcert.example.com. IN CERT ...

I guess you meant TLSA?

Is this really Kerberos-specific?  The realm names are.  The admin
principal names are (but would you list them all?)  The rest doesn't
seem Kerberos-specific.  If we think of realm names are "issuers" then
in a sense a new TLSA RR usage would fit the bill (though that might not
be useful for other reasons).

> Now, the question surfaces what use cases of KREALM records could
> exist.  I've identified three or four:
> 
>  1. Kerberos client (or his KDC) knows service name + hostname, and

Sure.

>  2. Kerberos node wants to find the case-sensitive realm name for a
>     DNS name, in a secure manner

I guess the difference between 1 and 2 is that the domainname in 2 might
not be a hostname?

>     realm administrator (principal name)

Can you be more specific?  Usually the node will just know this (e.g.,
because the admin is providing their name at a prompt).

>     X.509 or PGP certificate)

This seems utterly generic, not Kerberos-specific.  There might be many
contacts for different sub-systems (storage, cloud, this, that,
Kerberos).

>  5. (optional) Kerberos client wants to perform service discovery
>     under a realm and/or at a DNS name

But why not discover the service, then its realm (i.e., use-case 1).  If
you know the realm a priori then there's no need to discover the realm
(unless it's to make sure the two match before going any further).

====

What if there are multiple realms/whatever defined?

> patterns for the data. I am aware that the keys will be vital for
> trust in the information found!
> 

If we drop the Kerberos-specificity, what then happens politically with
this proposal?  Does this become a TXT replacement swiss knife that
suddenly requires more work to obtain consensus?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 14 Sep 2015 10:28:33 -0500

> > the zone apex; the I-D specifies an efficient, DNS-folk-agreeable way

I don't think that the zone apex is necessarily a good place to stop.
DNS delegation does not imply as much as you make it out to.  I'm not
sure what the best thing to do here is.  I'll think about it.  But I'm
quite certain that DNS zone cuts are not the right thing to use.

Also, your method is:

|  5.  When the type bit map in the secure denial indicates the presence
|      of a SOA record under the current name, then no further
|      iterations are possible, and the algorithm ends in failure.

which fails if there are KREALM RRs for some things but not realm.

I think the "key" part of the KREALM RR RDATA may be best as an
_-prefixed label in the qname (not least as it reduces response size, at
the expense of increasing the number of queries when the client needs
more than one key's RDATA, but this is fine I think).

Then there'd not be much difference between a KREALM RR and a TXT RR...

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Mon, 14 Sep 2015 11:40:44 -0400

On 09/14/2015 04:35 AM, Rick van Rein wrote:
> trust to put into DNS in the past.

My reactions are similar to Nico's.

I would advise reducing the problem statement.  We know we have a
problem with hostname-to-realmname mappings; none of the other use cases
strike me as real problems.  If we reduce the problem to "I have a
hostname and I want the realm," then most of the complexity goes away.

---

From: Rick van Rein <[email-masked]>
Date: Mon, 14 Sep 2015 17:41:45 +0200

Hi Nico,

Thanks!
> Why call it KREALM if it can be used to find things other than Kerberos

It's realm descriptive information -- but if you have a better
suggestion I'm listening.  It's just what I came up with back then.

> Why use this to find service names?  The app knows the service name.

Yes, in the particular use case of an app.   I'm also playing around
with use cases that involve service discovery.

By the way, the app may lookup the service name as part of the DNS name
that it queries, but that will then be case insensitive, so it may want
to distinguish One from ONE and oNe.  No, we don't do that yet, but for
completeness sake, I think the ability to define a service name is a
logical mirror image of what a realm name does.

> and

I don't know what you are saying here; but can I assume the above dealt
with it?
> (For better or worse, GSS apps are now stuck using "HTTP" as the service

I would love to approach a realm and iterate over services, and discover
that "imap" and "smtp" and "afs" were all there.  Think of a blanc
deskop, on which you login with kinit, only to have your mail and file
storage automatically mounted :)

And yes, that's all highly optional for the DNS admin... it's a use case
that he may or may not want to support as far as I'm concerned.
> the port number into the service name would have been plenty good enough

Hmm, ports and such are transport level issues... with KREALM I'm aiming
at the level of authentication and principal names.
>> admcert.example.com. IN CERT ...
No, CERT.  If I want to contact a realm admin in person (yet another
usecase) I want to have his credentials validated by DNSSEC under the
DNS-mapped realm name.

TLSA is wonderful stuff for KDC and mates, I'll grant you that! because
those are protocols running on ports over some transport.

> be useful for other reasons).

Indeed, it's a bit more "soft soap" perhaps -- I want to contact a realm
administrator (to talk about realm crossover, say) and would like to
find contact information including security hints.  That is a use case
we can decide to like or dislike.
> I guess the difference between 1 and 2 is that the domainname in 2 might

No, this is reversing the DNS-mapping for a DNS-styled realm name (i.e.
ignoring its case and hereby getting it back).  We could never do that
in a secure manner and so it was never formalised.
> because the admin is providing their name at a prompt).

I'm working on more extensive use cases.  This one might help to get a
remote service setup for under your realm, based on that fact that you
are in charge as an admin.
> contacts for different sub-systems (storage, cloud, this, that,

It is generic, and I think it should be and can be because manual
handling is involved.  Someone wants to email the admin and although
general ideas are posted they have never been linked into use cases,
which is what I am hereby proposing to do.  Because I believe it is
valuable to have mechanisms to find one another online in a secure manner.
> (unless it's to make sure the two match before going any further).
You may not know all the server names that you would need to discover. 
But yes, if you define those under your realm's DNS entry then this
works.  It's actually what I've also been moving towards.

> What if there are multiple realms/whatever defined?

Either will do, as specified.  If an app needs a realm, it has a few to
try in this case.
> suddenly requires more work to obtain consensus?

It will be more difficult to make security assumptions from it.  And it
will be practically impossible to pass as a proposal I fear.  Doing this
for Kerberos alone is difficult enough as it stands.  Unless Kitten
wants to pick it up in that more general form, then things would be
different.  But Kerberos is the most obvious usecase that needs to learn
realm names for (remote) services, especially when realm crossover is
available and can reach a large number of realms.

-Rick

---

From: Rick van Rein <[email-masked]>
Date: Mon, 14 Sep 2015 17:53:34 +0200

Hi Nico,

> Nico Williams <mailto:[email-masked]>
> 14 September 2015 17:28
>

> I don't think that the zone apex is necessarily a good place to stop.

I've seen  lots of these cautious remarks.  The alternative might to not
iterate, but other than that I see no clear point.

I picked the zone apex, marked by the "start of authority" RR, because
it is a known breaking point for DNSSEC security because it's where
DNSKEYs get changed, and control over them.

We've been talking about this before, and it always seems to end up in
not having a conceptually clear, and query'able place where to stop
upward iteration on security grounds.  What this proposal is saying is
that in case your parent domain contains proper realm records, you will
have to copy them in the lower one, thereby stating that the owner of
the child zone agrees.

> DNS delegation does not imply as much as you make it out to.

Wait -- I'm talking of DNSSEC delegation.  The change of DNSKEYs and
thereby of the control over a zone's security.

> I'm not
If you know a better place then I'm listening.  If it's going to be a
philosophical debate that stops us getting this important facility then
I'm really interested in (relatively clean) short cuts, including a
construct for DNS zones that may not be part of the original DNS design,
that was strengthened by the DNSSEC design but that was nevertheless
ever fully spelled out.

> which fails if there are KREALM RRs for some things but not realm.
Yes, and that's deliberately, although we could discuss advantages of
changing it.

If you start defining KREALM RRs you should put all those in place that
belong there, so you don't need to continue iterating after you found
the first KREALM RRset.

> more than one key's RDATA, but this is fine I think).
I completely agree, and am indeed formulating that now in -05.

> Then there'd not be much difference between a KREALM RR and a TXT RR...

There's an incredible difference in semantics, that have been defined
for KREALM and not for TXT.  Also, the DNS folk really don't like
overloading TXT with structured / meaningful / interpreted data, they
were the ones who drove me to define a new RRtype.

Cheers,
 -Rick

---

From: Rick van Rein <[email-masked]>
Date: Mon, 14 Sep 2015 17:58:03 +0200

Hi Greg,

> hostname and I want the realm," then most of the complexity goes away.
I agree that the spec would get much simpler; I'm now trying to solve multiple things in one stroke and that might be going over the top.

When we step back to 1 or 2 use cases, we might still consider to use to KREALM construct that I'm now working on and that could support the more luxureous features in the feature, how does that idea strike you if the actual resolution got really straightforward for the defined use cases?  I mean, if we limit the number of use cases supported that doesn't necessarily mean that we should also define the least extensible KREALM RR around it?

-Rick

---

From: Nico Williams <[email-masked]>
Date: Mon, 14 Sep 2015 11:11:01 -0500

On Mon, Sep 14, 2015 at 11:40:44AM -0400, Greg Hudson wrote:
> problem with hostname-to-realmname mappings; none of the other use
> cases strike me as real problems.  If we reduce the problem to "I have
> a hostname and I want the realm," then most of the complexity goes
> away.

+1.

I would also drop the zone apex business.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 14 Sep 2015 11:26:28 -0500

> suggestion I'm listening.  It's just what I came up with back then.

If you wanted to stick to a swiss army knife then the first question to
answer is whether the "key" belongs in the RDATA or in the domainname.
Either way it's not Kerberos-specific so drop the "K" and the "REALM"
from the RR type name and call it something generic.  If the key moves
to the domainname then this is basically a TXT RR but not for arbitrary
text.

> with use cases that involve service discovery.

Hosts tend to offer many services.  Discovering one does no good.
Listing them isn't necessarily a useful thing from a security
perspective.

Service name canonicalization is not something that we've ever needed
before, and I don't think it's a good idea to start providing that now.

> I don't know what you are saying here; but can I assume the above dealt

No.  You really need to have familiarity with the GSS-API and GSS-API
application code to understand this comment, and the comment remains on
point.  (It's the same comment as the above about service name
canonicalizetion.)

> that "imap" and "smtp" and "afs" were all there.  Think of a blanc

Why?

> storage automatically mounted :)

But my desktop would be a client for these services, not a server.

> at the level of authentication and principal names.

This is about MSSQL using service principal names of the form
<service>@<hostname.fqdn>:<port-number>@<REALM>, which has been very
problematic for interop.  The port number should have been in the
service name.  (MSFT needed to put the port number in the name because
many instances of SQL Server can be running as different users, and so
there's a need to distinguish them as service names.)

> usecase) I want to have his credentials validated by DNSSEC under the

I still don't understand why not TLSA.

> in a secure manner and so it was never formalised.

I don't understand this at all.

> are in charge as an admin.

I don't think you need more use cases.

> valuable to have mechanisms to find one another online in a secure manner.

If it's generic then make it so.

> Either will do, as specified.  If an app needs a realm, it has a few to

Existing implementations don't do that even though their configuration
language supports it.  And anyways, we need a limit to the number of
attempts a client will make.

> It will be more difficult to make security assumptions from it.  And it

Eh?  Why?

> will be practically impossible to pass as a proposal I fear.  Doing this

It will be much harder to pass a trojan horse generic proposal.

> for Kerberos alone is difficult enough as it stands.  Unless Kitten

Not if you limit yourself to just the one use case you need (determining
a host's realm).

Nico
--

---

From: Rick van Rein <[email-masked]>
Date: Tue, 15 Sep 2015 09:08:42 +0200

Interesting :)

While talking on DNSEXT, the complexity of KREALM started to explode, and that's why I came up with use cases as a guideline.  What you're now telling me is that there is only one real problem for Kerberos (to which I agree) and that the rest is not specific to Kerberos (which I hadn't realised yet, but agree with too).

So, time to simplify.  What we're now looking it is a very simple KREALM record that says stuff like

www.example.org.  IN KREALM  "EXAMPLE.ORG"
                  IN KREALM "EXAMPLE.COM"

if it wants to state the Kerberos realms to consider for the DNS name www.example.com.  As a freebe, we're also getting the possibility to say

example.org.  IN KREALM "EXAMPLE.ORG"

so we now how to spell the DNS-name's realm in proper case.  But although that's defined (somewhere) as missing-because-not-secure, it is not actually necessary for Kerberos to function.  Which is true.

I'm also pulling back my thought on permitting the more complicated use cases, because you've convinced me that this is not Kerberos-specific stuff.

I want to rethink offline how I got to the current proposal, because I think I originally started with precisely this...

> I would also drop the zone apex business.

I definately won't define iteration that passes through the zone apex because the DNSKEY switch makes that a security problem, but I can agree to not iterating at all.  In that case, we'd simply have to specify a KREALM record next to each server name.  Still, that's quite acceptable I think, even if it replicates data in multiple places of a zone; by now I'm convinced that the alternative adds too much complexity.  And at least the records got simple again :)

FWIW, wildcards won't work to define KREALM for all servers in a zone -- a server will have an AAAA or A or SRV record for the server's hostname, which interferes with a matching wildcard.

If you guys are happy with this, I will redraft and post it here and return to DNSEXT.

Thanks for the fireworks ;-)
 -Rick

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Sep 2015 07:30:30 +0000

> www.example.org.  IN KREALM  "EXAMPLE.ORG"

Text strings used to be handy for realm names in DNS when associated
SRV records were plausibly optional.  These days, the REALM *should*
be a DNS name.  Therefore, a simpler design would be:

    ; Realm mapping per-host reduces lookup latency
    ;
    _kerberos.host.name.example.com. IN PTR EXAMPLE.COM.

    ; "Fallback" realm mapping at ancestor domain
    ;
    _kerberos.example.com. IN PTR EXAMPLE.COM.

    ; Associated SRV records
    ;
    _kerberos._udp.example.com. IN SRV 0 100 88 kdc.example.com.
    _kerberos._tcp.example.com. IN SRV 0 100 88 kdc.example.com.

This does not require a new RR type, PTR will do.

-- 
	Viktor.

---

From: Rick van Rein <[email-masked]>
Date: Tue, 15 Sep 2015 09:41:12 +0200

Hi Viktor,

> be a DNS name.

If that's not MUST then I don't think it's a safe assumption to make.

> Therefore, a simpler design would be:
>

The value of PTR is a <domain-name> rather than a binary <character-string>, which makes it case-insensitive and I wouldn't be surprised if some name server mangled the case of PTR records to all-lowercase.

Also, the trailing dot is not the only form that may be used; there can be relative names.

And, you are using PTR in forward DNS, which may upset people.

Finally, the PTR record already has its meaning, and that is not the one we have in mind.  The new RRtype can be hard and clear about its meaning for Kerberos, and avoid security questions relating to the use of certain records.

I've initially proposed overloading TXT and that gave strong responses to instead register a new RRtype, and nobody on DNSEXT is questioning that change.  I therefore propose to not follow your idea.  It made me smile though, because it is an interesting find.

Thanks!
 -Rick

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Sep 2015 14:47:24 +0000

> If that's not MUST then I don't think it's a safe assumption to make.

The proposal need not support all legacy options.  Folks who want
non-DNS name realms can manage the mapping outside DNS.

> The value of PTR is a <domain-name> rather than a binary <character-string>,
> which makes it case-insensitive and I wouldn't be surprised if some name
> server mangled the case of PTR records to all-lowercase.

No, it is not "case-insensitive".  The value of PTR records is
returned verbatim by nameservers.  What's case insensitive is
lookups derived from that name when you use it in a query string.

> there can be relative names.

You're confused.  DNS wire format carries fqdns, as a sequence of
length-encoded labels, with the last length set to 0 (there is no
trailing ".", there's an empty label).  There might be "relative"
names in zone files, but none will appear on the wire.

> And, you are using PTR in forward DNS, which may upset people.

There's no such thing as "forward" vs. "reverse" DNS.  All zones
are just zones.  There's nothing magic about in-addr.arpa or
ip6.arpa.  Plus there are frequently CNAMEs from these into other
zones allowing users to manage their own PTRs.

> Finally, the PTR record already has its meaning, and that is not the one
> we have in mind.

It it *exactly* the meaning you have in mind.  A DNS name that is
not an alias.  A pointer to another place in the DNS.

> I've initially proposed overloading TXT and that gave strong responses to
> instead register a new RRtype, and nobody on DNSEXT is questioning that
> change.  I therefore propose to not follow your idea.  It made me smile
> though, because it is an interesting find.

You haven't seen my battle scars fighting broken nameservers that
block TLSA queries.

Try the following experiment:

    $ dig +short -t mx disa.mil | sort -n
    0 pico.disa.mil.
    5 indal.disa.mil.
    10 dnipro.disa.mil.

    $ dig +short -t a pico.disa.mil
    214.36.3.4

Now the fun bits, first a PTR lookup, which works as expected:

    $ dig +noedns +noall +comment +ans +nocl +nottl -t ptr pico.disa.mil
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37990
    ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

Now a TLSA lookup:

    $ dig +noedns +noall +comment +ans +nocl +nottl -t tlsa pico.disa.mil
    ... long delay ...
    ;; connection timed out; no servers could be reached

Now some brand new RRtype:

    $ dig +noedns +noall +comment +ans +nocl +nottl -t TYPE12345 pico.disa.mil
    ... long delay ...
    ;; connection timed out; no servers could be reached

Many firewalls mistakenly filter "exotic" DNS queries.  The KREALM
RRtype will encounter unnecessary friction.

With the PTR record, UTF-8 labels in Kerberos realms can be converted
to A-labels in zone files and on the wire, with the client mapping
them back to U-labels to reconstruct the realm name, and using the
A-labels directly to locate SRV records, ...

Kerberos realms in DNS should be DNS names, the PTR record will
work much better, is supported by existing zone management tools,
and is not blocked by firewalls.

-- 
	Viktor.

---

From: Rick van Rein <[email-masked]>
Date: Tue, 15 Sep 2015 09:09:03 +0200

Hey,

> I think we might want to add a priority number in the RDATA, especially
> for implementations that currently don't handle more than one realm
> per-host.  Otherwise those implementations either will show
> non-deterministic behavior or their implementors will have that much
> more work to do to implement this.

A full-blown priority scheme (and the need to sort on it) is perhaps a bit much for just that; a flag that signals "this record is (among) the most likely to work for you" seems to be all you need, and is much simpler to implement, especially for such contrived clients.

But... would it be fair to assume that KREALM-supporting hosts must implement some new functionality anyway to support this stuff in DNS, and should be willing to iterate over realms until they get a ticket for one they can stick with?

See... we're requiring DNSSEC to validate the KREALM record, and it is going to be difficult in general to rely on clients to accomadate that; they may be subjected to crummy NAT routers that interfere with, and break DNSSEC.  So, we will probably be dependent on KDCs for practical deployment of KREALM, and a KDC could use KREALM records to inspire a Server Referral in the style of RFC 6806.

So... it may be reasonable to assume that any KREALM client could work with multiple realms, because they will normally be KDCs.  And that'd mean we wouldn't need this priority or go-for-this-one flag.  Agreed?

-Rick

---

From: Rick van Rein <[email-masked]>
Date: Tue, 15 Sep 2015 17:11:07 +0200

Hi Vik,

> lookups derived from that name when you use it in a query string.

RFC 4343 states that DNS compression of domain names can lead to
conversion of case for RRtypes defined in RFC 1035.

There is another reason to prefer a binary format, and that is to leave
the door ajar for future i18n attempts of Kerberos realm names.  That is
hard enough as it is now, without having to deal with DNS i18n as well.
> not an alias.  A pointer to another place in the DNS.

Assuming a Kerberos realm from a DNS name is not automatically safe
because it may not be intended as such by the DNS zone operator /
signer.  Because not all DNS names are intended to be, or have Kerberos
realms.  That is the problem with overloaded / mind-read types that also
have anohter life.
> RRtype will encounter unnecessary friction.

I know that, the same can happen to DNSSEC queries.  It is why I expect
this to be easier to implement on a KDC located in a customised
networking context than on a Kerberos client in an undefined
environment.  Still, that is quite acceptable, as long as
canonicalisation will allow the KDC to respond with Cross-Realm Routing
hints as in Section 9 of RFC 6806.
> A-labels directly to locate SRV records, ...

I would like to hear if i18n experts agree to such mappings.  And
especially in the context of Kerberos, where we are dealing with older
applications that were a bit too liberal with what they put into their
realm name fields.
> Kerberos realms in DNS should be DNS names,

I've found that people in the Kerberos community treat old habits as
things that die hard.  What you are saying probably applies to 99% of
the users, but I see no point to forbid other forms of realm name in
DNS.  If others agree with Vik, then a +1 note may help, because without
more of those I simply fear making a dramatic choice that will make
people dislike this proposal.

Thanks,
 -Rick

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Sep 2015 10:35:17 -0500

>     _kerberos.host.name.example.com. IN PTR EXAMPLE.COM.

Clever.  I like this a lot.  For ASCII labels we even get the correct
case, whatever the server returns.  For IDNs, well, we haven't crossed
that river yet for Kerberos.

>     _kerberos.example.com. IN PTR EXAMPLE.COM.

The problem with the fallback thing is that we don't know how many
labels up to go, if any.  Should example.com. have an A RR but no
_kerberos.example.com., should we go ask com. what example.com.'s realm
should be?  Clearly not, but now try constructing a general rule...

> This does not require a new RR type, PTR will do.

+1

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Sep 2015 10:47:30 -0500

> If that's not MUST then I don't think it's a safe assumption to make.

If you want to use DNS then you must be using DOMAIN-style realm names.
That's a fair requirement to make.

> The value of PTR is a <domain-name> rather than a binary
> <character-string>, which makes it case-insensitive and I wouldn't be
> surprised if some name server mangled the case of PTR records to
> all-lowercase.

DNS is case-insensitive for QNames, and preserves their case in the
answer section, but not in any RDATAs in the response.

> Also, the trailing dot is not the only form that may be used; there

Relative to what?  The QName?  Wouldn't that be a form of compression?
DNS already knows how to compress domainnames in PTR RDATAs, (there
won't be so many answers and additional RRs that compression will be
meaningful, so relative realm names could be potentially useful, but
probably not enough to be something we should drop Viktor's proposal
for).

> And, you are using PTR in forward DNS, which may upset people.

"Meh".  I don't think it will be a problem.

> Finally, the PTR record already has its meaning, and that is not the
> one we have in mind.  The new RRtype can be hard and clear about its
> meaning for Kerberos, and avoid security questions relating to the use
> of certain records.

STD 13 doesn't restrict PTR as you think.  It doesn't even limit the
number of PTR RRs in an answer to one (though all getnameinfo()/similar
implementations always expect only one answer and use only the first).

> I've initially proposed overloading TXT and that gave strong responses

Yes, that was predictable :)

> to instead register a new RRtype, and nobody on DNSEXT is questioning
> that change.  I therefore propose to not follow your idea.  It made me
> smile though, because it is an interesting find.

Lack of objection doesn't mean they reviewed and approved.  And KITTEN
WG's consensus is still needed, and we're free to have objections that
DNSEXT didn't.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Sep 2015 16:20:22 +0000

> Hi Vik,

That's not my name.

> hard enough as it is now, without having to deal with DNS i18n as well.

Well, names that are i18n, but don't map into DNS are not going to
do anyone much good.  They need to be avoided.  It is precisely
*because* PTR constrains you to valid A-labels, that it is the right
way to map realms into DNS.

> realms.  That is the problem with overloaded / mind-read types that also

I'm not assuming anything.  I proposing that:

	_kerberos.host.example.com. IN PTR EXAMPLE.COM.

mean that the realm of "host.example.com" is "EXAMPLE.COM".  If
this mapping sometimes loses case, it may well be time to consider
defining the realm portion of Kerberos principals to be case-insensitive
for A-labels, and for non-ASCII names (as with IDNA 2008) *required*
to be effectively lower-case for U-labels.

The realm is going to be used for SRV lookups, and needs to be
valid DNS name.  Also the realm should be case-insensitive anyway,
time to bite that bullet.

> applications that were a bit too liberal with what they put into their

They don't all have to use DNS for realm mappings, they've gotten
by without so far.

> DNS.

I am proposing leaving legacy behind here, because we don't break
anything by not carrying it forward into DNS.

Of course you could simply standardize the current informal

    _kerberos.host.example.com. IN TXT "EXAMPLE.COM"

that'd be even more backwards compatible.  I already have a large
install-base of those.  And yet I think that PTR makes more sense
in the long run.  I see no compelling reason for KREALM.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Sep 2015 12:13:01 -0500

> to be effectively lower-case for U-labels.

Windows and AD are already case-insensitive/preserving for realm names
now.  I think it'd be a good idea to do the same in other
implementations.  For KDB lookups they may need to internally
canonicalize realm name case.  For name-based authorization services may
need to canonicalize realm name case as well.  But this isn't hard
because KDCs and services usually have sources of canonical realm case
already (in krb5.conf, in the KDB, in keytabs).

> time to bite that bullet.

It's going to be some work (see above), but I agree.

> They don't all have to use DNS for realm mappings, they've gotten

Indeed, between referrals and just... not having out-of-zone realms for
hosts we've not needed this.

>     _kerberos.host.example.com. IN TXT "EXAMPLE.COM"

Informative will do.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Tue, 15 Sep 2015 14:36:36 -0400

> So... it may be reasonable to assume that any KREALM client could work with multiple realms, because they will normally be KDCs.  And that'd mean we wouldn't need this priority or go-for-this-one f…

A KDC can only return one referral, so I'm not sure what it would do
with multiple realms, with or without priorities.  Perhaps I'm missing
something.

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Sep 2015 13:57:01 -0500

On Tue, Sep 15, 2015 at 02:36:36PM -0400, Greg Hudson wrote:
> > See... we're requiring DNSSEC to validate the KREALM record, and it
> > is going to be difficult in general to rely on clients to accomadate
> > that; they may be subjected to crummy NAT routers that interfere
> > with, and break DNSSEC.  So, we will probably be dependent on KDCs
> > for practical deployment of KREALM, and a KDC could use KREALM
> > records to inspire a Server Referral in the style of RFC 6806.
> > 
> > So... it may be reasonable to assume that any KREALM client could
> > work with multiple realms, because they will normally be KDCs.  And
> > that'd mean we wouldn't need this priority or go-for-this-one flag.
> > Agreed?
> 

Er, do we really want KDCs doing DNS queries for processing TGS-REQs?

I believe it could be done, and certainly LDAP and other things add
pressure to implement async evented KDCs, so that adding DNS queries
into the mix wouldn't be a big deal, but I suspect implementors are not
ready to bite that bullet.

Would this proposal (or variants discussed) really solve a _pressing_
problem?  Or a problem we believe will be pressing?

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Sep 2015 19:00:36 +0000

> with multiple realms, with or without priorities.  Perhaps I'm missing

I for one don't see any reason to support multiple realms in the response.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Tue, 15 Sep 2015 14:52:17 -0500

> I for one don't see any reason to support multiple realms in the

Some services have the same name in multiple realms...  If there's a
more preferred transit path (or not every path is available) then in
principle a client (or referral issuer) might need to know about the
service's multiple realms.  A KDC issuing referrals can certainly pick
the better realm based on the transit path that will be required (though
this need not be the optimal path from the service's point of view) to
reach it given the capaths information available to the KDC.

So multiple PTR RRs can be meaningfully supported, but I agree that by
and large only one should be published, and that supporting more than
one will impose a significant additional burden for implementors.

Nico
--

---

From: Rick van Rein <[email-masked]>
Date: Wed, 16 Sep 2015 08:14:51 +0200

Hi,

> problem?  Or a problem we believe will be pressing?

Realm crossover outside a fixed KDC set or federation needs KREALM or a variation on that theme; and could then be used to connect arbitrary domains using something like PKCROSS -- which is my hope and intention.

A KDC-side implementation of this mechanism would require DNS queries in the KDC.  It would be the place where an admin can manage this mechanism in a central place, without having to deal with various clients in various contexts.

-Rick

---

From: Rick van Rein <[email-masked]>
Date: Wed, 16 Sep 2015 08:51:56 +0200

> The value of PTR records is

Below is why I believe that PTR can mangle the case of letters; both
from the specs and a practical demonstration.

Section 4.1 of RFC 4343:

No "case conversion" or "case folding" is done
during such output operations, thus "preserving" case.  However, to
optimize output, indirect labels may be used to point to names
elsewhere in the DNS answer.  In determining whether the name to be
pointed to (for example, the QNAME) is the "same" as the remainder of
the name being optimized, the case insensitive comparison specified
above is done.  Thus, such optimization may easily destroy the output
preservation of case.

Section 3.3 of RFC 1035:

The following RR definitions are expected to occur, at least
potentially, in all classes.  In particular, NS, SOA, CNAME, and PTR
will be used in all classes, and have the same format in all classes.
Because their RDATA format is known, all domain names in the RDATA
section of these RRs may be compressed.

<domain-name> is a domain name represented as a series of labels, and
terminated by a label with zero length.  <character-string> is a single
length octet followed by that number of characters.  <character-string>
is treated as binary information, and can be up to 256 characters in
length (including the length octet).

[...]

3.3.12. PTR RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    /                   PTRDNAME                    /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

where:

PTRDNAME        A <domain-name> which points to some location in the
                domain name space.

I've put this to the test, which turned out even more liberal; I defined
under $ORIGIN vanrein.org:

$ORIGIN vanrein.org.
_kerberos.mixedcase.ptrdemo     3600    IN      PTR    
MiXeDcAsE.VaNrEiN.OrG.
_kerberos.uppercase.ptrdemo     3600    IN      PTR    
UPPERCASE.VANREIN.ORG.
_kerberos.lowercase.ptrdemo     3600    IN      PTR    
lowercase.vanrein.org.

Passing this through ods-signer (from OpenDNSSEC) already maps the PTR
values to lowercase, probably as part of name canonicalisation in
preparation of signing.  Manually editing the ods-signer output to mixed
and uppercase again, reloaded it into the NSD name server... and again,
the PTR values are mapped to lowercase.

-Rick

P.S. If you want to query this for yourself, then note that the DNSSEC
chain isn't complete for this zone, so you won't get AD set in responses.

---

From: Rick van Rein <[email-masked]>
Date: Wed, 16 Sep 2015 09:26:04 +0200

> with multiple realms, with or without priorities.  Perhaps I'm missing
The referral that the KDC returns is one for which it succeeded to construct a TGT.  Having multiple realms gives an opportunity to try multiple paths in constructing that TGT.  I wouldn't be surprised if there are use cases that want to exploit this, even if it puts a strain on the client's KDC.

-Rick

---

From: [email-masked] (Martin Rex)
Date: Wed, 16 Sep 2015 16:43:03 +0200 (CEST)

Greg Hudson wrote:
>> work with multiple realms, because they will normally be KDCs.
>> And that'd mean we wouldn't need this priority or go-for-this-one flag.
>> Agreed?
> 

KDCs and client may have substantially different requirements/purposes.

With traditional Kerberos, a service can only have one unique
Kerberos principal name (in exactly one Kerberos Realm).

So for users from different locations, which locally authenticate
via Kerberos, accessing a central (cross-location or cross-organization)
service traditionally requires Kerberos realm to trust each other
and transparent cross-location / cross-organization access for some
very dangerous network protocols.

(dns: upd/53, ldap: udp/389, kerberos: udp/88 and tcp/88)

Conceptually, setting up a central service with seperate/distinct
service principals from each remote location/organization totally
obviates creating long-distance kerberos realm trust relationships
along with the dangerous network protocols.

In our own Single Sign-On solution, with our own implementation of the
relevant server-side AP_REQ processing we currently support the concurrent
use of kerberos service principals from seperate/independent Kerberos Realms,
and it is actively being used by customers.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Wed, 16 Sep 2015 11:11:16 -0400

> (dns: upd/53, ldap: udp/389, kerberos: udp/88 and tcp/88)

And these are dangerous because what? Certainly Kerberos is ment to deal
with untrusted hostile things on the network.

> along with the dangerous network protocols.

This is not a good idea. Suppose I have users with multiple principals from
different realms and server principals from different realms. How do I know
what the access policy applied actually is? That's the advantage of cross
realm trust, if I understand it correctly.

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 16 Sep 2015 18:08:43 +0000

On Wed, Sep 16, 2015 at 08:51:56AM +0200, Rick van Rein wrote:

> preparation of signing.  

That's unnecessary.  The actual records need not be in canonical
form, just the input to the signatures needs to be canonicalized.

> Manually editing the ods-signer output to mixed

They are not generally mapped to lower-case at zone contstruction time:

    $ dig +noall +nocl +nottl +ans -t ptr -x 169.229.218.207
    207.218.229.169.in-addr.arpa. PTR ees-ppworker-prod-01.IST.Berkeley.EDU.

However, "compression" means that the case of domains in the query
influences the output:

  $ dig +noall +ans +nocl +nottl -t ptr \
      _kerberos.uppercase.ptrdemo.VanReiN.org
  _kerberos.UPPERCASE.ptrdemo.VanReiN.org. PTR uppercase.VanReiN.org.

so indeed PTR is not case-preserving.  The choice is to use "TXT"
which is already supported by both MIT and Heimdal, or to bite the
bullet and define realms as being domain names, and if two strings
are the same valid domain name, then they are the same realm.

I still see no advantage in introducing KREALM.  Just needlessly
less usable than TXT.

-- 
	Viktor.

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 Sep 2015 14:26:52 -0500

On Wed, Sep 16, 2015 at 08:14:51AM +0200, Rick van Rein wrote:
> Realm crossover outside a fixed KDC set or federation needs KREALM or
> a variation on that theme; and could then be used to connect arbitrary
> domains using something like PKCROSS -- which is my hope and
> intention.

The default host->realm mapping (strip left-most label, upcase the rest)
works well enough for 99% of cases, no?

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 16 Sep 2015 14:34:27 -0500

> are the same valid domain name, then they are the same realm.

Certainly there's no harm in describing the TXT RR approach (as
implemented) in an Informative RFC.

I do think we should define domain-style realm names as being
domainnames, which means they must be treated case-insensitively by KDCs
and services.  That's not new: WIndows and AD do this.  Since it can be
a breaking change for apps that do name-based authorization, it's useful
to "canonicalize" realm names at the service (acceptors), and preferably
where possible at the client (kinit, pam_krb5, alike).

> I still see no advantage in introducing KREALM.  Just needlessly

Because of the middle-box problems, right?  Agreed.

Nico
--

---

From: Rick van Rein <[email-masked]>
Date: Thu, 17 Sep 2015 09:45:56 +0200

Hey,

I'm also moving over to the TXT-or-PTR side of things.  The middle boxes
are a concern and I'm hoping that one day clients will be able to do all
this; middle boxes will be quicker to pass DNSSEC than to pass KREALM.

1. In essence, the value added by my proposal is the use of DNSSEC, not
the KREALM RRtype per se.  The _kerberos prefix takes away my anxiety
over accidental interpretation of a PTR record as a Kerberos pointer and
potential security threats that this might have caused.

2. TXT can hold multiple <character-string> entries, but each has a
length of up to 255 characters for the infix-dot notation, and DNS names
in "length, label, ... zerolength" notation can reach up to 255 bytes. 
As far as I can see, this leads to infix-dot domains of up to 254
characters, so we can constrain our use of TXT to one such
<character-string> of up to 254 chars without constraining the size of a
stored domain name, thus avoiding interpretation / comparison /
buffer-overflow problems.

3. PTR limits our use cases to domain-style realm names.  This is not a
problem to me, as I'm mainly interested in DNS-based realm crossover for
which the other / older forms are not going to work anyway.  But I do
see that TXT will support the older / other domain styles as well.

4. PTR can mangle case, although it doesn't always do it.  Since we are
limiting to domain-style realm names, there can be two ways out exist,
and their benefits can be stacked up to achieve benefits for the
flexible party:
   4a. Permit the KDC to use case-insensitive comparisons; more
generally, let it use the name-style to figure out what to do; X.509
attributes have their own case comparison and DNS does, too.  The latter
would give us case-insensitive comparisons.  If AD already does this,
then so much the better.  (I never considered to propose such major
changes!)
   4b. Permit the client to map the PTR outcome to uppercase, and
thereby match with 99% of the realms, even if the KDC is not supportive
of case mapping.

5. The current implementation of TXT does not take DNSSEC into account,
meaning that its existence is not going to be of as much use as we'd
like to think.  IOW, we'd still be imposing restrictions on KDCs,
probably in terms of their default settings.

6. As for i18n, we might use DNS' approach for it and let Kerberos
simply use the xn-- names internally.  I cannot imagine that this would
lead to different treatment of the names in the KDC.  As for end-user
tools, we could modify them to understand DNS i18n and print these names
in UTF-8.  Mindful of the potential problem of foreign-alphabet
lookalikes as we've also seen in URLs, we may not always be able to cope
with it by printing in multiple colours as was done for URLs, but in
case of mixed language subsets we might fall back to printing the xn--
style of names, clearly signalling to our users that something is the
matter.  In that notation, everyone can tell the difference between two
names.  This DNS-style use of i18n would be possible immediately and it
is easier to use with PTR than with TXT, since tools will interpret the
<domain-name> in PTR and not the <character-string> in TXT.

7. Something I don't know is whether and how the KDC distinguishes realm
name styles.  In the above I've assumed that it is tagged, and that end
user tools also get to see these tags.  If not, there might be a few
more problems lurking, and things to configure manually, with sane defaults.

I suppose KREALM is hereby history, so we would be making a choice
between TXT and PTR.  My vote is now on PTR, with the aforementioned
implications of i18n and making the KDC look at the realm's naming style
before it decides how to compare (or have per-realm configurable
comparison rules).  The break with implemented but never-standardised
TXT records is IMHO warranted because we are relying on DNSSEC which is
an extra responsibility for the KDC that goes beyond TXT anyway.

-Rick

---

From: Nico Williams <[email-masked]>
Date: Thu, 17 Sep 2015 14:40:51 -0500

> probably in terms of their default settings.

Well, no, the client can and should onlye use TXT RRs for this that have
been validated.  One could use TLSA RRs without DNSSEC -- it makes
little sense, but the point is that the same is true for TXT RRs for
host-to-realm lookups.

> simply use the xn-- names internally.  I cannot imagine that this would

This... is a large subject that we should not broach in this context.

That said (heh) I think the right answer is to consider DOMAIN-style
realm names as having multiple alias forms such that a) they are
case-insensitive (at least as to ASCII labels), b) A-labels are aliases
of the corresponding U-labels.  Clients and services should internally
canonicalize to up-cased Unicode forms wherever possible (with
configurable exceptions, as there are ASCII lower-case realm names in
production use) for name-based authorization compatibility reasons.
Finally, we can then either bite the KerberosString bullet or leave it
for later by using A-labels in KerberosString domainname slots.

> name styles.  In the above I've assumed that it is tagged, and that end

By the presence/absence of ':' in the name.  No realm-type value is
explicitly encoded in any Kerberos PDU.

> more problems lurking, and things to configure manually, with sane defaults.

No problems lurk here, thankfully.

> an extra responsibility for the KDC that goes beyond TXT anyway.

TXT to Informational.  PTR to Proposed Standard.  That's my preference.

Nico
--