how to use the gnupg for authenticated logins

[Carl L. Gilbert]

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:
> > > 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 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.

> 
> 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 '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.
> 

see above.  their is no trust in that key, servers benefit only.

> > client decrypts random key, and uses it to encrypt a secret message that
> 
> Automated decryption = lack of passphrase = weakness. This weakness must be 
> compensated by a strong identity/trust in the key being used to encrypt the 
> return packet. (lack of passphrase = command-line passphrase / non-human 
> stored passphrase). 
> 

The decryption is as it is today, passphrase optional.  Your first false
assumption is now mushrooming.  You do NOT care about the random key. 
if someone sends you a key, you fully expect them to be able to decrypt
a message encrypted to it.

this passphrase is just an old issue.  if you cant trust the computer
with your keys, you certainly wont be decrypting anything on it.


> Why is it weak? It is weak beacuse the security of the server .gnupg/ becomes 
> your only protection. Also, anyone can encrypt something to my key, I don't 

If the server is not secure, your done.  If the client is not secure,
your done.  If you can find a way around that, patent it.


> 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 could 
> get quite involved and need regular patches according to intrusion logs and 
> aborted attack methods. With automation, you get the War Games scenario - the 
> script will automatically respond to any machine that sends the right 
> packets. Mechanisms must be in place to patch the weakness - prevent repeat 
> attempts > a fixed #, halt processing and alert a real human if certain 
> methods are attempted, etc. Not impossible, just something else to add to the 
> protocol.
> 

I'll leave these complications to the GnuPG writers.

> > 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 
> message in advance of receipt of the token, the harder it will be to return 
> valid content in an attack.
> 

I said secret message, you said trusted key.  same thing.


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

Then you need to tell me how the server is first authenticating this
client that it KNOWS and TRUSTS, before it sends this encrypted random
text.

> This would be better signed, but then we lose the passphrase again. Not 
> insurmountable, but security of the server becomes imperative - you don't 
> 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 encrypted 
> packet is not signed. The secondary protocol just adds complexity and cannot 
> be as secure as the encryption (or else you'd just use the secondary protocol 
> 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 standard 
> becomes essential background reading for the attacker.
> 
> The registration part of the authorisation would be completely human dependent 
> (as in a normal keysigning). 

Ahh, so this is the KNOWN and TRUSTED part.  I agree. The buck stops
here.

> 
> 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?

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

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.


> I'm looking more at a server-automated Biglumber mechanism that does not 
> involve entering the token as clear text over normal HTTP_POST. 
> 
> The process could be fully automated by adapting the client side script, but 
> precautions would be needed to ensure that the login process cannot be 
> 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 - 
> higher privileges for encrypted login, less access for pre-verification 
> username/password (HTTP:AuthType:Basic) authentication.) Making a key 
> trustworthy without verification is inviting anyone to create a authenticated 
> back door.
> 
> 
> BTW. Does anyone here have in-depth knowledge of Kerberos? Is this thread just 
> trying to re-invent Kerberos for GnuPG?

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. 
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.

-- 
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)