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

[Nico Williams <[e-mail]>]

On Mon, Sep 14, 2015 at 10:35:54AM +0200, Rick van Rein wrote:
> 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"

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 "[e-mail]" 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.

> example.com. IN KREALM "realm" "EXAMPLE.COM"
> example.com. IN KREALM "admin" "john/[e-mail]"
> 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 ...

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

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

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

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?

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

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