Re: Git over HTTP; have flexible SASL authentication

From: Rick van Rein <rick@openfortress.nl>
Date: Feb 4, 2023, 11:34 UTC
Message-ID: <20230204113408.GD21507@openfortress.nl>
In-Reply-To: <xmqq7cx7aov7.fsf@gitster.g>

Hi Junio,

(Sorry for the late reply)

Show 8 quoted lines

> > Git providers are inventing proprietary extensions to HTTP authentication
> > for Git.  It seems smarter to use SASL for this purpose, possibly allowing
> > the client a choice and authentication ringback to the client's own domain.
> 
> To adopt things like this, the work to extend how to make extensible
> what is on WWW-Authenticate in the thread that contains this recent
> message https://lore.kernel.org/git/Y9LvFMzriAWUsS58@coredump.intra.peff.net/
> may be relevant, perhaps?

This framework tries to get away from just Basic / Digest auth, but if I read correctly, it still assumes a single authentication step, which greatly reduces the strength of authentication.

SASL assumes that the endpoints can hold state and progress through any challenge/response exchange, in multiple steps if needed. This is not trivial with stateless HTTP, but we fixed it with a "s2s" argument which can hold the (datestamped, signed, encrypted) state on the server side.

A few mechanisms that spring to mind as useful with Git over HTTP-SASL are

 - Kerberos / GSS-API, desirable for companies using its single sign-on
 _ FIDO, currently being added to SASL to benefit all protocols
 - OPAQUE, a very modern crypto, developed in IETF now
 - SXOVER-PLUS, our own work that calls back to a user's domain for login
	(so no server-stored credentials needed, only access control)

I'm curious if this would indeed be considered an improvement to Git.

Cheers,
 -Rick