Subject: [Sip] Is Domain X using Identity problem

From: Cullen Jennings <[email-masked]>
Date: Fri, 22 Apr 2005 15:17:31 -0700

On 3/6/05 1:30 PM, "Jonathan Rosenberg" <[email-masked]> wrote:

> 
> As such, I think some kind of companion technique for "checking if
> domain X is using sip-identity" is needed. It need not be defined here,
> but it seems crucial to successful deployment of this.
> 
> 

Imagine we had this. Consider the two cases:

a) domain supports identity but I just got a message with no Identity
headers

b) domain does not support it and I just got a message with no Identity
headers

The type of authorization I might do for these two case are somewhat
different so I can see that this has some value. However, many of the
attacks and problems that you might hope to stop with having this can still
be done by the attacker just using a domain that does not support identity.

Anyways, I can imagine a few ways to query this flag.
1) DNS - keep the flag in DNS
2) SIP - send an OPTIONS over TLS to the domain and get the flag
3) HTTP - send a HTTP request to some well known location

Option 2 has the advantage of an attacker not being able to spoof the
result. 

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Fri, 22 Apr 2005 15:51:42 -0700

I'm somewhat dubious on the harm that is stopped by including the Display
Name in the hash. It leads to a false sense of security that it is somehow
OK. I guess I don't really know what I think on this yet but let me propose
one thing. 

Imagine that a UA was implemented along the following lines. When it got and
incoming call, it looked for the URI in the address book and if it found
one, displayed the Nick Name that user had for this caller in their address
book. If nothing was found in the address book, it just displayed the URI.
If the user when to add an entry to the phone booked based on the current
caller, the Display Name information could be used to pre populate the
fields for the Nick Name. If the device had access to some sort of trusted
corporate directory it could also use that as part of the address book.

It might be good to try and figure out what are the cases where including
the Display Name in the hash helps.

On 3/6/05 1:30 PM, "Jonathan Rosenberg" <[email-masked]> wrote:

> * display name handling
> 
> I'm concerned that the treatment of the From display name. The current
> spec allows an authentication service to verify it (at MAY strength),
> and it can reject it if it doesnt like it. But, there is no signature
> that covers it, and no way for a verifier to know if the authentication
> service allowed it to pass.
> 
> I'm worried that, although we believe that the URI is the important form
> of identity to worry about, real people will be more concerned with the
> display name. The mechanism may, as a result, be extremely misleading,
> because users are still free to completely spoof the display name.
> 
> I'd like to consider adding the display name to the signature, under the
> constraints that, if done, it require the domain to tell the client the
> display names it can insert, so as to avoid all of these equivalence
> nightmares for internationalized names.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Apr 2005 19:11:18 -0400

Cullen,

What you describe sounds like a good policy. If I believed that would be 
followed most of the time then I would agree that signing the display 
name is unimportant and maybe undesirable.

But I am inclined to think that won't be the case - that (just like many 
mail readers) the display name will be the main or only displayed 
identity of the caller most of the time, and that the actual url will be 
something that only geeks know how to get. In that environment I would 
prefer the display name to be signed.

But perhaps the kind of approach you suggest has a chance to become 
ubiquitous. Convince me.

	Paul

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 22 Apr 2005 17:12:41 -0700

Well, let me tease apart what you mean by you want the Display Name to be
signed. What you really mean is that you want want to know that you can
believe this to decide if you want to answer the call or not. This has one
part which is integrity protecting across the network ( this is easy) and it
has a part of person asserting it knowing it is right (this is often hard
and the rest of the time it is impossible) Let's imagine some various use
caser here.

Case 1) We include the display name in the hash, byte for byte compare it,
and my phone only displays the display name. Now cisco might be able to
confirm that you are Paul Kyzivat and might allow you to use that. On the
other hand they might make me assert that my name is Fluffy. Whatever they
do, I will bet you anything that they make paf assert than his name is
something that can represented in US-ASCII so the identity in his email From
header matches his identity in his SIP IM. This is going to irritate paf.
But just assuming we decide it is ok for force most people to use US-ASCII,
lets consider what happens over at yahoo. Yahoo has no way of know peoples
names so it let's them assert any name they want. Some evil person goes and
gets the an account [email-masked] and sets the Display Name to Paul
Kyzivat. Now when this person call, everything is valid and the user see the
call as being from Paul Kyzivat. Basically, this did nothing for us to help
us but id did a bunch to harm us - by "signing" the Display Name we
convinced people that this was somehow safe when in reality it was
equivalent to being totally unsigned.

Case 2) Like above but we include a flag that indicates if the domain has
verified the Display Name or not. Presumably yahoo will correctly set this
but not the evil person just has to do the same attack from a domain that
does not correctly set the flag. Again, nothing was gained.

It's true that most email readers just display the Display Name and ignore
the aor and don't look the aor up in an address book. This is because it was
just as easy to spoof the aor in email as it was to spoof the Display Name
so there was no point. If we have a reason to do better in SIP, people might
actually do the right thing.

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 25 Apr 2005 10:47:35 +0200

I tried to point out the same facts that Cullen did in a previous 
thread, so here I am supporting him.

Paul is basing his arguments about human behaviour using email as an 
example. I think a more appropriate comparison is the way people use 
their phones. If a name is not found in the LOCAL address book, the 
number is displayed. The same would apply here, if a name is not found 
in the LOCAL address book, the sip uri is displayed.

I don't buy the argument that a uri is only something that geeks have 
to look at. The uri is the "thing" that people would have to dial if 
the number is not being pulled from an address book.

Regards,
Hisham

On Apr 23, 2005, at 1:11 AM, Paul Kyzivat wrote:

> Cullen,
>
> What you describe sounds like a good policy. If I believed that would 
> be followed most of the time then I would agree that signing the 
> display name is unimportant and maybe undesirable.
>
> But I am inclined to think that won't be the case - that (just like 
> many mail readers) the display name will be the main or only displayed 
> identity of the caller most of the time, and that the actual url will 
> be something that only geeks know how to get. In that environment I 
> would prefer the display name to be signed.
>
>> one thing. Imagine that a UA was implemented along the following 
>> lines. When it got and

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Apr 2005 16:57:40 -0700

> > domain X is using sip-identity" is needed. It need not be 
> > defined here, but it seems crucial to successful deployment of 
> > this.
> 
> b) domain does not support it and I just got a message with 
> no Identity headers
> 

Option 1 has the advantage that it's quicker, can easily be cached
locally, and we're relying on DNS already.

The problem, however, with Option 1 is defining a new DNS resource
record.

I agree - go with 2.

-d