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

[Nico Williams <[e-mail]>]

On Mon, Sep 14, 2015 at 05:41:45PM +0200, Rick van Rein wrote:
> > Why call it KREALM if it can be used to find things other than Kerberos
> > realm names?
> 
> 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.

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.

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

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.

> > and
> > finally, expecting "[e-mail]" in GSS to become
> > HTTP/foo.example@EXAMPLE in Kerberos would fail on older
> > implementations, thus why would one?
> 
> I don't know what you are saying here; but can I assume the above dealt
> with it?

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

> > (For better or worse, GSS apps are now stuck using "HTTP" as the service
> > name for HTTP.)
> 
> 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

Why?

> deskop, on which you login with kinit, only to have your mail and file
> storage automatically mounted :)

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

> > (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.)
> 
> Hmm, ports and such are transport level issues... with KREALM I'm aiming
> 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.)

> >> 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 ...
> >
> > I guess you meant TLSA?
> >
> 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.

I still don't understand why not TLSA.

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

I don't understand this at all.

> >>  3. Kerberos node wants to find automatic validation information for a
> >>     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).
> 
> 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.

I don't think you need more use cases.

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

If it's generic then make it so.

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

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.

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