Password authentication over Gemini

[Sean Conner]

It was thus said that the Great solderpunk once stated:
> I deliberately chose not to spec any kind of password-based
> authentication in Gemini, since TLS was already mandatory and so client
> certificate authentication was a possibility.  The "maximise power to
> weight ratio" philosophy kind of implies a "there should be only way to
> do it" philosophy as a corollary.
> 
> Anyway, I realised to my surprise yesterday morning that actually Gemini
> now supports password authentication quite readily:
> 
> CLIENT:    gemini://example.com/protected-resource/
> SERVER:    61 Please supply a temporary certificate to faciliate
>            interactive login
> CLIENT:    gemini://example.com/protected-resource/
>            (with disposable certificate)
> SERVER:    10 Username:
> CLIENT:    gemini://example.com/protected-resource/?solderpunk
> SERVER:    10 Password:
>            (after storing "solderpunk" in memory, indexed by client
> 	   certificate fingerprint)
> CLIENT:    gemini://example.com/protected-resource/?hunter2
> SERVER:    21 text/gemini
>            (after retrieving "solderpunk" from memory and verifying that
> 	   solderpunk/hunter2 matches what is stored (hashed and salted)
> 	   in a database

  There's no reason for the user to generate a certificate and then provide
a username/password when the certificate already has the username:

		CGI Environment Variables

AUTH_TYPE=Certificate
GATEWAY_INTERFACE=CGI/1.1
LANG=en_US.UTF-8
LC_COLLATE=C
PATH=/usr/local/bin:/usr/bin:/bin
QUERY_STRING=
REMOTE_ADDR=192.168.1.10
REMOTE_HOST=192.168.1.10
REMOTE_USER=Sean Conner
REQUEST_METHOD=
SCRIPT_NAME=/private/raw
SERVER_NAME=lucy.roswell.area51
SERVER_PORT=1965
SERVER_PROTOCOL=GEMINI
SERVER_SOFTWARE=GLV-1.12556/1
TLS_CIPHER=ECDHE-RSA-CHACHA20-POLY1305
TLS_CLIENT_HASH=SHA256:0eab5867fcb5b30046120e4c29562e31b88c51b167b091aee4b4e66221645a20
TLS_CLIENT_ISSUER=/C=US/ST=FL/O=Conman Laboratories/OU=Security Division/CN=Conman Laboratories CA/emailAddress=ca at conman.org
TLS_CLIENT_ISSUER_C=US
TLS_CLIENT_ISSUER_CN=Conman Laboratories CA
TLS_CLIENT_ISSUER_O=Conman Laboratories
TLS_CLIENT_ISSUER_OU=Security Division
TLS_CLIENT_ISSUER_ST=FL
TLS_CLIENT_ISSUER_emailAddress=ca at conman.org
TLS_CLIENT_NOT_AFTER=2020-06-18T23:54:56Z
TLS_CLIENT_NOT_BEFORE=2019-06-19T23:54:56Z
TLS_CLIENT_REMAIN=308
TLS_CLIENT_SUBJECT=/C=US/ST=FL/L=Boca Raton/CN=Sean Conner/emailAddress=sean at conman.org
TLS_CLIENT_SUBJECT_C=US
TLS_CLIENT_SUBJECT_CN=Sean Conner
TLS_CLIENT_SUBJECT_L=Boca Raton
TLS_CLIENT_SUBJECT_ST=FL
TLS_CLIENT_SUBJECT_emailAddress=sean at conman.org
TLS_VERSION=TLSv1.2

  This is the output from a CGI script running on my development server, and
you can see the TLS_CLIENT_SUBJECT contains what could be considered the
"username".  But other than that, yes, that is a way to sneak in an
alternative form of username/password into the spec.

> This is less hassle than using client certificates directly (i.e.
> generate a persistent certificate, email the fingerprint to the remote
> admin, carry your certificate around with you, all as per ssh keys),
> though of course also less secure (weak passwords can be guessed,
> password databases can be stolen).  Different approaches will be more or
> less appropriate for different applications.

  This is one reason why my initial status code proposal supported
certificates and "another way" left vague at the time.

> This motivates two possible changes to the spec:
> 
> Firstly, the <META> value sent with a 6x status is currently undefined.
> I would propose that for 61, <META> should be a human-readable message
> explaining *why* the server is politely requesting the user to
> voluntarily and temporarily surrender their anonymity.  Seems only
> reasonable.
> 
> Secondly, as a variant on 10, maybe 11 could carry the extra semantics
> that clients should not echo user input, so it can be used for things
> like passwords.
> 
> Any thoughts?

  Not much there, other than to ask about having second thoughs about
certificate only authentication?

  -spc