Subject: [Sip] privacy in draft-ietf-sip-identity - Privacy header field ineffective

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 25 Jul 2005 11:53:09 -0400

Folks,

Jon, Cullen and I wrote up an I-D that talks about the issues of privacy 
in draft-ietf-sip-identity. The draft can be found here:

http://www.ietf.org/internet-drafts/draft-rosenberg-sip-identity-privacy-00.txt

As it turns out, rfc3323 (the privacy header field), has numerous 
problems when applied to draft-ietf-sip-identity:

   Intra-Domain Privacy: Because the SIP identity mechanism relies on
       the domain of the From header field as a key for obtaining
       certificates used to validate the identity in the From header
       field, anonymity is restricted to being within a domain.  It is no
       longer possible, as described in RFC 3323, to populate the From
       header field with "anonymous.invalid" as the domain.  As a
       consequence, a recipient of the request will be able to determine
       the domain of the originator of the request, though they will not
       be able to determine which user within that domain sent the
       request.  This limitation is not very troubling for domains with
       extremely large numbers of users.  However, for small domains,
       such as enterprises or home networks, it can be equally revealing
       as the identity of the requestor themselves.

    Contact Privacy lost: Because the SIP identity mechanism relies on a
       signature over the Contact header field for referential integrity,
       a privacy service that provides header privacy cannot actually
       modify the Contact value.  This will reveal the IP address of the
       requestor to the recipient of the request, which can often provide
       substantial information about the requestor.

    Session Privacy lost: Session privacy is accomplished through a back-
       to-back user agent (b2bua) that rewrites the SDP to relay session
       media through an intermediary.  This no longer works at all with
       the SIP identity mechanism, as it relies on a signature over the
       body of the request (which contains the SDP) to provide
       referential integrity.

    Subscriber Identity Lost within Originating Domain: One of the
       benefits of the P-Asserted-ID header field when used in
       conjunction with the "id" level of privacy is that elements within
       the domain of the originator of the request will still be able to
       determine the identity of the originator.  This is necessary for
       providing features for the requestor, accounting for their usage,
       and so on.  With the SIP identity mechanism, if privacy is needed,
       the From header field contains an anonymous URI.  As a result, the
       request has no information that can identity the user within their
       own domain, unless the SIP identity mechanism is used in
       conjunction with RFC3325, which is redundant.

    These problems are in addition to the problems inherent in RFC 3323
    to begin with:

    Sensitivity to Boundary Configuration: Although RFC3323 argues
       strongly in favor of placing the privacy service very near the
       originator of the request, this goal is at odds with RFC 3325,
       which requires the privacy service to be on the egress edge of the
       trust domain.  As a result, privacy is actually provided only if
       every egress proxy is properly configured to take positive action
       and remove the P-Asserted-ID header field.  Because positive
       action from the network is required to provide privacy, this
       mechanism is sensitive to misconfiguration of network elements,
       particularly in large interconnected trust domains.

    Complicated Call Trace: In many networks, there is a requirement to
       provide a call trace feature that allows for malicious callers to
       be traced back to their source so that legal action can be taken.
       The utility of such features in a global SIP network aside, RFC
       3323 makes such a feature difficult to provide since the identity
       of the requestor is literally removed from the request.  This
       complicates the tracking procedures needed to identify the
       originator later on.

    Limited Flexibility The degrees of privacy that RFC 3323 could
       provide were coded into the tokens valid in the Privacy header
       field.  More complicated combinations - anonymity for certain
       media streams but not others, for example - were not possible.

The draft proposes a mechanism to fix these problems. This mechanism 
would allow rfc3323 to be deprecated.

Comments or questions?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Fri, 29 Jul 2005 16:49:18 -0400

Michael Thomas wrote:

> I guess my first question would be why you'd expect -identity
> to work through a b2bua in the first place.

It doesn't. I'm merely pointing out that problem.

  It seems to me
> to be *feature* that anything that changes the semantics of
> the original message would break the signature. That and my
> head goes in loops when say that you want source authentication
> that's, well, anonymous.

Not sure I follow here; I think there is a reasonable definition of an 
anonymous request with source authentication.

> 
> Don't all of these problems go away if you say that the
> B2BUA needs to be trusted by the originator, and that the
> anonymizing service becomes the new From: address, etc? I
> can't think of a case where the orignator wouldn't have to
> have some trust in the anonymization service because if
> nothing else it could trace your IP address back.

If each b2bua rewrites the From and re-signs, we basically have a 
solution with equivalent security properties to P-Asserted-ID. However, 
in more thoroughly connected networks, those properties have significant 
problems as I mention in the draft.

-Jonathan R.