Question about dns_lookup_realm and domain_realm

[Jeffrey Altman]

Simo Sorce wrote:
>> There are several issues here.  First, DNS TXT records are known to be 
>> insecure.
>
> Jeff,
> this statements is interesting, how are TXT records "insecure" ?
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 not
added to RFC 4120 as the DNS SRV records portion was.

http://tools.ietf.org/html/draft-ietf-krb-wg-krb-dns-locate-03
>
>>   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.
>
> 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 trustworthy
>> whereas 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 ?
If the host name resolves to a different IP address, the authentication 
will fail.
>
>> 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.
>
> Do we have information on which clients support referrals ?
> And are they implemented in MIT KDC (and how) ?
>
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.

http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-referrals-10.txt

Jeffrey Altman

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20080627/d8af7878/attachment.bin