Jos Backus wrote:
On Fri, Jun 27, 2008 at 01:57:37AM -0400, Jeffrey Altman wrote:
There are several issues here. First, DNS TXT records are known to be insecure. Turning them on for use in realm resolution provides for convenience but at the risk that your clients
can be redirected to a realm that you do not control.
Understood.

Second, any domain_realm mapping for your domain .foo.com is going to override the use of DNS lookups. That is because local configuration data is considered to be trustworthy
whereas DNS lookups are not.
That's something my patch changes as it performs the DNS lookup first (when
configured).
Which in turn would disable Kerberos referrals.

In the case of two realms, PROD.FOO.COM and DEV.FOO.COM some of your hosts are in one and some are in the other. By default you want PROD.FOO.COM to be used. However, for specific hosts you want DEV.FOO.COM. Using the config file you would
specify

[domain_realm]
  devhost1.foo.com = DEV.FOO.COM
  .foo.com = PROD.FOO.COM

Yup, tried that, works, but doesn't scale well.
There is a serious need for the zero configuration solution for Kerberos deployments. Of course, DNS is insecure so relying on DNS to boot strap your authentication system is undesirable. That is not to say it has not been used but only because there have
been no other choices.

If you want to rely on DNS TXT records you have to make sure that there are no mappings
in the config file.  Then you would create records for

  _kerberos.devhost1.foo.com IN TXT DEV.FOO.COM
  _kerberos.foo.com IN TXT PROD.FOO.COM

Okay. We have the former (obviously) but not the latter. I can add that.

Because DNS TXT records are insecure and there is a need to be able to provide for centralized configuration data Microsoft created the Kerberos referrals mechanism. Using referrals a client asks the KDC belonging to the TGT realm for a referral to the correct realm for the desired service principal. Referrals are used whenever there is not a local [domain_realm] mapping.
So this implies two-way trust and communication, yes? I wonder if this will
require network/ACL changes.
For referrals to work the user must have already obtained a TGT. If you are trying to decide which identity a user should obtain a credential for based upon the host that the user is going to communicate with, that is not something that will be solved by referrals. To be honest, I don't think it will be solved by domain_realm mappings whether stored
locally or in DNS.

The safe way to add DNS TXT records back into the equation would be to add the DNS TXT
lookup after the referrals request fails.

ISTR that's where krb5_get_fallback_host_realm() is called, from a comment in
the code. Now it's clear why although I still don't quite grok the referral
mechanism. Time to study the documentation.

Thanks for the critique and helpful information, Jeffrey.

No problem.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to