It looks like your argument is not with the SIP WG
but with the CAT WG. I'm sure a lot of folks there
would be willing to entertain (or not) this
argument. In particular, the assertion that that
Kerberos is inherently subject to dictionary
attacks looks more like an indictment against
symmetric key cryptography in general, rather than
Kerberos in particular.
Mike
James A. Donald writes:
> --
> 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
>
>
>
