--
At 09:02 AM 8/30/2000 -0700, Michael Thomas wrote:
> A cross realm Kerberos based solution would be more than adequate to
> give you a high level of confidence that a piece of information came
> from the realm it claims to have come from.
While you are correct that we should use Kerberos like security
servers, Kerberos itself is broken. It has been broken for some time.
The problem is described in http://theory.stanford.edu/~tjw/krbpass.html,
and with the passage of time the problem becomes ever worse, due to the
increased power of offline dictionary attack hardware and software.
A modern security system, (which kerberos is not) must only permit online
attacks on the password. Kerberos permits offline attacks. In a modern
system the attacker must only be able to test his guesses by using the
guessed password to attempt to establish a secure connection to the
security server. After some large number of consecutive failures, the
security server will temporarily disable the account, and send to the user
an insecure notification containing a log of all information about the
failed attempts. After each successful logon, the system sends the user
information about all previous failed attempts through the secure connection.
The proposal to use PGP keys or verisign keys uses modern security
techniques to solve the wrong problem.
The proposal to use kerberos techniques addresses the right problem in the
right way, but the particular details of the solution are obsolete.
I propose the following EKE like solution, similar to that described in my
web page http://catalog.com/jamesd/kong/secure_video.htm
The user establishes a secure connection with the secure personal presence
server.
The personal presence client logs in to the personal presence server using
the name and password. The password is never revealed to the server. An
outside attacker would have to try his guessed password by attempting to
log on. If he tried lots of logons, this would become noticeable.
The server knows, not the password p , but h(p)*G where G is an elliptic
point that the server makes known to anyone.
When the user created his account, his client software informed the server
of h(p)*G through https. The software ensures that it gave this account
creation information only to the real server, thanks to the usual https
mechanism, which guarantees the server's true name. The server does not
need to verify the users true name.
Lower case letters stand for very large integers, upper case letters stand
for elliptic points. h(x) means "one way hash of x "
The object of the logon protocol is to ensure that the client program is
communicating with a server that knows h(p)*G , and the server knows it is
communicating with a client who knows h(p) In this the protocol differs
from SPEKE, where both the client and the security server both know
p. The implementors have to keep in mind the usual EKE concerns described
in http://world.std.com/~dpj/speke97.html.
When the user logs on he sends the server his logon name in the clear, The
server generates a true random number b , and sends the user b*G .
The client similarly generates a true random number c and sends the server c*G.
An attacker can discover c*G, b*G, and G, but cannot calculate c or b from
this information.
The client then generates the secret elliptic point (b*G)*[c+h(p)]
The server similarly generates the secret elliptic point b*[(c*G)+(h(p)*G)]
, which will be equal to the point generated by the client. This elliptic
point is then used as the symmetric secret key for secure communications
between client and the security server until the user logs off.
In order to succeed with the protocol, in order for the client to construct
a secret elliptic point equal to that of the server, it must know h(p)
corresponding to the server's h(p)*G
Of course, ultimately our objective is not secure communications with the
security server, but secure communications between any two users, and
secure communications between a user and all the various entities that are
involved in setting up his communication.
The simplest way of solving this is the classic DH method, now patent free,
where each entity generates one true random transient public/private key
pair, which lasts the duration of a login session. Each security server
authenticates the public keys of its users and entities, and only the user
or entity knows the private key.
This could potentially lead to a very large number of public key
operations, which are quite slow Because the keys change infrequently,
this problem can be solved by each entity caching the results of previous
public key operations. The cache is discarded when the entity logs out..
When Bob sends an authenticated and secure message to Ann, saying "Hi Ann,
how are things?" it would use intolerable bandwidth if that message, and
each of the various acks and nacks by various entities required to locate
Ann and set up and send the message, required a verisign style public key
signature, or pgp style public key signatue.
Instead, for any two entities, there will be a unique DH shared secret,
constructed from each one's DH key. Each obtains the other's public DH key
from the others security server. That unique shared secret will not change
as long as both entities remain logged on to their security server. Since
each ack and nack will be sent encrypted using that unique and unchanging
shared secret, no public key operations will be needed to prove who is
sending the ack, since only the apparent author or the apparent recipient
could decrypt it or encrypt it. We have only one public key operation per
logon time per pair of entities that need to communicate securely, which
will have an insignificant bandwidth and computational cost, not several
public key operations per ack and nack, as would be required if we employed
a signature system similar to that employed by verisign or PGP.
--digsig
James A. Donald
6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
i4N8MYu3lFyxRz7rj6IX3CMlEt8P5QsQNrYF+dGO
478RouxqobjnPMPR6Cg+Lf/c/t2dukyvpj+QkrgkK
