[RFC/PATCH] cifs.upcall: use kernel.provided principal name if available

[simo]

On Thu, 2011-09-08 at 15:13 +0200, Martin Wilck wrote:
> Doesn't work, sorry. Actually, it doesn't seem to make any difference
> in
> my setup. In my scenario, cifs.upcall would be able to infer the
> correct
> SPN with the following algorithm:
> 
>  - get the IP address using DNS
>  - get the "real" server FQDN using RDNS
>  - use "cifs/<hostname portion of the "real" FQDN>" as SPN

If cifs does an explicit PTR resolution than that is probably a bug and
should be fixed.

> Thus RDNS might indeed be beneficial here (but "rdns = true" makes no
> difference, either).
> 
> OTOH, from the security point of view, this algorithm might not be
> more
> secure than the server-provided SPN, because the attack scenario
> assumes
> that DNS and/or general network packet transmission is already
> hijacked.

DNS being hijacked is not an issue. The issue is thinking you are
connecting to server A and instead ending up with connecting to B

If DNS is hijacked so the A points to B's ip address you still ask for a
ticket for A and that's what you get from the KDC. When then ou try to
auth to B with A's ticket, all breaks down.

Instead if you trust what B says its name is, then you would get a
ticket for B and auth will continue properly.

So a user that wanted to contact server A ends up contacting servr B and
may not notice.

Now reply A with topsecret.agency.gov and B with public.agency.gov and
you understand why that is an issue.

> The question remains: what are the windows clients doing to overcome
> this situation?

They delegate a lot of name resolution to the KDC, in particular they
let the KDC do the name canonicalization instead of doing it on their
own.

Simo.

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