Re: Is "SPN advertisement" or well-known SPNs a security hole?
- From: Srinivas Kakde <srinivas.kakde@xxxxxxxxx>
- Date: Wed, 16 Jan 2008 13:32:23 -0800 (PST)
Jeffrey wrote:
For example, if you are trying to authenticate to the ftp server at
ftp.secure-endpoints.com you should be asking for the shared secret for
host/ftp.secure-endpoints.com@xxxxxxxxxxxxxxxxxxxxx But what if you
didn't ask for that but instead waited for the server to give you a
name. Let's say that there is a user "john" who has a personal machine
keyed by the SECURE-ENDPOINTS.COM realm and he is able to get you toauthenticate
connect to his machine by spoofing DNS or some other means. You have
now connected to johns-machine.secure-endpoints.com but think you are
connected to ftp.secure-endpoints.com and john tells you to
to "host/johns-machine.secure-endpoints.com@xxxxxxxxxxxxxxxxxxxx".This
authentication is going to succeed but you are not connected to thehost
you wanted to connect to.
Thank
you. This is a good response. I see how this is a problem. Now I
think this is what Russ Allbery and Todd Stecher were talking about in
their responses too. It also makes me think more about the important
relationship between the system that supplies binding information
(network address, port, etc) used by the client to connect to the
server and the Kerberos service principal name used in the mutual
authentication.
In Jeffrey's example, the client locates the
service using the DNS name. For DNS there are translated algorithms to
derive principal name and realm. But I don't think these algorithms a
normative or required by Kerberos. It is good thing too because there
are environments such as SOA where users of client applications do not
know the DNS name of the servers. Instead, client applications locate
services by capability with out requiring the user to supply IP address
or DNS names. I do not think that location of services by capability
or characteristics a new problem and there are many solutions. LDAP
is one such solution.
I
think there must be equivalence between permission required create a
principal on
a KDC and the permission required associate the service principal name
with network binding information. I think this is an interesting area
of study. Does anyone on the Kerberos list have a paper, web site, or
study that talks about such security rules for service location that
includes Kerberos service principal name returned as part of the
returned network binding information, or derived from from network
binding information?
There are other scenarios as well. Since the realm you contact is
determined by the domain name of the host, if the server tells you to
authenticate to ftp.compromised.com, the attacker can convince you to
authenticate using a compromised KDC that might be accessible via a
cross-realm relationship.
OK.
However, I do not think that this scenario is such a big concern as the
first example. I think the foundation of Kerberos
security is based on security of KDCs and cross realm relationships.
Attacker that is able obtain control of a KDC or cross-realm keys will
be able to cause very serious problems regardless of the mechanism used
by clients to select principal names. In contrast, the attack in
first example, could be attempted by anyone with a valid Kerberos
account.
____________________________________________________________________________________
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
.
- Prev by Date: Possibility of not creating host principals and keytabs for Workstations
- Next by Date: Re: Possibility of not creating host principals and keytabs for Workstations
- Previous by thread: Re: Is "SPN advertisement" or well-known SPNs a security hole?
- Next by thread: Re: Is "SPN advertisement" or well-known SPNs a security hole?
- Index(es):
Relevant Pages
|
