Subject: [Sip] comments on privacy-04

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 18 Mar 2002 11:03:46 -0600

Since we now have a WGLC on sip-privacy-04, I have a couple of comments that
I apologize in advance for not presenting earlier.

I think that SIP needs a network-provided privacy mechanism, and I think the
system described by this draft is a reasonable solution to that problem.
However, the sip-privacy-04 system is more complicated than it needs to be
in order to solve this problem, and these complexities give rise to
confusions about the implementation and applicability of the mechanism.
Today, the SIP charter speaks to a need for privacy mechanisms but not, for
example, for new identity-assertion mechanisms.

Jon Peterson
NeuStar, Inc.

-----

- rpi-screen: As the recent thread in the SIP ML suggested, the behavior in
sip-privacy-04 for handling RPIDs received from an untrusted source might be
confusing. If untrusted entities shouldn't add the RPID header (which I
gather from the applicability), then why not say that a proxy MUST remove
any RPID headers it receives from an untrusted source? Today, it sets the
'screen=no' parameter instead. However, no behavior in the document is
defined for using an RPID header with 'screen=no' - it merely says that a UA
that receives it in a message shouldn't trust it (although what exact
behavior this entails is unclear). If this is totally deadweight in
signaling, it should just be removed - SIP messages don't need any help
getting larger. If you receive a RPID from a trusted entity, 'screen=yes'
could just be assumed; a parameter that says "trust me" may very well be
redundant in a trusted network. If it turns out that an RPID that the proxy
will add itself is identical to an RPID that has been supplied by an
untrusted source, then while this may be just lip service I think the least
ambiguous and most secure language is still to say that the proxy removes
the untrusted header and adds a trusted header. If for whatever reason it
turns out we do need this parameter, the idea that both 'screen=yes' and
'screen=no' can appear in the same RPID header (this is permitted in 6.1)
must be unnecessary. Finally, if you are going to have this parameter,
calling it "screen" is a little misleading; screening in the PSTN can refer
to selectively blocking calls based on the original calling/called number
(to me it implies that some feature has been invoked that inspects the ANI
and the dialed number and determines that this is a legitimate target for
the caller's class of service). Maybe "verify" would make more sense.

- rpi-pty-type: This parameter allows you to specify which party's identity
is contained in the RPID header ("calling" or "called" are currently
allowed). However, no motivation for this capability is presented in the
draft - it defines the conditions under which these parameters are inserted,
but there is no recipient behavior that justifies their insertion. Moreover,
the behavior for adding the parameter holds only that a request contains a
'calling' id, and the response contains a 'called' id. This sounds right -
I'd imagine that a privacy mechanism would use the RPID header to express
the private identity of the sender of a message; and in fact, if the
rpi-id-type header is not present, that's exactly what the recipient
assumes. So in short the motivation for this parameter isn't clear. If there
is a need for it then the draft should describe it, otherwise, I think this
parameter should be removed, since the default behavior seems appropriate.
This draft allows network-asserted identity as a means to end-user privacy;
the identity that is private is the identity of the originator of the
message. Finally, if you are going to have this parameter anyway, "calling"
and "called" are a little too telephony-specific, and those telephony roles
don't map cleanly onto the mechanism. This is already causing problems in
the draft: in 7.5, it suggests that you proxies should use the "calling"
rpi-id-type to identify the originator of any INVITE request - but what
about a re-INVITE in the reverse direction in the middle of a dialog?

- rpi-id-type: I find this the most problematic of the existing parameters.
I believe that the sip-privacy mechanism (at least, this chartered work)
exists to make an identity private, not to invent new forms of identity. I
believe that the kinds of entities in a SIP network that have privacy
concerns are users - not client devices, or intermediary devices, or what
have you. Now, that isn't to say that keeping a user's identity private
might not require hiding information about the device from which a user is
calling, and so on. This does not, however, motivate a need for a
network-asserted device URI like the "term" value of the rpi-id-type. No
proxy or UAS behavior is suggested in the document for use of the "term"
rpi-id-type, nor is it made clear how a proxy inserting this RPID would know
to assert an "identity" for a terminal (possibly from some out-of-band
authentication mechanism? but does the terminal authenticate itself as well
as the user?). Also, the distinction between "user" and "subscriber" in
privacy-04 is a little confusing. They represent a new distinction between
identities in SIP, and it isn't particularly clear why they are required as
part of a privacy mechanism; the difference between a "subscriber" (the
default, and traditionally the user of the SIP session), and a "user" seems
to be somehow related to settlement, or the administrative grouping of user
accounts. It isn't clear how a proxy would ascertain that it needs to apply
these parameters to an RPID, or how they'd be used  So, I'd also like to
suggest that if there is a need for a parameter or header that can assert
arbitrary new types of identity (distinguishing between subscribers or
users, URIs for devices, secret superhero identities, etc), then I for one
would like to see this proposed in a separate document. New types of
identity introduced to SIP may in turn have some privacy requirements, but
it does not follow from this that a privacy document is the right place to
propose all kinds of new identities. If these identities are useful outside
the context of privacy, that might have suggested that this is a separable
issue. The privacy considerations for these new identities can be explored
subsequent to their acceptance by the SIP community. For the time being, I
think this parameter is superfluous and confusing, and it should be removed.

- rpi-privacy: To me this parameter is really the crux of the draft - that
and the fact that the RPID header can be added, deleted or modified only by
proxy servers. However, it hasn't been clear to me why the privacy parameter
is defined only within the scope of the RPID header. If we would like this
draft to have general applicability to the privacy problem, perhaps it would
be better if "privacy" were defined as a general URI header. The RPID header
should usually, but perhaps not always, contain a URI that has a "privacy"
parameter. I'd be interested to hear if there are scenarios within the
applicability of the draft in which the RPID header should be used without a
"privacy" parameter - perhaps the presence of "privacy" in RPID could be a
MUST. However, I see no reason why it might not make sense for other URIs
than those in an RPID to contain the "privacy" parameter.

- Extensibility: While it's generally desirable for a mechanism to be
extensible (you should reuse existing mechanisms to solve new problems if
you can), sometimes extensibility can be confusing. Given the strict
applicability that precedes sip-privacy-04, it isn't really clear how much
extensibility is desirable - and at what point extensibility would invite
the use of RPID to architectures outside of that applicability. While I
applaud the move in sip-privacy-04 to require that extensions to the RPID be
published in an RFC, I'm not sure that this alone is sufficient. The middle
two parameters I've discussed above (rpi-ip-type and rpi-pty-type) are
extensible in privacy-04. Given that I'm a little queasy on their current
values (not to mention their overall relevance), it would probably go
without saying that I'm unsure about extending them further. These
reservations do not however carry over to the 'rpi-privacy' parameter - I
believe that should be extensible.

- RPID-Privacy: The need to assert any of the above parameters in the
RPID-Privacy should probably also be revisited in the light of the
considerations above. I think it's pretty clear that an RPID-Privacy header
should express the wishes of the originating user to keep their identity
private in this message, and it isn't clear why a user would want to tell
the network to, say, keep some other user's identity private. If this is
needed, the draft should explain when it would be useful.

- Gobbledygook in From: The motivation for cryptographically random garbage
in the From header may have gone away in light of the mandate for the 'tag'
parameter in the From field of requests in rfc2543bis, which guarantees that
dialog identification will be globally unique. I would suggest instead that
the From header for an anonymous request should be completely homogenous, so
all private From headers look alike. rfc2543bis09 actually contains examples
of both - in some places, anonymous requests use an apparently random user
and/or host, in other places something standard like 'anonymous@localhost'.
I would recommend the latter, if only because you already have to build
something globally unique for the tag - or at the very least, that this
point be revisited in light of bis. 

_______________________________________________
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: Tue, 19 Mar 2002 01:02:33 -0500

Hi Jon

Thanks for the comments. I've responded below, however if possible, I would
suggest breaking this into a couple of threads.

"Peterson, Jon" wrote:

> behavior this entails is unclear).

I may choose to display the information but with an indication that it is
untrusted. For example, if I'm busy and I get a call claiming to be from my wife
with a "screen=no" indication, I'll probably take the call. However, if I get a
call claiming to be from Elvis Presley with a "screen=no" indication, I probably
won't.

> If this is totally deadweight in

> the untrusted header and adds a trusted header.

Just because a given piece of identity information could not be verified, does
not mean it is worthless and hence I would not want the proxy to try and get
"too smart" here on my behalf. I prefer deciding myself whether I want to use
the information or not - all I need to know is whether I can trust it or not.
Thus, I would not want to mandate removal of Remote-Party-Id headers that cannot
be verified.

> If for whatever reason it
> must be unnecessary.

It's not permitted, however should you receive this, then "be liberal in what
you accept".

> Finally, if you are going to have this parameter,

On the other hand, both SS7 and Q.931 define a screening indicator similar to
the function in the privacy draft, so I think this is OK as is.

> parameter should be removed, since the default behavior seems appropriate.

It's a question of generality (actually two)
1. Do we foresee a need for having calling and called in other messages than
respectively requests and responses ? I believe Dean had a 3GPP example from
Germany where this was needed.
2. Do we want to enable other party types in the future ? This is a question of
extensibility.

> about a re-INVITE in the reverse direction in the middle of a dialog?

I agree the terms "calling" and "called" are somewhat misleading at this point.
Let me know if you have better suggestions.

> as the user?).

How you determine identity of any type is outside the scope of the document. As
to "terminal" identity type, I could imagine a service where calls originated
from some devices would get a different treatment than calls from other devices,
irrespective of the user making a call. I will grant you that it's not clear why
the remote party would want to know the terminal identity, but I can see uses
for this at intermediaries as well as the ability to actually suppress my
terminal identity.

> Also, the distinction between "user" and "subscriber" in
> these parameters to an RPID, or how they'd be used

True - this would be part of the authentication framework which is outside the
scope of the document.

> So, I'd also like to
> subsequent to their acceptance by the SIP community.

I'm not sure how to answer this except that the three types of party identity
very specifically requested to be in the privacy draft and they have been there
for a loong time without anybody complaining.

> For the time being, I

> proxy servers.

Not quite - trusted UA's add it too.

> However, it hasn't been clear to me why the privacy parameter
> be better if "privacy" were defined as a general URI header.

This is an interesting idea, albeit perhaps a little late. I presume you would
then require that any header containing a URI with a privacy indication would
have to have privacy afforded to it as described for Remote-Party-Id in the
current draft ?

> The RPID header
> MUST.

There should only be a privacy parameter if the user has asked for privacy (or
if he specifically does not want privacy). Omitting the privacy parameter is
thus perfectly reasonable and in fact quite common I suspect.

> However, I see no reason why it might not make sense for other URIs

This is a good point indeed, but it would be a significant change. I would like
to solicit more input on this.

> believe that should be extensible.

This is largely a philosophical discussion. I personally feel (and I know I'm
not the only one) that the extensibility is important as it allows you to reuse
the general privacy handling defined in the draft. However, I also understand
the concern you have about misuse of this extensibility which could turn
Remote-Party-Id into something it was not supposed to be. I believe that
requiring such extensions to be documented in an RFC and also to have a
designated expert review the extension is a good compromise towards satisfying
the desires and concerns of both sides here.

> needed, the draft should explain when it would be useful.

I think the resolution here should be the same as for the Remote-Party-Id header
itself.

> something globally unique for the tag

I agree.

-- Flemming

> - or at the very least, that this

--
Flemming Andreasen
Cisco Systems