Cheap or not, do you really want to start chipping away at the image that people have that a phone call is ubiquitous, reliable, and (relatively) secure transaction in their minds? It took decades of marketing and technical performance to get to that point, why not try to maintain that in the future?
How long did it take the phone companies to finally put an end to blue boxing, and how much money did they lose? Even if the calls are incredibly cheap, it could be easy for people to make incredibly large numbers of them if for nothing else, just for the fun for watching the network crater. Strong security and authentication is important in a system where you have in-band signalling, and everything is visible to (and reproducible by) the end user if not for other users protection, but for the protection of the network itself.
If the fault of the original phone system was that is was a closed system, as is often stated by those working on IP telephony, the fault of the next generation phone system, cheap or not, is going to be security and reliablility if we're not careful.
Brian
-----Original Message-----
From: Henry Sinnreich [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 31, 2000 7:37 PM
To: James A. Donald; Michael Thomas; Henning Schulzrinne
Cc: Michael Thomas; Jonathan Rosenberg; Harris, David [NCRTP:3M12:EXCH];
Sip-Implementors (E-mail); sip
Subject: RE: [SIP] Re: SIP gateways and authentication
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
