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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Sep 2000 02:38:41 -0400

Henning Schulzrinne wrote:
> 
> I'll repeat my question, since the answer matters greatly: are you
> talking about Basic/Digest or PGP authentication?
> 
> Since that's what's implemented, I'm assuming Basic/Digest for now.
> 
> With Basic/Digest, it only matters what name(s) and associated secrets
> the receiving proxy recognizes. If it recognizs gateway:spoiled-milk for
> all request-URIs, that's fine, but it's not clear what establishing a
> canonical user name, realm or password accomplishes.
> 
> In any event, the secret has to be hard-configured for each gateway. For
> the proxy and UA case,
> 
> sip:[email-masked]
> ...realm="foo"
> and
> sip:[email-masked]
> ...realm="foo"
> 
> are different protection spaces.
> 
> As a guide to implementors, it may be useful to indicate that if you
> don't care about different authentications for different request-URIs,
> it makes sense to establish a "global" user name/password/realm that's
> the default challenge if a particular user name doesn't have its own
> realm or set of user names. Similarly, gateways may want to try their
> global user name and secret when challenged.

This is what I am trying to get at. This global username/password/realm
needs to be mentioned somewhere. I suppose since you need to configure a
username/password anyway, you can also configure the realm for this
(i.e., we need not define any special syntax for a global realm). What
we do need to do is ensure that discussion of this concept appears in
the specs, so that implementors support such a concept. The text above
is probably right on target. Can we add it in?

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Maddux, Michel" <[email-masked]>
Date: Fri, 1 Sep 2000 12:04:56 -0500

Jonathan R. writes:

-Jonathan R.

=======================

I agree that the nuances of provide the encryption/trusted system are
interesting.  To me, the most important questions are those that suggest
who/what should be trusted.  From that decision it should follow the best
way (meaning, the best among available tools) to implement the various
levels of protection for the applications.

Here I suggest that we need three levels of "trust":

o the user level; authentication primarily for billing and non-repudiation
type services
o the server level; authentication to establish a trusted relationship from
server to server
o the management level; an imperfect superset of the user level.

The most interesting of these to me falls into the server level plane; e.g.
how can I trust that the information passed to me by proxy X is valid?

thanks. /m.

---

From: "Maddux, Michel" <[email-masked]>
Date: Fri, 1 Sep 2000 12:07:59 -0500

Brian writes: 

[...snip...]

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  

=========

Agreed; the dangers inherent with in-band signaling are readily apparent;
remember the Cap'n Crunch bandit of the '60's phone phreaks.  /m.

---

From: "James A. Donald" <[email-masked]>
Date: Sat, 02 Sep 2000 08:12:38 -0700

--
At 09:59 AM 8/31/2000 -0700, Michael Thomas wrote:
 > 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.

There is nothing special about symmetric key cryptography that makes it 
particularly subject to dictionary attacks.  In all public key solutions, 
the public keys are used to set up a symmetric key that is not subject to 
dictionary attacks.

It is probably possible to set up a system with properties similar to those 
that I outlined using nothing but symmetric key cryptography, though it 
would be more complex, hence harder to understand and harder to get right.

Existing symmetric key solutions (Kerberos) are vulnerable to dictionary attack

Existing public key solutions are hard to use and unpopular.  This is a 
property of the particular implementations, and the particular tasks for 
which they are used, not a property of the underrlying technology

Most proposed alternatives to Kerberos work the same way as kerberos does 
for the user, and are arguably simpler in their internal implementation, 
but employ public key operations internally.

     --digsig
          James A. Donald
      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
      sz1++Q1L/bMWO8371Rxt7o5B/H0Xsn6u/sX227rI
      4PFseTKUfAEU9X1rCbMXXjjvrDk7PeeoknjQHHjJr

---

From: "James A. Donald" <[email-masked]>
Date: Sun, 03 Sep 2000 19:14:25 -0700

--
At 1214 PM 9/1/2000 -0400, Henning Schulzrinne wrote
 > 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.

To make cell phones work satisfactorily, to prevent cloning, the cell phone 
protocol had to be an encryption protocol.

If SIP is secure, it WILL be an encryption protocol, using standard long 
established algorithms, almost certainly protocol analogous to that of 
kerberos, and an algorithm similar to that of SPEKE.

If it is not an encryption protocol, it WILL NOT be secure.

Let us look at what happened with cell phones.

Cell phones were insecure, and suffered cloning, with users who had at all 
times kept complete control over their phone finding themselves charged by 
the phone company with bills of tens of thousands of dollars, and no way to 
prove or disprove who was responsible for those phone calls.

To remedy this problem, crappy encryption was belatedly retrofitted into 
cell phones.  It turned out that the encryption was not good enough, being 
a classic snake oil product, probably concocted by the french spy agency 
who did not want people using good encryption, and a better encryption had 
to be retrofitted.  So the cell phone protocol had to be redone twice, and 
is still fouled up by this process.

     --digsig
          James A. Donald
      6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
      4QR3Fl3XkhVHbkpFuVQ7WaKz+C0cYWlkohKFp1Jm
      4ehFpyOhRgF8Oecry6vjW1k6r/XUV4s8Z4S0MGqoQ