Is "SPN advertisement" or well-known SPNs a security hole?

[Srinivas Kakde]

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 at SECURE-ENDPOINTS.COM.  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 to 
> 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
 authenticate 
> to "host/johns-machine.secure-endpoints.com at SECURE-ENDPOINTS.COM".
  This 
> authentication is going to succeed but you are not connected to the
 host 
> 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