how to use the gnupg for authenticated logins

[Carl L. Gilbert]

--=-qC21XIC0aqX2TXRobC2v
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2003-08-10 at 06:33, Neil Williams wrote:
> On Sunday 10 Aug 2003 1:55 am, Carl L. Gilbert wrote:
>=20
> > > > > The server sends the token to the client, encrypted with the trus=
ted
> > > > > client key. Once this is verified, the process can be automated f=
rom
> > > > > the client end:
> > > > >
> > > > > 1. Client requests connection.
> > > > > 2. Server sends a token encrypted with the trusted client key. (F=
ail
> > > > > if no trusted key)
> > > > > 3. Client can decrypt this token (preferably using a human entere=
d
> > > > > passphrase) and then return the token re-encrypted to the trusted
> > > > > server key. (Fail if decrypted token doesn't exactly match text s=
ent
> > > > > 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 onl=
y
> > > authenticate one client and the server maintains a list of outstandin=
g
> > > tokens and the keyID's used to encrypt them. Upon successful
> > > authentication, the token is invalidated by the server and deleted fr=
om
> > > the outstanding list. Together with the need for successful verificat=
ion
> > > 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 befo=
re
> > > the client replies, so the options for record and playback should be
> > > limited.
> > >
>=20
> Would you agree that the invalidation of the token and the use of random =
text=20
> can give some reassurance about replay attacks on this system (should I e=
ver=20
> get it operating)?
>=20

I don't see why it has to be this way.  They already know each others
keys.  So their is nothing special required at this point.

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.

Its pretty simple if both share each others keys.  nothing can be
replayed because the random message changes every time.

> > > 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 tim=
e.
>=20
> > 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.
>=20
> I agree, the fingerprint used by SSH can be confirmed at this stage using=
=20
> secondary sources - signed emails, packages etc.
>=20
> =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
>=20
> Have we worked out a working idea then? Could the trusted key / keysignin=
g /=20
> random text / encrypted token scheme work as a protocol? (It'll need a be=
tter=20
> name!!!)
>=20

I think it will work.  But I also suspect its probably already
invented.  Somebody said its like SSH1.  So investigate SSH1 and SSH2
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.

> 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 scrip=
ting=20
> languages. The only output to a browser is the ASCII armoured encrypted t=
oken=20
> - 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.
> :-))
>=20

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
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
little complicated, but after that its just the push of a button.  java
script can handle the rest.

also their is the issue of client side disk access.=20


> The automated form would need some form of daemon and client, this is whe=
re=20
> GnuPG could win over existing users of username/password combinations - t=
he=20
> authentication could be transparent and the client would only need to pro=
vide=20
> their GnuPG passphrase to the local client program. An identification coo=
kie=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 tha=
t=20
> work? (The cookie ID string could be included in the token.)
>=20

I am lost in what role the token you keep mentioning is playing.

> Provided it is clear to all users that the passphrase DOES stay local and=
 that=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=
 the=20
> authentication proceed with just the passphrase being entered.
>=20

I would suggest eliminating the passpharase totally.  Only allow it to
be added manually by advanced users.  Otherwise it could complicated
things as users get confused about the difference between their local
key passpharas and their website password.

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

you speaking of something running on the server and talking to apache?

> I'd like a daemon that can be queried by PHP/Perl and output the ID strin=
g for=20
> the cookie before authentication. PHP/Perl could then ask the daemon agai=
n=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=
 if=20
> the sessionID and the cookieID match would PHP continue the session.
>=20

not to sure about the security of cookies.

I think once authenticated this whole process retires.  their should be
somehow a secure handoff to SSL.


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

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'm willing to implement the daemon/client if someone can help with the c=
ode.
>=20
> (This whole idea only started because there's a chicken:egg problem with=20
> 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.

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
give the server your certificate while you are logged in, then
subsequent logins can use your certificate automatically through SSL, as
a replacement for your password.

can this work?

--=20
Thank you,


CL Gilbert
"Then said I, Wisdom [is] better than strength: nevertheless the poor
man's wisdom [is] despised, and his words are not heard." Ecclesiastes
9:16

GnuPG Key Fingerprint:
82A6 8893 C2A1 F64E A9AD  19AE 55B2 4CD7 80D2 0A2D
GNU Privacy Guard http://www.gnupg.org (Encryption and Digital
Signatures)

--=-qC21XIC0aqX2TXRobC2v
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

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

iD8DBQA/NjxSVbJM14DSCi0RAtMuAKDgW25nr2or3IUIES2+Gats5OQ1igCeJYU9
Fs2sh2VqIUEh4egjDmKqjNU=
=5Ssy
-----END PGP SIGNATURE-----

--=-qC21XIC0aqX2TXRobC2v--