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

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

[Stephen R. van den Berg]

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.
-- 
Sincerely,
           Stephen R. van den Berg.

"And now for something *completely* different!"

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

[Petr Baudis]

On Wed, Aug 13, 2008 at 06:26:44PM +0200, Stephen R. van den Berg wrote:
> 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.

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

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

[David Brown]

On Wed, Aug 13, 2008 at 06:36:46PM +0200, Petr Baudis wrote:
>On Wed, Aug 13, 2008 at 06:26:44PM +0200, Stephen R. van den Berg wrote:
>> 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.
>
>In the past, such an idea was dismissed with desire not to reimplement
>something ssh already implemented, and much better than we would.

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

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

[Petr Baudis]

On Thu, Aug 14, 2008 at 12:48:05AM -0700, David Brown wrote:
> On Wed, Aug 13, 2008 at 06:36:46PM +0200, Petr Baudis wrote:
>> On Wed, Aug 13, 2008 at 06:26:44PM +0200, Stephen R. van den Berg wrote:
>>> 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.
>>
>> In the past, such an idea was dismissed with desire not to reimplement
>> something ssh already implemented, and much better than we would.
>
> 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.

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

				Petr "Pasky" Baudis

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

[Stephen R. van den Berg]

Petr Baudis wrote:
>On Thu, Aug 14, 2008 at 12:48:05AM -0700, David Brown 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.

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

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.
-- 
Sincerely,
           Stephen R. van den Berg.

"Hold still, while I inject you with SQL."

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

[Petr Baudis]

On Thu, Aug 14, 2008 at 01:07:39PM +0200, Stephen R. van den Berg 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.

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).

> - 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.

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 "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates

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

[Stephen R. van den Berg]

Petr Baudis wrote:
>On Thu, Aug 14, 2008 at 01:07:39PM +0200, Stephen R. van den Berg 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.

>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).

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.

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

>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.)

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).
-- 
Sincerely,
           Stephen R. van den Berg.

"Hold still, while I inject you with SQL."

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

[Shawn O. Pearce]

"Stephen R. van den Berg" <srb@cuci.nl> wrote:
> 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.

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.

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

[Stephen R. van den Berg]

Shawn O. Pearce wrote:
>"Stephen R. van den Berg" <srb@cuci.nl> wrote:
>> What are the opinions on adding a basic challenge-response type
>> authentication mechanism to the native git protocol?

>> SHA1 (surprise ;-) to actually encrypt username/password/salt

>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
...

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

>Isn't there some authentication frontend that some IMAP servers
>use to handle the authentication for them?  I think last time

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..
-- 
Sincerely,
           Stephen R. van den Berg.

"And now for something *completely* different!"

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

[Shawn O. Pearce]

"Stephen R. van den Berg" <srb@cuci.nl> wrote:
> Shawn O. Pearce wrote:
> >"Stephen R. van den Berg" <srb@cuci.nl> wrote:
> >> What are the opinions on adding a basic challenge-response type
> >> authentication mechanism to the native git protocol?
> 
> 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).

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.

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

[Stephen R. van den Berg]

Shawn O. Pearce wrote:
>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

Correct.

>point it may actually be easier (and safer) for the admin to just
>handle a GnuPG or SSH public key.

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

>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 agree, which is why I don't want to put this complexity in git proper.

>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.

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.
-- 
Sincerely,
           Stephen R. van den Berg.

"And now for something *completely* different!"

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

[Shawn O. Pearce]

"Stephen R. van den Berg" <srb@cuci.nl> wrote:
> 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.

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.

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

[Stephen R. van den Berg]

Shawn O. Pearce wrote:
>"Stephen R. van den Berg" <srb@cuci.nl> wrote:
>> 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.

>- Add to git-daemon a new service command, "git-authenticate-user".
[...implementation suggestion omitted...]

Sounds like a plan.  I'll see if it is workable.
-- 
Sincerely,
           Stephen R. van den Berg.

"Hold still, while I inject you with SQL."

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

[Andreas Ericsson]

Shawn O. Pearce wrote:
> "Stephen R. van den Berg" <srb@cuci.nl> wrote:
>> 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.
> 
> 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 .
> 

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                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Stephen R. van den Berg]

Andreas Ericsson wrote:
>I'd do it like this instead:

>daemon: auth_user = dlsym(dlopen("auth-module.so", RTLD_NOW), 
>"authenticat");

>This approach has several nifty benefits:
>* The otherwise duplicated code (for different auth schemes) is
> done only once (in the git daemon).

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

>* 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.

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

>* 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.

If by "modules" you mean dynamically loaded libraries, then I
wholeheartedly disagree.
-- 
Sincerely,
           Stephen R. van den Berg.

"Hold still, while I inject you with SQL."

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

[david]

On Thu, 14 Aug 2008, Andreas Ericsson 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.

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

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

[david]

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

> 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...

are you thinking of SASL?

David Lang

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

[Shawn O. Pearce]

david@lang.hm wrote:
> On Wed, 13 Aug 2008, Shawn O. Pearce wrote:
>
>> 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...
>
> are you thinking of SASL?

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.  :)

-- 
Shawn.