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

From: "Mark Watson" <[email-masked]>
Date: Thu, 3 Jan 2002 18:15:29 -0000

Michael,

The point is that there are, and will continue to be, service deployment
models where the user has a Service Level Agreement with a local service
provider, and this service provider has SLAs with other service providers
etc. etc., and these SLAs can include a committment that identity
information is either verified or marked as unverified by the sender.

Yes, this is 'transitive trust', yes, cryptographic solutions are an
alternative but there are pros and cons. Also, such SLAs are already
familiar to many existing Service providers.

It's not 'trust me because I put in a magic tag', but 'trust me because you
have a binding Service Level Agreement which says I am trustworthy'.

It's not the only deployment model & it certainly has disadvantages, but
it's not one we can ignore, especially in the short/medium term.

...Mark

-----Original Message-----
From: Michael Thomas [mailto:[email-masked]]
Sent: 03 January 2002 17:33
To: Watson, Mark [MDN05:EP10:EXCH]
Cc: 'Jonathan Rosenberg'; Flemming Andreasen; [email-masked];
[email-masked]
Subject: Privacy draft (was: RE: [Sip] Open Issue #188: Reply-To)

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:
 > > 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
 > <!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>

---

From: Michael Thomas <[email-masked]>
Date: Thu, 3 Jan 2002 11:22:36 -0800 (PST)

> information is either verified or marked as unverified by the sender.

The issue here is not whether a particular
business model is good or bad, but whether the
protocol should assert whether something is
verified or not, and expect something on the far
end to take action based on that tag. Without
crypographic identity verification, the tag is
somewhere between impotent and highly misleading.
I find that pretty problematic. If service
providers want to structure the _contents_ of the
RPI based on handshakes, they're completely at
liberty since SIP doesn't have to say anything
about that. Once you involve the protocol itself,
we should be a lot more circumspect.

	  Mike

_______________________________________________
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

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 03 Jan 2002 14:52:30 -0500

Michael Thomas wrote:

> end to take action based on that tag.

It doesn't expect the far end to do anything - it merely asserts that is has
been verified. Whether the far-end chooses to trust that or not is up to it.

> Without

Deja vu. Yes, the transtive trust model is weak and that is pointed out in the
privacy draft. Yes, cryptography based authentication is much better, but we
just don't have the required PKI infrastructure to support this in place, nor is
everybody willing to pay the price for it. We've had this discussion numerous
times, and as far as I know nothing has changed.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Michael Thomas <[email-masked]>
Date: Thu, 3 Jan 2002 12:10:28 -0800 (PST)

> been verified. Whether the far-end chooses to trust that or not is up to it.

   Clearly there's a choice; you said it right above
   in the last sentence. The reason I say that it's
   potentially misleading is because the UAS has
   no way to know whether to believe it or not. Since
   the only way to make the scheme workable is to
   have some conventions which SIP by definition cannot
   define, why not just require that those conventions
   be encoded in the RPI value? In that case, SIP doesn't
   have to make _any_ statement at all about the potential
   trustworthiness which is almost certain to be
   misunderstood if it's in the spec.

		Mike

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 04 Jan 2002 17:26:09 -0500

Michael Thomas wrote:

>    no way to know whether to believe it or not.

Very true - it all comes down to trust.

> Since
>    be encoded in the RPI value?

I'm not sure I understand the proposal - can you elaborate ?

> In that case, SIP doesn't

Maybe I'm misunderstanding, but given the current state of affairs, I still believe
there is value in saying "no, this is definitely not verified", or "I claim this
has been verified, and how much trust you want to place in that is up to you" as
opposed to saying nothing at all.

-- Flemming

--
Flemming Andreasen
Cisco Systems