Re: CAC enabled authentication with git transfer protocols

From: Chris Kees <cekees@gmail.com>
Date: Mar 13, 2012, 02:20 UTC
Message-ID: <CAOVFbFhbuWDFYcOqW3vcN==eC8495xuGRONLOrcWO6uZwJ2ETA@mail.gmail.com>
In-Reply-To: <CAJo=hJsshrJc0Onjph3LcQxEkXDSzEPp8TQetGoy9Rwz6OXRuw@mail.gmail.com>

On Mon, Mar 12, 2012 at 8:53 PM, Shawn Pearce <spearce@spearce.org> wrote:

Show 13 quoted lines

> On Mon, Mar 12, 2012 at 17:54, Jones, Brian P CTR
> SPAWARSYSCEN-PACIFIC, 63600 <brian.p.jones4.ctr@navy.mil> wrote:
>> Does anyone know if git is being used in a military CAC enabled environment? This means that the DoD CAC card is required to authenticate when hitting the git transfer protocol. This is a requirement before I can propose using git. I understand that git is able to use https as well as ssh or over port 9418. Is there any documentation on setting up CAC enabled git protocols?
>
> The git:// protocol on port 9418 has no authentication. It won't meet
> your requirements.
>
>
> For Git over ssh://, Git just relies on the SSH client and server
> binaries installed on the system. You would have to find out if these
> binaries meet your requirements. If they do, you may just be able to
> use SSH.
>

It seems like ssh might be the best shot. Kerberised ssh servers and clients can already be set up so that they use a CaC for authentication.

Show 25 quoted lines

>
> Git 1.7.9 and later on https:// can use a credential helper binary to
> obtain the user's "password" string. A credential helper is an
> external program Git calls to help it authenticate over HTTP using
> either HTTP basic or HTTP digest authentication. It may be possible to
> write a git-credential-dodcac binary that does the magic required.
> Install this binary in the user's $PATH, have them enable it with a
> `git config --global credential.helper dodcac` configuration setting,
> and away they go.
>
> If a DoD CAC is like a one time password scheme, it may be possible to
> have the user's "password" over HTTP actually be $password:$onetimepad
> or some such format, and then use a custom authentication system on
> the server to decode this string and verify it.
>
> Internally at $DAYJOB we use a custom git-credential-$DAYJOB binary to
> acquire a unique token that identifies the caller and pass this to the
> server over HTTPS. The HTTP server in turn verifies this string with
> the authentication system. Its not really their password, its just a
> mutually agreed upon blob that was passed around between the client
> workstation and the server.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html