Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Date: Sat, 21 Nov 2015 22:59:15 +0000
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Philip Martin <philip.martin@wandisco.com>
Cc: dev@subversion.apache.org
Subject: Re: svn+ssh long-lived daemon
Message-ID: <20151121225915.GD2335@tarsus.local2>
References: <871tblc0ii.fsf@wandisco.com>
 <20151120030822.GG2103@tarsus.local2>
 <87mvu86hu5.fsf@wandisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87mvu86hu5.fsf@wandisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

Philip Martin wrote on Fri, Nov 20, 2015 at 11:17:06 +0000:
> Daniel Shahaf <d.s@daniel.shahaf.name> writes:
> > 3. VPN with key-based authentication, then just use svn:// over the VPN
> > subnet.  For example, OpenVPN can do this.
> 
> This also requires Subversion authentication over the VPN.  The server
> still has to configured for Subversion credentials in addition to the
> VPN credentials and the user is authenticated twice.
> 
> What I want is a single authentication that only requries a key pair and
> a username.

You could set up the VPN to dedicate an IP address to each user, and
arrange for svnserve to only accept a particular username if the remote
IP address is that user's IP address.  At that point you don't need to
have an ra_svn password at all, svnserve will check the username against
the remote IP address, the server doesn't even need to request
a password from the user.  Security will rely on the VPN IP routing, not
on a password.

You could arrange something similar with the 'ssh -W' idea: if svnserve
listened on multiple IP:port tuples, and .ssh/authorized_keys permitted
each user to connect to only one of those IP:port coordinates, svnserve
could derive the authenticated username from the port number the
connection was accepted on, and no ra_svn-level password will be
required, only an SSH key.

But zooming out, what's so unreasonable about assigning two
authentication secrets to each user?  Such as two secret keys, or
a secret key and a password that only works in conjunction with that
specific key?  Requiring "a single secret per user" seems like an
arbitrary requirement, you gave no reason for it, theoretically it's
unmodelable.  What's your concern?  Administrative overhead?  One
employee (an "inside" attacker) impersonating another employee?

You mentioned SASL in your first mail but I don't understand why using
keys with SASL would require code changes.  Using SASL with straight
svn:// would probably be easiest solution.

Regarding your in-band proxy idea, one minor tweak to it would be to use
SCM_CREDS / SCM_CREDENTIALS for the sideband protocol, instead of
inventing a custom side protocol.  For example, you could have svnserve
listen on a unix socket and authorized_keys execute a setgid wrapper,
one wrapper per SSH-authenticated identity.  The wrapper would act like
'socat STDIO svnserves_unix_socket' and call SCM_CREDS at the right
moment.

Also, you didn't mention if on-the-wire encryption is a goal, or just
authentication.

Cheers,

Daniel