[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Yves Martin <yves.martin_at_elca.ch>
Date: 2007-07-04 14:56:07 CEST

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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 4 14:57:38 2007

This is an archived mail posted to the Subversion Dev mailing list.