Am not sure such complexity is jutified for phone calls having
the cost close to e-mail.
Henry
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of
>James A. Donald
>Sent: Wednesday, August 30, 2000 10:53 PM
>To: Michael Thomas; Henning Schulzrinne
>Cc: Michael Thomas; Jonathan Rosenberg; David Harris;
>Sip-Implementors
>(E-mail); sip
>Subject: Re: [SIP] Re: SIP gateways and authentication
>
>
> --
>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
>
>
>
>
>_______________________________________________
>SIP mailing list
>[EMAIL PROTECTED]
>http://lists.bell-labs.com/mailman/listinfo/sip
