Subject: RE: [Sip] Questions/Comments on privacy-04 draft

From: "George Foti (LMC)" <[email-masked]>
Date: Tue, 5 Mar 2002 10:35:22 -0500

Thanks for the clarification.
I agree that the untrusted UAC should not include a Remote-Part-ID, but the
draft must deal with that case anyways.
I still have one more clarification:

> 
> Section 5 says that "If the proxy wants to ensure, that the 
> calling party can be
> identified by the called party, the proxy MUST..." (note the 
> "if").

So if an untrusted UAC included a Remote-Party-ID,  and the proxy is able to
*validate* that (via some means) and consequently set the screen to YES, it
is then up to the proxy (i.e  it is optional)  if it wants to include yet
another  Remote-Party-ID  or not.
Of course if validation fails or cannot be done, then the proxy *MUST*
include a Remote-Party-ID  if the request is to be forwarded to another
trusted entity.

Is this a correct interpretation ?

/gf

_______________________________________________
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, 05 Mar 2002 11:06:29 -0500

> draft must deal with that case anyways.

Right (and it does).

> another  Remote-Party-ID  or not.

Yes.

> Is this a correct interpretation ?

Not entirely. There is no absolute requirement that the proxy includes a
Remote-Party-Id. If the proxy can determine the identity of the subscriber, then
it SHOULD include a corresponding Remote-Party-Id. However, if the proxy cannot
determine the identity, it may reject the request or simply forward it without
adding a Remote-Party-Id.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Michael Thomas <[email-masked]>
Date: Tue, 5 Mar 2002 17:42:27 -0800 (PST)

> > another  Remote-Party-ID  or not.

   I don't understand: which one does the UAS choose
   if there are two RPID's?

   I have another question: suppose that the UAC puts
   an RPID into an SMIME body. What is the
   intended behavior of the proxy? The UAS?

		     Mike

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 5 Mar 2002 20:54:01 -0600

>    I don't understand: which one does the UAS choose

All of them? It's not a singular proposition. There are identities asserted.
I've got six different identities associated with my PGP key. What's the
problem?

>    intended behavior of the proxy? The UAS?

Ooh, that's a good one. That's why I wanted to know who it was that asserted
the RPID. Even better, I like to be able to verify that assertion.

--
Dean

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 06 Mar 2002 09:11:56 -0500

>    I don't understand: which one does the UAS choose

That's a local UA decision.

>    intended behavior of the proxy? The UAS?

The use of bodies is fundamentally incompatible with network asserted identity, since
proxies are not allowed to modify bodies (shouldn't even look at them). This should
probably be stated explicitly. Currently, the draft only specifies that end-to-end
encrypted Remote-Party-Id's cannot be trusted.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 06 Mar 2002 09:27:50 -0500

Michael Thomas wrote:

> Dean Willis writes:
>    Well, if a proxy isn't capable of scrubbing
>    previous RPID's, the UAS gets the choice of
>
>    Remote-party-id: [email-masked]
>    Remote-party-id: [email-masked]
>
>    What could possibly be useful about [email-masked]
>    when it could chose The King? Seriously, if RPID
>    is good for anything, it's to inform a UAS (and
>    likely the user) who's calling as known by the
>    service provider. Since there might be multiple RPID's
>    the UAS has no way to determine which one the proxy
>    inserted. Without cryptographic identity or scrubbing,
>    I simply don't understand how this is in any
>    way enforceable.
>

There is a screening indicator to indicate which one(s) the proxy believe are
valid. Normally, I would expect a single identity (per type), but if there are
multiple valid identies, I don't see a problem with that.

>    Yes. Thus my protestations that we're solving
>    the wrong problem. :-(

Well, I've been hearing these statements for the past 2+ years without seeing any
solutions - time's up IMHO.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Mar 2002 06:11:35 -0800 (PST)

Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Mar 2002 07:16:04 -0800 (PST)

> multiple valid identies, I don't see a problem with that.

   I still don't understand. If the proxy cannot
   remove a RPID header, a malicious UAC can clearly
   clone an identical RPID, screen=yes and all. Since
   the draft only says that a proxy MAY reject the
   request, there's nothing which necessarily enforces
   misbehaving UAC's from sending "trustworthy" RPID's.

   IMO, either you make it normative that a proxy MUST 
   reject a UA which inserts RPID, or explicitly state
   that a UA MAY add RPID. The meta-state in the current
   draft leaves UAS's with complete ambiguity as to which
   one is trustable.

   Another problem I see: what if I run an untrusted
   proxy at home? Note that the trust issue is as seen by
   the downstream service provider's proxy, not by
   my proxy. In that case, mine quite reasonably might
   add RPID. Yet across the trust boundary, the downstream
   proxy would like to assert its version of RPID. Here
   it seems unreasonable to reject the message since
   my proxy is doing a perfectly legitimate proxy
   function. This would yet again lead to several 
   different RPID's where the UAS would have no
   clue which one was more trustworthy.

   What I think this boils down to is that
   prohibiting UA's from inserting RPID is
   somewhere between useless and dangerous. 
   Without the ability to scrub those headers,
   the trusted proxies are either defenseless,
   or put in a position of rejecting perfectly
   reasonable messages from other proxies. 
   Something needs to give here. Either you
   allow scrubbing, or you require cryptographic
   identity (or both). The current security of
   this draft is not adequate, and since a 
   generalized approach to crypto has been
   vetoed, I think this entire issue needs to
   revisited.

 > solutions - time's up IMHO.

   Uh, I sure hope you're not impling that I had
   anything to do with the decision making here.

   In any case, you didn't answer the original
   question.

		Mike

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 06 Mar 2002 10:40:49 -0500

>    misbehaving UAC's from sending "trustworthy" RPID's.

The draft very clearly states in Section 7.5 that the proxy either sets the screen
parameter to "no" or removes the Remote-Party-ID - what's the problem ?

>    draft leaves UAS's with complete ambiguity as to which

Two problems here. First of all, the proxy may not know what the previous hop is.
Secondly, trusted UAs do in fact include Remote-Party-Ids. As far ambiguity goes, the
screen parameter is there to tell the UA if the Remote-Party-Id is trustworthy or not.

>    proxy would like to assert its version of RPID.

Right, and since the draft deals with network asserted caller-id, the one your proxy
added will be deemed untrustworthy by having screen=no, unless it could be verified.

> Here

It seems you have missed the screen parameter function.

>    somewhere between useless and dangerous.

Nowhere in the draft does it say that a UA cannot insert a Remote-Party-Id (in fact,
trusted UAs do as described in the draft). As far as useless and dangerous goes, I don't
follow either of them.

>    identity (or both).

I repeat:     scrubbing and setting "screen=no" are both allowed.

> The current security of

We have been down this path countless times without any kind of resolution. I have no
reason to believe that this will change anytime soon and hence see no reason to repeat
this yet again. There has been ample opportunity to come up with something better, but
nothing has emerged. There is an applicability statement and an architecture description
that points out the scenarios and assumptions under which the mechanism is useful and
where it is not. I don't see the big problem here.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Mar 2002 08:06:33 -0800 (PST)

> parameter to "no" or removes the Remote-Party-ID - what's the problem ?

   It seems I've been led astray by the discussion here
   which led me to believe that the scrubbing/rewriting
   parts of the draft had been removed, and the "final"
   decision on the calls that RPID couldn't be included 
   by a UA. I guess I missed when that was
   reversed (again). So I guess I'm OK with this.

   Two comments though: in section 6.5, it
   repeatedly says that there should only be one
   screen= tag, but it doesn't explicitly say that
   the intended behavior is that it should be
   rewritten. This is somewhat confusing. Second,
   in section, 5.1 it says that screen=no should
   take precedence over screen=yes? Am I misreading this?

	       Mike

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 06 Mar 2002 11:38:14 -0500

Michael Thomas wrote:

>
>
>    Two comments though: in section 6.5,

7.5 I presume

> it
>    rewritten. This is somewhat confusing.

Right now it talks about the proxy adding one screen parameter and making sure this is the
only one. You could talk about rewriting an existing one if it existed, but it doesn't
seem to change anything from a functional point of view.

> Second,
>    in section, 5.1

6.1 I presume

> it says that screen=no should

No. The header definition essentially says, that if you see a Remote-Party-Id with more
than one screen parameter, then you shouldn't treat it as an error, but just go with the
"no" value if present. The behavior section on the other hand says, that you don't include
more than one screen parameter - it's the "be liberal in what you accept" philosophy.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Michael Thomas <[email-masked]>
Date: Wed, 6 Mar 2002 09:00:56 -0800 (PST)

> seem to change anything from a functional point of view.

   I'm only commenting that the current text is
   rather oblique about what to do if there is
   a screen parameter already, but it is wrong
   from the point of view of the examining proxy.
   If the intended behavior is to rewrite it alone,
   it would be helpful to state that in the same
   place it states that it needs to differentiate
   the cases.

 > more than one screen parameter - it's the "be liberal in what you accept" philosophy.

   I think you're misunderstanding me. This section implies
   that a UA should prefer a screen=no RPID over a 
   screen=yes RPID. That seems reversed to me.

	      Mike

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 06 Mar 2002 14:43:53 -0500

>    place it states that it needs to differentiate

OK

>    screen=yes RPID. That seems reversed to me.

Not within a single Remote-Party-Id - if it both indicates that it is trustworthy ("yes") and non
trustworthy ("no"), then I would say it's not trustworthy. If on the other hand there is one
Remote-Party-Id that was screened ("yes") and one there was not ("no"), then I agree you'd be
better off using the screened one, but that is not what the precedence is talking about.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Michael Thomas <[email-masked]>
Date: Thu, 7 Mar 2002 08:57:46 -0800 (PST)

> better off using the screened one, but that is not what the precedence is talking about.
 
   OK, I'm now even more confused. It says that there
   aren't supposed to be multiple screen= tags though. As in, a
   compliant proxy shouldn't do that. If what you're
   saying is that if a UA receives a RPID with multiple
   screen= tags it should consider it untrusted, I agree
   but the text is not very clear here: it seems to 
   saying that if you get multiple *RPID's* you
   should prefer screen=no, which I think we agree
   is not how it should be interpreted.

	  Mike

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 11 Mar 2002 10:03:33 -0500

Michael Thomas wrote:

>    but the text is not very clear here:

Hmm, it says "Multiple rpi-screen parameters MAY be present in a Remote-Party-ID - if both "yes" and
"no" are present, "no" will take precedence."

Notice that it says "*a* Remote-Party-ID", not multiple.

> it seems to

Right.

-- Flemming

--
Flemming Andreasen
Cisco Systems