Subject: [Sip] WGLC for draft-ietf-sip-privacy-general

From: "Dean Willis" <[email-masked]>
Date: Tue, 28 May 2002 16:32:06 -0500

We need to do a quick review of the general privacy draft developed out
of our discussion in Las Vegas.

Please send any issues to the list and the editor IMMEDIATELY.

The draft is available from:

http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-general-00.
html
http://www.softarmor.com/sipwg/drafts/draft-ietf-sip-privacy-general-00.
txt
And soon to be available from internet-drafts if not already . . .

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 29 May 2002 15:28:49 -0400

Comments:

> Withholding the identity of a user will, among other
>    things, render the other parties in the dialog unable to send new SIP
>    requests to the user outside of the context of the current dialog.

Thats not necessarily true; I can remain anonymous and even get a call
back later on (for example, Reply-To: sip:[email-masked]) -
the key is that my identity is never revealed.

> A display-name is a quoted string containing
>    a name for the identified user (for example, "Alice"). 

As a nit, display-names need not be quoted strings.

> The privacy problem is further complicated by proxy servers (also
>    referred to in this document as "intermediaries" or "the network")
>    that add headers of their own, such as the Record-Route and Via
>    headers. 

Its probably also worth referncing the identity work as another source
of identity information that can be inserted by proxies.

> The scope of these privacy requirements is solely the SIP protocol as
>    it is described in [1].  The mechanisms at the disposal of user
>    agents and proxy servers are restricted to those described in the SIP
>    specification.  Also, the privacy properties of the headers listed in
>    the core SIP specification alone, as opposed to headers defined by
>    any existing or planned extension, are considered here.

I don't quite understand this paragraph. If a future extension defines a
header that reveals identity information, shouldn't this draft cover
requests for privacy of that information?

> The
>    author maintains that these problems are sufficiently well addressed
>    in the baseline SIP specification and related documents, and that no
>    new mechanisms are required.

Minor nit - but as a working group draft, its not appropriate to make
statements about the opinions of the author, as the document represents
group consensus. Its sufficient to just strike "The author maintains
that".

> When a user voluntarily asserts an identity in a request, they are
>    claiming that they can receive requests sent to that identity in that
>    domain.

Thats a narrow definition of identity, particularly since the draft
discusses ip address privacy, which wouldn't qualify as an identity by
the above definition. Neither would a contact URI.

meta-comment: as the draft is a bit verbose, it might be helpful to have
in the introduction a paragraph or two which overviews the structure of
the document and discusses how the sections relate.

> The following SIP headers, when generated by a user agent, can
>    directly or indirectly reveal identity information about the
>    originator of a message: From, Contact, Reply-To, Via, Call-Info,
>    User-Agent, Organization, Subject, Call-ID, In-Reply-To

The sentence ends mid-stream.

Also, you have forgotten two very, very important ones - Authorization
and Proxy-Authorization. In general, I think the draft needs discussion
of these headers specifically. The user should only include such headers
if it is willing to provide identity information for the realm provided
in the challenge. Furthermore, the user may need to verify that the
proxy is indeed part of the realm that they claim to be from before the
user provides identity information to it. Right now, we have no real way
to do that unless the proxy is the first hop proxy, in which case TLS
can be used to ascertain the identity of the proxy that is providing the
challenge before providing credentials. All of this needs to be
discussed. The issue is similar to that of routing requests to privacy
services.

Also, you left off the Server header and the Warning header, both of
which can potentially (although unlikely) reveal identity information in
a response.

> destination of the message, users MAY also place legitimate values
>    for these headers in encapsulated 'message/sip' S/MIME bodies as
>    described in the SIP specification.

A reference to the specific section number would be useful here.

> Privacy-hdr  =  "Privacy" HCOLON priv-value *(COMMA priv-value)
>    priv-value   =   "header" | "session" | "user" | "none" | "critical" | token

I would strongly advise that you also allow for semi-colon separated
parameters for the purposes of future extensibility.

Also, you need to use slashes "/" to separate or-values, not vertical
bars "|".

> header: The user requests that a privacy service obscure those
>       headers cannot be completely expunged of identifying information
>       without the assistance of intermediaries (such as Via and
>       Contact). 

s/cannot/that cannot

>  Note that requesting session privacy when end-to-end session
>       encryption is not possible raises serious security concerns (see
>       Section 6.2).

Indeed. This is why I wrote
http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-session-policy-00.txt

which allows both to the extent that is possible.

>  Header field          where   proxy ACK BYE CAN INV OPT REG
>    ___________________________________________________________
>    Privacy                        amrd  o   o   o   o   o   -

I think privacy is still useful in a register message. It would be
helpful when I want to register through my provider using an anonymizer
service, which possibly obfuscates the Contact header. Interestingly,
the privacy service couldn't obfuscate the From or To field, since these
are needed by the registrar. Perhaps that is why Privacy is not allowed
here? It makes me wonder if there is a need to specify privacy on a
slighlty more granular level, allowing the user to request obfuscation
of groups of headers (To/From in one group, Contact/Via/RR in another).

Also, you need to explicitly specify the set of valid combinations of
the various privacy values; its not entirely clear from the text.

>  critical: The user asserts that the privacy services requested for
>       this message are critical, and that therefore, if these privacy
>       services cannot be provided by the network, this request should be
>       rejected.  Criticality cannot be managed appropriately for
>       responses.

OK, I hate to dredge up old issues, and perhaps this was hashed out in
the many privacy threads I didn't get to, but, it seems like the value
of critical is going to neccessitate a Proxy-Require header. The draft
makes no mention of the use of proxy-require or the protocol
implications if the extension is not supported by proxies. The
proxy-require can be removed once the services have been performed,
which is a good thing.

>    It is RECOMMENDED that service providers couple the privacy service
>    function with a local outbound proxy.  Users can thereby send their
>    messages that request privacy through their usual outbound route.
>    Users should not assume, however, that the administrative domain that
>    is the destination of the request would be willing and able to
>    perform the privacy service function on their behalf. 

How does the user know whether privacy services are supported? Do they
need to try it with Proxy-Require to see if the request fails? 

I also toyed with the idea of defining a URI parameter that indicated
that the URI represents a resource that can provide privacy functions,
similar to the way we have a URI parameter for indicating that a
resource can provide compression. However, I don't think this is a good
idea, but wanted to mention it for completeness.

> What a responding user agent can do, however, is ensure that the path
>    by which requests reach them traverses their privacy service.  In
>    some architectures, the privacy service function will be fulfilled by
>    the same server to which requests for the local administrative domain
>    are sent, and hence it will automatically be in the path of incoming
>    requests.  However, if this is not the case, the user will have to
>    ensure that requests are directed through a third-party privacy
>    service.  The simplest way to accomplish this is to procure a
>    'private' URI from the third-party service and to distribute this as
>    an address-of-record.  The user would then register their normal
>    address-of-record as a contact address with the third-party service.

Based on this, the third party privacy service would see the request
before their actual provider. I can imagine there are also cases where
the opposite makes more sense - the user registers their anonymous AOR
as a contact address with their actual provider. TO me, this makes more
sense. You want the privacy function closest to the user; in the case of
responses, that means that you want it to be the first element that gets
the response, which would motivate registering the anonymous AOR as a
contact with the actual provider.

Another means for providing anonymity of responses is to use a CPL
script to forward a request to the anonymization service. I think its
worth mentioning this as well.

This also raises the question of whether a privacy service is a "hop"
described by a URI in a route header, or is an identity, which would
appear in the request URI and be translated. Clearly, the assumption
above is the latter. Thats going to be true for some privacy services,
but for things like session privacy, I would argue that these are hops,
and they are ideally reached with URIs in route headers, not the
request-URI.

> The techniques described in this section do not extend to the
>    creation of falsified but plausible URIs and display-names that do
>    not identify the originator but may fool the remote party into
>    believing that the originator is not anonymous. 

Awkward - reword.

> If these headers require anonymization, the
>    user MUST request that service from an intermediary, namely a privacy
>    service.
> 

MUST seems overly strong in this case....

> For headers indicating how further requests in the current dialog
>    should be routed (such as the Contact header)

I think its useful to provide the full set, namely, Contact, Via, and
SDP addresses and hostnames.

I don't understand why section 5 is a separate section. Since its about
construct anonymous messages, it seems like it is naturally a subsection
of 4.1. This relates to my meta-comment about the verbosity of the
draft; it reads a bit too much like a dialog, and not quite enough like
a protocol specification. Section 5 is really describing normative
behavior for user agents, and belongs in the section which describes
that.

> This document defines a new SIP logical role called a "privacy
>    service".  The privacy service role is instantiated by a network
>    intermediary, frequently by entities that can act as SIP proxy
>    servers.  The function of a privacy service is to supply privacy
>    functions for SIP messages that cannot be provided by user agents
>    themselves.

I think its worth noting that privacy services are described by URIs
(see above comments on whether they are hop URIs or destination URIs)

> However, if the Privacy header value of
>    'none' is specified in a message, privacy services MUST NOT perform
>    any privacy function.

I have a feeling that the MUST NOT strength is going to be a problem for
these folks that claim they have a regulatory requirement to provide
privacy even when the user doesn't want it (or at least, I recall that
this was the claim).

>  Privacy services MUST implement the 'none' and 'critical' privacy
>    levels, and MAY implement any of other privacy levels described in
>    Section 4.2 as well as any extensions that are not detailed in this
>    document.

'critical' is not really a level, so much as a qualifier on all of the
other levels. 

> When a privacy service performs one of the functions corresponding to
>    a privacy level listed in the Privacy header, it SHOULD remove the
>    corresponding priv-value from the Privacy header - otherwise, any
>    other privacy service involved with routing this message might
>    unnecessarily apply the same function, which in many cases would be
>    undesirable.  When the last priv-value (not counting 'critical') has
>    been removed from the Privacy header, the entire Privacy header MUST
>    be removed from a message.

I am concerned about the complete removal of the privacy header. THe
problem is that downstream elements may insert additional identification
information into the request. I would propose that a new value for the
header be defined, say "no-add", which tells elements that they don't
need to modify any headers, but that they should not add any further
identification information to a request. If the header value was present
in a request, and is then performed by a proxy, the proxy changes that
value to no-add.

> Firstly, a request for header privacy entails that the server SHOULD
>    NOT add any of the following headers to the message: Call-Info,
>    Server, and Organization.  All of these provide optional information
>    that could reveal facts about the user that has request anonymity.
> 

I would make the statement more general, namely, it SHOULD NOT add any
headers which could reveal any identity information. For example,
Call-Info, Server and Organization.

> Privacy services operating on requests SHOULD remove all Via headers
>    that have been added to the request prior to its arrival at the
>    privacy service (a practice commonly referred to as "Via hiding")

No, its not "via hiding", which has a specific definition from rfc2543.
This is different; I would call it "via stripping". 

> Note
>    that the topmost such Via header in a request contains an IP address
>    or hostname that designates the originating client, and subsequent
>    Via headers may indicate hosts in the same administrative domain as
>    the client.

This is backwards. Its the bottom-most Via header value. Note also that
you should use the formal terminology - there is only one Via header,
but it has multiple values.

>  When a privacy service alters the Contact header of a
>    request, it MUST insert a Record-Route header pointing to itself so
>    that it can restore the appropriate contact address as necessary.

Thats not true. The Contact header will presumably route to itself, so
that an additional record-route is not necessary. 

> In a manner similar to Via hiding, a privacy service SHOULD also hide
>    any Record-Route headers that have been added to a request before it
>    reaches the privacy service.  Such Record-Route headers might also
>    divulge information about the administrative domain of the client.
>    Once Record-Route headers have been hidden, however, the privacy
>    service MUST add appropriate Route headers to future requests as
>    needed.

Given how easy it is to get this wrong, I would avise putting a bit more
text in there about properly constructing the route and record-routes. 

>  that are so removed, which requires the privacy service to keep a
>    pretty significant amount of state on a per-session basis. 

Its per-dialog. Its worth noting that forking could create multiple
dialogs, each of which would then need to be managed.

> Note that the privacy service MUST remove any non-essential
>    informational headers that have been added by the client, including
>    the Subject, Call-Info, Organization, User-Agent, Reply-To and In-
>    Reply-To.

You use the term client here, which would imply that this is only for
requests. Since the spec is generally request/response agnostic, you
need to use the term "user agent". I suspect there are other instances
of things like this too; I personally read most of the draft with
requests in mind. Its worth doing a pass on the document with responses
in mind to make sure its correct.

> Therefore, any time that a privacy service needs to modify any
>    dialog-matching headers for privacy reasons, it SHOULD act as a
>    transparent back-to-back user agent

This was discussed on the list; the term transparent B2BUA is not
defined in bis or in this document. You need to be more exact in your
definitions.

> Note that authentication mechanisms, including the Digest
>    authentication method described in the SIP specification, are outside
>    the scope of the privacy considerations in this document.  Revealing
>    identity through authentication is highly selective, and may not
>    result in the compromise of any private information.  Obviously,
>    users that do not wish to reveal their identity to servers that issue
>    authentication challenges MAY elect not to respond to such
>    challenges.

Ah, here is some text on Proxy-Auth and Auth. I disagree that these are
outside the scope of the spec, and I think they deserve discussion along
the lines I have outlined above.

> IANA Considerations
> 
>    This document defines a new SIP header called "Privacy" that allows a
>    user agent to request a certain degree of privacy for a message.
>    This header is defined in Section 4.2.

I am a big fan of very explicit IANA considerations sections. I would
recommend you format this section as an outline, like this:

  Header Name to be Registered:  Privacy
  
  RFC of Specification: RFC XXXX [Note to RFC Editor: please replace
XXXX with the RFC number of this specification]

  Compact Form: none defined

By the way, do we want to define a compact form?

> The current values of the "Privacy" header are restricted to
>    'header', 'session', 'user', 'none' and 'critical'.  However, further
>    values for the "Privacy" header can be defined in RFCs approved by
>    the SIP working group.  IANA registration for these "Privacy" header
>    field values is required.

If you are setting up an IANA registry for these values, you are going
to need more detail than this. See the sip-events spec for a good
example of how to define an IANA registry.

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