Subject: RE: FW: [Sip] Comment, SIP Privacy draft

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 1 Apr 2002 14:39:37 -0600

A pointed question and a few other comments below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Monday, April 01, 2002 5:56 AM
> To: Peterson, Jon
> Cc: 'William Marshall'; [email-masked]'; Dean Willis; Joerg Ott; Rosen,
> Brian; Rohan Mahy
> Subject: Re: FW: [Sip] Comment, SIP Privacy draft
> 
> 
> 
> 
> 
[snip]
> > > With the present
> > > semantics, some people (I'm one of them) still find it useful from a
pure
> > > caller-id service perspective to have a clear-text caller-id being
presented
> > > although it was untrusted as opposed to having nothing at 

[snip]
> 
> It allows for a network-asserted identity provided by network A to be
delivered
> via network B, even though network B does not trust A.
> 

Yes, you seem to have skipped the question I was building up to... Who is
supposed to be the consumer of the network-asserted identity here, then? You
say above that you want 'screen' for Caller-ID. But in this Iraqi case,
surely if the originating user requested anonymity, no Caller-ID is going to
be displayed (and the From field would be just as good as RPID if anonymity
weren't requested). Since its untrusted, I don't think the RPID could be
used by the network either (for call-trace or billing). So who will be using
the untrusted RPID? I see no reason why the answer isn't 'no one', and that
seems to suggest to me that untrusted RPIDs can be removed at the trust
boundary.

IIRC this is the only example for which you have argued, to date, that
'screen' is necessary. If we can't substantiate a use for 'screen' in this
case, I'm left with the impression that 'screen' is unmotivated.

> >
> > Moreover I've argued that we can dispense with the 'screen'
> > mechanism without solving the more difficult problem of 
> > signing RPIDs.
> 
> Yes you have, and you have also said that we must remove any untrusted
> Remote-Party-Ids. Well, if there in the future is a signature covering the
> Remote-Party-Id (among other things), the end-user can now actually see
who is
> vouching for the Remote-Party-Id, regardless of whether any intermediary
proxies
> trust the previous hop and/or verifies the signature. This makes the
> Remote-Party-Id more generally usable in the future as well, which seems
to be
> something you want to prevent.

Well, fair enough - I'm not averse to discussing this point too, but first
discuss the matter at hand: How would the 'screen' parameter help the
end-user if they could just read the signature of messages? What, if
anything, does this argue in favor of keeping 'screen'?

Now on this other matter, I suspect that the introduction of signatures just
does away with the concept of an intrinsically 'untrusted' RPID, since every
element in the network would be empowered to have its own opinion about
whose RPIDs they trust. In that sense, there would no longer be any border
elements that make trust decisions on behalf of the entire federation. I
have in fact been arguing that the concept of an 'untrusted' RPID isn't
useful and that it should go away, so yes, I agree that signatures would be
an improvement in the mechanism. Indeed, if the mechanism supported per-RPID
signatures you and I would probably be one step closer to agreement, but the
devil is in the details with all this signing/encryption stuff.

> -- Flemming
> --
> Flemming Andreasen
> Cisco Systems

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

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 01 Apr 2002 16:57:13 -0500

"Peterson, Jon" wrote:

> be displayed

Certainly, but call trace may still work. Just becuase the information was
untrusted does not mean it is false. If the Iraqi phone company keeps sending us
false information, we can always put appropriate procedures in place to deal
with that.

> (and the From field would be just as good as RPID if anonymity
> weren't requested).

Not if you want network asserted identity information which is what
Remote-Party-Id gives you.

> Since its untrusted, I don't think the RPID could be
> used by the network either (for call-trace or billing).

It is correct that Remote-Party-Id does not provide for non-repudiation, but if
you really want that, you have a hard problem on your hand. Present day
telephony and data service provide trace solutions without any resemblance of
such guarantees and I suspect they will continue that way for a while.

> So who will be using

As I have explained many times already, untrusted does not equal useless in my
philosophy book. Furthermore, if you remove it, you can't provide a more secure
solution (read: crypto signature) in the future for this mechanism without
having everybody being able to verify such signatures. Any intermediary not able
to do that will will impose it's ugly policy on you and remove it even though
the signature could perhaps be verified by somebody else.

> anything, does this argue in favor of keeping 'screen'?

If you don't have screen, you need to specify that you remove
unverified/untrusted Remote-Party-Id. If you remove untrusted Remote-Party-Id,
you require all intermediaries to be able to either trust or verify a given
Remote-Party-Id. If you have a signature on a Remote-Party-Id, you don't want to
remove an untrusted Remote-Party-Id since a downstream entity can verify the
signature to determine authenticity.

> Indeed, if the mechanism supported per-RPID

If you had paid any attention to previous (and even fairly recent) discussions
about this draft, you would know that it used to have a signature mechanism, but
it was noted that it was a special case of a general security problem. General
problems should have general solutions, and hence we are waiting for the
security gurus to come up with that general security solution which could, among
other things, sign Remote-Party-Ids. This consensus has been formed long time
ago and was repeated recently.

-- Flemming