Subject: [Sip] Comments on draft-munakata-sip-privacy-clarified-00

From: "Elwell, John" <[email-masked]>
Date: Thu, 15 Mar 2007 10:40:27 +0000

Mayumi,

I think the Privacy header field does need to be brought up-to-date by
removing unused and badly specified values and to align with more recent SIP
capabilities such as GRUU, Target-Dialog, Identity, etc., so I welcome this
draft. Some comments:

It needs to be clarified whether this is intended to obsolete or update RFC
3323. Section 1 says that it obsoletes RFC 3323. However, it also refers to
and clarifies the extensions to the Privacy header field in RFC 3325 and RFC
4424, and these extensions refer normatively to RFC 3323. So I don't think
it is possible to obsolete RFC 3323 unless RFC 3325 and RFC 4424 are updated
to reference the new RFC.

In section 1 it mentions the Identity header field as revealing identity
information. This is not true, because it is simply irreversible
cryptographic information. However, the Identity-Info header field could
reveal information about the requester's domain (although this would only be
included when signing a From header field URI that itself reveals
information, so I don't think it needs to be considered). Impact also on
5.1. It should also be mentioned that a privacy service must come before an
authentication service (RFC 4474), because the authentication service will
sign the From and Contact header field URIs, for example. I see that 6.2.7
has more in-depth discussion on these header fields, but I am not sure it
captures these points accurately.

In section 3.2, it should be mentioned that if only network privacy is
requested no network intermediary is allowed to override the user-provided
privacy.

In section 4.1, we should mention in the table all methods, including those
defined since RFC 3323 was published (e.g., PUBISH).

In section 5.1, table 1, P-Preferred-Identity is missing. Should we
recommend that a UA omit it, or is it still useful between the UA and its
domain proxy?

Table 1 does not make a distinction between requests and responses. For
example, you cannot anonymise a Call-ID or Via header field in a response
(although it can restore stripped out values, as mentioned below the table
for Call-ID).

Section 6.1.2, last paragraph. Presumably this refers to the Contact header
field URI.

Section 6.2.1, add Join to the list of header fields that can contain a
call-ID. There is a dependency on in-bound requests outside a dialog being
routed via the same privacy service - is this an issue? I think it is
captured later in 6.4.3 specifically for the Replaces header field, but does
it need to be discussed earlier in general terms? Also it should be
mentioned in the sections dealing specifically with Join and Target-Dialog.

Section 6.2.11 recommends anonymisation of Referred-By, but is there any
benefit in having an anonymous Referred-By URI as opposed to omitting this
header field?

Section 6.2.14. Surely it is acceptable to add a Subject header field if it
doesn't reveal identity in any way?

Section 6.4.4. Shouldn't this discuss the restoration of Route header field
values that have been stripped out of Record-Route header fields?

Section 7.1. This fails to discuss location of a privacy service for
mid-dialog-requests (but I think that is covered in section 8, where use of
Record-Route is discussed, so perhaps it doesn't matter). More importantly,
it fails to discuss location of a privacy service for requests that contain
header fields such as Replaces, Join and Target-Dialog.

I may have missed it, but is it specified anywhere whether a privacy service
is required to pass on the Privacy header field or strip it out?

John

_______________________________________________
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: Mayumi Munakata <[email-masked]>
Date: Fri, 16 Mar 2007 11:53:02 +0900

Hi John,

Thank you for the detail comments to my privacy-clarified draft.

See inline.

> to reference the new RFC.

I am unfamiliar with the process, but we will change the text 
to say that it updates RFCs 3325 and 4244 to reference the new RFC, 
if necessary.

> information, so I don't think it needs to be considered). Impact also on

You're right.  The Identity header doesn't reveal user's 
information.  But the Identity-Info header may reveal the 
information about the administrative domain of the user.  
I believe that the Identity/Identity-Info headers could 
sign functional anonymous From/Contact headers, and in this 
case, the domain name in the Identity-Info header is the 
only part that could reveal user privacy related information.

> captures these points accurately.

A privacy service doesn't always have to come before an 
authentication service.  As mentioned in section 6.2.7, 
if an authentication service comes before, a privacy service
 will compute and replace the Identity/Identity-Info header 
when it anonymizes From/Contact headers.

> requested no network intermediary is allowed to override the user-provided

Agree.  We will add text.

> defined since RFC 3323 was published (e.g., PUBISH).

Agree.  We will add PUBLISH and REFER(oops!) in the table.

> recommend that a UA omit it, or is it still useful between the UA and its

The P-Preferred-Identity header must be removed by proxy in 
a trust domain so you don't have to worry about the privacy.
We can add a text in section 6.4 (Considerations for 
Non-Target SIP Headers).

> (although it can restore stripped out values, as mentioned below the table

How to handle Call-ID and Via headers in a response is 
mentioned in section 6.2.1 and 6.2.16, respectively.  
However, I agree that it is more easily understandable 
if the table is separated into requests and responses.

> Section 6.1.2, last paragraph. Presumably this refers to the Contact header

Right.

> mentioned in the sections dealing specifically with Join and Target-Dialog.

We might have make an oversight about the Join header.
Yes, a dependency on in-bound requests outside a dialog 
being routed via the same privacy service is the issue.

> benefit in having an anonymous Referred-By URI as opposed to omitting this

This is another issue we would like to discuss in Prague.

> doesn't reveal identity in any way?

That's right.  This behavior traces back to RFC 3323.  
We will change the text.

> values that have been stripped out of Record-Route header fields?

This is complex so we need to show some examples to explain.
When UAC (Alice) requires privacy for a request, 
a privacy service doesn't have to handle Route header.

Alice > INV(Privacy:all) > P1 > INV(Record-Route:P1, Privacy:all) 
	> PS > INV(Record-Route:PS) 
	> P2 > INV(Record-Route:P2,PS) > Bob
Bob > 200(Record-Route:P2,PS) > P2 
	> PS > 200(Record-Route:P2,PS,P1) > P1 > Alice
Alice > re-INV(Route:P2,PS,P1, Privacy:all) 
	> P1 > re-INV(Route:P2,PS, Privacy:all) 
	> PS > re-INV(Route:P2) > P2 > re-INV > Bob

When UAS (Bob) requires privacy for a response, 
that's another story.

Alice > INV > P1 > INV(Record-Route:P1) 
	> P2 > INV(Record-Route:P2,P1) > Bob
Bob > 200(Record-Route:P2,P1, Privacy:all) > P2 
	> PS' > 200(Record-Route:PS',P1) > P1 > Alice
Alice > re-INV(Route:PS',P1) > P1 > re-INV(Route:PS') 
	> PS' > re-INV(Route:P2) > P2 > Bob

Yes, I agree that the Route header should be restored 
by the stripped value out of Record-Route, in this case.

Again, we need to distinct the behaviors for 
requests and responses...

> header fields such as Replaces, Join and Target-Dialog.

That is an issue, too, unless we don't have to make the 
replacement work using Replaces with anonymous call-ID.

> is required to pass on the Privacy header field or strip it out?

As mentioned in the 6th paragraph in section 8, a privacy service 
should remove the corresponding priv-value and must remove the 
entire Privacy header when all the priv-value has been removed.

Thanks,
Mayumi

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 16 Mar 2007 08:01:54 +0000

Mayumi,

Just a few points.

John 

> -----Original Message-----
> From: Mayumi Munakata [mailto:[email-masked]] 
> Sent: 16 March 2007 02:53
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [Sip] Comments on draft-munakata-sip-privacy-clarified-00
> 
> Hi John,
> 
[JRE] OK, but I think this needs group discussion before making the change.

> when it anonymizes From/Contact headers.
[JRE] Then the privacy service is forced to become an authentication service
too. I don't think we should mix the two concepts. If we assume that a
privacy service will always remove the domain from the From header field URI
(replacing it with anonymous.invalid), then in fact an authentication
service coming after the privacy service will be unable to add an Identity
header field, so no problem. If the authentication service comes first, the
privacy service must simply remove the Identity and Identity-Info header
fields. Perhaps that is all we need to say.
However, if the privacy service were to retain the domain in the From header
field URI, an authentication service that comes after the privacy service
would be able to add an Identity header field to authenticate the caller as
an anonymous user in the domain concerned. This too would be harmless.
Because this option is not recommended, I guess we don't need to say
anything.

[JRE] We seem to be missing a statement that we MUST or SHOULD use
sip:[email-masked] when anonymising a From header field URI.
This recommendation was given in RFC 3323 and must not be lost.

> entire Privacy header when all the priv-value has been removed.

[JRE] Another point. The recommendation for the UA to include a
Proxy-Require header field if it "believes that it is sending a request
directly to a privacy service". Is this a reasonable recommendation? In
general, a privacy service is likely to be realised at the domain proxy, and
there would be no need to provide a privacy service at edge proxies. Is it
reasonable for the UA to have to take this into account? Perhaps a solution
is to specify procedures for edge proxies that are aware that there is a
downstream privacy service to pass on the Privacy header field along with
the Proxy-Require header field. Furthermore Proxy-Require is not appropriate
in responses.

[JRE] Yet another point. This document contains a very large number of
SHOULD statements and relatively few MUST statements. As a consequence,
there is very little a UA or proxy needs to do to conform to this, if it
ignores all the SHOULD statements. I think this largely reflects the style
of RFC 3323. However, recent thinking is to use SHOULD conservatively, and
when it is used provide discussion concerning circumstances where the
recommendation need not be followed.