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

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 30 May 2002 12:37:46 -0500

Thanks for these extensive notes - the draft definitely needed a solid
reading. Most of these edits I'll accept as you've suggested; a few notes
below on interesting or controversial issues.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, May 29, 2002 12:29 PM
> To: Dean Willis
> Cc: 'sip'; [email-masked]; [email-masked]; [email-masked];
> Jon Peterson ([email-masked])
> Subject: Re: [Sip] WGLC for draft-ietf-sip-privacy-general
> 
> 
> 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.
> 

I think anonymous callback is distinct from privacy as it is defined here.
Apparently, sip:[email-masked] is an address at which you can reached
-  even though it is a relatively opaque piece of data, I would still
consider it in this definition a form of identity, one best suited to
something like anonymous callback. The term 'personal information' is
sometimes used in this draft to refer to something other than 'identity' -
the identity sip:[email-masked] reveals no personal information.
Perhaps this is a distinction that could be drawn out a bit more.

[snip]
> 
> > 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?
> 

I'll rephrase that a bit. My point was just that I don't happen to reference
and detail any existing SIP extensions in this draft. Obviously the draft
has its own extensibility mechanism to accomodate future extensions, and
even some recommendations for authors of extensions to SIP.

[snip]
> 
> > 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
> 
[snip]
> 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.
> 

Some effort has been made in the recent privacy/identity work to split
privacy and identity concepts into separate drafts. The practices you
describe for providing identity information to a server that issues
challenges, I think, belong in the identity drafts, not here (there is some
text exactly to this effect in the second section of my longterm identity
draft, actually). For the most part, we've also tried to put concerns
related to authentication into the identity drafts, both of which
normatively depend on the privacy draft. I really don't want to duplicate
language and so forth, so I hope that the language in the Sec Cons of the
privacy draft is really all we need here.

There are, after all, other forms of authentication than SIP Digest, which
have parallel concerns, and I don't think we should open that can of worms
in the privacy draft.

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

Yes, the To/From implication combined with obscuring of the Contact(s) is
one reason why Privacy isn't allowed here. Note that the levels of
granularity you suggest are already in the draft, I think, since the
procedures for 'header' level privacy (6.1) entail the obfuscation of
Contact/Via/RR, whereas only 'user' level privacy conceals the To/From. So
actually, I think it would be possible to only obscure contacts.

I guess this extension just isn't designed to keep identity information
private from registrars - the utility of that remains obscure to me after
some reflection on the matter. This is partly a question of when the privacy
service should be closer to the user (presumably one hop away) than a
registrar, when it should be farther away, and when the privacy service and
registrar should be colocated. Registering an anonymous Contact could be
meaningful when your privacy service is closer to you than your register. If
the two are conflated, or the registrar is closer than your privacy service,
there probably wouldn't be any need to register an anonymous Contact.
Although the draft mandates no architecture, I think it leans towards this
second scenario for providing privacy when you are the called party.

Given all that, though, I agree that this restriction can be removed -
there's no reason to forbid registering a Contact through a privacy service
that will provide privacy for these Contact addresses (granted that what
appears in the Contact after it passes through a privacy service is an
'anonymous callback' sort of contact address, rather than an unroutable URI
that expresses anonymity).

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

Proxy-Require would also make it difficult to have a privacy service reside
more than one hop away from a client.  But agreed that criticality is
severely hampered without something along these lines. This had been
discussed briefly (off the list, I think), but I don't think the discussion
ever arrived at any conclusion.

Throughout the draft the assumption is made that the user is aware of a
distinct privacy service in the network, with which they have some sort of
relationship, through which calls will be routed. Arguably, without that
relationship a privacy service is of no value (that is, not just any privacy
service will do - it must be one that is specifically known to the user for
reasons of accountability). In that sense, the draft makes the (possibly
dangerous) assumption that no in-band feature negotiation is necessary - the
user knows out-of-band that that the server in question supports privacy.
Would be a pity if they were wrong.

As we've discussed before, this taps somewhat into the whole service
discovery/composition problem, one that we know isn't going to be resolved
in the scope of this draft, anyway.

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

The text above is meant to suggest that users should know out-of-band that
their local administrative domain supports a privacy service function.

[snip]
> 
> > 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.

I think both approaches probably have their place. The approach I detail
above is more of a sort of anonymous callback' service; a user could
distribute a 'private' URI in the From field of requests they send. In this
case the privacy service effectively becomes the registrar of the user.

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

I think you are exposing that latent distinction in the draft between an
'anonymous callback' identity and a privacy service that acts on normal
identityies - that there are actually a couple of ways that a request could
potentially reach a privacy service. Pre-loaded routes are the most common
way, but anonymous callback identities are another way to reach a privacy
service. Again, agreed that this distinction should be formalized a bit.

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

I suppose I felt that URI creation actually wasn't the exclusive
responsibility of user agents - privacy services also have some
responsibility for creating anonymous URIs. I really don't feel that
strongly about how the sections are arrayed.

Specmanship is a much more difficult art than protocol design. I think there
needs to be a prosody RFC, a Strunk & White of the IETF, so slow learners
like myself can get up to speed a little quicker.

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

I hope the existing wording will be sufficient - my conversations with some
of the parties raising these regulatory concerns have suggested that
networks are required to implement the user's preferences (that tends to be
the motivating government requirement). The trick is, there needs to be a
way for those preferences to be specified implicitly and administratively,
not just explicitly and in-band. We do provide a way to do that in the
draft.

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

Agreed that parties downstream might add further information to the request
- but these entities might not even support the Privacy extension at all.
I'm not sure what we can really do to guard against this contingency. Maybe
this doesn't really come through in the text today (something I should fix),
but I've been envisioning that users should try not to route the request
through intermediaries that are likely to add personal information
subsequent to the privacy service (by choosing appropriate preloaded Route
header orders, perhaps). This argues a bit on the 'closeness' issue for
keeping your privacy service far away from you.

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

That would work too, and is probably more efficient -  I was envisioning
that the privacy service would add a Contact header with an anonymous URI
(i.e. one using the 'anonymous.invalid' hostname), and that therefore
Record-Routing was necessary to get the request back to the privacy service.
Of course if the Contact indicates the privacy service, that is sufficient.
I note that this makes the anonymous Contact registration story make a bit
more sense.

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

Agreed, it's potentially pretty complicated. My text above does ring a bit
of "magic happens".

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

I'd hate to be defining that common term in this document... but, agreed,
this section should be more explicit about the exact behavior required.

> > IANA Considerations
[snip]
> By the way, do we want to define a compact form?

Um... I don't know, really. Any other opinions about that?

> THanks,
> Jonathan R.

_______________________________________________
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: "Bob Penfield" <[email-masked]>
Date: Fri, 31 May 2002 15:53:19 -0400

see comments below
----- Original Message -----
From: "Peterson, Jon" <[email-masked]>
[snip]
> actually, I think it would be possible to only obscure contacts.

As you say, there is only an implication of which headers the 'user' or
'header' levels apply to. Do we need an explicit list in the draft?

> that expresses anonymity).

Although I agree that privacy is useful for REGISTER, it then becomes
critical that the REGISTER message be secured between the UA and the
registrar since it contains the mapping between the AOR and
anonymous-callback-URI.

> their local administrative domain supports a privacy service function.

I too am quite concerned about this. It seems adaquate to say the UA "just
knows" when we're talking about a P-Header with limited applicability, but
not necessarily for a general purpose protocol mechanism.

However, this mechanism would use a Require header, not a Proxy-Require.
There are very few headers mentioned in this draft that RFC 3261 allows a
proxy to modify or delete. I assert that performing any user, header or
session privacy functions in an intermediary turns the privacy service into
a B2BUA. If the UA is aware that is sending to a privacy service then it can
certainly be aware that it is sending to a B2BUA and include the tag in its
Require header.

[snip]
> I note that this makes the anonymous Contact registration story make a bit

I agree that just the Contact is more efficient, but will that be the only
method allowed?

And one more thing, in section 6 it says "Privacy services MUST implement
the 'none' and 'critical' privacy levels". I just thought it was weird that
a privacy service that had the minimum required implementation would not
actually perform any privacy function.

cheers,
(-:bob

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 May 2002 16:08:57 -0400

"Peterson, Jon" wrote:

> Perhaps this is a distinction that could be drawn out a bit more.

I'm confused as to whether you are agreeing or disagreeing with me....

> even some recommendations for authors of extensions to SIP.

Right - but what I mean is, if a future extension to SIP defines some
new form of identity, this specification would apply to help ensure
privacy of that information, no?

> privacy draft is really all we need here.

There are privacy concerns with digest which are important to mention.
Specifically, a UA that wants to know who I am might issue a 401, and
fake the realm for my domain. I provide my identity in an Authorization
header, and this information is then provided to the UAS. The problem is
that the existing digest mechanism has a flaw regarding privacy, in that
there is no assurance that the entity requesting credentials for the
realm properly represents the realm, unless you are connected to them
through TLS. Thus, I think it is important to mention this problem here.

> have parallel concerns, and I don't think we should open that can of

The problem above is specific to digest. It doesn't exist for other
forms of authentication (for example, entering a pin into an IVR
system), since there I can verify the identity of the system because I
dialed the number to access it, and *presumably* pstn routing will
ensure that the call reaches the proper system.

> actually, I think it would be possible to only obscure contacts.

OK, I missed that.

> that expresses anonymity).

True; this differing requirement may be sufficient to say that REGISTER
security really is something different, and would necessitate a separate
tag for it. So, I'm changing my mind here.

> more than one hop away from a client.

I thought you had argued that it more or less HAS to be one hop away in
order to properly authenticate it....

>  But agreed that criticality is

Big pity.

> in the scope of this draft, anyway.

I don't think we need to boil the ocean here. If the common case is the
one where the privacy service is one hop away, and the user wants
assurance that its really running there, Proxy-Require provides an easy
way to determine that with no loss of functionality (it should strip the
proxy-require). There are clear problems if its multiple hops away, and
so perhaps its not used in that case, or perhaps it is, but at least its
defined and available in order to get a high degree of assurance.

> case the privacy service effectively becomes the registrar of the user.

OK, so can the other case get documented here as well?

> strongly about how the sections are arrayed.

We ran into this issue a few times with bis, and decided to place the
text within the context that first needed it, and then back-reference it
from the other place. 

> - but these entities might not even support the Privacy extension at

Yup. Bad. 

> I'm not sure what we can really do to guard against this contingency.

Well, if you had the proxy-require tag, you could have a privacy tag
which instructed the last service to not strip proxy-require. This
provides insanely high degrees of certainty, at a cost of interop. If
the proxy-require is stripped, having the privacy tag still there at
least helps in those proxies which DO understand this extension, so its
still better than nothing. If, as we hope, this draft gets widely
implemented, and every proxy supports it, you would hamper the ability
to offer privacy functions to future extensions that might have proxies
inserting information. As such, I feel quite strongly that some kind of
privacy tag needs to get propagated all the way.

> Maybe

Well, I don't know in general how the user would know ahead of times
what route headers to use in order to avoid additional intermediaries...

> Um... I don't know, really. Any other opinions about that?

I always have mixed feelings on compact form; arguably sigcomp makes it
moot, but since we are approaching the mtu in many inter-proxy
messages...

-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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 May 2002 16:17:17 -0400

Bob Penfield wrote:

> not necessarily for a general purpose protocol mechanism.

Right.

> certainly be aware that it is sending to a B2BUA and include the tag in

Hmm. The problem is that you want get the desired effect if there are no
privacy services on the path, and you thought there were. Inserting a
Require: privacy in teh request would get the request all the way to the
UAS, who then knows your identity, in addition to knowing that you
wanted to be anonymous. Seems like the worst of all cases. So, while in
theory, you might be right, practically speaking this has to be
proxy-require to work.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 31 May 2002 17:00:12 -0400

Dean Willis wrote:
> 
> > Hmm. The problem is that you want get the desired effect if
> > there are no privacy services on the path, and you thought
> > there were. Inserting a
> > Require: privacy in teh request would get the request all the
> > way to the UAS, who then knows your identity, in addition to
> > knowing that you wanted to be anonymous. Seems like the worst
> > of all cases. So, while in theory, you might be right,
> > practically speaking this has to be proxy-require to work.
> 
> And you have to KNOW you have a proxy in between, otherwise the remote
> UA gets the Proxy-Require header AND your AI.

Good point. 

> 
> Query -- is the presence of the Proxy-require header in a message
> delivered to the remote UA in and of itself a privacy issue? They KNOW
> you've requested privacy . . .

The from field already says its anonymous (in all likelihood). So, I
don't see a problem.

-Jonathan R.

---

From: "Dean Willis" <[email-masked]>
Date: Fri, 31 May 2002 15:54:21 -0500

--
Dean