Simo Sorce wrote:
I will refer you to the security considerations section of the internet draft. Note that the insecurity is one reason that the TXT record portion of the draft was notThere are several issues here. First, DNS TXT records are known to be insecure.Jeff, this statements is interesting, how are TXT records "insecure" ?
added to RFC 4120 as the DNS SRV records portion was. http://tools.ietf.org/html/draft-ietf-krb-wg-krb-dns-locate-03
If the host name resolves to a different IP address, the authentication will fail.Turningthem on for use in realm resolution provides for convenience but at the risk that your clientscan be redirected to a realm that you do not control.You can do the same with DNS poisoning, if you do not trust DNS any name resolution becomes "insecure". Isn't "validation" all about verifying the KDC is one we can really trust by using a trusted secret ?
If the host name resolves to a different IP address, the authentication will fail.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 trustworthywhereas DNS lookups are not.How is local configuration data trustworthy given that to resolve names to IPs we still rely on DNS ? Or do you also rely on /etc/hosts for most of the data ?
Heimdal, MIT, and Microsoft support referrals as implemented in Windows Active Directory. The IETF Kerberos working group is still working on an RFC for referrals.The safe way to add DNS TXT records back into the equation would be to add the DNS TXTlookup after the referrals request fails.Do we have information on which clients support referrals ? And are they implemented in MIT KDC (and how) ?
http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-referrals-10.txt Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
