Subject: RE: [Sip] Comment, SIP Privacy draft

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 29 Mar 2002 02:12:36 -0600

It is true that the Call-Info header mechanism is a relatively
underspecified and open-ended way of inserting some information, possibly
information that could reveal an identity, into SIP messages. If one reads
the spec with an open mind, one could construe the Call-Info header as a way
that a proxy server could insert an identity on behalf of the sender of a
message. In that respect it could be argued (though I think it's a bit of a
stretch) that there is arbitrary network-asserted 'identity' information
floating around in bis09 that has no adequate authentication or privacy
story. Bill is certainly right to assert that many things are underspecified
in the SIP family of standards, and that it is dangerous to throw
applicability statements when you live in glass houses. 

Should there be a mechanism in SIP that allows a user agent to suggest that
proxies treat their requests privately? Of course. I think the presence of
some sort of privacy flag/header in requests is a reasonable way to do so
(vide the RPID-Privacy header in sip-privacy today). Guaranteeing privacy
entails managing a number of headers that could potentially divulge identity
- Call-Info is one of many examples (the open-ended User-Agent and Server
headers could also be used as repositories for potentially private data, let
alone common headers like Via and Contact). I think that the general privacy
story for SIP needs to account for restricting the presentation of data that
might appear in any of these headers. The final version of a privacy draft
in the SIP WG, IMHO, should answer all these risks. When I request privacy
from the network, if the network supports this privacy capability, it should
be mindful of the Call-Info header.

All that said, I feel that it is somewhat misleading to suggest that
Call-Info and RPID actually have a similar function, or more directly, that
Call-Info should in fact be replaced with RPID. The note below actually
suggests Call-Info could be used to implement a CLIP/CLIR service - suffice
it to say I do not believe this was the intention behind 20.9 in bis09.
Call-Info is intended to be a way to display optional content to the
recipient of a message referenced by something like HTTP URIs.
Remote-Party-ID, as far as I can make out, is intended to be a repository
for a network-verified SIP URI designating the identity of a party in a
session. Prima facie these do not seem co-extensive. Personally, I would be
happy to see Call-Info specified in more detail in the standard, and
significantly limited in the process. For example, I'm not aware of the
motivation to allow proxies to add Call-Info, and on initial reflection that
doesn't seem indispensible. I have not exactly found the proponents of RPID
to be similarly accomodating. 

A few specific points on the analogy between Call-Info and RPID. First of
all, section 20.9 does not suggest that the Call-Info carries identity
information (at least, not in the sense that the From or RPID header carries
an identity) - I suppose that the fact that Call-Info could carry any URI
means that the spec does not rule out carrying a SIP URI. But throughout bis
(including the sole example given in 20.9), this header is used to carry
HTTP URLs associated with the originator of the message. Second, to my
knowledge no examples are given in which Call-Info is set by a proxy server
- I acknowledge that the header can be modified by proxies, but 20.9
suggests that Call-Info is predominantly managed by UAs. Third, nothing in
the text of 20.9 suggests that a Call-Info header will be populated as a
result of the authentication process. Rather, the RECOMMENDED text cited
below merely suggests that you should know the identity of the sender of
this message before you follow the URL (again, presuming an HTTP URL) in the
Call-Info header - presumably because following arbitrary HTTP URLs can pose
known security risks (downloading virus-laden applets, or maybe just
annoying audio files). The text does not support a reading of Call-Info in
which it is set as a result of the authentication process (as suggested by
the account given below).

Any resemblance between the two headers further breaks down when we begin to
look at the functional behavior of RPID - when it is added, how screening
operates, and so forth. The most important difference is that Call-Info
entails no concept of trusted and untrusted networks which are most
certainly entailed by the RPID header. The use of the RPID header is
predicated on the configuration of a set of 'trusted' destinations which can
inspect the RPID header, and the assumption that it must be removed if it is
transferred to an untrusted entity. Personally, I don't think Call-Info
requires any such concept if it is used as the spec seems to intend.

The argument that Call-Info is a subset of RPID I also find a little
troublesome - when properly configured quite a few SIP headers, including at
least To and From, could be represented by RPID. With the current
extensibility mechanism in sip-privacy-04 I have no doubt it could be argued
that RPID should replace all other means of asserting identity in SIP.
Personally, I believe this is a defect of sip-privacy-04 rather than a
strength.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: William Marshall [mailto:[email-masked]]
> Sent: Wednesday, March 27, 2002 2:19 PM
> To: [email-masked]
> Subject: Re: [Sip] Comment, SIP Privacy draft
> 
> 
> In all the criticism and discussion of draft-ietf-sip-privacy, there
> has been one fact conveniently overlooked - the facilities already
> in bis-09.  I find them scary.
> 
> When a UAC sends an INVITE and is challenged by a proxy, and responds
> with the authentication credentials, the proxy has ascertained the
> identity of the UAC.  The proxy can then add a "Call-Info" header
> to the INVITE that contains whatever identity information it wants.
> See Section 20.9 of 2543bis-09.  As for the UAS, "It is RECOMMENDED
> that a UA only render the information in the Call-Info header field if
> it can verify the authenticity of the element that originated the
> header field and trusts that element."  How?  No clue is given.
> 
> Note that with "Call-Info" headers can appear in both requests
> and responses, and may be used by the UAC/UAS for presentation,
> there are *no* restrictions on what this information could be, *no*
> restrictions on how far it is propagated, *no* requirement that it
> be encrypted, and *no* mechanism for the UAC/UAS to request that this
> not be done.
> 
> In that sense, draft-ietf-sip-privacy *really* is about privacy.
> It includes a mechanism whereby the UAC can request that its
> identity be kept private and that proxies NOT include information
> (which the proxies will obtain and know) in the message that is
> forwarded to the destination.  The entire rest of the draft deals
> with the consequences of this request.
> 
> I find it very surprising that an attempt to restrict the use of the
> Call-Info header (thereby requiring a new header name, Remote-Party-ID)
> is meeting with such objection, when there was absolutely no comment
> on the Call-Info usage (and no applicability statement attached to it)
> during the WGLC or AD review of 2543bis.
> 
> From a service provider point of view, I'm not sure I see a difference
> between requiring certain proxy behavior with respect to the "Call-Info"
> headers, than requiring the same proxy behavior with "Remote-Party-ID"
> headers.  Codifing the requirements would be useful in either case;
> and doing this with purchase orders is likely not the best way to do 
> this.  
> 
> However, I do believe Remote-Party-ID is more general than Call-Info, 
> and solves a bigger piece of the problem.  While sufficient
> mechanism exists in bis-09 to do CLIP/CLIR through the use of
> Call-Info headers, it is without the ability of the UAC/UAS to know
> that its anonymity request will be honored (presumably signaled through
> use of "Anonymous" in the display-name of the From header).  
> 
> Better trust that proxy when you send the Authorization information.
> 
> Bill Marshall
> [email-masked]
> 
> -----original message-----
> Date: Wed, 27 Mar 2002 12:08:45 -0800
> To: Flemming Andreasen <[email-masked]>
> From: Matt Holdrege <[email-masked]>
> Subject: Re: [Sip] Comment, SIP Privacy draft
> Cc: Dean Willis <[email-masked]>, [email-masked]
> 
> At 11:57 AM 3/27/2002, Flemming Andreasen wrote:
> > Matt Holdrege wrote:
> > > You can work on the
> > > more general case and I fully support that. But some of 
> us still care about
> > > interworking with the PSTN and we need to get that bit 
> specified ASAP
> > > before the world is polluted with proprietary SIP headers.
> >
> >If that's all you want it's pretty easy:    Just add an ISUP 
> body to all 
> >your SIP
> >messages and fill in the blanks. However some of us were hoping for 
> >something a
> >little more general and useful.
> 
> No, we actually need the Remote Party ID and restricted flag. 
> I also hope 
> for a more general and useful way to deal with privacy. But 
> it seems like 
> that's going to be a difficult sell or at least a longer term 
> project than 
> originally expected. So it would be nice to get something 
> less out the door 
> now so that Service Providers can use it today, and the ITU-T 
> and 3GPP 
> won't go off and do something to the SIP headers that the 
> IETF doesn't support.
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Fri, 29 Mar 2002 08:33:28 -0500

"Peterson, Jon" wrote:

> message.

OK - so we agree that Call-Info duplicates Remote-Party-Id functionality as far
as this point is concerned. All we need is someone specifying the usage.

> In that respect it could be argued (though I think it's a bit of a

> applicability statements when you live in glass houses.

It certainly is - surely there is no double standard here ?

> alone common headers like Via and Contact).

Indeed they could, just like a Remote-Party-Id header can be used in ways people
did not intend to. But why is it, that this must be obstructed at all cost in
the privacy-draft case, but it's perfectly legit in the SIP spec ? In fact, if I
rewrote the privacy-draft to use Call-Info instead of Remote-Party-Id, what
would your arguments now be ?

> I think that the general privacy

We can agree on that as long as we keep in mind, that the privacy-04 draft is
not the final SIP privacy story.

> Call-Info should in fact be replaced with RPID.

Well, I would actually argue the other way. Let's drop Remote-Party-Id and just
use Call-Info since nobody can object to that.

> The note below actually

Ahh, but it could be used in that way - why is there not an applicability
statement to make sure it can't be misused ?

> result of the authentication process.

Well, why on earth are proxies allow to muck with it then ? Also, why does it
talk about "trust that element" ? This all sounds very familiar to me.

> Rather, the RECOMMENDED text cited

Hmm, I quote:

    "Therefore, it is RECOMMENDED that a UA only render the information in the
Call-Info header field if it can verify the authenticity of the element that
originated the header field and trusts that element."

> requires any such concept if it is used as the spec seems to intend.

A couple of problems here. First of all the Call-Info talks about trust without
specifying what that is. Secondly, you are talking about providing privacy for a
Call-Info header which you agreed above would be valuable, so the part about
"removing" before forwarding to untrusted entities ends up being the same (you
agreed above that a generic privacy mechanism should cover Call-Info). Finally,
Remote-Party-Id is not supposed to be removed when forwarded to an untrusted
entity - it is supposed to be encrypted so we can do call trace.

> Personally, I believe this is a defect of sip-privacy-04 rather than a

Yeah, nothing like the good old smokescreen. Nobody has suggested the above so
let's leave this out - shall we ?

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 29 Mar 2002 19:24:05 -0500

> to be similarly accomodating.

This can be very useful for my incoming proxy: You call me, my proxy
looks up your web page or other similar information in a database,
network information repository, etc. This is then presented to the
(embedded) end system with your call. Usual caveats about trusting the
information apply. Why should this functionality be ruled out?

Short of disallowing users or proxies to insert any information in SDP
(for users) or SIP headers, there is no way you can keep any proxy from
inserting whatever they want. If this information is public, not much to
object to. If my carrier or other party releases private information to
a third party, including the request destination, without my consent
this is presumably a breach of contract or a breach of law, depending on
the jurisdiction. (In Europe, it would be an actionable offense.) We can
help "good guys" do the right thing, by indicating our privacy desires.
We can't keep bad guys from leaking information they have access to.

Also, email has a long tradition of inserting information without
explicit user consent, for example, X-Authentication-Warning.

I think we should be careful of trying to over-engineer what's primarily
a social or legal problem.

Henning