Subject: [Sip] Anonymous URI for From header in ua-privacy-01

From: Mayumi Munakata <[email-masked]>
Date: Tue, 19 Feb 2008 14:45:08 +0900

All;

I have just submitted a new version of ua-privacy draft.
http://www.ietf.org/internet-drafts/draft-ietf-sip-ua-privacy-01.txt

Thanks to John Elwell for his comprehensive review,
we managed to make a lot of editorial corrections
and some technical.

One profound open issue we have is on how to get an
anonymous URI for a From header.  While we can use a
temp-gruu for a Contact header, there is no mechanism
to obtain a functional anonymous URI for the From
header or any other headers that houses URIs.

RFC3323 recommends to use "[email-masked]"
for an anonymous URI in a From header.  However, this
impedes the use of SIP-Identity, as SIP-Identity
mandates the domain portion of the "From" URI and
that of "Identity-Info" to match.

One of the expired draft written by Jonathan, attempted
to use the GRUU to get this functional yet anonymous URI
to address this issue.
http://ietfreport.isoc.org/idref/draft-rosenberg-sip-identity-privacy/

I can see few ways forward.

1. Suggest the use of anonymous@{user's domain name}, which
   verifier then can verify the signature's validity as
   domain portion of the URI and that of Identity-Info matches.
    >> If SIP-Identity is used, the domain is given away anyhow
       in the Identity-Info, so what is the point of hiding the
       domain in the From header?

2. Make a note that SIP-Identity will not function when
   [email-masked] is used.
    >> Describe the caveat that verifier is likely to fail the
       request or suggest that Authentication Service does not
       add Identity-Info/signature.

3. Extend GRUU to support mechanism that Rosenberg suggested.

Does anybody has any preferences or any other suggestions?

Regards,
Mayumi

_______________________________________________
Sip mailing list  http://www.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: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Feb 2008 10:37:38 -0500

Why would you want sip-identity for an anonymous From address?

IMO it is perfectly fine to provide an address with no identity.

	Paul

---

From: ".:: Francesco la Torre ::." <[email-masked]>
Date: Tue, 19 Feb 2008 16:56:25 +0100

According some general privacy considerations, from an authentication
service's point of view, an anonymous may be a known user in his domain
that he has authenticated, but he's keeping its identity private.
Nothing strange.

Francesco la Torre

IIT-National Council Research
Security Session 
Pisa, Italy

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Feb 2008 11:04:49 -0500

> that he has authenticated, but he's keeping its identity private.

Fine. But what value does that bring to the recipient, compared to no 
authenticated identity at all?

	Paul

---

From: ".:: Francesco la Torre ::." <[email-masked]>
Date: Tue, 19 Feb 2008 17:34:22 +0100

IMO authenticated but private is something more then not authenticated.
In first case, you know that on the other end there is an authenticated
user for that domain, in the second one there is a complete lack of
identity ... this entails that there is no reasons why sip uri (e.g.
[email-masked]) cannot be signed by authentication service.

This uri may be used for special scenarios generating the value you are
looking for.

Francesco la Torre

IIT-National Research Counsil
Security Session 
Pisa, Italy

---

From: David R Oran <[email-masked]>
Date: Tue, 19 Feb 2008 13:14:42 -0500

> [email-masked]) cannot be signed by authentication service.
Of what value to a recipient is an authenticated From:[email-masked] 
? Or a phished [email-masked]?

In the absence of a reputation service and separate authentication of  
the source domain I don't see any at all. What are your assumed  
preconditions for this authentication to have value?

These need explicit statement.

---

From: Dean Willis <[email-masked]>
Date: Tue, 19 Feb 2008 13:56:26 -0600

> preconditions for this authentication to have value?
There is a distinct difference between a caller who is unknown to me but 
known to someone who is known to me and a caller who is truly anonymous. 
In the first case, if the caller proves to be "a problem", I have some 
recourse through channels. In the second, I do not.

So let us take the typical public network scenario.  If all caller's 
identities are known to the operator, an anonymized identifier asserted 
by that operator could be used to trace a nuisance call back to the 
source. That's useful: It could drive "black listing" operations, "white 
listing" operations, and support legal investigation into harassment 
calls, etc.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 19 Feb 2008 16:17:23 -0500

In this case there is no expectation that the anonymized address will be 
willing or able to report to anyone what the identity of its client was. 
In the absence of any such assurance, having sip identity is of no use.

	Paul

Dean Willis wrote:
>> Of what value to a recipient is an authenticated 
>> From:[email-masked] ? Or a phished 
>> [email-masked]?
>>

---

From: Dean Willis <[email-masked]>
Date: Tue, 19 Feb 2008 21:10:50 -0600

On Feb 19, 2008, at 3:17 PM, Paul Kyzivat wrote:

> In this case there is no expectation that the anonymized address  
> will be willing or able to report to anyone what the identity of its  
> client was. In the absence of any such assurance, having sip  
> identity is of no use.

I disagree.

The presence of an Identity header declares that the  asserter of the  
anonymized identity  of the address, will if suitably encouraged (as  
in a court order), reveal the identity of the client.  If they aren't  
willing to take the responsibility of having made an assertion of  
identity on behalf of that client, then they shouldn't put an Identity  
header in.

I might be more willing to accept a call from an anonymous party if I  
knew that,  should said anonymous party be making a threat, my lawyer  
can subpoena somebody and find the culprit.

--
Dean

---

From: Mayumi Munakata <[email-masked]>
Date: Wed, 20 Feb 2008 13:57:10 +0900

Even if the asserter is not going to reveal identity of the client,
you can at least tell whether the call is authenticated by identity
service or not.  On the basis of that, I might want to receive
authenticated anonymous calls but reject simple anonymous calls.

Mayumi

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2008 07:35:10 -0500

Dean,

I don't think I agree.

In the non-anonymous case, the asserter will attest that the source is 
entitled to claim the address. AFAIK nothing else is implied. But assume 
it will provide more - for instance the name, address, and SS# of the 
person entitled to the address.

Now assume that the address is an "anonymous" address. The asserter will 
then be providing information about the anonymizer, not the entity that 
is being anonymized. Its entirely possible (likely) that the anonymizer 
won't maintain records that would give it the capability of reporting on 
the address being anonymized.

	Paul

Dean Willis wrote:
>> In this case there is no expectation that the anonymized address will 
>> be willing or able to report to anyone what the identity of its client 
>> was. In the absence of any such assurance, having sip identity is of 
>> no use.
> 
> 
> I disagree.
> 
> anonymized identity  of the address, will if suitably encouraged (as in 
> a court order), reveal the identity of the client.  If they aren't

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2008 07:44:10 -0500

If some UAS prefers an anonymous address that has been authenticated, 
then I have no objection, though I consider it irrational. But I don't 
see this as a necessary condition for a privacy mechanism.

	Paul

Mayumi Munakata wrote:
>> identity on behalf of that client, then they shouldn't put an 
>> Identity  header in.
>>

---

From: Dean Willis <[email-masked]>
Date: Wed, 20 Feb 2008 12:41:20 -0600

On Feb 20, 2008, at 6:35 AM, Paul Kyzivat wrote:

> Dean,
>
> I don't think I agree.
>
> In the non-anonymous case, the asserter will attest that the source  
> is entitled to claim the address. AFAIK nothing else is implied. But  
> assume it will provide more - for instance the name, address, and  
> SS# of the person entitled to the address.
>
> Now assume that the address is an "anonymous" address. The asserter  
> will then be providing information about the anonymizer, not the  
> entity that is being anonymized. Its entirely possible (likely) that  
> the anonymizer won't maintain records that would give it the  
> capability of reporting on the address being anonymized.

Well then in most jurisdictions it can go to jail for contempt of  
court when it can't respond to the court order. Seriously, you really  
shouldn't be acting as an identity service if you have no way to  
validate the identity being asserted against. It's like notarizing a  
signature on a document without checking the signer's ID.

In other words, the anonymizer and the identity service MUST be  
integrated. The identity service needs to perform an identity  
verification check on the user BEFORE anonymizing, if it's going to  
act as an identity service for that user. Slapping an identity record  
on something that's been anonymized elsewhere is worse than useless.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2008 14:00:11 -0500

Dean Willis wrote:
>> entitled to claim the address. AFAIK nothing else is implied. But 
>> assume it will provide more - for instance the name, address, and SS# 
>> of the person entitled to the address.
>>
> Well then in most jurisdictions it can go to jail for contempt of court 
> when it can't respond to the court order. Seriously, you really 
> verification check on the user BEFORE anonymizing, if it's going to act 
> as an identity service for that user. Slapping an identity record on 
> something that's been anonymized elsewhere is worse than useless.

We are entering the realm of legal opinion, where I am not qualified to 
operate. But I will still render an opinion.

I could potentially operate an anonymization service simply by getting 
two PSTN phones. If you want my service, you call me on one of my lines 
and tell me who you want to call. I call that number with my other line, 
and just hold the receivers together to couple the media.

The recipient will get the callerid of my 2nd line. You can serve me 
with a court order to provide the actual identity of the caller, but it 
won't do any good because I don't know who that was.

Further, I am not identity provider. My telco provider is the identity 
provider for the line. A court order to them also will serve no purpose.

I don't *think* anybody is violating any laws here.

I see a sip anonymization service as being logically equivalent to the 
above.

	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 20 Feb 2008 14:48:19 -0600

On Feb 20, 2008, at 1:00 PM, Paul Kyzivat wrote:
>
>
> I could potentially operate an anonymization service simply by  
> getting two PSTN phones. If you want my service, you call me on one  
> of my lines and tell me who you want to call. I call that number  
> with my other line, and just hold the receivers together to couple  
> the media.
>
> with a court order to provide the actual identity of the caller, but  
> it won't do any good because I don't know who that was.
>
> Further, I am not identity provider. My telco provider is the  
> identity provider for the line. A court order to them also will  
> serve no purpose.

Some would argue that you could be held culpable due to aiding and  
abetting. What happens if someone uses the open access point at your  
house to send threatening messages to the white house? What happened  
to the folks who ran the anonymous remailer service in Finland a while  
back? (see http://en.wikipedia.org/wiki/Penet_remailer)

> I don't *think* anybody is violating any laws here.

Laws vary. But we're I thought we were talking about another  
situation, see below.

>
>
> I see a sip anonymization service as being logically equivalent to  
> the above.
>

I didn't say you couldn't have a SIP anonymization service.  I'm  
saying that if you're running an identity service that inserting an  
identity header asserting that you know who the message is from when  
you don't actually know who the message is from  is a bad idea.

Conversely, there is a legitimate role for a service that is both an  
anonymizer and an asserter of identity. The assertion here is "I know  
who this person is, but I'm not telling you without proper cause". As  
an end user, I'd be inclined to grant this a higher level of trust  
than I would a message that claims nothing about who it might be from.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Feb 2008 16:47:45 -0500

> you don't actually know who the message is from  is a bad idea.

*ANY* anonymization service will have this problem. It can know who *it* 
is getting the message from, but it cannot know if that source is acting 
as a relay point. If it can't provide identity without knowing that then 
it can never provide identity.

> than I would a message that claims nothing about who it might be from.

Yes, I guess there could be some value in such a thing. But it will only 
be valuable if the recipient of the identity can determine it has this 
property.

If I get a call from an address I don't recognize (which is typically be 
the way I will see it if there is an anonymizer involved) then how am I 
to know:
- this is an anonymizer (as opposed to a direct call from somebody
   I don't know)
- that this anonymizer will be willing and able to disclose the
   identity under certain circumstances
- what those circumstances are

	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 20 Feb 2008 16:12:34 -0600

On Feb 20, 2008, at 3:47 PM, Paul Kyzivat wrote:

>> .
>
> *ANY* anonymization service will have this problem. It can know who  
> *it* is getting the message from, but it cannot know if that source  
> is acting as a relay point. If it can't provide identity without  
> knowing that then it can never provide identity.

We have traditionally presumed that if the party requesting anonymity/ 
identity can pass a digest authentication or equivalent test that some  
level of assertion about the identity of that party is warranted.

>
>
>> Conversely, there is a legitimate role for a service that is both  
>> an  anonymizer and an asserter of identity. The assertion here is  
>> "I know  who this person is, but I'm not telling you without proper  
>> cause". As  an end user, I'd be inclined to grant this a higher  
>> level of trust  than I would a message that claims nothing about  
>> who it might be from.
>
> Yes, I guess there could be some value in such a thing. But it will  
> only be valuable if the recipient of the identity can determine it  
> has this property.
>
> If I get a call from an address I don't recognize (which is  
> typically be the way I will see it if there is an anonymizer  
> involved) then how am I to know:

the anonymizing identity service has an included an Identity header  
signed by the identity service. That's different from NOT having one.

Consider the difference between a SIP request with a "From:" of "[email-masked] 
" and the same request carrying an RFC 4474 Identity body that is  
signed with the FBI.GOV cert (which validates back to a trusted root).

Or consider the difference between this message, and a similar one  
signed by  the self-signed cert for "john smith".

As in all certificate work, you have to have knowledge of the policy  
and role of a signer in order to decide what sort of trust you wish to  
extend to it.

> - what those circumstances are

I see this is more a function of "identity" than "anonymity". If you  
act as an identity service, whether anonymizing or not,  then you  
probably need a policy statement about your identity service just as  
every CA needs a policy statement about its credential service.  But  
mosly, it comes down to a trusted relationship.

A signature from an anonymizing identity service that you don't trust  
obviously adds no value.

Let's talk about the context of eBay. Buyers and sellers occasionally  
communicate outside of the offer-bid cycle. This has raised the  
opportunity for all sorts of fraudulent activity, such as forged "2nd- 
chance" offers.

Ebay found it necessary to put in its own messaging infrastructure  
which provides for authenticated transmission. If you get a message in  
that channel claiming to be from the seller of an item on which you  
are bidding, there is a much higher probability that this is true than  
if you get such a message from a 3rd parry email server. Here, eBay is  
acting as an identity service -- somebody presumably had to be able to  
log into eBay as the seller in order to be able to send the message.  
The seller is still more-or-less anonymous -- we don't know who they  
are -- but eBay has vouched for their role, and we know that if things  
go bad, they'll attempt to apply their published policy in resolving  
the situation.

Extending to the SIP anonymous/pseudonymous/identity discussion, I  
might get an INVITE from "Anonymous" that carries an Identity header  
verifiably from eBay. From this, I'd know that the party contacting me  
has a verified relationship with eBay, and I'd be able to make some  
decision about that message that might be a different decision than if  
the Identity header were not present.

And yes, there's all sorts of room for SAML-like things added to  
Identity headers.

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Feb 2008 09:18:36 +0000

Mayumi,

I would note that RFC 4474 already allows option 1. I see various emails
discussing the usefulness of this. I can see it as beneficial where a
domain wishes to assert that the request originated in that domain, but
does not wish to disclose the particular user ID, e.g., in call centres.

Given that this is already allowed in RFC 4474, I would prefer that the
ua-privacy draft does nothing to deprecate that.

Of course, we also need to allow the use of option 2.

I don't see a need for option 3, and I haven't heard anyone else
speaking in its favour.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mayumi Munakata
> Sent: 19 February 2008 05:45
> To: [email-masked]
> Subject: [Sip] Anonymous URI for From header in ua-privacy-01
> 
> All;
>