neon@webdav.org
[Top] [All Lists]

Re: [neon] Win32 SSPI Negotiate authentication with virtualhost/multi-ho

Subject: Re: [neon] Win32 SSPI Negotiate authentication with virtualhost/multi-homed
From: "Yves Martin"
Date: Wed, 04 Jul 2007 14:56:07 +0200
On Tue, 2007-07-03 at 17:36 -0500, Alec Kloss wrote: 
> 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.

For the moment, I image one server with multiple services published
thanks to different virtual hosts. In that case, a Unix client using
GSSAPI works, a Win32 using SSPI client does not.

Either I compile the Win32 client with GSSAPI too,
either I have to dedicate a new IP address to my service URL - if there
is a chance that mod_auth_kerb on server use the right keytab entry (I
still have a doubt)

I'm asking why you reject so firmly DNS canonicalization. Even libgssapi
from MIT Kerberos does it now.
If you need other examples of DNS canonicalization with SSPI:
. Firefox: "MakeSN" method in
mozilla/extensions/negotiateauth/nsNegotiateAuthSSPI.cpp 
. putty: "sspi_construct_service_name" method (controlled by a config
key  "sspi_trust_dns")
http://rc.quest.com/viewvc/putty/trunk/putty/ssh.c?revision=96&view=markup 


My opinion is that Kerberos is an "intranet-only" authentication
mechanism (most server implementation relies on DNS entries)
I do not think it is designed to be used over internet and in seperate
companies. Now new HTTP based protocols (CAS, SAML) are designed for
internet usage - whereas SPNEGO is considered as weak if not over
https !

But the source of the whole story is a basic need: integrate Subversion
in an enterprise identity management for authentication and
authorization: Kerberos with ActiveDirectory and AuthzNetLDAP to check
group members with LDAP.

At the moment https and SPNEGO is the only option - because basic
authentication (over http or https) mainly results in domain password
storage on the client workstation disk by the user/svn client. And I
consider that security issue more critical than a DNS-based MITM attack
on Kerberos.

For performance reason, I'm also expecting a lot of the SASL support
over svn protocol (release 1.5). But it only concerns authentication,
and I have to found a solution for authorization checking.

To conclude: who should decide if neon implements DNS canonicalization
for the SSPI service name and how (configuration control) ?

Best regards
-- 
Yves Martin

_______________________________________________
neon mailing list
neon@xxxxxxxxxx
http://mailman.webdav.org/mailman/listinfo/neon

<Prev in Thread] Current Thread [Next in Thread>