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

[Ken Raeburn]

On Jan 14, 2008, at 16:57, Srinivas Kakde wrote:
> Hello,
>
> There is an old posting to samba-technical
>
> http://lists.samba.org/archive/samba-technical/2007-July/054354.html
>
> This message says: From a security standpoint, allowing the server  
> to specify its
> service principal is a "bad idea".
>
> Why it a bad idea?

Basically, you're no longer authenticating the server as the entity  
you want to talk to, merely as the entity it says it is.  Consider:

I type in "ftp foo.bar.com".

An attacker intercepts my TCP connection establishment, spoofs a DNS  
reply, brings up a system on foo's address while it's down for some  
reason, or otherwise gets me to connect to a box that isn't foo.bar.com.

If, at this point, I let the server tell me what name to authenticate  
to, it may say quux.bar.com.  So, I ask my KDC for credentials to  
authenticate me to quux.bar.com; it gives them to me, and I  
authenticate to the server.

So now I'm connected to, and have authenticated to, a server that is  
not the one I specified.

If I'm not monitoring an interactive session carefully, but am  
running some GUI that connects, fetches (or deletes) a file, and  
disconnects, I may never see anything that would tell me something  
went wrong.  So I may delete file X from the wrong system, fetch the  
wrong version of a file, etc.

I may use a bogus account set up in my name by someone who  
compromised a machine (which may not even be in the same company,  
thanks to cross-realm authentication, and possibly someday PKCROSS),  
or I may just be redirected to one of my accounts that I didn't want  
to use for the operation.

If you use the name as supplied by the user (or as retrieved securely  
from a trusted source), it's not such a problem, if the protocol is  
designed right.  (If you just send an authenticator, and then conduct  
the rest of your session in the clear with no protection, it's still  
not much better than not authenticating at all, even if you use the  
requested-server name.  A compromised system could just discard the  
authenticator and say "okay, you're logged in".)

There's a proposal at the IETF (draft-ietf-kitten-gssapi-domain-based- 
names) which would help address this, by letting you specify in the  
server principal name both the hostname providing the service *and* a  
user-supplied domain name for the service.  It does require that the  
KDC have more information about which services are provided by which  
hosts, but better supports services where there may be multiple  
providing hosts and they may be looked up by insecure means (e.g.,  
you get back three DNS SRV records from your nameserver, and you're  
not using DNSSEC).  However, the proposal isn't finalized yet.

Ken