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

From: Michael Thomas <[email-masked]>
Date: Fri, 29 Jul 2005 13:28:36 -0700

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

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.

		Mike, it's been a long time so treat me gingerly

Jonathan Rosenberg wrote:
> 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.
> 

_______________________________________________
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