What are the issues with dns_lookup_realm ?
Brian Candler
http://web.mit.edu/Kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Mapping-Hostnames-onto-Kerberos-Realms
it says:
"The second mechanism [for mapping hostnames onto Kerberos realms] works by
looking up the information in special TXT records in the Domain Name
Service. This is currently not used by default because security holes could
result if the DNS TXT records were spoofed"
Can you point me to further information on what these security issues are,
and how big a risk they might pose, so as to be able to make an informed
judgement as to whether to turn this on?
Let's say I have a user on workstation pc.foo.example.com, who wants to
ssh to server.bar.example.com. Both are in realm EXAMPLE.COM, and I declare
this in the DNS using
example.com. IN TXT "EXAMPLE.COM"
Both machines have dns_lookup_realm = true and default_realm = EXAMPLE.COM
in krb5.conf
(1) What DNS lookups are made by the workstation and/or the server when a
connection takes place?
(2) Could any of the DNS responses take precedence over the default_realm
specified in the config file for either the client or the server? (*)
(3) What's the worst that could happen if someone managed to insert a
spoofed TXT record in one of the responses?
(4) Kerberos also relies on reverse DNS to map IP address to hostname (and
hence to realm, either by domain_realm rules or by another DNS lookup). Are
the security issues with dns_lookup_realm any more severe than those already
inherent in IP to hostname lookups?
Thanks,
Brian Candler.
(*) The documentation for default_realm is unclear. It says:
"If this is not specified and the TXT record lookup is enabled (see Using
DNS), then that information will be used to determine the default realm"
which implies to me that the TXT record *won't* be looked up if you define
default_realm, even if dns_lookup_realm is true.
However, experimentation suggests that if I have dns_lookup_realm = true,
and I omit the TXT record from the DNS, then authentication doesn't work.
This is with krb5 1.3.4 from CentOS 4.6 and 4.4
Greg Hudson
> (1) What DNS lookups are made by the workstation and/or the server when a
> connection takes place?
pc.foo.example.com looks up a TXT record for
_kerberos.server.bar.example.com.
> (2) Could any of the DNS responses take precedence over the default_realm
> specified in the config file for either the client or the server? (*)
Yes. The precedence order of domain-relam mappings is:
1. krb5.conf domain_realms
2. KDC referrals
3. DNS TXT lookups, if turned on
4. The domain heuristic, if turned on
5. The upper-cased parent realm of the hostname
6. The default realm, if the hostname has no parent realm
So the default realm is actually not used in very many cases.
The "domain heuristic" is configured by setting [libdefaults]
realm_try_domains = N for some integer N, and involves trying to resolve
the hostname and N realm ancestors of it as Kerberos realms.
> (3) What's the worst that could happen if someone managed to insert a
> spoofed TXT record in one of the responses?
By spoofing a TXT reply, someone could cause you to use
host/server.bar.example.com@ATTACKER-REALM service tickets instead of
the correct tickets. The attacker will presumably also spoof the IP
address of the server. The client then successfully mutually
authenticates to the wrong host, and perhaps forwards credentials there
or enters a password, compromising the user's account.
For this attack to succeed, ATTACKER-REALM needs to be a realm which the
client can perform cross-realm authentication to.
If the domain heuristic is used instead of TXT records, there is the
potential for a similar attack if DNS lookups are enabled for KDC
resolution (which is the default), but the attack is limited to
ATTACKER-REALM values equal to ancestor domains of the server hostname.
> (4) Kerberos also relies on reverse DNS to map IP address to hostname (and
> hence to realm, either by domain_realm rules or by another DNS lookup). Are
> the security issues with dns_lookup_realm any more severe than those already
> inherent in IP to hostname lookups?
The issues are not substantially different, no. We'd like to get away
from DNS canonicalization and have some plans to do so (basically, a KDC
configuration option determined at initial authentication time which
means "rely on KDC referrals instead of host canonicalization").
> (*) The documentation for default_realm is unclear. It says:
>
> "If this is not specified and the TXT record lookup is enabled (see Using
> DNS), then that information will be used to determine the default realm"
>
> which implies to me that the TXT record *won't* be looked up if you define
> default_realm, even if dns_lookup_realm is true.
The misunderstanding here is that "the default realm" is not the default
for host-to-realm mappings. It's the default for parsing principal
names which don't contain realms--for example, if you "kinit bcandler"
instead of "kinit bcan...@EXAMPLE.COM".
The documentation is saying that you can use TXT records to determine
the default realm instead of configuring it explicitly on each client.
Of course, that allows an attacker to control a client's default realm,
which has some security implications (although fewer than you'd think,
since initial authentications won't succeed if you don't know a user's
password).
Greg Hudson
> 4. The domain heuristic, if turned on
I should have noted that the domain heuristic was added in MIT krb5 1.7,
which may be newer than the version on your client hosts.
Brian Candler
> On Mon, 2010-10-04 at 07:01 -0400, Brian Candler wrote:
> > (1) What DNS lookups are made by the workstation and/or the server when a
> > connection takes place?
>
> pc.foo.example.com looks up a TXT record for
> _kerberos.server.bar.example.com.
OK, that makes sense. The server doesn't care anything about the hostname/IP
of the client, as the client has already authenticated into a particular
realm. But the client has to work out which realm the server belongs to,
and to trade tickets as necessary to prove its identity to the server in
another realm.
Which brings me to an aside: does this mean that all communication is
initiated by the client to each KDC, except for the final server to its KDC?
There's no KDC to KDC traffic? I'm particularly interested whether I can
make the following scenario work with a NAT/PAT firewall:
NAT>
+-+
client ----------------> | | ----------------> server
| |
| |
KDC for | | KDC for
FOO.EXAMPLE.COM | | BAR.EXAMPLE.COM
+-+
If the communication goes
client -> KDC FOO
client -> KDC BAR
server -> KDC BAR
then I think it should work. I'll need a more complex testbed to try it out
though :-)
> By spoofing a TXT reply, someone could cause you to use
> host/server.bar.example.com@ATTACKER-REALM service tickets instead of
> the correct tickets. The attacker will presumably also spoof the IP
> address of the server. The client then successfully mutually
> authenticates to the wrong host, and perhaps forwards credentials there
> or enters a password, compromising the user's account.
>
> For this attack to succeed, ATTACKER-REALM needs to be a realm which the
> client can perform cross-realm authentication to.
Many thanks for your clear and detailed explanation.
Regards,
Brian.
Jeffrey Altman
> On Mon, Oct 04, 2010 at 12:57:17PM -0400, Greg Hudson wrote:
>> On Mon, 2010-10-04 at 07:01 -0400, Brian Candler wrote:
>>> (1) What DNS lookups are made by the workstation and/or the server when a
>>> connection takes place?
>>
>> pc.foo.example.com looks up a TXT record for
>> _kerberos.server.bar.example.com.
>
> OK, that makes sense. The server doesn't care anything about the hostname/IP
> of the client, as the client has already authenticated into a particular
> realm. But the client has to work out which realm the server belongs to,
> and to trade tickets as necessary to prove its identity to the server in
> another realm.
>
> Which brings me to an aside: does this mean that all communication is
> initiated by the client to each KDC, except for the final server to its KDC?
> There's no KDC to KDC traffic?
there is no server to kdc traffic. it is all client to kdc.
> I'm particularly interested whether I can
> make the following scenario work with a NAT/PAT firewall:
>
> NAT>
> +-+
> client ----------------> | | ----------------> server
> | |
> | |
> KDC for | | KDC for
> FOO.EXAMPLE.COM | | BAR.EXAMPLE.COM
> +-+
>
> If the communication goes
> client -> KDC FOO
> client -> KDC BAR
> server -> KDC BAR
> then I think it should work. I'll need a more complex testbed to try it out
> though :-)
>
client->server
client -> KDC FOO
client -> KDC BAR
client -> server
Brian Candler
>
> 1. krb5.conf domain_realms
> 2. KDC referrals
> 3. DNS TXT lookups, if turned on
> 6. The default realm, if the hostname has no parent realm
>
> So the default realm is actually not used in very many cases.
FWIW, I just had a very odd situation with mod_auth_kerb, which appears to
be related to chosing a realm.
It was all working fine with true kerberos authentication (*):
<Location /testapp>
AuthName "Hello Kerberos World"
AuthType Kerberos
# Allow fallback to Basic Auth?
KrbMethodK5Passwd Off
KrbAuthRealms IDM.EXAMPLE.COM
Krb5Keytab /etc/httpd/conf/krb5.keytab
require valid-user
</Location>
But when I tried to add fallback to Basic Auth (KrbMethodK5Passwd On) for
non-Kerberos users, no usernames/passwords were being accepted. This was
odd because mod_auth_kerb only needs to authenticate as the user principal,
which normally can happen from any host - even when the client IP/hostname
doesn't itself map to any realm.
The error message from /var/log/http/ssl_error_log was unhelpful:
[Mon Oct 11 11:20:17 2010] [error] [client 172.31.131.185] krb5_verify_init_creds() failed: Key table entry not found
What was even more odd, if I did a 'su' to the apache user, I was able to
'kinit' using one of the usernames/passwords which apache was rejecting as
Basic Auth credentials. Surely mod_auth_kerb should be doing the same??
I did find a solution in the end. krb5.conf has
[libdefaults]
default_realm = IDM.EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
The machine's primary name is uk1-sys-rds1.maint.example.com
and there is a DNS entry for this subdomain to map to a realm:
_kerberos.maint.example.com. TXT "IDM.EXAMPLE.COM"
However the clients were connecting to a virtual host
"rails.api.example.com" on that machine. The apache keytab file had service
principals for both HTTP/rails.api....@IDM.EXAMPLE.COM and
HTTP/uk1-sys-rds1.ma...@IDM.EXAMPLE.COM, just to be sure.
The change which made password authentication work was to add a DNS entry
for the api domain:
_kerberos.api.example.com. TXT "IDM.EXAMPLE.COM"
I tried tcpdumps of udp port 88 in both cases. Before the DNS addition,
there was a 4 packet exchange. After the DNS addition there was a much
longer exchange, but the first 4 packets seemed to have pretty much the same
contents.
The fact that adding the DNS record fixed things suggests that it was a
hostname-to-realm mapping issue. But I'd really like to know what principal
it was looking for when I got the "Key table entry not found" error message.
This particular Apache server is running CentOS 4.6 with only kerberos
1.3.4, so perhaps a newer version would have given a better error message.
Regards,
Brian.
(*) That is: using Chrome where I had started it with
/opt/google/chrome/google-chrome --auth-server-whitelist=*.example.com
and with Firefox where I had gone to about:config and set
network.negotiate-auth.trusted-uris example.com
Christopher D. Clausen
> The error message from /var/log/http/ssl_error_log was unhelpful:
>
> [Mon Oct 11 11:20:17 2010] [error] [client 172.31.131.185]
> krb5_verify_init_creds() failed: Key table entry not found
>
> What was even more odd, if I did a 'su' to the apache user, I was able to
> 'kinit' using one of the usernames/passwords which apache was rejecting as
> Basic Auth credentials. Surely mod_auth_kerb should be doing the same??
There is more to it than just a kinit, unless you have KrbVerifyKDC off
which you shouldn't b/c it can be a security problem. Mod_auth_kerb is just
blindly trusting that ANY successful Kerberos reply comes from your KDC with
this turned off. When it is on, it uses its keytab to verify that the KDC
that responded is legit and not one an attacher setup.
> [snip]
> The fact that adding the DNS record fixed things suggests that it was a
> hostname-to-realm mapping issue. But I'd really like to know what
> principal
> it was looking for when I got the "Key table entry not found" error
> message.
The requested service principal name would likely be logged on the KDC when
apache tries to authenticate users and produces this message.
<<CDC
Brian Candler
> >What was even more odd, if I did a 'su' to the apache user, I was able to
> >'kinit' using one of the usernames/passwords which apache was rejecting as
> >Basic Auth credentials. Surely mod_auth_kerb should be doing the same??
>
> There is more to it than just a kinit, unless you have KrbVerifyKDC
> off which you shouldn't b/c it can be a security problem.
> Mod_auth_kerb is just blindly trusting that ANY successful Kerberos
> reply comes from your KDC with this turned off. When it is on, it
> uses its keytab to verify that the KDC that responded is legit and
> not one an attacher setup.
That makes a lot of sense.
> The requested service principal name would likely be logged on the
> KDC when apache tries to authenticate users and produces this
> message.
Good point. Unfortunately, in this particular scenario, the KDC is Windows
AD (which I have little visibility of, nor desire to learn :-) But in any
case, I did capture the packets going to/from the KDC, and saw the username
and expected (user's) realm in them.
But following your explanation above, I guess something like this is
happening:
- mod_auth_kerb tries to find realm for rails.api.example.com
(the virtual server hostname), via DNS lookups
- mod_auth_kerb fails to find one
- mod_auth_kerb looks for something duff like "HTTP/rails.api.example.com@"
in its keytab, and fails
That would explain the error message seen. I was expecting default_realm to
be used, but as Greg already told me at
http://mailman.mit.edu/pipermail/kerberos/2010-October/016586.html
''The misunderstanding here is that "the default realm" is not the default
for host-to-realm mappings. It's the default for parsing principal
names which don't contain realms--for example, if you "kinit bcandler"
instead of "kinit bcandler at EXAMPLE.COM".''
Maybe it would be cleaner if the client code failed immediately when asked
to map a host to a realm but was unable to? An error like "unable to find
realm for host 192.0.2.1 (rails.api.example.com)" would have been easier for
me to interpret.
Regards,
Brian.
Brian Candler
> Which brings me to an aside: does this mean that all communication is
> initiated by the client to each KDC, except for the final server to its KDC?
> make the following scenario work with a NAT/PAT firewall:
>
> NAT>
> +-+
> client ----------------> | | ----------------> server
> | |
> | |
> KDC for | | KDC for
> FOO.EXAMPLE.COM | | BAR.EXAMPLE.COM
> +-+
For the benefit of the list, I have set this up and it seems to work fine. I
am using vmware server. Getting the above scenario to work just involved
changing client and kdc.foo.example.com to a 'NAT' interface while
kdc.bar.example.com has a 'bridged' interface with its own IP.
* On client, do 'kinit' (gets ticket for cand...@FOO.EXAMPLE.COM)
* On client, ssh to kdc.bar.example.com
* Cross-realm authentication works fine
I did some tcpdump testing.
When I do initial kinit: I see an exchange from client to kdc.foo only.
When I initiate ssh connection: apart from port 22 traffic I see
* kerberos exchange from client to kdc.foo
* reverse dns lookup on kdc.bar [probably sshd / tcp_wrappers]
* kerberos exchange from client to kdc.bar
kdc.bar doesn't have any /etc/hosts entry for the NAT external IP, so
doesn't seem to need it.
Regards,
Brian.
Greg Hudson
> - mod_auth_kerb tries to find realm for rails.api.example.com
> (the virtual server hostname), via DNS lookups
> - mod_auth_kerb fails to find one
> - mod_auth_kerb looks for something duff like "HTTP/rails.api.example.com@"
> in its keytab, and fails
I doubt it's actually failing. It's probably falling back to
API.EXAMPLE.COM as the best available heuristic; that happens to be the
wrong answer.
> ''The misunderstanding here is that "the default realm" is not the default
> for host-to-realm mappings. It's the default for parsing principal
> names which don't contain realms--for example, if you "kinit bcandler"
> instead of "kinit bcandler at EXAMPLE.COM".''
I'm actually a little surprised that mod_auth_kerb is doing a
host-to-realm lookup instead of just using the default realm for the
verification service principal. I guess in some virtual host settings,
that's desirable.
> Maybe it would be cleaner if the client code failed immediately when asked
> to map a host to a realm but was unable to? An error like "unable to find
> realm for host 192.0.2.1 (rails.api.example.com)" would have been easier for
> me to interpret.
The code could, I suppose, try to determine whether API.EXAMPLE.COM is
actually a Kerberos realm, and then fall back to the default realm.
That has its own pitfalls, though; if API.EXAMPLE.COM ever became a
realm (through SRV records, say), you'd get an unexpected behavior
change.
In any event, I've committed a change for 1.9 which would make the error
message from the keytab lookup more informative:
No key table entry found for HTTP/rails.api....@API.EXAMPLE.COM
Brian Candler
> On Mon, 2010-10-11 at 10:22 -0400, Brian Candler wrote:
> > - mod_auth_kerb tries to find realm for rails.api.example.com
> > (the virtual server hostname), via DNS lookups
> > - mod_auth_kerb fails to find one
> > - mod_auth_kerb looks for something duff like "HTTP/rails.api.example.com@"
> > in its keytab, and fails
>
> I doubt it's actually failing. It's probably falling back to
> API.EXAMPLE.COM as the best available heuristic; that happens to be the
> wrong answer.
Is that the "domain heuristic"? This machine has (RedHat's version of)
Kerberos 1.3.4, and I thought you said that capability was only introduced
recently.
In this case it would also give an invalid choice, because if it then goes
ahead to try to find a KDC for API.EXAMPLE.COM, it won't find one - neither
in DNS nor in [realms].
Which I guess is what you meant by this:
> The code could, I suppose, try to determine whether API.EXAMPLE.COM is
> actually a Kerberos realm, and then fall back to the default realm.
> That has its own pitfalls, though; if API.EXAMPLE.COM ever became a
> realm (through SRV records, say), you'd get an unexpected behavior
> change.
Yes, I agree it shouldn't fall back to the default realm. But it could fail
the hostname->realm lookup.
> In any event, I've committed a change for 1.9 which would make the error
> message from the keytab lookup more informative:
>
> No key table entry found for HTTP/rails.api....@API.EXAMPLE.COM
For this case that gives a much clearer message, thank you.
Regards,
Brian.
Greg Hudson
> Is that the "domain heuristic"? This machine has (RedHat's version of)
> Kerberos 1.3.4, and I thought you said that capability was only introduced
> recently.
No, it's not the domain heuristic, which is off by default anyway; it's
the next step after the domain heuristic, which is to use the parent
domain (uppercased) without trying to decide whether it's a real realm
or not.
Brian Candler
> No, it's not the domain heuristic, which is off by default anyway; it's
> the next step after the domain heuristic, which is to use the parent
> domain (uppercased) without trying to decide whether it's a real realm
> or not.
So you'd only ever fall back to default_realm if the host doesn't have a
FQDN at all?
Greg Hudson
That's correct.
nagaraj...@gmail.com
dns_lookup_realm = true difference between dns_lookup_realm = false