how to use the gnupg for authenticated logins

[Neil Williams]

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

On Saturday 09 Aug 2003 4:53 am, Carl L. Gilbert wrote:
> On Fri, 2003-08-08 at 18:49, Neil Williams wrote:
> > On Friday 08 Aug 2003 10:10 pm, Carl L. Gilbert wrote:
> > > On Fri, 2003-08-08 at 14:08, Neil Williams wrote:
> > > server sends a random key encrypted.
> >
> > Why a random key? How can a random key be trusted? How will the client
> > know that this is a suitable random key and not an attacking random key?
> > IP's can be spoofed.
>
> if its random, then you don't need to trust it by definition.  That key
> is sent so that the server can auth the client only.  no information can
> be gained by a false server sending a key because the client would never
> be able to decrypt it.

A random key cannot verify the server to the client. Your authentication is=
=20
only one-way.

The random key has to be encrypted to the client key, which is public. Anyo=
ne=20
can encrypt a random key to a public key of a client. As the random key is=
=20
untrusted, the client has no way of knowing that the real server has sent i=
t.

A false server using a spoofed IP can send a random key encrypted with the =
key=20
of the client - the client imports the key and encrypts the token back to t=
he=20
false server - classic man-in-the-middle attack. The false server may not=20
gain any information from the real server but if the client is fooled by=20
MITM, the false server could pick up all sorts of data as the client believ=
es=20
it is the real server and starts using the services.

You can't encrypt a random key to itself, no-one would be able to decrypt i=
t.=20
Anyone can encrypt to my key, I will be able to decrypt anything sent=20
encrypted with my key. I cannot decrypt tokens encrypted with any other key=
s,=20
random or otherwise. For the client to decrypt the token containing the=20
random key, the token must be encrypted with the client key. When that key =
is=20
publicly available, the attack is in motion.=20

If you make it a random key encrypted with a known server key, you have to=
=20
distribute the server secret key - not healthy.
If you don't encrypt it, you have to verify the client - anyone can encrypt=
 to=20
a random key sent in plain text - and you still haven't verified the server.

> > If the key can be trusted, why send it at all? It must be known to the
> > client to be trusted, so the client doesn't need the key. Use the 'secr=
et
> > message' (which might as well be random text) and encrypt that. The
> > client decrypts it, sends it back re-encrypted to the server key.
>
> see above.  their is no trust in that key, servers benefit only.

If the client cannot trust the server key, there is nothing for the client =
to=20
trust in the authentication.

> The decryption is as it is today, passphrase optional.  Your first false
> assumption is now mushrooming.  You do NOT care about the random key.

I do if I cannot verify that it belongs to the server I think it should bel=
ong=20
to.

> > 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=20
authenticate one client and the server maintains a list of outstanding toke=
ns=20
and the keyID's used to encrypt them. Upon successful authentication, the=20
token is invalidated by the server and deleted from the outstanding list.=20
Together with the need for successful verification of the client signature =
on=20
the returned token, this should mean that a recorded token is useless as so=
on=20
as the server receives the real one. A diverted token may be a different=20
problem - have to see if diversion could be defeated by the signature,=20
perhaps include a route/network address inside the signed token. A spoof=20
token cannot be created before the client replies, so the options for recor=
d=20
and playback should be limited.

> yes, not full automation.  but like ms passport is using, or like
> browsers that use recorded passwords.  My objective is to trade in a
> password for a PGP key.  So every time I go to a new web board or new
> web store, I can trade the password they give me, for my PGP key.

That seems a long way off. These sites don't know anything about PGP or Gnu=
PG=20
and I can't see many offering the trade.

> This is my feelings.  I am actually telling about a true system that I
> have worked on that is used in cars.  just to show how its done there.

So the real system has no means for the client to verify the server???
I wouldn't touch it!

> But not really recommending it because computers already have so many
> encryption systems.  ssh is a dually authenticated and encrypted
> channel.  Its basically what we want to mimic here.

But SSH keeps to the same key - once verified, the key details don't change=
=20
and any MITM attack can be detected. SSH still leaves the possibility of th=
e=20
client connecting to a false server that first time. Your proposed random k=
ey=20
would leave the client open to MITM EVERY time because the client cannot=20
verify that the server is the same one as before. A simple IP spoof, a subt=
le=20
change in the URL and the client is talking to your competitor / enemy!

Authentication needs to protect the client data as well as the server data.

=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?sn=3DNeil+Williams


--Boundary-02=_7VTN/JySCBF2p91
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA/NTV7iAEJSii8s+MRAtcRAJ9+MCskjkuf5z2K3ZpcWerUJvZnJACfZnir
Cq+C3GyH/AO6J2XeD/0HtNw=
=Q5nt
-----END PGP SIGNATURE-----

--Boundary-02=_7VTN/JySCBF2p91--