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

[Andrew Bartlett]

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.

> 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). 

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/linux-cifs-client/attachments/20080825/7ccdbdc9/attachment.bin