From: Bill Stewart <stewarts@ix.netcom.com>
Date: Thu, 28 Sep 95 01:40:08 PDT
To: patrick@Verity.COM (Patrick Horgan)
Subject: Re: Looking for advice.
Message-ID: <199509280839.BAA03015@ix6.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


At 09:58 PM 9/27/95 -0700, you wrote:
>For two programs communicating via TCP/IP and exchanging authentication
>information, I want to make sure that the authentication info, (user's
>name and password,) doesn't pass in the clear.  I can think of a few
>ways to handle this.  
>
>1) Encrypt via shared key using symetric encryption.
>   This works but key management is a problem.
>2) Encrypt via public keys using public key encryption.
>   There's licensing issues, and how do you generate public and private
>   pairs for all of the programs?  That could be a lot of primes!
>3) The "server" could keep user names and passwords stored as hashed values.
>   That way the "client" could do a hash (MD5?) before sending it.
>   This has the drawback of the server not having access to the unhashed
>   values...if it needs that access this method won't work.

[Perry Metzger often has good comments about the order of doing things in.]

Are you planning to encrypt your sessions, or not?  What threats are you 
worried about?  What threats are you aware of but not worried about?
How much opportunity do the users of the programs have to set up communications
beforehand?  Is this one-shot, or will a given client and server do a lot
of repeat business?  Are you concerned about privacy from machine to machine,
or also from user to user?  Are you worried about man-in-the-middle attacks?
Are you worried about protecting the user's name, or only their password?
Are you willing to buy hardware, or do you want software-only?
How critical is setup speed?  How slow are your processors?
Are you worried about your TCP sessions getting hijacked once you've
done the authentication?

For some applications, Diffie-Hellman is a good answer - the basic protocol
doesn't do authentication, but does do secure key negotiation as long as you
either don't have a man-in-the-middle or else have authentication such as
digital signatures on your key-parts.  Once you've created a shared key
by DH, you can then use it to encrypt your session, or at least exchange 
passwords securely.

If you're willing to buy a bit of hardware, there are cryptographic smartcards
that let you generate time-varying one-time passwords; some of them are decent.

Phil Karn's S/Key technology (ftp-able from and I think patented by Bellcore)
takes a nice approach using hash functions - let h^n(m) denote message m cranked
through hash function h n times, = h(h(h(...(h(m))...))), where h is a secure
one-way hash like MD4 that's tolerably fast.  To set up, calculate h^n(m),
and store it in the server's password file.  When you log in for the first time,
the server tells you n-1, you calculate h^(n-1)(m), send it as your password,
the server hashes it to get h^n(m), and compares it with the saved value.
If it works, the server now saves h^(n-1)(m); the next time it'll ask you for
n-2, you give it h^(n-2)(m), the server hashes to get h^(n-1)(m), etc.
Obviously you've got to reset after n-1 uses.

If you have an environment where you can store secret keys safely on the server,
you can use secret-key challenge-response methods effectively - the server
sends a random number, and you send back the number, encrypted, or there are
variants where you modify the number by 1, with or without timestamps,
and maybe the server sends the number encrypted also.  If you can't secure
a general-use machine, but are able to secure a machine that just does
authentication and keep it locked in a room with only network access and power,
pretty soon you've invented Kerberos.

Do you need separate public keys for each application X user?  Depending on what
you're trying to authenticate, you could have a public key for the application
or even just the machine it runs on, and send passwords encrypted with that;
again there are variants with timestamps, random challenges, etc., to deal
with issues like replay attacks.  Or maybe you can have the server issue
random numbers as challenges that you sign with your registered public key.
If you do that, though, better have the server sign with _its_ public key also,
since you'd probably rather not just go signing any random number anybody
hands you.  And what if there's a man in the middle there helping you log on...?
#---
# Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---