how to use the gnupg for authenticated logins

Neil Williams
Sat Aug 9 00:47:02 2003

Content-Type: text/plain;
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=
that this is a suitable random key and not an attacking random key? IP's ca=
be spoofed.

If the key can be trusted, why send it at all? It must be known to the clie=
to be trusted, so the client doesn't need the key. Use the 'secret message'=
(which might as well be random text) and encrypt that. The client decrypts=
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=
return packet. (lack of passphrase =3D command-line passphrase / non-human=
stored passphrase).=20

Why is it weak? It is weak beacuse the security of the server .gnupg/ becom=
your only protection. Also, anyone can encrypt something to my key, I don't=
want to decrypt and automatically process something that could be malformed=
possibly exposing an exploit in another part of the system. This decryption=
wouldn't be a simple script - the error-handling and security routines coul=
get quite involved and need regular patches according to intrusion logs and=
aborted attack methods. With automation, you get the War Games scenario - t=
script will automatically respond to any machine that sends the right=20
packets. Mechanisms must be in place to patch the weakness - prevent repeat=
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=

> 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=
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=
valid content in an attack.

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


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=
to create a lovely back-door.

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

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

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 en=

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 passphra=
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.)

Personally, I don't need a system that is fully automated - I'm looking at =
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,=
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=
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=
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=
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=
back door.

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


Neil Williams

Content-Type: application/pgp-signature
Content-Description: signature

Version: GnuPG v1.2.1 (GNU/Linux)