how to use the gnupg for authenticated logins

[Neil Williams]

--Boundary-02=_y9hN/YG+fH6p7WC
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:55 am, Carl L. Gilbert wrote:

> > > > The server sends the token to the client, encrypted with the trusted
> > > > client key. Once this is verified, the process can be automated from
> > > > the client end:
> > > >
> > > > 1. Client requests connection.
> > > > 2. Server sends a token encrypted with the trusted client key. (Fail
> > > > if no trusted key)
> > > > 3. Client can decrypt this token (preferably using a human entered
> > > > passphrase) and then return the token re-encrypted to the trusted
> > > > server key. (Fail if decrypted token doesn't exactly match text sent
> > > > to the client identified by the token.)
> > >
> > > can't this fall to a record and playback attack?
> >
> > The token has to be a one-off. The random text in the token would only
> > authenticate one client and the server maintains a list of outstanding
> > tokens and the keyID's used to encrypt them. Upon successful
> > authentication, the token is invalidated by the server and deleted from
> > the outstanding list. Together with the need for successful verification
> > of the client signature on the returned token, this should mean that a
> > recorded token is useless as soon as the server receives the real one. A
> > diverted token may be a different problem - have to see if diversion
> > could be defeated by the signature, perhaps include a route/network
> > address inside the signed token. A spoof token cannot be created before
> > the client replies, so the options for record and playback should be
> > limited.
> >

Would you agree that the invalidation of the token and the use of random te=
xt=20
can give some reassurance about replay attacks on this system (should I eve=
r=20
get it operating)?

> > But SSH keeps to the same key - once verified, the key details don't
> > change and any MITM attack can be detected. SSH still leaves the
> > possibility of the client connecting to a false server that first time.

> For me, the fingerprint could be on the receipt in my package when I
> receive my merchandise from the store.  Or it could be displayed on the
> website.  Or I could walk into the bank and pick up a copy, etc.

I agree, the fingerprint used by SSH can be confirmed at this stage using=20
secondary sources - signed emails, packages etc.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Have we worked out a working idea then? Could the trusted key / keysigning =
/=20
random text / encrypted token scheme work as a protocol? (It'll need a bett=
er=20
name!!!)

I just need to work out how to implement it. As far as I can see, the=20
semi-automated human authentication should work fine using existing scripti=
ng=20
languages. The only output to a browser is the ASCII armoured encrypted tok=
en=20
=2D the client can copy it to the clipboard and verify, sign, encrypt and=20
return via a HTML form. It's a fair bit of work for the client though,=20
compared with a username/password, so there would need to be some real=20
goodies to play with once logged in.
:-))

The automated form would need some form of daemon and client, this is where=
=20
GnuPG could win over existing users of username/password combinations - the=
=20
authentication could be transparent and the client would only need to provi=
de=20
their GnuPG passphrase to the local client program. An identification cooki=
e=20
could be set when the token is requested and the cookie updated when the=20
browser refreshes the page after authentication via the client. Would that=
=20
work? (The cookie ID string could be included in the token.)

Provided it is clear to all users that the passphrase DOES stay local and t=
hat=20
all network traffic is encrypted, I think users would be happy. Perhaps a=20
configurable output, much like KMail, where the signed/encrypted data is=20
displayed for user reassurance before transmission. Users who have built up=
 a=20
trust in the software can later set an option in the client config to let t=
he=20
authentication proceed with just the passphrase being entered.

My knowledge of daemons/clients isn't up to doing this well, (better to be=
=20
honest here!), anyone here willing to help?=20

I'd like a daemon that can be queried by PHP/Perl and output the ID string =
for=20
the cookie before authentication. PHP/Perl could then ask the daemon again=
=20
when the page is refreshed. When the daemon/client have completed=20
authentication, the daemon would output a new ID that PHP could use to=20
maintain authentication between pages alongside the usual sessionID. Only i=
f=20
the sessionID and the cookieID match would PHP continue the session.

Could the daemon actually be a perl script - started by the token request a=
nd=20
quitting after authentication or a time-out? The ID itself could be put int=
o=20
a database for verification during the session and deleted at logout. This=
=20
would simplify implementation on existing web servers - requesting a whole=
=20
new (untested) service is not going to be easy!

I'm willing to implement the daemon/client if someone can help with the cod=
e.

(This whole idea only started because there's a chicken:egg problem with=20
devising a new protocol.)


=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=_y9hN/YG+fH6p7WC
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA/Nh9yiAEJSii8s+MRAruPAKDw+66L2xRxCJeU9MzwevfiEcOVswCgv4m9
Zoqp2fVZT/PwDNPKPsw5vUw=
=kW6X
-----END PGP SIGNATURE-----

--Boundary-02=_y9hN/YG+fH6p7WC--