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@xxxxxxxxx> Principal Software Engineer at Red Hat, Inc. <simo@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
