how to use the gnupg for authenticated logins

[Neil Williams]

--Boundary-02=_kZmN/Xbh/yk7HCh
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

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=
y,=20
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=
=20
process has to have some way of communicating with the authentication. (To=
=20
get people to login when they return to a bookmark for one thing - or in th=
e=20
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=
=20
tunnelled through SSH before it can work. It involves more configuration of=
=20
the server. This GnuPG process *should* allow any existing system to bolt-o=
n=20
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.)
3. GnuPG

On Linux servers especially, this is a simple RPM/apt-get and one ./configu=
re=20
make make install. Site-by-site adjustments to make use of the new service=
=20
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=
le=20
installation! Most webhosts will only offer .htaccess, MySQL, GnuPG, PHP an=
d=20
Perl, or less. (Can't see this working with much less than those - MySQL is=
=20
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).
or
Apache, ASP (possibly), Perl, PGP/GnuPG-win, .htacces ( ditto )

MySQL and SSL optional.

Client:
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=
k=20
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=
e=20
signed. The GnuPG passphrase needs to be entered somehow to verify that the=
=20
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=
ess=20
for the existing username/password combo, full access once the client key i=
s=20
signed and has signed the server key. New / unverified users won't be able =
to=20
login using their GnuPG key.

> little complicated, but after that its just the push of a button.  java
> script can handle the rest.

I don't see Javascript being able to do it - Javascript cannot call GnuPG.=
=20
Java maybe, but many Linux clients don't come with Java. More likely a bina=
ry=20
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=
on=20
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=
d=20
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=
nd
> > 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=
th
> > 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=
e.=20
Once the GnuPG key is signed, the website username and password become=20
redundant.

> > 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=
 or=20
Perl scripts via the command line and backticks.
$tokenID =3D `gpg_login --verify-id 234A2D345EBC2342898F`;
# $tokenID might contain 1224510011224004577 for example.
session_register('cookieID');
session_register('cookiesource');
$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 -=
 it=20
can be set to expire, it can be removed on user logout, it will be deleted =
if=20
the browser is closed. The cookie can't be copied to another machine as the=
=20
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=
SL=20
connections available! Sure, sites can use SSL if it is available, to encry=
pt=20
the actual transaction data - users will expect that for certain sites - bu=
t=20
GnuPG login can be independent of SSL.

The process will retire, but the final act is to set the cookie and to do t=
hat=20
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=
st
> > 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=
va=20
be a barrier to getting the process on more servers? Not because it won't r=
un=20
but because it might not be installed. (Thinking Linux servers here, at lea=
st=20
initially.) I know I haven't got Java installed on any test systems or the=
=20
live server.

> > 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 =
the=20
configuration of existing servers to allow login by trusted users, without=
=20
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,'
> automatically.
> 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 =
YOU=20
are, it just enables whoever you are to talk securely to the system on whic=
h=20
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.

=2D-=20

Neil Williams
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
http://www.codehelp.co.uk
http://www.dclug.org.uk

http://www.biglumber.com/x/web?qs=3D0x8801094A28BCB3E3

--Boundary-02=_kZmN/Xbh/yk7HCh
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA/NmZkiAEJSii8s+MRAgEGAJ0c0uEfnGG8625ATQbtNdGmNhG/2ACgjnGz
fiypI2zMA8CjpbEZVaNf31Q=
=jSp/
-----END PGP SIGNATURE-----

--Boundary-02=_kZmN/Xbh/yk7HCh--