Subject: Privacy draft (was: RE: [Sip] Open Issue #188: Reply-To)

From: "Mark Watson" <[email-masked]>
Date: Thu, 3 Jan 2002 10:38:34 -0000

> 
> Mark Watson wrote:
> 
> > Jonathan, 
> > 
> > I can't see how the two mechanisms are orthogonal. 
> Reply-To: seems to be
> > a straight sub-set of the functionality in Remote-Party-ID in
> > privacy-02.
> 
> 
> We've been through this one. R-P-ID is a network provided 
> identity. It 
> is not a catch-all for all forms of identification. If that were the 
> case, we would deprecate Contact, From, and To, and use 
> R-P-ID instead. 
> Thus, Reply-To is an end-user provided reply address.
> 

Well, this is what pirvacy-03 says, but not what privacy-02 said. In 02, RPI
*was* a generic capability for both network provided & user provided
information - that's why it had a tag which indicated whether the
information had been verified by the network!

Of course we didn't deprecate Contact, From and To - just because we have
some pre-existing (& rather fundamental to SIP) specific solutions does not
make it bad to add a generic capability later. (BTW, what's with the
'catch-all bad, generic good' language :-)

Yes, network provided & user provided identity information have some
different characteristics & requirements, but they also have a lot in common
- enough that IMO it makes sense to combine the two.

Even if the consensus is RPI for network provided, new headers for user
provided, then there is still a need for user provided RPI and for RPI tags
corresponding to any new identity headers, because there is value in the
outbound proxy being able to 'verify' a user provided identity as being
valid for that user - ask any CLI-opinionated regulator - in Europe they'd
even like us to retro-fit the distinction between verified & unverified
identities to analogue CLASS displays on the PSTN, so please lets ensure SIP
has full support for this from the beginning.

...Mark

---

From: Michael Thomas <[email-masked]>
Date: Thu, 3 Jan 2002 09:32:38 -0800 (PST)

For the record, I still don't see any reason why a
UAC shouldn't set it. The key property we need to
enable is for an interior proxy to either override
the value, or create its own value (ie, RPI as
known by XXX). The UAC is going to need to assert
its identity with strong authentication at some
point, so all we're doing here is drawing a
distinction between interior proxies and UA's. I
don't think this is especially helpful because
from the UAS's standpoint they're just going to
look at RPI and determine whether they trust who
it was signed by. Nor do I see how this can even
be enforced. If I can get a message to your UAS
either directly or through your upstream proxy, my
UAC can set it to whatever it likes. Thus it
provides no inherent protection, and to me this
just seems like a completely artificial
restriction which hinders direct UA-UA
interoperability.

To your point about unverified/verified: this is
easy. At this point, they should all be treated as
unverified. Verification *really* requires some
sort of cryptographic signed identity which can be
checked. The only possible exception would be
either direct e2e communication where you have a
security association with the peer (and thus know
who sent the message), or _just maybe_ if the UAS
has an agreement with their upstream proxy that
they'll scrub RPI's which come from untrustworthy
sources. Allowance for this kind of transitive
trust is hazardous though and may, in fact, be an
illusion. I'm well acquainted with the tradeoff
(public key signatures are expensive), but this
entire concept of "trust me because I put in this
magic tag" makes me very uneasy.

	 Mike

Mark Watson writes:
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
 > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
 > <TITLE>Privacy draft (was: RE: [Sip] Open Issue #188: Reply-To)</TITLE>
 > </HEAD>
 > <BODY>
 > 
 > <P><FONT SIZE=2>&nbsp;</FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; Mark Watson wrote:</FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; &gt; Jonathan, </FONT>
 > <BR><FONT SIZE=2>&gt; &gt; </FONT>
 > <BR><FONT SIZE=2>&gt; &gt; I can't see how the two mechanisms are orthogonal. </FONT>
 > <BR><FONT SIZE=2>&gt; Reply-To: seems to be</FONT>
 > <BR><FONT SIZE=2>&gt; &gt; a straight sub-set of the functionality in Remote-Party-ID in</FONT>
 > <BR><FONT SIZE=2>&gt; &gt; privacy-02.</FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > <BR><FONT SIZE=2>&gt; We've been through this one. R-P-ID is a network provided </FONT>
 > <BR><FONT SIZE=2>&gt; identity. It </FONT>
 > <BR><FONT SIZE=2>&gt; is not a catch-all for all forms of identification. If that were the </FONT>
 > <BR><FONT SIZE=2>&gt; case, we would deprecate Contact, From, and To, and use </FONT>
 > <BR><FONT SIZE=2>&gt; R-P-ID instead. </FONT>
 > <BR><FONT SIZE=2>&gt; Thus, Reply-To is an end-user provided reply address.</FONT>
 > <BR><FONT SIZE=2>&gt; </FONT>
 > </P>
 > 
 > <P><FONT SIZE=2>Well, this is what pirvacy-03 says, but not what privacy-02 said. In 02, RPI *was* a generic capability for both network provided &amp; user provided information - that's why it had a tag which indicated whether the information had been verified by the network!</FONT></P>
 > 
 > <P><FONT SIZE=2>Of course we didn't deprecate Contact, From and To - just because we have some pre-existing (&amp; rather fundamental to SIP) specific solutions does not make it bad to add a generic capability later. (BTW, what's with the 'catch-all bad, generic good' language :-)</FONT></P>
 > 
 > <P><FONT SIZE=2>Yes, network provided &amp; user provided identity information have some different characteristics &amp; requirements, but they also have a lot in common - enough that IMO it makes sense to combine the two.</FONT></P>
 > 
 > <P><FONT SIZE=2>Even if the consensus is RPI for network provided, new headers for user provided, then there is still a need for user provided RPI and for RPI tags corresponding to any new identity headers, because there is value in the outbound proxy being able to 'verify' a user provided identity as being valid for that user - ask any CLI-opinionated regulator - in Europe they'd even like us to retro-fit the distinction between verified &amp; unverified identities to analogue CLASS displays on the PSTN, so please lets ensure SIP has full support for this from the beginning.</FONT></P>
 > 
 > <P><FONT SIZE=2>...Mark</FONT>
 > </P>
 > 
 > </BODY>
 > </HTML>

_______________________________________________
Sip mailing list  http://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