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

From: "Mark Watson"<[email-masked]>
Date: Tue, 2 Apr 2002 15:04:50 +0100

All,

I feel profoundly lucky that yesterday and Friday were public holidays in
the UK :-)

Perhaps I can take advantage of this vantage point to offer a summary of the
thread. Protagonists please speak up if I have mis-represented you below,
but please don't re-open old fronts.

1) Call-Info

Long arguments about the alledged similarities/differences between Call-Info
and RPID. Suffice to say that the point has been made that Call-Info (and
perhaps other things) could be abused to do the things that RPID does, and
in particular to do the 'Bad Things' that some are worried about with RPID.
The point of disagreement was whether in the case of Call-Info, this would
be 'major abuse', with RPID was set up to make these 'Bad Things' easy, or
whether there was some equivalence.

The key point is that this kind of abuse of Call-Info may happen if we do
not provide an alternative.

2) Abuse of From/To headers

Jon is concerned that 'untrusted RPID' provides a standardised alternative
to From/To, allowing Bad Things, like never putting the real From/To
information in the From/To fields.

Others have pointed out that the draft explicitly states that untrusted UAs
MUST NOT add RPID. However the draft explicitly described proxy handling of
RPID headers from untrusted sources (proxies OR UAs), and allows these to be
propogated, marked as untrusted.

Therefore, a UA which DID add RPID, although non-compliant to the draft,
would have its RPID propogated through the network.

3) 'Untrustworthy RPID'

Flemming, Bill et al argued that RPID information is still useful when it is
'untrustworthy'. This can occur legitimately within the draft when an RPID
which is not 'private' (and so not encrypted) crosses a trust boundary. This
would represent an identity asserted by Network A and passed to Network B,
when B has no explicit trust relationship with A.

The contention was that since this information still has some value, it
should be passed to the UAS for display, and might also have some
application for call trace, although obviously not as useful as a
'trustworthy' identity.

Jon argued that the From field provides well enough for display, and the
value of untrustworthy information for call trace is debatable (and has been
debated at length).

There is agreement that some form of 'signed RPID' would be better.
Previously we have agreed on the need for a general mechanism to sign
information in SIP headers. Flemming has pointed out that if you agree to
have 'Signed RPID' then as a subset you have 'Untrustworthy RPID' (when you
don't recognise the signature). So removing 'Untrustworthy RPID' now would
be inconsistent, since there is already agreement to re-introduce it later.
That is unless you feel that the time interval during which Untrusted RPID
is not standardised is important.

Many other points were made, but the above seemed to me to be the key
issues.

And, now, my opinions:

1) Call-Info: I think the point has been made here - we're into judgement
calls on how bad an abuse X is compared to Y - I would rather there was no
need for people to abuse the protocol at all.

2) From/To: RPID is not the problem here, is it a solution to an underlying
problem with From/To. Blocking RPID will not solve the underlying problem,
and people will just route around to find another, probably worse, solution.
Better to address the real problem which has led people to propose
obfuscating From/To in the first place. If this problem is solved, then
there is no reason for people to want untrusted UAs to insert RPID. See
separate mail on this.

3) Untrustworthy RPID: I think Flemming and Bill have demonstrated the
utility of 'untrustworthy identity', and indeed this is what the From field
already provides. But From just provides the users assertion. If a network
has asserted additional identity information, why should the user should be
denied this ?

Having said that, the propogation of 'untrustworthy' RPID is strictly out of
scope according to the (retro-fitted) Applicability Statement. But then we
have agreement to add it 'in future' by virtue of the generic signing
mechanism - I guess this inconsistency is one for the ADs.

Regards,

Mark

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 02 Apr 2002 10:03:11 -0500

<snip>

> utility of 'untrustworthy identity', and indeed this is what the From
> field already provides. But From just provides the users assertion. If
> a network has asserted additional identity information, why should the
> user should be denied this ?
>
> Having said that, the propogation of 'untrustworthy' RPID is strictly
> out of scope according to the (retro-fitted) Applicability Statement.

Actually, it's not. The Applicability Statement allows for more than a
single domain and does not specify whether such domains have to trust
each other or not, so either case is allowed and hence described in the
document.

-- Flemming

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Apr 2002 03:28:18 -0400

Mark Watson wrote:
> 
> All,
> 
> I feel profoundly lucky that yesterday and Friday were public holidays
> in the UK :-)
> 
> Perhaps I can take advantage of this vantage point to offer a summary of
> the thread. Protagonists please speak up if I have mis-represented you
> below, but please don't re-open old fronts.

Thanks for the summary. It is well needed. I suspect much of the lack of
comment derives from the difficulty in following this long thread.

I would kindly request all participants to please keep the discussions
technical. A lot of the emails in this thread were personal attacks.
Many more were threats along the general line of "do X or standards body
Y will do Z". I really hate the latter ones. Let us hear no more of
either type of nonsense. It is not the IETF way.

> 
> 1) Call-Info
> 
> Long arguments about the alledged similarities/differences between
> Call-Info and RPID. Suffice to say that the point has been made that
> Call-Info (and perhaps other things) could be abused to do the things
> that RPID does, and in particular to do the 'Bad Things' that some are
> worried about with RPID. The point of disagreement was whether in the
> case of Call-Info, this would be 'major abuse', with RPID was set up to
> make these 'Bad Things' easy, or whether there was some equivalence.
> 
> The key point is that this kind of abuse of Call-Info may happen if we
> do not provide an alternative.

It was never our intent for Call-Info to provide any form of network
asserted identity that could be used in any useful way. Generally, the
idea was that insertion of Call-Info was either done by the UA, or in
the case of proxy-inserted values, was for "opt-in" services were the
user had signed up for content to be added. That said, there are
certainly cases where the caller may opt in for this service but require
privacy for a particular call, and we need a mechanism to support that.

However, in no way would I support or advocate the use of Call-Info as
an alternative for R-P-ID. 

> Jon is concerned that 'untrusted RPID' provides a standardised
> alternative to From/To, allowing Bad Things, like never putting the real
> From/To information in the From/To fields.

I think that the proper way to handle this, as pursued in other threads,
is to provide a sane alternative to 3gpp so that they don't do this. I
believe we all agreed it would be bad.

> 
> Others have pointed out that the draft explicitly states that untrusted
> UAs MUST NOT add RPID. However the draft explicitly described proxy
> handling of RPID headers from untrusted sources (proxies OR UAs), and
> allows these to be propogated, marked as untrusted.
> 
> Flemming, Bill et al argued that RPID information is still useful when
> it is 'untrustworthy'. This can occur legitimately within the draft when
> an RPID which is not 'private' (and so not encrypted) crosses a trust
> boundary. This would represent an identity asserted by Network A and
> passed to Network B, when B has no explicit trust relationship with A.
> 
> value of untrustworthy information for call trace is debatable (and has
> been debated at length).

IMHO, 'untrusted RPID' is identical to the From, except that it is
purportedly inserted by a network element, whereas From is purportedly
inserted by the end user. Neither provides any guarantees. The essence
of the debate, I think, is whether you believe there is value to the end
user in a field which is the identity purportedly inserted by some
network element.  Since there is apparently value to the identity
purportedly inserted by the end user, I see no reason why we should
discriminate. 

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com