On 2007-07-03 20:28, Joe Orton wrote:
> On Tue, Jul 03, 2007 at 08:41:32AM -0500, Alec Kloss wrote:
> > Can we be cautious about implementing DNS-based SPN canonicalization?
> How can it be avoided, though? If this is what the GSSAPI libraries do,
> then it's a de facto standard; changing it would be an interop problem.
> (as is being demonstrated by the behaviour of the SSPI implementation)
I guess I'll show my spots, but I don't (or at least didn't) want
to get into a long discussion of c14n. I'm of the opinion the DNS
canonicalization is a disaster for security for reasons discussed
in email thread I mentioned. Personally I've found it's a disaster
for operability since lots of systems have erratic reverse DNS,
wierd (or missing) cross-realm relationships and other oddness. I
don't see a way to make DNS canonicalization work with virtual
hosting across multiple krb realms. Imagine I'm virtual-hosting
for companyA and companyB on the same IP address. DNS
canonicalization means I can only do GSSAPI/SSPI for one company
and not the other.
Unfortunately, putting a client-side knob in Neon doesn't really
help much because then I need to explain to people what to set and
why, and if they need canonicalization for other sites... yikes.
I'm not sure about how I feel about this, but we could *abuse* the
HTTP authentication realm to include a hint for neon about
canonicalization... it's 100% gross... but so's DNS.
FYI, Yves, the null dereference in Tortoise/SVN/neon has already
been fixed in Neon's trunk (thanks Joe). Revs 1161 and 1093.
In 0.26.3, it's lines 1213-1214. SSPI seems to work with
mod_auth_kerb after that, but I've got something running around
linking both msvcr80d.dll and msvcr80.dll which seems to kill svn
later on... still working on it.
Alec Kloss alec@xxxxxxxxxxxxxxxxxx IM: angryspamhater@xxxxxxxxx
PGP key at http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA241980E
The mountain called Monkey had spoken. There was only fire. -Gorillaz
neon mailing list