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
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 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?
-Solderpunk
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
> There's no reason for the user to generate a certificate and then provide > a username/password when the certificate already has the username: This is kind of neat, but would require the interface interaction that happens in response to a 61 to give the user the opportunity to specify these details. At best, this is an unnecessary bit of UI friction in cases where it won't be used. At worst, for very privacy-conscious users, being asked to specify any kind of personal information at all to include in something which is supposed to be an entirely ephemeral / disposable / transient will feel like a red flag, I suspect. > This is one reason why my initial status code proposal supported > certificates and "another way" left vague at the time. I think I am pretty set on the philosophy of not building into the protocol any kind of high-level actions which can be straightforwardly achieved with combinations of lower-level actions already in there. It's a great way to keep the protocol slim and easy to reason about. > Not much there, other than to ask about having second thoughs about > certificate only authentication? Sorry, can you clarify? Do you mean second thoughts about only having certificates as a way to authenticate (i.e. are we sure we don't want passwords as first-class citizens?). Or do you mean second thoughts about allowing authentication with only a certificate? Why wouldn't we want to allow that? -Solderpunk
It was thus said that the Great solderpunk once stated: > > There's no reason for the user to generate a certificate and then provide > > a username/password when the certificate already has the username: > > This is kind of neat, but would require the interface interaction that > happens in response to a 61 to give the user the opportunity to specify > these details. At best, this is an unnecessary bit of UI friction in > cases where it won't be used. At worst, for very privacy-conscious > users, being asked to specify any kind of personal information at all to > include in something which is supposed to be an entirely ephemeral / > disposable / transient will feel like a red flag, I suspect. You're already asking for clients to generate a temporary certificate. Before going too down far this rabbit hole, why not make a few temporary certificates and hitting: gemini://gemini.conman.org/private/ There's nothing there that generates a status of 10, but it is asking for temporary certificates. It's not even expecting any set information. It might be instructive to know what what is and isn't required for a certificate. > > Not much there, other than to ask about having second thoughs about > > certificate only authentication? > > Sorry, can you clarify? Do you mean second thoughts about only having > certificates as a way to authenticate (i.e. are we sure we don't want > passwords as first-class citizens?). Or do you mean second thoughts > about allowing authentication with only a certificate? Why wouldn't we > want to allow that? I meant I had no thoughts about your question re: status code of 11. My question to you was, why have a usernames/password scheme when you have certificates, which are a combination of username/password? -spc
> You're already asking for clients to generate a temporary certificate. Which is just some random bytes which can't be tied to anything or anyone, so what's to be afraid of? > Before going too down far this rabbit hole, why not make a few temporary > certificates and hitting: > > gemini://gemini.conman.org/private/ > > There's nothing there that generates a status of 10, but it is asking for > temporary certificates. It's not even expecting any set information. It > might be instructive to know what what is and isn't required for a > certificate. Nothing at all is expected of an ephemeral cert generated in response to a 61 status. It's just a random session ID, or rather, some hash of the cert becomes a random ID. If a server throws up a 62 then it's expecting a *particular* certificate from an authorised whitelist. I never really imagined any of the metadata fields on a certificate being used as part of the validation (on a self-signed certificate they don't count for much), though a guess if a server wanted to they could use them. > I meant I had no thoughts about your question re: status code of 11. My > question to you was, why have a usernames/password scheme when you have > certificates, which are a combination of username/password? Certificates aren't really comparable to a username/password combination, though. A user/pass combo I can carry around in my head and use from any computer with a Gemini client. A key/certificate pair are a bunch of files I have to carry around on a USB stick and be careful about. They offer two different trade-offs between security and convenience. It's entirely analogous to SSH authentication, where user/pass and private key are both possibilities, and both widely used. -Solderpunk
It was thus said that the Great solderpunk once stated:
> > You're already asking for clients to generate a temporary certificate.
>
> Which is just some random bytes which can't be tied to anything or
> anyone, so what's to be afraid of?
I'm not so much afraid as I'm confused. I came up with a status code
proposal back in June [1] where I had status codes for both password
authentication and certificate authentication:
unauthorized
general
rejected 301 *
password
require 310
rejected 311
expired 312
certificate
require 320
rejected 321
expired 322
future 323
which you rejected outright and decided to go with just certificate
authentication. I can only suppose you have changed your mind somewhat on
this.
> > Before going too down far this rabbit hole, why not make a few temporary
> > certificates and hitting:
> >
> > gemini://gemini.conman.org/private/
> >
> > There's nothing there that generates a status of 10, but it is asking for
> > temporary certificates. It's not even expecting any set information. It
> > might be instructive to know what what is and isn't required for a
> > certificate.
>
> Nothing at all is expected of an ephemeral cert generated in response to
> a 61 status. It's just a random session ID, or rather, some hash of the
> cert becomes a random ID.
>
> If a server throws up a 62 then it's expecting a *particular*
> certificate from an authorised whitelist. I never really imagined any
> of the metadata fields on a certificate being used as part of the
> validation (on a self-signed certificate they don't count for much),
> though a guess if a server wanted to they could use them.
A username is a username. Of the two protected areas on my Gemini server
[2], one requires a certificate I signed in order to access. You generate a
CSR (certificate signing request), I sign it and send back the certificate.
It is also possible to send me (out of band) a certificate that you
generated that will also be checked upon each request, but there has to be
---
Previous Thread: Text reflow woes (or: I want bullets back!)