Subject: [Sipping] Privacy comment (was Re: calling number blocking at sip/isup gate way)

From: "Mark Watson"<[email-masked]>
Date: Tue, 19 Feb 2002 20:28:46 -0000

As presently described in privacy-03, the Remote-Party-ID header is only
ever inserted by proxies, based on the proxy's knowledge of the identity of
the UA (which it determines from some authentication mechanism out of scope
of the privacy draft).

Privacy-02 allowed the UA to insert Remote-Party-ID too. I think this should
be reintroduced for the *specific case* of a UA with multiple identities, to
allow the UA to choose which identity it wishes to be known by. The Proxy
would still be responsible for ensuring that this identity was valid for the
user and would still use some other authentication scheme to authenticate
the user. The proxy would need knowledge of which identities were valid for
which users.

I believe this is a requirement for 3GPP, where a UA can have multiple
'public identities' and chooses which of these it wishes to be known by for
each call. The proxy authenticates the UA by some other means and then
checks the subscription data to ensure it is really allowed to use the
public Identity it has included. 

I've suggested this a few times, and there has not been much comment for or
against. It would be good if we could get a resolution before the next
version of privacy is published.

So, comments ?

Regards...Mark

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: 18 February 2002 23:12
> To: Watson, Mark [MDN05:EP10:EXCH]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [Sipping] RE: [Sip] calling number blocking at sip/isup
> gateway
> 
> 
> Mark said:
> 
> > Your example below needs only a small extension to 
> illustrate Mike's point
> > and show why something like Remote-Party-ID as defined in 
> the privacy
> draft
> > is needed, and how it works despite the lack of a signature.
> 
> Yep. And what happens when my misconfigured proxy forwards 
> the call without
> paying attention to the Privacy header, because for some reason it's
> forwarding to the outside world instead of a PSTN gateway 
> under my control?
> We get a privacy leak.
> 
> But other than that, I'd say you've precisely described a 
> "sunny day" use
> case for RPID.
> 
> It still has a lot of security issues based on transitive 
> trust, which make
> it a lot more palatable in a two-party case than in three or 
> more party
> transitivity.
> 
> I believe we're approaching a general consensus that the Privacy draft
> provides a reasonable approach to solving a specific class of problem
> wherein interoperator-transitive trust is couple to 
> transport-layer message
> protection. That's not a general privacy mechanism, but it 
> does seem to have
> enough constituency to justify publication as long as it has a REALLY
> serious applicability statement explaining the particular 
> requirements and
> environments for which it is useful.
> 
> How does that sound?
> 
> --
> Dean
> 
>

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 19 Feb 2002 18:26:55 -0600

I concur that your proposal would add to the utility of RPID.

--
Dean

----- Original Message -----
From: "Mark Watson" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, February 19, 2002 2:28 PM
Subject: [Sipping] Privacy comment (was Re: calling number blocking at
sip/isup gate way)

> > environments for which it is useful.

_______________________________________________
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