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

From: "Peterson, Jon" <[email-masked]>
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 
> -----Original Message----- 
> From: William Marshall [mailto:[email-masked]] 
> Sent: 27 March 2002 22:19 
> 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:44:23 -0500

"Peterson, Jon" wrote:

> conditions under which proxies could or should add Call-Info.

So a draft that specified this, one way or the other, would be perfectly legit.

> Call-Info

I think we have all agreed on this point as far as the general SIP privacy story
goes. How you ensure that this actually happens without some kind of "trust"
somewhere is another story.

> rather than an untrusted entity, has added a screened RPID.

We have been over this issue numerous times. Authenticity is a general SIP
problem that should not be solved by each individual header. There is supposed
to be a general SIP security solution that can solve this problem and once it
does, it can provide true authenticity for the Remote-Party-Id header as well.

> The only SIP
> the header.

Very true, however I repeat:    A general security problem should have a general
security solution. I thought we already had consensus on this.

> I might also add that I for one have not particularly howled

So to sum up. You are not opposed to having a header that can be misused
(becuase then you would be opposed to the Call-Info header), but you want to
make sure that people get some guidelines about appropriate header usage.
Consequently, you should not be opposed to the Remote-Party-Id header and its
procedures as currently defined, only the applicability statement in case it's
not clear enough. However, that's clearly not the case, so what am I missing
here ?

-- Flemming

--
Flemming Andreasen
Cisco Systems