Comments below.
At 08:53 PM 8/30/00 -0700, James A. Donald wrote:
> --
>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,
The first line of defense against dictionary attacks in Kerberos is a reasonable
password policy. The paper you cite does nothing to show that a reasonable password
policy is not adequate to prevent these attacks - the paper demonstates attacks
against a Kerberos 4 realm with a very weak password policy. In particular, some users
had passwords with 1 character, some had passwords with 2 characters, etc.
Jonathan
>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
>
>
>
>
>_______________________________________________
>SIP mailing list
>[EMAIL PROTECTED]
>http://lists.bell-labs.com/mailman/listinfo/sip
