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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 27 Mar 2002 10:45:28 -0000

If changing the word privacy to something else really solves the problem,
then let us change it.

Treatment of calling line identity in the PSTN/ISDN has never used the word
privacy in the specifications, but has concentrated simply on the word
"restriction".

Another word that was being used in the meeting was "verify", and although
this one is inherited from the PSTN/ISDN, I think it is possibly also
carrying implications of a function being performed that is not. All that is
checked in the PSTN/ISDN is that the number is one of an acceptable list,
and "screening" is probably a better word to use for that function.

However, I suspect that changing terminology is only part of the problem,
however I would, like Fleming, appreciate a better understanding of what the
problem really is.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Mark Watson[SMTP:[email-masked]]
> Sent: 	27 March 2002 10:16
> To: 	'Dean Willis'; 'Flemming Andreasen'
> Cc: 	[email-masked]
> Subject: 	RE: [Sip] Comment, SIP Privacy draft
> 
> I think we should be careful not to confuse 'scope' - what the mechanism
> actually does/solves - with 'applicability' - environments in which it
> actually works to provide this.
> 
> Used within the environment described in the applicability statement, the
> mechanism *does* provide for a *certain level* of privacy to be maintained
> whilst also supporting transfer of identity information.
> 
> This aside, I'd suggest that the broader privacy issue is very urgent.
> There are many kinds of privacy service, but we can be sure that many of
> them will require modification of the To/From fields, and so cannot be
> carried out at a proxy (if you want 2543 compatibility).
> 
> In the absence of even minimal support for such privacy services to be
> requested/performed, organisations such as 3GPP are forced into
> obfuscating the To/From fields & defining proprietary mechanisms for
> transferring this same information from UE to local proxy. I would suggest
> that this is a 'bad thing' for SIP. Also, the arguments which lead them to
> doing this are much more widely applicable than 3GPP networks, so others
> will be forced down the same path in due course (IMO).
> 
> We are not going to solve the general privacy problem in time to prevent
> this kind of messed up handling of To/From, but 3GPP networks at least do
> fall within the scope of the privacy-04 applicability statement.
> 
> So, I think we do need something urgently which works within the
> environments described in the Applicability Statement - whether it is this
> draft or another one I do not care, as long as it happens soon.
> 
> What is needed is: 
> a) A way for network entities to assert 'private' identities, in the case
> that To/From have been obfuscated due to privacy requirements
> 
> b) A way for users to request that privacy be applied to their identity,
> whilst also allowing the user to indicate their desired identity to the
> network
> 
> A draft which remains within the terms of the Applicability statement
> could do this. Only 2-3 comments were made *on the list* during WGLC and
> we have not made much attempt to resolve these. Perhaps those concerned
> that the draft exceeds the applicability statement could provide detailed
> comments on the sections they would like modified, or even a modified
> draft ?
> 
> Regards, 
> 
> Mark 
> 
> 
> 
> 
> 
> > -----Original Message----- 
> > From: Dean Willis [ mailto:[email-masked]] 
> > Sent: 27 March 2002 02:58 
> > To: 'Flemming Andreasen' 
> > Cc: [email-masked] 
> > Subject: RE: [Sip] Comment, SIP Privacy draft 
> > 
> > 
> > > > > I would argue that the draft goes outside its applicability 
> > > > > statement anytime it discusses providing privacy. 
> > > 
> > > This seems rather backwards to me. Are you saying that the 
> > > applicability statement is an exhaustive listing of scope and 
> > > requirements and anything that is not listed in there can by 
> > > definiton not be mentioned in the document ? 
> > 
> > Well, I'm suggesting that the draft SHOULD NOT include functionality 
> > that is clearly OUTSIDE the scope specified by the applicability 
> > statement. That's why we're getting the push back saying the 
> > document is 
> > inconsistent with the AS. Why should a draft present 
> > mechanisms to solve 
> > problems for which the draft declares itself "not applicable"? That 
> > means either adjust the scope of the draft, or adjust the scope of the 
> > AS, as needed and allowed by our "spirit guides" in the IESG . . . 
> > 
> > > > As written, it DOESN'T provide 
> > > > 
> > > > > privacy. It provides a means whereby a user can REQUEST 
> > > that network 
> > > > > elements NOT PUBLISH additional information that, if published, 
> > > > > would compromise privacy. 
> > > 
> > > Well, it notes that there are different degrees of privacy 
> > > and provides procedures for not only hiding this additional 
> > > information, but also discussion about other headers that 
> > > need to hidden. It also discusses IP address privacy, which 
> > > will give you full privacy, however, at your request, the 
> > > Anonymity header that used to solve this was removed, but the 
> > > issue is still discussed. 
> > 
> > Could I propose we abstract that discussion of privacy 
> > concepts into the 
> > baseline of a general privacy requirements and definition doc? That 
> > would be cool! We need such a doc, and it would help manage the "Scope 
> > vs AS" issues on this doc. 
> > 
> > > > I believe that "publish", in the context of this 
> > > > > document, means "distribute outside a group of proxies 
> > > with a shared 
> > > > > administrative policy of mutual trust." 
> > > 
> > > Proxies or User Agents. Also, do not forget the call trace 
> > > requirement, which was an integral part of the motivation 
> > > behind this draft (of course per your argument, we now can't 
> > > support call trace either since that's not part of the 
> > > applicability statement). 
> > 
> > Well, that gives us good reason to push back on the AS. OTOH, 
> > I bet the 
> > security droids would chew on us less if the "sensitive" information 
> > were always cryptoprotected, as you propose to do to meet the 
> > call-traceback-from-outside-the-trust-domain requirement. 
> >  
> > > > > 
> > > > > And I think it is the lack of mutual understanding 
> > > agreement at this 
> > > > > level that is the holdup. 
> > > 
> > > I have no idea what the continued holdup is since there's 
> > > rarely anything concrete on the table on the mailing list. It 
> > > would be helpful if we got something from the people that 
> > > have concerns. 
> > 
> > Color me "concerned". 
> > 
> > -- 
> > Dean 
> > 
> > 
> > _______________________________________________ 
> > 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: "Christian Huitema" <[email-masked]>
Date: Wed, 27 Mar 2002 13:15:19 -0800

> >
> > > > What is needed is:
> > > > a) A way for network entities to assert 'private' identities, in
the
> > > > case that To/From have been obfuscated due to privacy
requirements
> > > >
> > > > b) A way for users to request that privacy be applied to their
> > > > identity, whilst also allowing the user to indicate their
desired
> > > > identity to the network
> >
> > Yes, let's work on an actual privacy draft.
> 
> Are you thereby suggesting that the "caller-id" draft should not
address
> any
> kind of privacy beyond the Remote-Party-Id (e.g. inserting
> "anonymous@localhost" in the From header field) and hence not be
concerned
> with a more general privacy solution ?

Yes. We should have a separate caller-id/remote-party-id draft, which is
a tactical solution for some types of networks, and a generic privacy
draft, that looks at how to actually provide reasonable privacy across
the whole chain, without assuming a "public telephony server" in the
middle.

-- Christian Huitema

---

From: William Marshall <[email-masked]>
Date: Wed, 27 Mar 2002 17:18:57 -0500 (EST)

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.

---

From: "Mark Watson"<[email-masked]>
Date: Thu, 28 Mar 2002 10:25:57 -0000

> the whole chain, without assuming a "public telephony server" in the

I absolutely agree on the need for the generic privacy draft - and I think
this is quite urgent.

If you restrict the other part to identity-assertion between trusted
entities, and remove privacy indications altogether, you then have to assume
that these identities are 'private' i.e. cannot be passed outside the
trusted network. This doesn't work well when interworking with the PSTN - I
could check the identity in the From field, and if it is a tel URL which
matches the network asserted identity, I'd know I would mark this as
'available' in the PSTN, but this matching is not very clean. Plus a UA
which has a telephone number *and* a normal SIP URI will put the latter in
the From.

In my view you just can't separate identity assertion and privacy - trying
to do this with From and To was a big mistake in the first place. If we
define a *basic* identity assertion mechanism for the trusted network case
it should include *basic* 'restriction status' too, and a means for the UA
to indicate this, if it knows.

The reference to "Public telephony server" above is very misplaced. 3GPP &
DCS SIP networks are not telephony networks. We need less of this invective
and more focus on the real problems.

We should be aware that if we take the above approach we still have the
following problem:

UAs cannot include information in the existing SIP headers which (a) they
know to be subject to privacy restrictions *and* (b) needs to be processed
by the network. This is because they have no way of indicating that the data
has this privacy status.

So, people will still try to invent new headers to effectively replace the
From field, which I think everyone agrees is a bad thing, and perhaps
exactly what we are trying to avoid.

A possible solution, as mentioned in the WGLC comments, would be to define a
way for the UA to indicate the privacy status of existing headers as well
(if it knows!).

...Mark

---

From: [email-masked]
Date: Thu, 28 Mar 2002 08:13:18 -0500

>Better trust that proxy when you send the Authorization information.

Isn't this true for all systems. If there isn't at least a minimal amount
of trust nothing at all can be accomplished.

William Marshall <[email-masked]>@ietf.org on 03/27/2002 05:18:57 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:

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]

won't go off and do something to the SIP headers that the IETF doesn't
support.

---

From: "Mark Watson"<[email-masked]>
Date: Thu, 28 Mar 2002 14:07:32 -0000

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

> From: William Marshall [mailto:[email-masked]]
> Sent: 27 March 2002 22:19
> To: [email-masked]

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 28 Mar 2002 08:20:14 -0800

> DCS SIP networks are not telephony networks. We need less of this 
> invective and more focus on the real problems.

The reference was not an invective, but rather an acknowledgement of
legal implications of providing a "public service". The requirements to
be able to provide call tracing applies to public services, and result
in a requirement to have something like the remote party ID. It is quite
unclear that such a requirement applies to a private service, e.g.
direct calls over the Internet between two corporations. OTOH, the
existence of technologies such as remote-party ID have to be taken into
account when devising a privacy solution: we must assume that whatever
information is given to the network will be disclosed.

-- Christian Huitema

---

From: Kevin McCandless <[email-masked]>
Date: Thu, 28 Mar 2002 11:42:50 -0800

I agree with this statement.  The draft could better renamed and be less
confusing by calling it "Caller ID Support".

Kevin

> From: Matt Holdrege [mailto:[email-masked]]
> Sent: Wednesday, March 27, 2002 12:35 AM
> To: Dean Willis; 'Flemming Andreasen'
> Cc: [email-masked]
> Furthermore, per the AS this really has nothing to do with 
> Privacy. If this 
> draft is simply to meet the needs of supporting Caller-ID in 
> SIP to PSTN 
> scenarios, you should remove the word "privacy" from the 
> entire draft and 
> replace it with "screening". Then perhaps you can create a 
> separate draft 
> which deals with more pure Internet scenarios for privacy.
> 
> I'd be happy to write draft-ietf-sip-clip-clir-00.txt to get the ball 
> rolling on that one so we can get it out of the way and work on more 
> interesting stuff.
> 
> 
> At 06:57 PM 3/26/2002, Dean Willis wrote:
> >Well, that gives us good reason to push back on the AS. 
> OTOH, I bet the

---

From: William Marshall <[email-masked]>
Date: Fri, 29 Mar 2002 08:21:08 -0500 (EST)

Jon Peterson wrote:
> 								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.

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

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.

> 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.

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.

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.

> Sent: Wednesday, March 27, 2002 2:19 PM
> To: [email-masked]

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

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?

Remote-Party-ID? 

...Mark

---

From: William Marshall <[email-masked]>
Date: Fri, 29 Mar 2002 08:57:16 -0500 (EST)

Jon Peterson wrote:
> I don't actually believe that call trace, as I understand it, requires RPID
> or any comparable apparatus in SIP signaling. No new protocol mechanism is
> required for a proxy server to record the results of an authentication
> (indexed perhaps by Call-ID) so that administrative requests for the
> identity of the originator of a call can be satisfied. 

So to make an untraceable call, simply re-use the same From, To, and
Call-ID values from the last call you received.....  Or is it the
job of the proxies to verify the global uniqueness of Call-ID?
How much history information do you expect proxies to keep?

The key question with call trace is, what (and how much) information
does the UA need to keep, and to provide back to the administration
system, in order to perform the trace.  A full "message/sip" of
the INVITE request?  But that won't include the To-tag; so both
the INVITE and the 200-OK final response to the INVITE?  A huge
request and a huge database, vs. a single header with all the info
packaged up.  Why is this not a no-brainer?

Bill Marshall
[email-masked]

-----original message-----
From: "Peterson, Jon" <[email-masked]>
To: "'Flemming Andreasen'" <[email-masked]>,
        Dean Willis <[email-masked]>
Cc: [email-masked]
Subject: RE: [Sip] Comment, SIP Privacy draft
Date: Fri, 29 Mar 2002 02:02:51 -0600

A note on the paragraph below.

First, I don't think that the applicability statement in sip-privacy is
intended to be an exhaustive list of requirements for the mechanism - quite
the opposite, it's a set of restrictions on the use of the mechanism. The
need for these restrictions arose from the (concrete) ways in which the
mechanism was being applied.

I don't actually believe that call trace, as I understand it, requires RPID
or any comparable apparatus in SIP signaling. No new protocol mechanism is
required for a proxy server to record the results of an authentication
(indexed perhaps by Call-ID) so that administrative requests for the
identity of the originator of a call can be satisfied. I think RPID actually
attempts something a little more ambitious; sharing this identity
information in a putatively secure fashion within a community of 'trusted'
servers, so that this private identity information is immediately available
to any 'trusted' element that inspects the signaling, although it is still
concealed from end users. How the applicability statement hinders even this
goal, though, is unclear to me. All that the applicability statement
restricts is the insertion or receipt of RPID by untrusted elements. Surely
this is unrelated to call trace? In short, I doubt that the AS has made call
trace an impossible goal for the RPID header.

Jon Peterson
NeuStar, Inc.

> From: Flemming Andreasen [mailto:[email-masked]]
> Sent: Wednesday, March 27, 2002 5:49 AM
> To: Dean Willis
> Cc: [email-masked]
[snip]
> 
> If the AS is trying to be a complete listing of requirements then it is
> clearly deficient. Moreover, if this is indeed the intention with an
> applicability statement, then it is very concerning, that we have this
> applicability statement being forced into the document by our "spirit
> guides" at the last minute without any discussion about the actual
> requirements. As I mentioned before, call trace completely  fell through
the
> cracks here essentially rendering the draft useless for what it was
supposed
> to do. As this discussion shows, there is disagreement on other points as
> well.
> 
> 
[snip]
> -- Flemming
> Flemming Andreasen
> Cisco Systems

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 29 Mar 2002 13:20:41 -0600

One more note here.

Jon Peterson
NeuStar, Inc.

> Sent: Friday, March 29, 2002 10:31 AM
> To: Peterson, Jon
> Cc: 'William Marshall'; [email-masked]
[snip]
> 
> >
> > It also isn't correct that Call-Info contains all of the extensibility
> > mechanisms of RPID.
> 
> On the contrary - the production for info-param allows for unlimited
> extensibility via generic-param.

Why pick on Call-Info? Any number of SIP parameters could be misinterpreted
to contain identity info, especially because they happen to be extensible.
Via has a generic-param extension as well, so we could propose an 'rpid='
Via parameter that replicates RPID there, which each entity that generates a
Via should add. The point is that the RPID header is intended to be part of
some identity/privacy assertion mechanism - that's its reason for existing,
and that is why it is has attracted these applicability concerns. Via and
Call-Info have a different purpose, which is why (to date) we haven't had
any reason to worry over their applicability - to date, no one has bothered
to formally propose an abusive application of their extensibility.

But anyway, in the quote above I was just making the less ambitious and more
specific point that 20.9 happens to state that the Call-Info characterizes
the entity that originated the message, and that this would seem to argue
against the inclusion of a rpi-pty-type parameter.

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 29 Mar 2002 13:25:16 -0600

Nearing the end now.

Jon Peterson
NeuStar, Inc.

> Sent: Friday, March 29, 2002 11:03 AM
> To: Peterson, Jon
> > I really hope we all agree that the "proposal" Bill made to conflate
RPID
> > and Call-Info was not serious, but was intended to make a point about
> > underspecification in the SIP spec, and also to illustrate that
Call-Info
> > has its own privacy implications. Right?
> >
> 
> No, we are actually quite serious. We have a problem that needs a
solution, and
> if the privacy draft ends up dying or otherwise does not provide that
solution
> very soon, we need an alternative. Since Call-Info is already spec'ed and
we are
> low on alternatives, the choice is pretty clear.
> 

Well, fortunately, I am almost at a loss for words after this. Let me just
say that I don't believe sip-privacy is dying - but nor do I believe we have
all arrived at consensus about its usage. Switching gears to Call-Info or
any other mechanism would only delay this process further, though, I feel.
All of this talk about Call-Info, while it raises important concerns, has
only drifted focus away from the issues that require immediate solutions.

[snip]
> >
> > I can object, and I would. Why would anyone fail to object 
> to that usage?
> 
> You cannot object to using an already defined header in specific ways,
> regardless of whether it was intended to be used that way or not.
> 

I disagree with this most strenuously. I believe it would require
significant further standardization to make Call-Info something relevantly
like RPID. Of course, you could choose to forgo the standards process in
defining the needed capabilities - that is your prerogative. But provided
that this is considered a standard SIP capability, I think the SIP community
has the right to object to any such absurdities.

---

From: William Marshall <[email-masked]>
Date: Fri, 29 Mar 2002 16:58:20 -0500 (EST)

> I really hope we all agree that the "proposal" Bill made to conflate RPID
> underspecification in the SIP spec, and also to illustrate that Call-Info

Actually, the proposal is quite serious.  PacketCable needs a solution
for the CMSS spec, and waiting for IETF is not an option.  We still have
to deal with the missed deadline on the REFER draft too, somehow.
While rfc2543 did not contain anything usable for this feature (and,
therefore, we submitted draft-dcsgroup-sip-privacy 3 years ago),  2543bis
does.  A profile for this application is technically workable.

> The real, material difference here is that people want to do Bad Things with
> RPID, and RPID has broadened its definition and its mechanism to accomodate
> these things in the name of privacy. Call-Info is merely underspecified.

If anything, RPID is over-specified, and covers cases that (if every
element was compliant) would never happen.  That is much different from
a statement that certain behavior MAY occur.  I think that is the case
with your whole list of "Bad Things", but can't say for sure because I've
never seen such a list.

And a lot of SIP is underspecified.  That leads to new applications and
new services, and is its advantage over other protocols that aren't and
don't.  We concluded long ago not to standardize services; lets keep it
that way.

> sip-privacy-04 says 'encrypt or remove', yes. But not enough information
> about encyrption is provided for that to be a viable option - this isn't
> entirely the privacy draft's fault, but sip-privacy-04 could have said more
> than it does, anyway. It is also not clear to me how 'encryption' helps call
> trace. Encryption would only be relevant to call trace in so far as all
> entities that will be able to decrypt the RPIDs are trusted, ...

Section 7.2 gives almost a full page of spec language on this subject, and
a RECOMMENDED algorithm to do it.  Listing the encrypting UA in the host
port is the mechanism to get back to an entity that will be able to decrypt.

Bill Marshall
[email-masked]

-----original message-----
From: "Peterson, Jon" <[email-masked]>
To: "'Flemming Andreasen'" <[email-masked]>,
        "Peterson, Jon" <[email-masked]>
Cc: "'William Marshall'" <[email-masked]>, [email-masked]
Subject: RE: [Sip] Comment, SIP Privacy draft
Date: Fri, 29 Mar 2002 12:33:26 -0600

A few notes below.

Jon Peterson
NeuStar, Inc.

> Sent: Friday, March 29, 2002 5:33 AM
> To: Peterson, Jon
> "Peterson, Jon" wrote:
[snip]
> 
> 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.
> 

I really hope we all agree that the "proposal" Bill made to conflate RPID
and Call-Info was not serious, but was intended to make a point about
underspecification in the SIP spec, and also to illustrate that Call-Info
has its own privacy implications. Right?

I think it would be problematic to suggest that the Call-Info and RPID
should be conflated, as the remainder of my note bears out.

[snip]
> > 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 ?
> 

To limit the scope of the Call-Info, since the Call-Info is not intended to
be an network-verified identity carriage parameter. Of course.

This is not 'legit' in the SIP spec. We all know that in the two-hundred-odd
pages of the SIP spec there are many remaining nits and gotchas, even when
one is not reading the text in bad faith. This is clearly a bad faith
reading of 20.9. No one would honestly believe that Call-Info is intended as
a network-verified identitiy carriage mechanism. If that were proposed, I
believe the authors of bis09 would say that was not a correct usage.

The real, material difference here is that people want to do Bad Things with
RPID, and RPID has broadened its definition and its mechanism to accomodate
these things in the name of privacy. Call-Info is merely underspecified.

> > 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.
> 

I can object, and I would. Why would anyone fail to object to that usage?

> > 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 ?
> 

Although I already said this above, it is worth reiterating that RPID
purports to be a privacy mechanism, but it has been earmarked for use in a
number of ways that reflect poorly on privacy.

[snip differences between RPID and Call-Info]
> 
> 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.
> 

To your first question, I dunno, actually. I mean, I guess I could see cases
where a service provider wanted to add their homepage HTTP URI to a request
as it passed as a kind free advertising. Really, those are the only sorts of
cases I can imagine.

To you second question, if you get an email from someone that you don't know
which contains an HTTP URL, should you follow that URL? No, it could lead
you somewhere you don't want to go, or worse, download some malicious
software. This is all that "trust that element" note is saying. People have
really chosen to read that in a hostile way.

[snip]
> >
> 
> 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."
> 

And your quotation here supports what position, exactly? The account I gave
above of why you shouldn't follow arbitrary URLs was the motivation for this
text, as far as I remember, and I read this as consistent with the above.

> 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.
> 

It's clear to me, anyway, that the 'trust' here is unrelated to the 'trusted
network' concept in RPID. For one thing, the trust of Call-Info is a matter
of human oversight. In much the same way that you choose to follow a URL in
an email or not, you can choose to follow the URL in a Call-Info - this URL
is intended to be consumed by humans. This is radically different than the
identity in an RPID. Automatons (proxies) need to decide programmatically
whether or not they "trust" the next hop to which they are sending
signaling, and groom the RPIDs in messages appropriately. These two forms of
trust are quite different.

I see Call-Info as one of many ways that potentially private information
could be communicated inadvertantly to an end user, so in that sense I agree
it is valuable for the general SIP privacy mechanism to discuss Call-Info.
However, I don't think Call-Info should play a role in expressing a
network-verified identity of end-users.

sip-privacy-04 says 'encrypt or remove', yes. But not enough information
about encyrption is provided for that to be a viable option - this isn't
entirely the privacy draft's fault, but sip-privacy-04 could have said more
than it does, anyway. It is also not clear to me how 'encryption' helps call
trace. Encryption would only be relevant to call trace in so far as all
entities that will be able to decrypt the RPIDs are trusted, and that
trusted elements encrypt the RPIDs so that they can pass through untrusted
entities on the way to some other trusted entity. Encryption doesn't really
make decisions about trust any easier (which key do I to encrypt RPIDs when
I send them to an untrusted source? how do I know where the signaling will
eventually end up?), it just pushes the problem around.

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

I am trying to argue in good faith here - this is not meant to be deceptive,
but rather just to illustrate that if you want to conflate RPID with
Call-Info, there are quite a few other headers you could also choose to lump
in with those two. It is dangerous to go down that path, I think.

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 29 Mar 2002 16:01:13 -0600

A note below.

Jon Peterson
NeuStar, Inc.

> Sent: Friday, March 29, 2002 1:26 PM
> To: [email-masked]
> Cc: [email-masked]
[snip]
> 
> Whether I'm the first to suggest use of Call-Info for this purpose
> or not seems irrelevant.  You state that it is to be used for displaying
> optional content to the end-user, which is one of the main
> problems being addressed in the privacy draft.  In that sense,
> it squarely meets the need.
> 

Regardless of our differences of opinion about the requirements for a
privacy mechanism in SIP, surely we all agree that the main problem of the
privacy draft is not "displaying optional content to the end-user". The
privacy draft defines an extension to SIP by which network elements can
insert a verified identity into SIP messages in support of privacy, and
prevent untrusted elements from inspecting this verified identity data. I
think it's about NOT displaying certain content to the end-user, actually. I
don't believe anyone, no matter how liberally they read bis09, could
seriously contend that Call-Info provides such a mechanism. It would require
significant further standardization to adapt Call-Info to these purposes.
The sort of "optional content" Call-Info is intended to render, from the
examples, is something like a web homepage.

That much said, if you feel this is a credible proposal you are obviously
empowered to write it up as a new practice for the evaluation of the working
group, and it would no doubt be considered on its merits.

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 29 Mar 2002 15:55:56 -0600

More, always more, below.

Jon Peterson
NeuStar, Inc.

> Sent: Friday, March 29, 2002 12:34 PM
> To: Peterson, Jon
> Cc: 'William Marshall'; [email-masked]'; Dean Willis; Joerg Ott; Rosen,
> Brian; Rohan Mahy
> Subject: Re: FW: [Sip] Comment, SIP Privacy draft
> 
> 
> "Peterson, Jon" wrote:
>
[snip] 
> 
> Just because your network cannot verify the authenticity of the
> information does not mean the information is useless. With the present
> semantics, some people (I'm one of them) still find it useful from a pure
> caller-id service perspective to have a clear-text caller-id being
presented
> although it was untrusted as opposed to having nothing at all, as long as
I know
> it's untrusted. 

This is the issue that I was trying to zoom in on. Who generates that
caller-id that will be displayed to the UAS in your Iraqi case? The UAC? My
point is that the From header already provides a clear-text caller-id that
was generated by the originating user but not necessarily verified by any
intermediary, right? With or without sip-privacy-04, the From header already
provides an (untrusted) means for an end-user to assert an identity that
could be displayed by the destination endpoint, which the destination
endpoint does not know to be verified by the network. So what does untrusted
RPID add to this?

The only case I can think of where untrusted RPID potentially adds anything
to the information about the caller are cases in which the originating user
has requested privacy, and the From field therefore is Anonymous. But surely
in this case the originating user has an expectation that their identity
won't be revealed to the UAS - and so the motivation for carrying around
unverified RPIDs can't be to display them to the UAS (i.e. caller-id) in
this instance. So who is the consumer of the unverified RPID, then? I'm not
questioning the motivation for casual, untrusted identities - I'm
questioning why RPID has any bearing on this. This case is the subject of
the concerns I raised in my last mail.

I believe that the From field is sufficient to carry any identity of the
client user that will be displayed by the UAS that has not necessarily been
verified by the network.

> The longer term problem with your statement is that it assumes
> that the "screen" mechanism is the only authenticity mechanism forever. As
I
> have stated many times, we expect a generic security solution that can
> authenticate various headers in the future. Once we get that, you can now
have a
> Remote-Party-Id signed, sealed and delivered from an "untrusted" network
and
> actually still be able to verify it even though your network provider
can't
> vouch for it. Pretty useful - no ?
> 

Since I am (at the moment) only arguing for the removal of 'screen', I have
a hard time seeing how I would have a problem with assuming that 'screen'
goes away. Moreover I've argued that we can dispense with the 'screen'
mechanism without solving the more difficult problem of signing RPIDs. The
IOU above does not seem to encourage me to support the existing 'screen'
mechanism, but rather to put everything on hold until we get to the more
general mechanism. I'm not sure how this argues in favor of pushing the
existing mechanism in sip-privacy-04 forward.

What signing and encryption both really get you is a more flexible
definition of the 'trusted' network. Today, in sip-privacy-04, a proxy
server has to be pre-configured with a set of trusted hosts to which it can
safely deliver and from which it can safely receive RPIDs - those are the
trusted network. Signing and encryption remove this restriction, since each
message can be evaluated on the basis of its signatures to determine whether
or not a trusted source created the RPIDs regardless of whether or not a
message was received directly from a trusted entity. However, in that
instance a proxy that is trying to figure out whether or not it should trust
a message must still be pre-configured with a set of trusted keys - it isn't
that the 'trusted network' concept goes away, it is just no longer related
to the next signaling hops, but rather to the encryption keys. This is a
more powerful and flexible architecture, but many of the fundamental
problems arising from the trusted network concept are not immediately
resolved by the introduction of encryption and signing, it just shifts these
problems around a little. I think ultimately signing messages might even be
orthogonal to the issue of setting the 'screen=' parameter. How would
encryption or signing help you with your Iraqi case? From what I read above
I gather you'd still want to be able to carry unverified data, even if
well-known encryption and signing practices were available?

---

From: William Marshall <[email-masked]>
Date: Fri, 29 Mar 2002 17:15:13 -0500 (EST)

> 						I don't want to destroy
> sip-privacy-04. I want to see things like 'screen' removed so that the
> mechanism comes into parity with the applicability. If you honestly
> supported the sentiment you tout above, I believe you would have no problem
> removing 'screen'. 

The issue here is whether the mechanism defined can be extended to other
types of identity than calling-number and calling-name.  Back long ago
that was the only use; discussion on the list led to the consensus that
additional types of identification should be allowed.  So then what
happens when one proxy doesn't understand a new identity type?
Therefore the "screen" parameter.  So is the argument to un-do last
year's consensus?  That part went a very long time with no comments.

Bill Marshall
[email-masked]

-----original message-----
From: "Peterson, Jon" <[email-masked]>
To: "'Flemming Andreasen'" <[email-masked]>,
        "Peterson, Jon" <[email-masked]>
Cc: "'William Marshall'" <[email-masked]>,
        "[email-masked]'" <[email-masked]>
Subject: RE: FW: [Sip] Comment, SIP Privacy draft
Date: Fri, 29 Mar 2002 13:00:38 -0600

Some further notes below.

Jon Peterson
NeuStar, Inc.

> Sent: Friday, March 29, 2002 10:20 AM
> To: Peterson, Jon
> Cc: 'William Marshall'; [email-masked]'
[snip]
> >
> > I think it takes a relatively hostile reading of Call-Info to suggest
that
> > this is an appropriate usage.
> >
> 
> No more hostile than to suggest that Remote-Party-Id is for user-asserted
> identity, when both the title, applicability statement and the text
throughout
> specifically says that the draft does not deal with user authentication.
The
> fact that Remote-Party-Id *can* be used for this is another story, just
like
> Call-Info *can* be used for this.
> 

One huge difference is that the backers of the Call-Info header did not
openly intend to use it for user-asserted identity (let alone any form of
identity). In the case of RPID this is exemplified in sip-privacy-04 by the
presence of the 'screen=' parameter. In the past, you've made the case that
carrying around unverified, user-asserted identities is useful for RPID.
This goes very much against the spirit of the AS.

I fear that we're losing sight of the points that motivated this whole
discussion (or more selfishly, my own involvement). I don't want to destroy
sip-privacy-04. I want to see things like 'screen' removed so that the
mechanism comes into parity with the applicability. If you honestly
supported the sentiment you tout above, I believe you would have no problem
removing 'screen'. To me this is all about bringing the mechanism into
conformity with the applicability. I only entered into this fray because of
the ways that RPID was proposed to be used, because a concrete case was
raised in which a major customer of SIP wanted to abuse RPID and create
serious interoperability concerns. 

I don't think this is a double standard - the squeaky wheel gets the grease,
and RPID happened to be squeaking. While you and Bill have made a reasonable
case that Call-Info as its syntax is described could theoretically be
misinterpreted, to date I must point out that it hasn't been (outside of
this little thought-experiment). If someone did put out an I-D proposing the
use of Call-Info for things along these lines (for example, proposing a
'screen=' and 'privacy=' parameter for Call-Info, and then appropriate proxy
handling for Call-Info in a 'trusted federation of networks'), I doubt it
would pass WGLC. Why these Call-Info arguments should encourage us to
proceed with sip-privacy-04 as it stands is mysterious to me.

---

From: William Marshall <[email-masked]>
Date: Fri, 29 Mar 2002 17:31:47 -0500 (EST)

> against the inclusion of a rpi-pty-type parameter.

Characterizing the entity that originated the message sounds like *exactly*
what is needed.  Subsriber, office-owner, calling-person, instrument,
location - all this is characterizing the entity that originated the
message.  Even more general than what is needed.  Call-Info allows
a "card" type, so it can also include everything that rfc2426 does
(birthday of the caller???).

True, many other SIP parameters could be misinterpreted to contain
identity information.  Just like many are used to offload state 
information (as first described in draft-dcsgroup-sip-state).
But since Call-Info has as its stated intent "optional content
presentation to users", it is a far better fit, and hardly abusive.

Bill Marshall
[email-masked]

-----original message-----
From: "Peterson, Jon" <[email-masked]>
To: "'Flemming Andreasen'" <[email-masked]>,
        "Peterson, Jon" <[email-masked]>
Cc: "'William Marshall'" <[email-masked]>, [email-masked]
Subject: RE: [Sip] Comment, SIP Privacy draft
Date: Fri, 29 Mar 2002 13:20:41 -0600

One more note here.

Jon Peterson
NeuStar, Inc.

[snip]

---

From: William Marshall <[email-masked]>
Date: Fri, 29 Mar 2002 17:46:33 -0500 (EST)

>								Let me just

Glad to hear that, because it seems the opposite from here.  The deadline
given by ITU-SG9 was a frozen spec by the end of March, which is fast
approaching.

Since Call-Info is already defined in a published (or, frozen and soon to be
published) specification, and is underspecified in that specification,
there is no reason why a profile defining its usage needs to be delayed.

It would certainly be nice to have a standardized solution to the problem.
But not if that is three more years away (remember its been three years
already).

Bill Marshall
[email-masked]

-----original message-----
From: "Peterson, Jon" <[email-masked]>
To: "'Flemming Andreasen'" <[email-masked]>,
        "Peterson, Jon" <[email-masked]>
Cc: "'William Marshall'" <[email-masked]>, [email-masked]
Subject: RE: [Sip] Comment, SIP Privacy draft
Date: Fri, 29 Mar 2002 13:25:16 -0600

Nearing the end now.

Jon Peterson
NeuStar, Inc.

RPID
Call-Info
solution, and
solution
we are

[snip]

---

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 29 Mar 2002 18:29:47 -0600

Batching up some of Bill's mails below.

Jon Peterson
NeuStar, Inc.

> Sent: Friday, March 29, 2002 1:58 PM
[snip]
> with your whole list of "Bad Things", but can't say for sure because I've

Specifically, I am concerned with RPID usage as a replacement for the To and
From headers, in architectures which have proposed that To and From should
always contain random/anonymous information for all calls (not just when
privacy is needed) and RPID alone should be used to assert originating and
destination identities. I feel that these architectures pose tangible
threats to interoperability. Moreover, I feel there are capabilities in
sip-privacy-04 that support this architecture which have no apparent
internal motivation and which are not integral to the privacy function that
sip-privacy-04 attempts to provide. Were the SIP WG to pass sip-privacy-04
as it stands it would be unnecessarily open to these sorts of abuses (though
I would be the first to note that it is better than -03, which had no
applicability statement and did not require IANA registration for
extensions). If the remaining loopholes were closed, I would go back to
ignoring sip-privacy-* as I have in the past; it certainly was not until I
heard about the RPID To/From replacement architectures that I became, as I
am now, interested is seeing changes to the draft. If you would like to see
the changes I suggested, they are available in the ML archives here:

http://www1.ietf.org/mail-archive/working-groups/sip/current/msg04258.html

This is not to say that all SIP headers must be overspecified to prevent
such abuses. Again, this happened to come up for RPID and not for anything
else, and the squeaky wheel gets the grease. That much said, I think
Call-Info has not invited this particular abuse in the past because it would
need to have many concepts added to it ('screen=', 'privacy=', proxy
handling rules) before it became anything like the RPID. 

[snip]
> port is the mechanism to get back to an entity that will be 

There's a RECOMMENDED algorithm? I just went through the document looking
for one and I couldn't find it. All I see is something about symmetric keys
and Base64 encoding. Where does it name something like DES, or AES, or what
have you for encryption?

There are also some issues with the mechanism in so far as a trusted entity
sends out a chunk of encrypted data in an RPID that only it can decrypt, and
then expects entities that want access to this information to 'get back' to
them via the given hostname and port. First of all, while it may be
specified elsewhere, nothing that I can see in sip-privacy-04 tells me how I
can 'get back' to the host that generated the encrypted data. What should I
expect is listening on that hostname or port? A SIP server? If so, what sort
of request do I send to it (suggesting "please decrypt this string", maybe)?
Have any NAT or firewall considerations been taken into account for this?
How does the server decide whether or not it should grant you access to the
plaintext string? There are a number of issues along these lines...

The only alternative to 'getting back' to the host that generated the string
doesn't sound like a very well-defined prospect:

   However, there is also no well-defined way for a downstream 
   (trusted) entity to determine the identity of the calling party, 
   without that entity knowing both the details of how the private 
   "addr-spec" was constructed (crypto algorithm, MAC, encoding, etc.) 
   as well as which key to use for decrypting the information. The 
   solutions to these problems are left as an exercise to the reader, 
   and hence interoperability should not be expected.  
    
So I think I will stand by my statement that not enough information about
encryption is provided for this to be a viable option. Again, it may be
specified elsewhere, but it doesn't seem to be in sip-privacy-04.

---- Next mail

> (birthday of the caller???).

Um, sorry to be imprecise, by 'characterizes the entity that originated the
message' I meant that Call-Info assumes that the originator of the message
is the entity described in the Call-Info - so it assumes a single value,
effectively, for what the rpi-pty-type would specify for the RPID (whether
the RPID characterizes the 'caller' or 'callee' or what have you). I wasn't
trying to make a broader statement about Call-Info's vocation.

> presentation to users", it is a far better fit, and hardly abusive.

It's not 'optional content presentation', it's 'display optional content'.
The difference between the two is that the RPID means "it is important
whether or not this information should be displayed to the end user - only
do so when the end user is trusted" whereas the Call-Info means "this is
unimportant information that the end user should display if they can,
otherwise, don't worry about it."

> > > Call-Info and RPID actually have a similar function, or 
> more directly,
> that
> > > suggests Call-Info could be used to implement a CLIP/CLIR 
> service -
> suffice
> > > Any resemblance between the two headers further breaks 
> down when we
> begin to
> > > 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
> > > extensibility mechanism in sip-privacy-04 I have no doubt 
> it could be
> argued

---

From: William Marshall <[email-masked]>
Date: Sat, 30 Mar 2002 00:22:51 -0500 (EST)

> destination identities. 

privacy-04 already says that UA's don't insert RPID headers.  If a UA
is going to do it anyway, I don't see how a MUST NOT will stop it.
At the proxy, it still needs to handle INVITEs from both trusted
and untrusted sources, so considering the UA an untrusted source
simplifies the number of cases to specify and handles some errors.
I'd tend to agree that such architectures may cause interoperability
problems, but have no basis in facts for that belief.

>					If you would like to see

Flemming already responded to this message, point by point, msg04277.html.

> can 'get back' to the host that generated the encrypted data. 

Section 7.2 clearly states that it generates a sip: or sips: URI,
and has requirements for the content of the hostport, and for the
contents of the username, and for a user-param.  Section 6.1 states
that such a URI can be used as a Request-URI by the UA for certain
call control functions or subsequent calls.  While the mechanisms you
described can also be done, a simple INVITE to the enrypted URI
is simpler.

> trying to make a broader statement about Call-Info's vocation.

I had confused rpi-pty-type and rpi-id-type.  Your point.

> It's not 'optional content presentation', it's 'display optional content'.

bis-09 Section 28.2, first bullet item.  Its "optional content presentation
to users"

> 		....  whereas the Call-Info means "this is

My old rotary phone does exactly this with the Caller-ID info.  Perhaps
I need to upgrade my UA.

Bill Marshall
[email-masked]

-----original message-----
From: "Peterson, Jon" <[email-masked]>
To: "'William Marshall'" <[email-masked]>,
        "Peterson, Jon" <[email-masked]>
Cc: [email-masked]
Subject: RE: [Sip] Comment, SIP Privacy draft
Date: Fri, 29 Mar 2002 18:29:47 -0600

Jon Peterson
NeuStar, Inc.

[snip]

[snip]

    

---- Next mail

---

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 30 Mar 2002 03:43:29 -0600

A few more quick points.

Jon Peterson
NeuStar, Inc

> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Friday, March 29, 2002 5:36 PM
> To: Peterson, Jon
[snip]
> 
> I agree that overloading is harmful, particularly if the trust and
> control semantics are different. Call-Info and Alert-Info have no
> in-band trust indication or notion as to who can and should insert or
> remove it. I find this distinction more important than the difference
> between a name and a URL.
> 

I think the proposal is to provide these missing mechanisms in some
unstandardized fashion, since there are no restrictions on the extensibility
of the Call-Info header, and presumably the control semantics could be
proprietary.

> 
> If Call-Info (and maybe other headers) are inserted by the caller, the
> issue is "can you trust the information?". If it's inserted by a proxy,
> the issue is also "is the proxy allowed to do that, legally speaking?".
> 
> In general, I could see a need for, say, a caller-preferences indication
> that would say "don't route my call where my identity is likely to be
> revealed". Indeed, caller-preferences may well have suitable mechanism
> (preference vs. don't-make-the-call-if-you-can't-oblige) already in
> place, only needing the appropriate labels.

I think sip-privacy-04 aspires to specify on a per-call basis what degree of
privacy the user wishes the network to employ - and this seems like an
achievable goal. So, with the RPID-Privacy, the user can dictate whether
(and to what degree) the network should restrict identity information about
the originator. The only point I was making with regard to privacy concerns
is that this mechanism could encompass the Call-Info header, so that, for
example, if the user requests degree X of privacy for this call, servers
will not insert a Call-Info URL that they might insert otherwise. This could
undoubtedly be cast as a caller-preference as well.

[snip]
> 
> While I'm not disagreeing with your specific sentiment, I can sympathize
> with the frustration of the authors of the "privacy" draft. I would feel
> better if we could get away from intent and such, and focus on who
> inserts what information where, making sure that the recipient of the
> information has enough data to judge the trustworthiness (or knows that
> this is always untrustworthy). As long as information doesn't make false
> pretenses and misleads implementors and users, intent is just a bit too
> much beyond engineering. I think attempts to align any differences
> between promises and reality in the draft, as already happening with
> wording suggestions regarding "privacy", are more helpful.
> 

Agreed that we shouldn't be dwelling on intent, but rather strict
functionality - trying to restrict intent probably won't get us anywhere. 

> Henning