[2291] in Kerberos_V5_Development
Re: ["Tony Mione" ] DNS lookups for Host Realm information
daemon@ATHENA.MIT.EDU (Theodore Y. Ts'o)
Fri Mar 7 15:24:33 1997
Date: Fri, 7 Mar 1997 15:22:12 -0500
From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: Ezra Peisach <epeisach@MIT.EDU>
Cc: Sam Hartman <hartmans@MIT.EDU>, krbdev@MIT.EDU
In-Reply-To: Ezra Peisach's message of Fri, 07 Mar 1997 13:52:29 EST,
<9703071852.AA06380@kangaroo.mit.edu>
Cc: krbdev@MIT.EDU
Date: Fri, 07 Mar 1997 13:52:29 EST
From: Ezra Peisach <epeisach@MIT.EDU>
I believe, although I cannot prove it, that if I can spoof a DNS packet
and fool a host into believing it is a host in my locally administrated
kerberos realm that I could probably break in by fooling login.krb5 to
talking to me for the initial TGT. If memory serves correctly, this
would be sufficient to break into a machine (assuming the machine in
question does not have a keytab).
So, some information in a configuration file is critical, but how much?
As mentioned above, I think realm info is. How about the name of the
servers - is this really critical, or can DNS provide it in an adequate
way?
Note that as long as DNS is insecure, you can always spoof the A record
for the Kerberos servers; hence you might as well provide the location
of the Kerberos servers via the DNS. The worst you can do is a denial
of service attack.
With login.krb5 and ksu, which attempt to validate the kerberos
password, there is a concern, and that's where you need to keep the "my
local realm" information correct, so that login.krb5 and ksu know which
key to find from the keytab.
How about this as a straw man --- to find the local realm, try to look
in the following ordered list of places:
krb5.conf
The realm of the first key in /etc/krb5.keytab (assuming that
you can read the keytab file)
From the DNS
--------------------------------------
The other set of information which you might want to get from the DNS is
configuration rules which map a DNS name to a realm. The risk of
getting this information from an insecure source is that an attacker who
controls one of the realms which you have exchanged a cross-realm key
might be able to spoof the mutual authentication of a service that you
are trying to authenticate to.
That is, suppose MIT.EDU has cross-realm keys with CAST.COM and
CLIPPER.GOV. While I'm trying to authenticate to a server
good-guy.cast.com, the attacker (who controls CLIPPER.GOV) spoofs the
DNS/Kerberos realm mapping rules so that my client program gets
cross-realm keys for service/good-guy.cast.com@CLIPPER.GOV, instead of
service/good-guy.cast.com@CAST.COM. The attacker can then intercept the
connection and spoof who the client program thinks that it is talking
to.
Of course, if you have secure DNS installed all of these problems go
away....
- Ted
