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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 2 Apr 2002 09:33:15 -0600

More below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Monday, April 01, 2002 1:57 PM
> To: Peterson, Jon
> Cc: 'William Marshall'; [email-masked]'
> Subject: Re: FW: [Sip] Comment, SIP Privacy draft
> 
> 
> "Peterson, Jon" wrote:
> 
[snip]
> 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.

Okay, so it's not Caller-ID any more, now it's malicious call trace. I don't
immediately see how this is a workable motivation either, though.

In the past, you have said of the Iraqi network example:
> ... Now it just so happens that I
> can't (and won't) want to make a distiction between an untrusted user and
an
> untrusted something else, because it doesn't make any sense to me.

I agree with this, and I think it is at the crux of the matter at hand.
Trusted entities must consider a source from which they receive messages to
either be trusted or untrusted. The way the mechanism currently works, if
the originator of a request is untrusted, trust recipients add 'screen=no'
to any RPIDs in the request. Right? 

Okay, so now we take a user, Carol, and the Iraqi network. Both are
untrusted. Both send request to a trusted proxy, and both requests contain
an RPID. The trusted proxy adds 'screen=no' to each and forwards the
requests along. What fact about the requests, exactly, tells downstream
entities to 'kinda' trust the Iraqi RPID for malicious call trace, but not
to trust Carol's RPID? 

You go on to say:

[snip]
> 
> 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.
> 

What this essentially means, I think, is that although you might not trust
the policies of the Iraqi network to ascertain identity, you still have to
treat it as if it is trusted, because well, that's the degree of certainty
with which the telephone network actually operates. What this means to me is
that you will configure your trusted proxies to treat requests coming from
the Iraqi proxy as if they are trusted - you should not set 'screen=no' on
these requests.

While I don't think Iraqi call trace provides any motivation for keeping
'screen=no' in the draft, this may suggest a requirement for somehow
describing the authentication policy that was used to ascertain someone's
identity (so that downstream entities can determine the degree to which they
should trust a particular RPID). Going down that road, however, would take
us far beyond the ISUP 'presentation restriction' concept, and certainly far
beyond anything in sip-privacy-04 today.

If we do, in the course of this discussion, eventually uncover a need for
'screen=no', I certainly hope it will be documented in sip-privacy-05.

> > 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.
> 
> 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.
> 

I think you for some reason believe I am committed to the position that
signed RPIDs should be removed as 'untrusted'. In my last mail, I suggested
that signatures would render obsolete the concept of intrinsically trusted
or untrusted RPIDs. In this architecture there would be no role needed for
border elements that either set the screen parameter or remove RPIDs. That
whole concept goes away.

I think this is a place where we actually agree, but are using different
semantics. When you say:

[snip] 
> 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.
> 

... I say, "But it isn't 'untrusted' anymore if it has a signature; the
concept of being intrinsically 'untrusted' is no longer meaningful." The end
result is the same - we agree that if an RPID is signed, it shouldn't be
removed.

> 
> 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.
> 

Agreed that it isn't sip-privacy-04's job to define how messages are signed,
it is a general security problem. But I think we also probably agree that
the requirements sip-privacy-04 attempts to fulfill will only be partially
realized without that signing mechanism. 

I'm not arguing (now, anyway) that sip-privacy-04 should be delayed until
the awaited signing mechanism has been invented. All I was saying is that I
think the signing mechanism is completely unrelated to the motivation for
'screen'.

> -- Flemming

_______________________________________________
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: Tue, 02 Apr 2002 12:15:46 -0500

snip snip ...

> to any RPIDs in the request. Right?

Correct.

> entities to 'kinda' trust the Iraqi RPID for malicious call trace, but not

Nobody has argued that an untrusted Remote-Party-Id is a reliable way of
performing call trace. However, if the Iraqi network is actually cooperating
with us, the trace will be performed. Had we removed instead, there would be
absolutely no tracing going on. Reliable and trustworthy - no . Better than
nothing - yes.

> the Iraqi proxy as if they are trusted - you should not set 'screen=no' on

No, that's not what I said. I'm setting "screen=no" becuase I dont' trust it,
but if you request a call trace nevertheless, I will still try and do it since
that's the best we've got.

> semantics.

No - I think you haven't understood the point. A proxy that only uses the
mechanisms defined in the draft will remove a Remote-Party-Id it either doesn't
trust or can't verify. A (future) signature mechanism that can be associated
with a Remote-Party-Id is of no relevance to this proxy since it doesn't
understand it. Thus, despite the fact that it may have been a perfectly valid
Remote-Party-Id, as the signature indicates, the proxy will remove it anyway if
we follow your suggestion.

-- Flemming