[linux-cifs-client] Handling Kerberos principals that don't match hostnames

[Jeff Layton]

On Thu, 7 Jan 2010 16:11:55 -0700
Doug Kelly <dougk at dougk-ff7.net> wrote:

> On Thu, Jan 07, 2010 at 04:30:17PM -0500, Jeff Layton wrote:
> > The CIFS client doesn't currently do mutual krb5 authentication but
> > eventually it would be nice if it did.
> > 
> > The problem with any scheme that relies on getting the SPN in this way
> > is that it leaves you open to DNS spoofing attacks even if you can
> > support mutual authentication.
> 
> That's true... I actually stumbled upon the debate on the mailing list
> about a year ago about using Server 2003's SPN provided with the SPNEGO
> setup, and it makes sense.  In fact, even from Windows hosts, it appears
> the Kerberos authentication fails, and it falls back to NTLMSSP.
> 
> Correct me if I'm wrong, but doesn't the current method of operation
> that cifs.upcall rely on this?  I guess the difference in expecting a
> server's response to contain the real hostname leaves you open for a
> man-in-the-middle attack, though, since another host could potentially
> spoof the user to connect to a malicious host.
> 
> Anyway, not to bring up that whole debate again, but this would be
> something that I'd find beneficial, simply because it'd allow me to
> Kerberize the entire process of mounting the users' home directories.
> I can't see how it'd weaken the security any more than what already
> happens with DFS referrals, either.
> 

By default the kernel and cifs.upcall just use the hostname portion of
the UNC as the SPN. The preferred scheme is to add service principals
for every possible hostname and put those in the server's keytab.
I believe that Windows does this for unqualified hostnames, for
instance.

Very recent versions of cifs.upcall support a --trust-dns flag that
will do a reverse lookup to get a SPN. It's not really recommended to
use that, but it may help in your case.

-- 
Jeff Layton <jlayton at samba.org>