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

[Rick van Rein <[e-mail]>]

Hi Nico,

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

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

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

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

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

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