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
. putty: "sspi_construct_service_name" method (controlled by a config
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
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
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) ?
neon mailing list