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

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

Well, I now believe that Flemming, Mark and I all read your original note
about Call-Info slightly differently. Some further notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: William Marshall [mailto:[email-masked]]
> Sent: Friday, March 29, 2002 5:21 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Sip] Comment, SIP Privacy draft
> 
> 
[snip]
> 
> I don't think it takes much of an open mind in reading the 
> spec, since 
> (1) 20.9 says a proxy can insert a Call-Info header
> (2) Table 2 says a proxy can add or concatenate the header 
> field if not present
> (3) Table 2 says a proxy must be able to read the header field

But I'll bet you are the first person to suggest that:

  (4) The proxy would insert a URL customized to the originating end user
  (5) Call-Info with an "info" parameter can contain a SIP URI (spec gives
an example only of a web page URL)
  (6) That the identity expressed in a Call-Info in (5) could be at variance
with other identities carried in the message
  (7) That under some circumstances Call-Info should be removed/obscured for
privacy reasons
  (8) That there should be a way proxies that insert a Call-Info can
indicate
that untrusted end users should not be able to perceive that Call-Info

I don't think these are possibilities that we considered.

> 
> So it is clearly the intent of this header that the proxy be able to
> insert it; the only question is under what conditions.  Granted it
> is underspecified, and inserting bad information is just as allowable
> as inserting good information.  But I think a reasonable interpretation
> of the existing text in bis-09 is that a proxy inserts this header
> as a result of the authentication exchange.  As an example:
>   Call-Info: <sip:[email-masked]>;purpose=info
>   Call-Info: <data:,Bill%20Marshall>;purpose=info
> So CLIP is easy.  And it is certainly dangerous to presume a http URL, 
> when the spec contains no such limit.

Well, let's talk about a reasonable interpretation. There are quite a few
examples of the use of Call-Info in the sip spec, all of which use HTTP
URLs. In fact, the 'minor functional changes' section

The Call-Info header is a cousin of Alert-Info. Alert-Info is also proxy
'ar' in Table 2. It contains an example of an HTTP URL.

> 
> > The argument that Call-Info is a subset of RPID I also find a little
> > troublesome ...
> 
> There was no attempt to claim that Call-Info was a subset of RPID, rather
> that the RPID is actually a set of restrictions on the allowable use
> of Call-Info.  RPID is a very restricted subset of Call-Info.  Note that
> Call-Info contains all the extensibility mechanisms as RPID.
> 

To me it isn't really material whether you think RPID should be conflated
into Call-Info or vice versa - the point I made is that they are not
co-extensive, that they have two very different intentions (carrying
identity around among trusted network elements versus displaying optional
content to the end-user), and that it therefore doesn't make sense to
congflate them.

It also isn't correct that Call-Info contains all of the extensibility
mechanisms of RPID. There's no rpi-pty-type equivalent, for one thing. Also,
I read your note as suggesting that Call-Info needed all of the handling
restrictions that currently apply to RPID.

> And, in another message (also attached), Jon wrote:
> > On another matter, note that sip-privacy-04 provides no mechanism that
> > allows the recipient of messages to authenticate the party that added a
> > particular header - sip-privacy only ensures that some 'trusted' entity,
> > rather than an untrusted entity, has added a screened RPID. 
> 
> As has been answered many times, previous versions of the privacy draft
> did include this, but it was removed in favor of a general (still to
> be defined) mechanism usable for other headers, too.  The extension
> mechanisms was specifically designed to allow this authentication.  You 
> can't both complain that it is there and complain that it isn't.
> 

I was just arguing why Call-Info gets us no closer than RPID, since neither
header provides any authentication info about the inserting party - I was
not claiming that it was a defect of sip-privacy that it wanted for this
authentication mechanism. In fact, the next line in the paragraph from which
the above quote is taken says this plainly.

> Bill Marshall
> [email-masked]
> 
> -----original message-----
> From: "Peterson, Jon" <[email-masked]>
> To: "'William Marshall'" <[email-masked]>, [email-masked]
> Subject: RE: [Sip] Comment, SIP Privacy draft
> 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.
> > 
> 
> -----other original message-----
> From: "Peterson, Jon" <[email-masked]>
> To: "'Mark Watson'" <[email-masked]>,
>         "'William Marshall'" <[email-masked]>, [email-masked]
> Subject: RE: [Sip] Comment, SIP Privacy draft
> Date: Fri, 29 Mar 2002 02:27:00 -0600
> 
> A few more things about this Call-Info business.
> 
> Firstly, nothing in the SIP standard that I'm aware of 
> suggests that there
> would be some sort of telephony service based on the proxy 
> insertion of
> Call-Info. As far as I know Call-Info is not intended to be an
> identity-assertion mechanism. Agreed that the spec does not 
> rule out proxy
> servers adding the header, but at the same time the spec 
> doesn't suggest any
> conditions under which proxies could or should add Call-Info. 
> Call-Info
> clearly exists for a purpose unrelated to privacy/identity management,
> although I concede that its intended use may have its own privacy
> implications. But do your concerns about the legality of publically
> available services extend to instant messaging, Internet 
> gaming, and the
> like?
> 
> I'd further note that I'm not sure that it is the 
> responsibility of each SIP
> header to provide its own mechanism by which a UA can specify 
> whether or not
> they would like the header to be added or modified by proxy 
> servers. Rather,
> I think a request by the end user for privacy from the 
> network should apply
> to any headers that would potentially divulge private 
> information. So in
> other words, I think that a mechanism comparable to the 
> RPID-Privacy header
> in sip-privacy-04 should allow a UA to specify how the 
> network should deal
> with their private identity information, regardless of the 
> header in which
> that information appears (including From, Call-Info, or what 
> have you).
> 
> On another matter, note that sip-privacy-04 provides no mechanism that
> allows the recipient of messages to authenticate the party 
> that added a
> particular header - sip-privacy only ensures that some 
> 'trusted' entity,
> rather than an untrusted entity, has added a screened RPID. 
> The only SIP
> headers I'm aware of that contain cryptographic 
> authentication are described
> in the Digest section of bis09 - headers of this form allow 
> one to ascertain
> the identity of the party that generated the header. RPID assumes some
> out-of-band mechanism by which an authenticated identity is 
> discovered which
> is in turn persisted in the RPID header. I'd therefore say 
> that RPID offers
> no improvement on Call-Info with regard to identifying the 
> party that added
> the header. I might also add that I for one have not 
> particularly howled
> about the lack of this feature (it would be nice as a general 
> property of
> SIP headers, like for Via, but this isn't in the scope of 
> this priblem). I'm
> only howling about the use of RPID outside the context of 
> network-verified
> identity in support of privacy.
> 
> Jon Peterson
> NeuStar, Inc.
> 
> -----Original Message-----
> From: Mark Watson [mailto:[email-masked]]
> Sent: Thursday, March 28, 2002 6:08 AM
> To: 'William Marshall'; [email-masked]
> Subject: RE: [Sip] Comment, SIP Privacy draft
> 
> Must say I hadn't spotted this - Bill makes some very good points. 
> 
> It's worth noting that it would not be legal in most places to build a
> publically available service based on proxy insertion of the 
> Call-Info.
> There is no way for the user to indicate on a call by call 
> basis whether the
> proxy should insert the Call-Info or not. This capability 
> would be required
> to have this as part of a publically available service, even 
> if you do have
> a trust relationship with your home proxy etc. etc.
> 
> The bis-09 text implies that proxies could insert this field 
> but makes no
> statements to warn service designers about the legal 
> minefield they would
> thus be entering. Very unfortunate when a single Call-Info-Restriction
> indicator would have solved the problem.
> 
> It was exactly statements about needing to 'verify the 
> authenticity of the
> element that originated the header field and trust that 
> element' which have
> generated howls of protest over Remote-Party-ID, even though 
> the RPID draft
> always described the trust model within which this was possible.
> 
> How exactly *can* you determine who added a particular header 
> and whether
> you trust them, outside of the type of scenario described in 
> the RPID draft?
> 
> Perhaps we should deprecate Call-Info immediately and replace it with
> Remote-Party-ID? 
> 
> ...Mark 
> 

_______________________________________________
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 13:31:25 -0500

> URLs.

Oh please - the privacy-draft has statements throughout saying it is not for
user-asserted identity and that it doesn't even deal with user authentication,
but that's apparently still not good enough since somebody could choose to use
it this way. What's good for the goose is good for the gander.

<snip>

> mechanisms of RPID.

On the contrary - the production for info-param allows for unlimited
extensibility via generic-param.

-- Flemming