Subject: RE: [Sipping] calling number blocking at sip/isup gateway

From: "Christian Huitema" <[email-masked]>
Date: Thu, 24 Jan 2002 14:04:53 -0800

> Christian, where were you when the DCS stuff was first introduced to
> IETF, and the same exact arguments and debates were made? I recall
> making these same arguments over a year back ;) The issue of trust
> boundaries has been the one and only real issue of debate and
discussion
> on this draft.

Well, days have only so many hours...

> As Flemming has pointed out, the R-P-ID header can stay so long as it
is
> within a trust boundary. Now, what one of those is, is a good
question.
> Practically speaking, for any inter-domain call, there will not be
> sufficient trust, and the header is stripped. Thus, anonymous calls
work
> as they should - the From field says anonymous, and there is no other
> identifying information about the caller (except IP addresses for RTP
> and SIP Contact, that is somewhat separate). Because I believe the
data
> will pretty much always be stripped as soon as it leaves the calling
> domain, the draft is far less silly as it might appear. It does solve
an
> important problem - which is a placeholder for a network authenticated
> identity, used to drive services and features in the user's domain.

If there is one thing that you don't want to trust, that is domain
boundaries. If you want information to be placed for eventual use by law
enforcement and not be seen by mere onlookers, or even by the called
party, then that information should be encrypted. For example, you could
encrypt it with a public key that is characteristic of your domain, and
bring the packet to an adequate decryption box that hold the private key
when an enquiry is requested. This would absolutely ensure that the
information never leaks, even if a gateway fails to strip it.

> > Frankly, I don't find this privacy draft useful or adequate. It
attempts
> > to comply with telephony-era regulations that have basically no
meaning
> > in the Internet. In fact, we could probably meet these regulations
by
> > having a much simpler solution that directly target ISUP
compatibility:
> > a calling telephone number header, with a privacy tag, that gateways
to
> > the telephone network could directly translate.
> 
> How would that solve the problem? If I want to be anonymous, this
> information would be inside the INVITE from the caller, and thus no
> privacy assured, for the exact reasons you point out above.

I guess you could solve it the same way, i.e. remove the information if
you are going out of the trusted domain. Or, if we believe in the
encrypted information approach, we could place the encrypted information
or a pointer to it in the ISUP message.

-- Christian Huitema

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 24 Jan 2002 21:20:08 -0500

> Well, days have only so many hours...

Indeed.

> party, then that information should be encrypted.

Right, that is possible too. I thought the draft pointed that out...
time for a re-read I guess. Encryption is a bit complex, though. There
are serious attacks possible with cut-and-paste replay (I snoop a call
from Flemming, copy the encrypted R-P-ID header, and paste it into a
malicious call I make with INVITE. You call the police, you decrypt it,
and find it indicates Flemming made the call, not me....). The
encryption stuff may have been yanked because of these problems.

> you are going out of the trusted domain. 

Right, so we are right back to where we started.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 28 Jan 2002 16:21:35 -0500

> Right, that is possible too. I thought the draft pointed that out...

Indeed it does.

> encryption stuff may have been yanked because of these problems.

In an almost two year old version of the draft, we had the ability to sign the
Remote-Party-ID (rather than just having the "screen" parameter), however,  it
was subsequently pointed out that it was subject to cut-and-past attacks as
you mention, and that it really was part of a much larger SIP security problem
that should be solved instead.

The encryption part has always been there but is only used to hide the
information.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Dean Willis <[email-masked]>
Date: Tue, 29 Jan 2002 11:05:10 -0600

On Monday 28 January 2002 03:21 pm, Flemming Andreasen wrote:
> In an almost two year old version of the draft, we had the ability to
> sign the Remote-Party-ID (rather than just having the "screen"
> parameter), however,  it was subsequently pointed out that it was
> subject to cut-and-past attacks as you mention, and that it really
> was part of a much larger SIP security problem that should be solved
> instead.

The problem is that the ability to use the RPID as an "introduced by" 
token is contingent on being able to sign it, as well as context 
associate it with the session being introduced. Hashing in To, From, 
cand Call-ID headers provides context (which I believe was covered in 
the two-year-old draft). The traditional mechanism for bounding replays 
is to apply temporal information.

I believe Michael objected to temmporizing the signing in that earlier 
draft because of the deifficulty of clock synchronization and of 
describing durations.

However, I think that it might be worth considering what COULD be 
gained from a time-stamped RPID signature. While one might not wish to 
use the resultant programatically as a final authenticator, the 
information might still be useful in making a HUMAN-scale 
interpretation of the RPID.

Opinions?

--
Dean Willis

---

From: "Cullen Jennings" <[email-masked]>
Date: Tue, 29 Jan 2002 09:36:21 -0800

much snipped

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Dean Willis
>  .....

IMHO it is a good idea - mostly because I don't see that it costs very much
to do. It does not completely solve the problem but it makes it far more
difficult to do a cut and paste attack and it greatly reduces the amount of
time this attack can effectively continue to do damage. For some attacks
like loss of privacy issues, breaking the system for any amount of time may
do immeasurable harm but for many other things like toll fraud, minimizing
the gain that can be had from doing the attack may make the attack not worth
doing.

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 29 Jan 2002 21:26:30 -0500

Dean Willis wrote:

> token is contingent on being able to sign it,

That is your contention. While I agree it is a way of solving the
problem
in general, it is also a complicated solution that may be overkill for
several commercially viable architectures. I assume you are talking
public-key cryptography here which means that we not only incur a
computational overhead, but we also have to solve the key
distribution problem and decide upon a proper signature scheme.

> as well as context
> the two-year-old draft).

I don't believe we ever settled on which headers should be covered by
the
signature. The important observation we did make however was, that the
issue of authenticating parts of a SIP message was a general problem and
should be solved as such. We should not have individual headers come up
with their own authentication schemes, etc, but rather take the usual
route
of solving the more general problem. I'm still of that opinion.

> The traditional mechanism for bounding replays

I think it was more than that, but I'll let Mike speak to that.

> interpretation of the RPID.

You are planning on defining a full-fledged signature scheme in
order to make the authentication information trustworthy, yet you
recognize
the practical problems and thus don't really want to rely on it anyway ? 

-- Flemming