[linux-cifs-client] Re: [PATCH] Add support for using server supplied principal (mic option)

[simo]

On Mon, 2008-08-25 at 14:05 +1000, Andrew Bartlett wrote:
> On Sun, 2008-08-24 at 23:58 -0400, simo wrote:
> > On Sun, 2008-08-24 at 23:49 -0400, simo wrote:
> > > On Mon, 2008-08-25 at 02:38 +0100, Love Hörnquist Åstrand wrote:
> > > > 25 aug 2008 kl. 02.25 skrev Jeff Layton:
> > > > 
> > > > > Everything I've read does say that windows clients don't use the
> > > > > contents of the MIC field. The idea was that this would be useful for
> > > > > allowing kerberos auth in situations where clients and servers have
> > > > > differing ideas about the hostname of the server (either broken DNS or
> > > > > maybe trying to mount a CNAME).
> > > > 
> > > > Semi modern windows servers doesn't put a hostname there, so it wont  
> > > > be much use either.
> > > > 
> > > > Windows just assume if you can look up the name, the same name will be  
> > > > in the SPN in the ldap.
> > > > 
> > > > > I'll confess though that I haven't thought through the security
> > > > > implications fully here. Obviously, we don't want to do this if it's
> > > > > dangerous...
> > > > >
> > > > > So that I understand correctly, what exactly is the risk of using the
> > > > > server-provided principal?
> > > > 
> > > > You try to connect to host/my.secrets.com at GOOD.COM, but since the host  
> > > > announces
> > > > host/will.fake.your.data.secrets.com at GOOD.COM you'll use that instead  
> > > > and never notice that you talk to wrong host.
> > > 
> > > Love,
> > > this would be true if we used the name returned to connect to a
> > > different host.
> > > But we only do use it to get a ticket, we do not use the name to resolve
> > > an IP to which to connect as we are already connected to the host.
> > > 
> > > Now, assuming the connection is already established, what would be the
> > > risk if the server is telling us the wrong name? The ticket we get from
> > > the KDC (after the connection is established) will work only if the
> > > server we are connected to actually has the corresponding keytab.
> > > 
> > > Is there an attack vector that could be used here if the ticket we try
> > > to use is not in fact the one we should use ?
> > 
> > Uhmm, I should have thought a bit more, what you are saying is that a
> > user may be fooled (for example through DNS poisoning) to connect to
> > will.fake.your.data.secrets.com instead of my.secrets.com, because we
> > use the returned name to fetch the ticket, we will not "know" as users
> > that the server we are actually connected to is not the right one,
> > although it must obviously have been a trusted (by the KDC) one at some
> > point.
> > 
> > This could be used by a compromised host to get access to data that we
> > think should be stored only on my.secrets.com
> 
> Yep.
> 
> > Given this reasoning, I agree this is indeed a security issue. If we
> > want to enable this behavior it must be optional and the users must be
> > warned in the documentation of the risks that activating such behavior
> > would imply.
> 
> Indeed, and we should also remove this behaviour from the current Samba3
> smb client and winbindd.  I've not dared to suggest this in the past,
> because changing this *will* break some existing sites, but I am very
> worried to see this added to a new tool. 
> 
> That sai, Samba4 has never used the supplied principal name, except by
> the administrator (or test script) specifying an option.

We should add an option to turn this behavior off, and make it default
to off for 3.3, can you add it ?

> > Now assuming we cannot use this mechanism, what would you suggest as the
> > recommended way to get the right ticket in the case the SPN is not
> > immediately evident ?
> 
> You should use the netbios name or DNS name the client specified.  If
> they use an IP address, then kerberos authentication is not available
> (as it is not in windows). 

Fair enough.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Senior Software Engineer at Red Hat Inc. <simo at redhat.com>