[RFC] Adding a challenge-response authentication method to git://

What are the opinions on adding a basic challenge-response type authentication mechanism to the native git protocol? I.e. the authentication would be a simple one, which uses SHA1 (surprise ;-) to actually encrypt username/password/salt and authenticate the user.

I'm willing to do the work, if there are no objections.

On Wed, Aug 13, 2008 at 06:26:44PM +0200, Stephen R. van den Berg wrote:

In the past, such an idea was dismissed with desire not to reimplement something ssh already implemented, and much better than we would.

				Petr "Pasky" Baudis

On Wed, Aug 13, 2008 at 06:36:46PM +0200, Petr Baudis wrote:

The problem is that ssh ties you in very closely with the ability to log into the machine. It's also hard to limit what ssh allows while still allowing some users more priveleges.

But, this problem comes up with other protocols that use ssh for authentication as well, so perhaps the solution is to fix the problems with ssh to allow it to more securely allow non-login services.

David

On Thu, Aug 14, 2008 at 12:48:05AM -0700, David Brown wrote:

Can you elaborate, in light of git-shell and Gitosis? What's the problem?

				Petr "Pasky" Baudis

Petr Baudis wrote:

Well, I looked into gitosis, and it solves part of the problem, it has a few downsides though:

- It depends on Python for no particular reason (it might as well have
  been built using shellscripts only, or if need be Perl, since git
  already uses that); yet any extra dependency is creating an extra
  hurdle for portability and adoption.
- It does authentication magic without properly documenting why it does
  it properly.
- It explicitly warns that it needs PATH and PYTHON_PATH magic and that
  using it without setting those up has not been tested; this does not
  inspire confidence that the security of the solution is airtight.

Other than that, gitosis looks fairly good if you want to use public keys.

On Thu, Aug 14, 2008 at 01:07:39PM +0200, Stephen R. van den Berg wrote:

Is this concern really any kind of practical one? To me it appears that Python and Perl are both so extremely wide-spread that this might be issue only on embedded systems, exotic systems with very low proportion of git users, and users with strong ideological opinions about the system (probably low proportion of git users too).

This doesn't seem to be convincing reason for _reimplementing_ the solution. (Of course, I don't prevent you from doing that, I'm just wondering about the feasibility.)

Petr Baudis wrote:

I agree that in general it shouldn't be a major problem to get it on the systems you want to use it on; but it does increase the difficulty of auditing the solution before deploying it.

I'm not going to reimplement gitosis. I'm going to do *less* than gitosis for situations where gitosis is undesirable (for whatever reason, not necessarily the critisisms I mentioned before).

"Stephen R. van den Berg" <srb@cuci.nl> wrote:

Last time we talked about this we got off onto some tagent about using GnuPG public keys to authenticate users, and then how we might store the public keys in a keyring and log pushes (changes to refs) so that one could replicate the log on another server and come up with the same result. Hence not just the current source code but also the "how we got here" could be verified externally.

Username/password management is always ugly. Some admins will want you to plug into PAM, others just want a flat file that is unique to the service, others want LDAP. And then you get into people wanting Kerberos support because they already have everything else in their domain supporting it. Tons of complexity for our project.

Isn't there some authentication frontend that some IMAP servers use to handle the authentication for them? I think last time I setup bincimap it used checkpassword. We might want to do the same if we are going down this road...

Shawn O. Pearce wrote:

...

That is the feature rich solution. For those there is ssh/webdav and possibly other setups.

There is GSSAPI, which allows plugging in just about anything you like. Nonetheless, for a lot of small projects, you have a relatively small number of developers (typically <32) which have commitrights on one or more source trees in a central repository.

In order to aid them in setting up a simple accesslist, git would do just fine by simply offering a flat-file like list. Forcing those setups to use anything more complicated makes adoption of git for those kind of projects unreasonably more complicated (IMO).

There are no promises for flexibility, security, whatsoever. The only things I'm aiming for are: a. Simplicity (need just git). b. No cleartext passwords over the wire. c. No encryption. d. Highest performance (native git protocol).

Anyone needing more is referred to webdav/ssh and assorted solutions. This minimises the dependencies on external libs, the only thing we need is a strong hash-function to implement (b); as it happens, we already have SHA1..

"Stephen R. van den Berg" <srb@cuci.nl> wrote:

Well, anytime you get into a flat-file access list you get into management of that list. How do users change their own password? How does an admin add/remove a user, or reset a password? What defines an admin? Can you do these things remotely? Can you keep the password encrypted on the remote side so an admin cannot see a user's (common) password and maybe gain access to unrelated sites?

If you are going to keep it "really simple" you may be tempted to say that all user additions/deletions/password changes should be done by the admin directly editing the password list. At which point it may actually be easier (and safer) for the admin to just handle a GnuPG or SSH public key.

This is why we tend to rely on SSH. It neatly solves all of this for us, and does it in a way that UNIX administrators are familiar with managing.

This is also why the last discussion on this topic went down the road of using GnuPG to handle the authentication portion of the protocol. Unfortunately dealing with the server side keychain is a little bit more complex then I'd like it to be out of the box, and the client side I think is lacking something as common as ssh-agent for caching the decrypted key.

I can see how it would be pretty simple to add authentication to
git-daemon based upon a shared secret, but such schemes always
cause management problems on both sides.
 

Shawn O. Pearce wrote:

Correct.

If you want that, that is best handled in ssh.

I agree, which is why I don't want to put this complexity in git proper.

I'm not trying to solve all management problems, I'm just trying to offer a simple solution for the small-user-base-central-repository case without a lot of code-bloat on the git side. If it doesn't fit ones needs, use ssh or something else; but it does have its merits for the simple centralised setups.

"Stephen R. van den Berg" <srb@cuci.nl> wrote:

OK, then my final two cents, and I'll shutup.

- Add to git-daemon a new service command, "git-authenticate-user".
- Clients request "git-authenticate-user 'repository'".
- The auth_user routine:
	enters 'repository' ('ala upload-pack)
	execs "git-authenticate-user ."

- git-authenticate-user:
	send pkt-line challenge
	recv pkt-line username
	recv pkt-line SHA-1(username + password + challenge)
	
	read gitconfig for "auth.passwordfile"
	read passwordfile for entry $username
		("user:pass:upload-pack,receive-pack")
	verify response

	send pkt-line ok/fail
	recv pkt-line "git-$service '.'"
	check $service is allowed
	exec git-$service .

Shawn O. Pearce wrote:

[...implementation suggestion omitted...]

Sounds like a plan.  I'll see if it is workable.

Shawn O. Pearce wrote:

I'd do it like this instead:

daemon: auth_user = dlsym(dlopen("auth-module.so", RTLD_NOW), "authenticat");
client: "git-authenticate action 'repository'"
daemon: send pkt-line challenge
client: send pkt-line username
client: send pkt-line SHA1(username + password + challenge)
daemon: if (auth_user(repository, action, username, password, struct sockaddr_in *inbound))
               allow_connection();

This approach has several nifty benefits:
* The otherwise duplicated code (for different auth schemes) is
  done only once (in the git daemon).
* If the git daemon has no authentication module loaded, we might
  as well not bother sending any challenge and just pretend we do
  not know about the authentication scheme.
* Any kind of authentication scheme can be supported without changing
  the core code. If the authentication module does something wrong,
  one can continue to serve read-only requests by simply unloading
  the module.
* Modules is a great way for newcomers to get started contributing to
  git so it's a nice way of getting more contributors/sub-maintainers.

Andreas Ericsson wrote:

I'd prefer that to be in a separate program, instead of git-daemon proper.

Loading modules is highly fragile across different OSes, so it's not really recommended at all.

If by "modules" you mean dynamically loaded libraries, then I wholeheartedly disagree.

On Thu, 14 Aug 2008, Andreas Ericsson wrote:

if you're going to do modules, you should give the module the connection until it's done so that different types of authentication can be implemented by the module.

David Lang

On Wed, 13 Aug 2008, Shawn O. Pearce wrote:

are you thinking of SASL?

David Lang

david@lang.hm wrote:

Maybe I was. But I think I was thinking about DJB's checkpassword tool. There are several tools that implement the same calling conventions, some of which link to PAM or an LDAP database, etc. Plus its fairly easy to create your own if you really needed a custom solution. You just have to be able to read fd 3. :)