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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 1 Mar 2002 10:11:30 -0000

3GPP has a need to be able to send identifiers from the UE that are not met
by existing identifiers. 

There is some discussion within 3GPP on what level of support is provided by
the existing identifiers, but this does not remove the need for something
like the Remote-Party-ID in at least some circumstances.

I believe it would be sensible to get some documentation under way
concerning this usage.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Mark Watson[SMTP:[email-masked]]
> Sent: 	19 February 2002 20:28
> To: 	[email-masked]
> Subject: 	[Sipping] Privacy comment (was Re: calling number blocking
> at sip/isup gate way)
> 
> 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 
> > 
> > 
> 
> 

_______________________________________________
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