Re: [Sip] comments on privacy-04

[Flemming Andreasen <fandreas@cisco.com>]

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:

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

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

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

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

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

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.


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

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.


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

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


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

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

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


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

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

Not quite - trusted UA's add it too.

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

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

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
> than those in an RPID to contain the "privacy" parameter.
>

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


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

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.


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

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


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

I agree.

-- Flemming


> - 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip

--
Flemming Andreasen
Cisco Systems





_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip