how to use the gnupg for authenticated logins
Sun Aug 10 17:34:02 2003
Content-Description: signed data
On Sunday 10 Aug 2003 1:36 pm, Carl L. Gilbert wrote:
> On Sun, 2003-08-10 at 06:33, Neil Williams wrote:
> > On Sunday 10 Aug 2003 1:55 am, Carl L. Gilbert wrote:
> server sends client a completely random number encrypted. client
> decrypts it, and adds to the end of it, its own random number. Then
> sends this new number off encrypted to the server. Server decrypts that
> message. Sees the first random number, then he is satisfied that the
> client is proper. Then server sends back to the client the random
> number the client sent. Now client is satisfied the server is proper.
But that's an extra network loop compared to the token - which, incidentall=
is just random text with a simple ID added for cookie purposes.
> Its pretty simple if both share each others keys. nothing can be
> replayed because the random message changes every time.
=46or authentication yes, but the user will want to DO something after=20
authentication, at which point we hand over to another process. That other=
process has to have some way of communicating with the authentication. (To=
get people to login when they return to a bookmark for one thing - or in th=
case of an incomplete login attempt.)
> I think it will work. But I also suspect its probably already
> invented. Somebody said its like SSH1. So investigate SSH1 and SSH2
SSH differs in that what the user wants to achieve AFTER authentication is=
tunnelled through SSH before it can work. It involves more configuration of=
the server. This GnuPG process *should* allow any existing system to bolt-o=
GnuPG authentication just using:
1. The daemon on the server
2. Updating the existing session variables in a few scripts.
(Can be done on a section-by-section basis.)
On Linux servers especially, this is a simple RPM/apt-get and one ./configu=
make make install. Site-by-site adjustments to make use of the new service=
should be minor.
I don't have SSL, SSH server or Java installed on my test systems, if=20
gnupg_login is going to simplify my life, it'd better not require large sca=
installation! Most webhosts will only offer .htaccess, MySQL, GnuPG, PHP an=
Perl, or less. (Can't see this working with much less than those - MySQL is=
more for the user actions once logged in.)
I'd like to see gnupg_login being able to run using just:
=46or the server:
Apache, PHP, Perl, GnuPG, .htaccess (for unverified new users).
Apache, ASP (possibly), Perl, PGP/GnuPG-win, .htacces ( ditto )
MySQL and SSL optional.
GnuPG, gpg_login client, any standard compliant browser.
> first. I think the difference here though is the way ssh can
> automatically authenticate the server with a simple Y/N. but here you
> want the human to auth the server and give 'ssh' the key ahead of time.
Also true. But SSH still relies on the username/password to complete=20
authorisation, it doesn't use the key alone.
> I Think this needs to be automatic. User should hit login button on
> server website. A client side browser plugin should then be activated
> that handles the login process, automatically. No cutting and pasting
The cutting and pasting is a test method, a way of getting the thing to wor=
and maybe a backup in case of errors but it will eventually be dropped.
There will be client intervention required - the returning token needs to b=
signed. The GnuPG passphrase needs to be entered somehow to verify that the=
trusted GnuPG secret key is available on that client - but there are=20
gpg-agent and the passphrase cache to help.
> required. However, first time this happens, the plugin will complain
> about not having the servers key. And the server of course will also
> need to way to initially accept the clients key. So first time is a
That's a keysigning issue. The login is likely to be two-tier - reduced acc=
for the existing username/password combo, full access once the client key i=
signed and has signed the server key. New / unverified users won't be able =
login using their GnuPG key.
> little complicated, but after that its just the push of a button. java
> script can handle the rest.
Java maybe, but many Linux clients don't come with Java. More likely a bina=
client written in C and compiled as normal. Using C makes it easier to=20
incorporate into GnuPG itself if it is successful.
(Getting ahead of myself!)
> > The automated form would need some form of daemon and client, this is
> > where GnuPG could win over existing users of username/password
> > combinations - the authentication could be transparent and the client
> > would only need to provide their GnuPG passphrase to the local client
> > program. An identification cookie could be set when the token is
> > requested and the cookie updated when the browser refreshes the page
> > after authentication via the client. Would that work? (The cookie ID
> > string could be included in the token.)
> I am lost in what role the token you keep mentioning is playing.
token =3D random_text and now with a cookieID string to maintain verificati=
once PHP takes over. The token is the content of the encrypted packets so=20
that both client and server can be verified to each other - getting a signe=
response isn't good enough, it needs to be a signed response to the right=20
server, otherwise you could be authenticated on a spoof server.
> > Provided it is clear to all users that the passphrase DOES stay local a=
> > that all network traffic is encrypted, I think users would be happy.
> > Perhaps a configurable output, much like KMail, where the
> > signed/encrypted data is displayed for user reassurance before
> > transmission. Users who have built up a trust in the software can later
> > set an option in the client config to let the authentication proceed wi=
> > just the passphrase being entered.
> I would suggest eliminating the passpharase totally. Only allow it to
I meant the GnuPG secret key passphrase required to get the return packet=20
signed. These will be ordinary, personal, GnuPG client keys used for all=20
manner of other tasks, omitting a passphrase from those keys isn't advisabl=
Once the GnuPG key is signed, the website username and password become=20
> > My knowledge of daemons/clients isn't up to doing this well, (better to
> > be honest here!), anyone here willing to help?
> you speaking of something running on the server and talking to apache?
Not necessarily apache, but available on the server to be queried using PHP=
Perl scripts via the command line and backticks.
$tokenID =3D `gpg_login --verify-id 234A2D345EBC2342898F`;
# $tokenID might contain 1224510011224004577 for example.
$cookieID =3D $tokenID;
$cookiesource =3D $id;
(PHP will run backticks, depending on the installation, or use Perl to=20
configure the cookie.)
> > sessionID. Only if the sessionID and the cookieID match would PHP
> > continue the session.
> not to sure about the security of cookies.
Let PHP deal with that. The cookie isn't permanent, it's a session cookie -=
can be set to expire, it can be removed on user logout, it will be deleted =
the browser is closed. The cookie can't be copied to another machine as the=
sessionID will change. After all, a cookie is the only authentication any=20
site has when the user moves passed the login page - HTTP is stateless.
> I think once authenticated this whole process retires. their should be
> somehow a secure handoff to SSL.
? Most servers willing to test GnuPG authentication are not going to have S=
connections available! Sure, sites can use SSL if it is available, to encry=
the actual transaction data - users will expect that for certain sites - bu=
GnuPG login can be independent of SSL.
The process will retire, but the final act is to set the cookie and to do t=
it needs the help of whatever is handling the cookie, e.g. PHP.
> > Could the daemon actually be a perl script - started by the token reque=
> > and quitting after authentication or a time-out? The ID itself could be
> > put into a database for verification during the session and deleted at
> > logout. This would simplify implementation on existing web servers -
> > requesting a whole new (untested) service is not going to be easy!
> I think their needs to be a script on the server side, and a plugin on
> the client side. I can certainly write Java on either side. my first
> web language was PERL, but that sooo long ago. I still have that PERL
> book though. I prefer Java even server side.
I prefer Perl server-side because it's easier to get supported. Wouldn't Ja=
be a barrier to getting the process on more servers? Not because it won't r=
but because it might not be installed. (Thinking Linux servers here, at lea=
initially.) I know I haven't got Java installed on any test systems or the=
> > I'm willing to implement the daemon/client if someone can help with the
> > code.
> > (This whole idea only started because there's a chicken:egg problem with
> > devising a new protocol.)
> I think still need to investigate ssh first. whatever ssh2 is using to
> authenticate is likely the latest and greatest in mutual
> authentication. plus the code is already written. it just needs to be
> layered on top off a login session.
I use SSH for maintenance - the appeal of gnupg_login would be to simplify =
configuration of existing servers to allow login by trusted users, without=
involving the installation of lots of extra layers.
> Also what is SSL doing? This is actually a form of permanent login. so
> once you login the first time, after that you just sort of 're-login,'
> it seems that SSL authenticates the server first. then lets the server
> do its own client authentication. So if you first login with SSL, then
SSL can't do the login, only encrypt the transaction. SSL doesn't care who =
are, it just enables whoever you are to talk securely to the system on whic=
it is installed.
> give the server your certificate while you are logged in, then
> subsequent logins can use your certificate automatically through SSL, as
Users don't have SSL certificates.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
-----END PGP SIGNATURE-----