Subject: RE: [SIP] Re: SIP gateways and authentication

From: "Brian Stucker" <[email-masked]>
Date: Fri, 1 Sep 2000 10:10:22 -0500

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-masked]]
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-masked]
>[mailto:[email-masked]]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-masked]
>http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 01 Sep 2000 12:14:32 -0400

Trimming cc list since everybody is presumably on the SIP list.

Note that authentication has at least three very different roles:

- authenticate SIP caller to callee (or caller-id-providing gateway to
callee) - this has nothing to do with whether charging is involved or
not. This was the topic of discussion.

- authenticate SIP caller to gateway (SIP authentication)

- authenticate resource reservation requests (where resources may
include, particularly for wireless, basic IP connectivity)

The third is independent of SIP, but may benefit from some SIP-related
information. See the OSP-related drafts. In general, this is more of a
AAA topic than a SIP topic and probably belongs there. Most of the
"charging for phone call" debates belong into this third category.

As has been said a few times on this list already: This group is *not*
chartered to develop new encryption or authentication algorithms or
protocols. Application of existing algorithms, if described in
sufficient detail, are obviously appropriate (although the danger of
having twenty different algorithms and protocols is great).

---

From: Matt Holdrege <[email-masked]>
Date: Fri, 01 Sep 2000 10:24:17 -0700

>not. This was the topic of discussion.

Not to try to extend useless debate, but this does involve charging. Think 
about the 900 service we have in the U.S. The callee bills the caller per 
minute. But since he doesn't have an indisputable method of billing, the 
callee uses the phone company to handle the authentication and billing. But 
in the SIP world, we can offer the callee an indisputable method of 
authentication that he can use for billing.

I'm sure some people smarter and richer than I will think of lots of ways 
to make money along these lines.