Jon, all,
With respect to the charter & the privacy draft, I guess we can argue which was chicken & which was egg. Both have been as they are now for some time without comment.
I think, as discussed before WGLC, that extensibility is important. When/if new identity types are required to be carried by Remote-Party-ID, we can add these and be sure that the correct privacy handing takes place at proxies which do not recognise the new identity type. This would not be the case for new headers.
Also, I think RPID should be self-qualifying, in that you should not have to look at the context (in terms of the individual message) to determine to whom the identity applies. This makes things simpler to understand and supports future re-use in other contexts. Any text saying that implications should be drawn from the particular message in which RPID appears, I think should be amended.
I agree completely with your desire to remove the factors which cause people to put gobbledegook in From:/To:. A general URI parameter as you suggest would allow 'private'(*) or 'potentially private' (**) information to be passed to trusted proxies in From:/To: by a UA. This may also remove the arguments for inserting RPID at an untrusted UA.
This is supposing that the URI parameter MUST be acted on by devices supporting the Proxy-Require: privacy tag. This in turn implies a requirement for those devices to be able to route via another device/function which can modify the From/To fields. [Let's not argue now about what such a device is called :-)]
(*) By 'private' I mean that the information cannot be passed to other UAs, but is required to be visible to (trusted) network entities.
(**) Information inserted by the UAC may become 'private' without the knowledge of the UAC due to the operation of services in the network. Such 'potentially private' information cannot presently be placed in From/To without a means of marking the privacy status and modifying the information as described above.
Finally, regarding 'subscriber' and 'user', one definition of these appears in the European Union Directive on protection of privacy in telecommunications networks:
(a) 'subscriber` shall mean any natural or legal person who or which is party to a contract with the provider of publicly available telecommunications services for the supply of such services;
(b) 'user` shall mean any natural person using a publicly available telecommunications service, for private or business purposes, without necessarily having subscribed to this service;
(c) 'public telecommunications network` shall mean transmission systems and, where applicable, switching equipment and other resources which permit the conveyance of signals between defined termination points by wire, by radio, by optical or by other electromagnetic means, which are used, in whole or in part, for the provision of publicly available telecommunications services;
(d) 'telecommunications service` shall mean services whose provision consists wholly or partly in the transmission and routing of signals on telecommunications networks, with the exception of radio- and television broadcasting.
I think these terms are pretty much applicable to SIP services, certainly within the realm of applicability of this privacy draft. If people are not happy with the common sense meanings of the terms, then we could include the above definitions.
Regards...Mark
> -----Original Message-----
> From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
> Sent: 18 March 2002 17:04
> To: 'sip@ietf.org'
> Subject: [Sip] comments on privacy-04
>
>
>
> 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>