You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Sigfred Håversen <bs...@mumak.com> on 2004/10/31 20:22:38 UTC
svnserve client authentication using certificates
To my previous svnserve SSL patch, I've added authentication using client
certificates. However, client management of certificates remains to be done
and I'm unsure on how to proceed. More on that below.
A SSL enabled svnserve will now accept clients that does not have that
capability, or does not want to use it. An exception, of course, is
authentication using certificates. If both svnserve and the client supports
ssl, a SSL handshake will be done.
A repo administrator will add users with certificates in a new section
[certificates] in the svnserve password file :
[certificates]
username1 = <PEM encoded certificate>
username2 = <PEM encoded certificate>
....
I've added a new auth mech "SSL-CERT" that the server send when it wants the
client to authenticate with a certificate. The authentication will only
succeed if the client gives a valid username and certificate during the
handshake. The authentication is done by checking that the client supplied
certificate is signed by the corresponding certificate in password file.
For the client certificate management there are two credentials that will be
useful : SVN_AUTH_CRED_SSL_CLIENT_CERT and
SVN_AUTH_CRED_SSL_CLIENT_CERT_PW. However, none of them supports caching.
Since my client certificate authentication is a pair (username, certificate),
it would be useful to have a "const char *username" member in
svn_auth_cred_ssl_client_cert_t as well.
I could change the providers, but I don't want to risk breaking existing usage
of those providers. Making a new credential seems wrong. Any ideas?
/Sigfred
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svnserve client authentication using certificates
Posted by Mark Benedetto King <mb...@lowlatency.com>.
On Sun, Oct 31, 2004 at 10:22:38PM +0200, Sigfred H?versen wrote:
> To my previous svnserve SSL patch, I've added authentication using client
> certificates. However, client management of certificates remains to be done
> and I'm unsure on how to proceed. More on that below.
>
> A SSL enabled svnserve will now accept clients that does not have that
> capability, or does not want to use it. An exception, of course, is
> authentication using certificates. If both svnserve and the client supports
> ssl, a SSL handshake will be done.
>
> A repo administrator will add users with certificates in a new section
> [certificates] in the svnserve password file :
>
> [certificates]
> username1 = <PEM encoded certificate>
> username2 = <PEM encoded certificate>
> ....
I think the way the config parser works, multi-line things like the
PEM-encoded certificate will have their newlines removed. This may
irritate the OpenSSL PEM parser. I suppose we could replace spaces
in the conf item with newlines before handing the cert off to OpenSSL.
What if you put the client cert's DN in there instead?
>
> I've added a new auth mech "SSL-CERT" that the server send when it wants the
> client to authenticate with a certificate. The authentication will only
> succeed if the client gives a valid username and certificate during the
> handshake. The authentication is done by checking that the client supplied
> certificate is signed by the corresponding certificate in password file.
>
> For the client certificate management there are two credentials that will be
> useful : SVN_AUTH_CRED_SSL_CLIENT_CERT and
> SVN_AUTH_CRED_SSL_CLIENT_CERT_PW. However, none of them supports caching.
> Since my client certificate authentication is a pair (username, certificate),
> it would be useful to have a "const char *username" member in
> svn_auth_cred_ssl_client_cert_t as well.
Can the server invert the mapping of user->DN and build a DN->user map?
(Or perhaps we should just store them that way in the password file)
Then the username wouldn't actually need to be part of the provider,
in fact, the client wouldn't even know the username!
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org