Subject: RE: [Sip] sip-identity-05: display-name woes

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 6 Apr 2005 21:04:37 -0400

> The simple answer (but perhaps not a popular one) would be to mandate 
> that the authentication service *must* have a policy wrt display names. 
> (A degenerate policy would be that display names simply aren't permitted.)

I would feel more comfortable about that if anyone had any idea how a domain might go about enforcing such policies and distributing legitimate display-names to users. Currently, we're taking it on faith that some domains will want to adopt such policies, and will figure out appropriate operational ways to execute them. Not a small thing to take on faith given the precedents in the email space, not to mention the fact that the domains themselves seem to gain little by enforcing these policies.

> I suppose it is then necessary to be a little more demanding about what 
> sort of policy is acceptable. (A policy of "you can use any display name 
> you want" is probably not an acceptable policy.)

Well, it's about as acceptable as the policy "you can use any username in the addr-spec portion of the From header field that you want", but that is effectively the state-of-the-art for SIP and email today. I doubt that sip-identity can have any appreciable effect on what policies domains want to use for this stuff. What is can do is specify a way, through mechanism, for a domain to communicate "my policies, however strict or lax, were followed with regards to this From header field". 

> Alternatively, perhaps there should be a standard way for discovering 
> the (human and/or machine readable) authentication policy of a 
> particular authentication service. It doesn't have to be part of the 
> request, just derivable from the authentication service credentials.

In the end analysis, I can't think of any way that the authorization decision made by a recipient would change if it had this information. After all, a bad domain could lie about its policies, deluded domains will tell you they have a good policy even though it is routinely circumvented by clever users, and good domains will be good regardless of whether or not they tell you your policies. As a verifier, I might be willing to take the word of a third-party auditor, but I don't think we can incorporate that into our protocol specification.

Jon Peterson
NeuStar, Inc.

> 	Paul
> 
> Peterson, Jon wrote:
> > The problem with that, I think, is that it does not provide 
> for the case where the display-name is present, but the 
> authentication service has no policy with regard to 
> display-names. What does the authentication service do then, 
> and how is that behavior disambiguated from the other cases 
> at the verifier?
> > 
> > I agree that if the display-name is present and 
> unauthorized, then the authentication service shouldn't sign 
> the message. In fact, you don't even have to include the 
> display-name in the identity-string in order to structure the 
> mechanism like that. The mechanism in sip-identity-04 
> essentially reads:
> > 
> > (G) If the domain has policies about display-names, and the 
> display-name is present and unauthorized, decline to sign the 
> message, sending back a 4xx suggesting that the display-name 
> needs to be correct. Otherwise, sign the message (NOT 
> including the display-name) and forward it.
> > 
> > Ultimately, a signature over the display-name itself is not 
> necessary unless you are concerned that the message is going 
> to be modified in transit (which is outside the threat model 
> of sip-identity, since sip-identity is only concerned with 
> impersonation). Replaying the message with a differnt 
> display-name isn't really an option because the replay would 
> be exposed by the other reference indicators present in the 
> request. So at a high level, the fact that a message is 
> signed at all (with or without a display-name) could 
> plausibly signify that either the domain liked the 
> display-name or that it doesn't care about display-names, but 
> it could never plausibly signify that the domain had policies 
> about display-names and that it didn't like the display name, 
> regardless of whether or not the display-name itself is 
> included in the identity-string.
> > 
> > The issue with (G), of course, is that it does not 
> disambiguate the case where the domain has policies about 
> domain names and authorized this message from the case where 
> the domain doesn't have policies.
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > 
> >>-----Original Message-----
> >>From: Paul Kyzivat [mailto:[email-masked]]
> >>Sent: Wednesday, April 06, 2005 2:31 PM
> >>To: Peterson, Jon
> >>Cc: [email-masked]
> >>Subject: Re: [Sip] sip-identity-05: display-name woes
> >>
> > 
> > [snip]
> > 
> >>I don't much like any of those alternatives.
> >>
> >>
> >>>Any better ideas, or barring that, any preferences among the above?
> >>
> >>(F) If the display name is present but unauthorized, 
> decline to sign the 
> >>message. If the display-name is present and authorized, include it.
> >>
> > 
> > 
> 

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Apr 2005 09:09:48 -0400

> I would feel more comfortable about that if anyone had any idea how a domain might go about enforcing such policies and distributing legitimate display-names to users. Currently, we're taking it on…

We shouldn't try to boil the ocean, but I think we should be looking to 
put a framework in place that will let the players do the right thing.

I have the impression there is some appreciation that callerid (both 
number and name) should be somewhat trustworthy. That notion just has to 
be embraced for SIP.

If callee devices don't trust, and hence don't display, untrusted 
display names, that might eventually provide a competitive advantage to 
those that provide trusted names. ("Alice, when you call me your name is 
never displayed. Why don't you switch to a service that provides the name?")

Or it may be that once there are some highly publicized abuses, there 
will be legal action to require reliable callerid from IP phones.

> In the end analysis, I can't think of any way that the authorization decision made by a recipient would change if it had this information. After all, a bad domain could lie about its policies, delu…

I think I take advantage of such info by configuring my system about 
what domains to accept names from.

In principle, I would think it might eventually be possible to arrange 
things so that the signer of the authorization service's cert vouched 
for the policy of the authentication service. Then it would be easier to 
configure who you trust. (But in practice this sounds hard.)

Regarding lying about policy - at least being on the record provides the 
basis for legal action against those that lie.

	Paul

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 7 Apr 2005 09:35:55 -0400

Maybe we want to step back and ask:
What is the purpose of a display name?
   And
What is the purpose of the Identity work?

We might find that there is no point in trying to assert anything about
display name ever.

A display name is something used to LABEL a caller.  It's displayed to the
user.

Identity is used to Identify a caller, primarily to provide a reasonably
reliable indication of who called, and how to call them back.

If you go to a telephone company and get a phone line, and you tell them
that your name is George Bush, they might kid you, but they aren't going to
give you the third degree because there really are a few other George Bush's
out there.  It's more work than doing something with the display name on
your SIP phone, maybe, but it's not something that is assertable.  The phone
company REPORTS the name on appropriate caller ID, but does not assert it
means anything.  The phone number, on the other hand, is an identifier, and
it does mean something.

Perhaps we simply do not ever include display name in the Identity
signature.

I think our email experience suggests that there is not a lot of harm when
you get a forged email display name.  We have harm with a forged email
address.  There is probably more concern over indecent names than forged
names, but as always YMMV. 

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: Thursday, April 07, 2005 8:10 AM
To: Peterson, Jon
Cc: [email-masked]
Subject: Re: [Sip] sip-identity-05: display-name woes

Peterson, Jon wrote:
> I would feel more comfortable about that if anyone had any idea how a
domain might go about enforcing such policies and distributing legitimate
display-names to users. Currently, we're taking it on faith that some
domains will want to adopt such policies, and will figure out appropriate
operational ways to execute them. Not a small thing to take on faith given
the precedents in the email space, not to mention the fact that the domains
themselves seem to gain little by enforcing these policies.

> Well, it's about as acceptable as the policy "you can use any username in
the addr-spec portion of the From header field that you want", but that is
effectively the state-of-the-art for SIP and email today. I doubt that
sip-identity can have any appreciable effect on what policies domains want
to use for this stuff. What is can do is specify a way, through mechanism,
for a domain to communicate "my policies, however strict or lax, were
followed with regards to this From header field". 
> In the end analysis, I can't think of any way that the authorization
decision made by a recipient would change if it had this information. After
all, a bad domain could lie about its policies, deluded domains will tell
you they have a good policy even though it is routinely circumvented by
clever users, and good domains will be good regardless of whether or not
they tell you your policies. As a verifier, I might be willing to take the
word of a third-party auditor, but I don't think we can incorporate that
into our protocol specification.

	Paul

---

From: Michael Thomas <[email-masked]>
Date: Thu, 07 Apr 2005 07:39:02 -0700

> names, but as always YMMV. 

  Oh really? I'm pretty sure that Wamu, eBay, and the
  rest of the phished set would disagree with that.

  In any case, something that doesn't account for human
  factors is likely to be more harmful than nothing at
  all. If I've been told that the sip call has been 
  "authenticated", I'm not going to remember that that
  doesn't have anything to do whatsoever with the name
  that's been put in front of me. That's a problem. A
  big one.

  Domain level identities aren't perfect, but they 
  don't have to be to still be useful. If I get a
  call from [email-masked] and it turns out not
  to be gwb on the line, I can call whitehouse.gov
  and tell them they have a problem. Without some
  cryptographic identity to gate who uses the 
  whitehouse.gov domain, that phone call will --
  and currently is with email -- useless. But with
  it, they can at least in theory check their logs,
  blah, blah, blah, before they cover it up. 

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 07 Apr 2005 12:32:34 -0700

> I would feel more comfortable about that if anyone had any idea how a domain might go about enforcing such policies and distributing legitimate display-names to users. Currently, we're taking it on…

In the email space there is absolutely no consequence to
having bad onramp polices because a domain has absolutely
no control over who uses their name. I think that basic
fact is far more important than the lack of ability to
police users. The general theory behind IIM is that when 
those domains regain control over who uses their name in 
email, there will be a lot of  incentive to police their 
users lest their name be sullied. The actual mechanics of
user policing is pretty well understood, I think: you
take them behind the barn and horsewhip them when they
misbehave. Right?

		Mike

---

From: Hisham Khartabil <[email-masked]>
Date: Mon, 18 Apr 2005 17:17:52 +0200

Brian does have some point in what he's saying. Usually, the number is 
displayed (the sip address in out case) unless the receiver has the 
caller in the address book. In this case the name displayed is the one 
in the local address book. But is it too late to think that way? It 
probably is since a lot of implementations out there already display 
the Display Name in the From header field, but we could recommend 
against it.

Hisham

---

From: Michael Thomas <[email-masked]>
Date: Mon, 18 Apr 2005 15:09:27 -0700

> the Display Name in the From header field, but we could recommend 

I think that people are tempting the fates if they
think that proscriptions against misuse buried in
some arcane RFC will stop developers from putting
juicy identity bits in front their users. Even if it's
really, really stupid. And insecure. 

And SIP is not just about voice rendezvous. Imagine a
proscription on an IM user agent against putting a 
display name in front of their user. It's not only
ludicrous, it would make the protocol useless.

		Mike

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 18 Apr 2005 18:50:52 -0400

I agree.

One way or another I think we need to have an approach caller id and 
calling name that works at least as well and reliably as it does in the 
PSTN, and that does so whether going between two sip endpoints in 
different domains, or between a sip endpoint and a PSTN gateway. And it 
needs to do this whether you are using sip native URIs or telephone 
numbers. For telephone numbers there probably must be consistency with 
what happens for PSTN-PSTN calls. For sip native addresses there may be 
some wiggle room about how it should work, but I think people will want 
the same level of trust with either kind of address.

	Paul

Michael Thomas wrote:
> ------------------------------------------------------------------------
>

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 19 Apr 2005 07:27:22 -0400

Which do you find more useful: Caller name in the PSTN or display name in
email?

One is "authenticated", the other is not.

Let's face it, the PSTN caller name system is fundamentally broken, and it
doesn't work as well, or as reliably FROM THE POINT OF VIEW OF THE USER, as
nearly anything else.  Imitating that is a poor choice.  To be sure, much of
what doesn't work is due to poor implementation and "star syndrome" (I block
my Caller ID and I don't take calls without CallerId).

No one really trusts display name in the PSTN.  Few even understand it.
Everyone who uses email knows what to expect of a display name.
With session initiation on the Internet, it's not very useful to hide behind
the trust of the originating carrier, because there are too many of them and
you have no reasonable way to distinguish a trustworthy one from an
untrustworthy one.  There may not even be an originating carrier.

In this case, I think we trust users to be polite, and when they aren't,
you have the option of not taking their calls.  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
Kyzivat
Sent: Monday, April 18, 2005 6:51 PM
To: Michael Thomas
Cc: [email-masked]; 'Peterson, Jon'
Subject: Re: [Sip] sip-identity-05: display-name woes

I agree.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 Apr 2005 10:30:25 -0400

I agree here as well.

The reason I raised this at IETF is that I think it is very likely that 
today and for some time to come, that user agents will use the display 
name in the From field to make decisions about call treatment. Automata 
won't use the display names, but people will. Users of the system will 
not understand that there is a difference between the display name and 
the URI as forms of identity.

As for whether a service provider has a way to reliably determine a 
user's display name in order to assert it, well, there is strong 
precedent in the existing phone system that they have ways that have 
been found to be good enough. There are tons of public records that link 
people's names to various kinds of other identifiers that they can 
present to verify their identity. Sure, all of them can ultimately be 
bypassed, but I don't want to turn the perfect into the enemy of the good.

In terms of what to concretely do here, I had Paul's (F) in mind:

(F) If the display name is present but unauthorized, decline to sign the 
message. If the display-name is present and authorized, include it.

I think there is no need to convey the policies of the signing domain. 
When I receive a message, its really simple. Whatever is there in the 
 From field, display name or not, is what the domain is willing to vouch 
for, period. If the display name is absent, a recipient has no way to 
know whether the caller simply didnt provide one, or whether the domain 
policy prohibits signing of the display name. I don't think it really 
matters much.

The entity that DOES need to know the policy is the caller. I would 
propose that the spec require that there is a means for configuring the 
caller's UA with an indicator of whether the display name can be signed 
or not, and if so, what the display name for that user is that the 
domain is willing to sign. This can then be included verbatim by the 
calling UA in its INVITE. This avoids the case where the domain won't 
sign display names at all, but the calling UA doesnt know it, and so 
inserts one only to have its message completely unsigned, both display 
name and URI.

Thanks,
Jonathan R.

Paul Kyzivat wrote:

>>> Brian does have some point in what he's saying. Usually, the number 
>>> is displayed (the sip address in out case) unless the receiver has 
>>> the caller in the address book. In this case the name displayed is 
>>> the one in the local address book. But is it too late to think that 
>>> way? It probably is since a lot of implementations out there already 
>>> display the Display Name in the From header field, but we could 
>>> recommend against it.
>>
>>
>>
>> proscription on an IM user agent against putting a display name in 
>> front of their user. It's not only

-- 
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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 20 Apr 2005 12:39:50 -0700

On Tue, 2005-04-19 at 07:30, Jonathan Rosenberg wrote:
> The entity that DOES need to know the [signing] policy is the 
> caller [UA].
 
Why? 

		Mike