connection establishment todo, secure transport, sasl temporary alternative

[solo turn <so...@yahoo.com>]

when reading connection establishment
todo(subversion/libsvn_ra_svn/todo), two things were not clear to me:
1. why would you need a port assignment from iana, if
   you are using http/webdav/deltav,
   isnt there port 80/443 already "defined"?
2. why there is nothing saying "ssl" as temporary and easy
   to implement alternative to sasl.

if you do plain text password authentication over secure transport,
it is secure. and https provides that. and we have it today. the only
thing which might bother some people is the effort for encrypting the
whole traffic (and the client does not offer to display the
certificate a server presents ... but this is a different story).

if this is a real problem, why not having the following configuration
options:
- server: https, http, http+https
  --> we have it today via apache
- client: use https for critical info, which might be passwords,
  directories with a certain property, ...)
  --> could be easily added by extending the ~/.suversion/servers
      file.

an example how a config file could look like (i used xml notation,
cause i don't know how to write it in the current settings file
notation):

<!-- section for servers/groups: -->
  <!-- enforces connection establishing via https -->
  <group id="tigris_group" http="80" https="5000"
security="https-connection-establish">
     <dns>*.collab.net</dns>
     <dns>*.tigris.org</dns>
  </group>
  <group id="seconndgrp">
  ...
  </group>

  <!-- default group, enforces no https at all -->
  <group id="default" http="80" https="443">
  </group>

     
<!-- section for proxies: -->
  <!-- special proxy for some groups -->
  <proxy id="myproxies" 
         applytogroups="tigris_group, secondgrp"
         exceptgroups=""
         host="bla.proxydomain.org"
         port="8080"
         user="myuser"
         password="uhm"
         >
  </proxy>
  <!-- default proxy -->
  <proxy id="default">
    <exceptdns>
      <dns>*.localdomain.net</dns>
      <dns>*.localdomain2.net</dns>
    </exceptdns>
    <!-- read linux proxy environment variables -->
    <host getfrom="env"/>
    <port getfrom="env"/>
  </proxy>





__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: connection establishment todo, secure transport, sasl temporary alternative

[Garrett Rooney <ro...@electricjellyfish.net>]

solo turn wrote:

>when reading connection establishment
>todo(subversion/libsvn_ra_svn/todo), two things were not clear to me:
>1. why would you need a port assignment from iana, if
>   you are using http/webdav/deltav,
>   isnt there port 80/443 already "defined"?
>2. why there is nothing saying "ssl" as temporary and easy
>   to implement alternative to sasl.
>  
>

ra_svn is a different repository access layer than ra_dav.

ra_dav works over http/webdav/deltav, ra_svn works over a tcp connection 
with a custom protocol greg hudson has devised.  thus, ra_svn will 
require a new port assignment, and will have to implement some things 
that we already get from ra_dav and apache.  on the other hand, it is 
likely that the whole of ra_svn's code will be smaller (and thus more 
auditable for security issues) than ra_dav and mod_dav_svn/apache, and 
that will please many people who don't want something as large and 
complex as apache for their svn server.  it's a tradeoff though.  ra_dav 
and apache/mod_dav_svn will likely remain more powerful simply because 
of the large amount of stuff we can get from apache.

-garrett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: connection establishment todo, secure transport, sasl temporary alternative

[Joe Orton <jo...@manyfish.co.uk>]

On Tue, Dec 03, 2002 at 12:23:21PM -0500, Greg Hudson wrote:
> As Garrett pointed out, ra_svn doesn't use Apache.  And one of my goals
> in writing ra_svn was to eventually support the full range of SASL
> mechanisms, not the limited range of authentication options available
> through HTTP.

Not to say that you couldn't use SASL as an HTTP auth protocol, of
course (I'm working on this for neon at the moment, as it happens).

http://www.ietf.org/internet-drafts/draft-nystrom-http-sasl-05.txt

joe

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: connection establishment todo, secure transport, sasl temporary alternative

[Greg Hudson <gh...@MIT.EDU>]

As Garrett pointed out, ra_svn doesn't use Apache.  And one of my goals
in writing ra_svn was to eventually support the full range of SASL
mechanisms, not the limited range of authentication options available
through HTTP.  SSL and ssh may be good enough for 90% of the user
population, but there are krb5 sites (like my workplace), and SRP sites,
and OTP sites, and smartcard sites, and it would be nice if Subversion
could fit into those infrastructures.

Anyway, a goal of what's listed in todo is to make it impossible to use
plain-text passwords with ra_svn.  If the client and server send a
secret, there is no good reason to compromise that secret by blatting it
over the network in the clear.  Plain-text passwords over SSL is secure,
but openssl is not a mandatory dependency of Subversion.

I'm still a bit nervous about implementing a native username/password
mechanism at all (whether PLAIN or CRAM-MD5 or SRP), because it wouldn't
be possible for us to be file-format compatible with Cyrus-libsasl on
the server.  So maybe the native code will only implement ANONYMOUS and
EXTERNAL (for EXTERNAL read "tunneled over ssh"), and you'll have to
link in libsasl for anything else.

(Once libsasl is integrated, SSL will be possible via the STARTTLS
mechanism.)


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org