how to use the gnupg for authenticated logins

[Neil Williams]

--Boundary-02=_qjCN/nBq+J+RVBM
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Friday 08 Aug 2003 10:10 pm, Carl L. Gilbert wrote:
> On Fri, 2003-08-08 at 14:08, Neil Williams wrote:
> > On Thursday 07 Aug 2003 11:40 am, Sharad Sahu wrote:
> This whole thing must be automated or its going to be inconvenient.

I'd like to agree, but I am cautious and cynical.

> server sends a random key encrypted.

Why a random key? How can a random key be trusted? How will the client know=
=20
that this is a suitable random key and not an attacking random key? IP's ca=
n=20
be spoofed.

If the key can be trusted, why send it at all? It must be known to the clie=
nt=20
to be trusted, so the client doesn't need the key. Use the 'secret message'=
=20
(which might as well be random text) and encrypt that. The client decrypts=
=20
it, sends it back re-encrypted to the server key.

> client decrypts random key, and uses it to encrypt a secret message that

Automated decryption =3D lack of passphrase =3D weakness. This weakness mus=
t be=20
compensated by a strong identity/trust in the key being used to encrypt the=
=20
return packet. (lack of passphrase =3D command-line passphrase / non-human=
=20
stored passphrase).=20

Why is it weak? It is weak beacuse the security of the server .gnupg/ becom=
es=20
your only protection. Also, anyone can encrypt something to my key, I don't=
=20
want to decrypt and automatically process something that could be malformed=
 -=20
possibly exposing an exploit in another part of the system. This decryption=
=20
wouldn't be a simple script - the error-handling and security routines coul=
d=20
get quite involved and need regular patches according to intrusion logs and=
=20
aborted attack methods. With automation, you get the War Games scenario - t=
he=20
script will automatically respond to any machine that sends the right=20
packets. Mechanisms must be in place to patch the weakness - prevent repeat=
=20
attempts > a fixed #, halt processing and alert a real human if certain=20
methods are attempted, etc. Not impossible, just something else to add to t=
he=20
protocol.

> the server and the client already know from previous communication (like

The client doesn't need to have any prior knowledge of the message or token=
,=20
only a trusted key. The less the client knows about the content of the=20
message in advance of receipt of the token, the harder it will be to return=
=20
valid content in an attack.

> a password).
> server decrypts message.
>
> if all is well, we have mutual authentication with both ways encryption.

Alternative:

Server sends random text encrypted to a KNOWN and TRUSTED client key
This would be better signed, but then we lose the passphrase again. Not=20
insurmountable, but security of the server becomes imperative - you don't=20
want someone hacking the server box and sending signed tokens to themselves=
=20
to create a lovely back-door.

Client must rely on a secondary protocol to identify the server if encrypte=
d=20
packet is not signed. The secondary protocol just adds complexity and canno=
t=20
be as secure as the encryption (or else you'd just use the secondary protoc=
ol=20
for the entire transaction). The secondary protocol would have to be public=
=20
(the client needs to be able to verify the content), so the protocol standa=
rd=20
becomes essential background reading for the attacker.

The registration part of the authorisation would be completely human depend=
ent=20
(as in a normal keysigning).=20

The server sends the token to the client, encrypted with the trusted client=
=20
key. Once this is verified, the process can be automated from the client en=
d:

1. Client requests connection.
2. Server sends a token encrypted with the trusted client key. (Fail if no=
=20
trusted key)
3. Client can decrypt this token (preferably using a human entered passphra=
se)=20
and then return the token re-encrypted to the trusted server key. (Fail if=
=20
decrypted token doesn't exactly match text sent to the client identified by=
=20
the token.)

Personally, I don't need a system that is fully automated - I'm looking at =
a=20
system of semi-automation where the server responds but a human (not a=20
process) is logged in. In my scenario, I can (must) insist on a human=20
operating the client machine during the authentication process (after all,=
=20
the purpose of the login for my system is for the authenticated user to=20
achieve something personal and variable within the site, like update person=
al=20
details, check reports and data, send messages etc.).

I'm looking more at a server-automated Biglumber mechanism that does not=20
involve entering the token as clear text over normal HTTP_POST.=20

The process could be fully automated by adapting the client side script, bu=
t=20
precautions would be needed to ensure that the login process cannot be=20
initiated by a new member who has not been verified by the usual keysigning=
=20
party process. (This is why I'm interested in a two-tier login system -=20
higher privileges for encrypted login, less access for pre-verification=20
username/password (HTTP:AuthType:Basic) authentication.) Making a key=20
trustworthy without verification is inviting anyone to create a authenticat=
ed=20
back door.


BTW. Does anyone here have in-depth knowledge of Kerberos? Is this thread j=
ust=20
trying to re-invent Kerberos for GnuPG?

=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=_qjCN/nBq+J+RVBM
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA/NCjqiAEJSii8s+MRArexAJ4n7h0GEdVm+WyOq81ZwyxAmtyhOACfeLrM
orJfPadceBA95bxu92Hj5GU=
=WlS4
-----END PGP SIGNATURE-----

--Boundary-02=_qjCN/nBq+J+RVBM--