Subject: RE: [Sip] UA and Display Names

From: "Peterson, Jon" <[email-masked]>
Date: Fri, 22 Apr 2005 20:10:41 -0400

As I've argued previously on the list, whether or not the display-name is 'signed' isn't the issue, I think. The issue is whether or not any policies were applied to by the originating domain when it inspected the display-name. There are a number of senses in which signing the display-name doesn't solve any problem.

- Signing the display-name doesn't prevent people from impersonating your display-name. So what if cisco.com will sign the display name when you make a call? I can go to fwd.net and get a new account and assign it the display-name "Paul Kyzviat" and call whomever I want. fwd.net will sign the request, and if all receiving user agents care about is the display name, I will be perfectly impersonating you. If you think that signing the display-name is somehow going to prevent this, well, it doesn't.

- Signing the display-name doesn't prevent replay attacks. If the display-name were unsigned, then presumably, someone could try to capture an INVITE and replay it with a different display-name. Perhaps even the original caller, who wants to masquerade as someone else, and thus captures their own INVITE and replays it. That would work just fine if there were not other provisions in sip-identity for preventing replays that would cause this to be detected by a verifier. Signing the display-name does change how this replay protection would work.

- Signing the display-name doesn't prevent man-in-the-middle attacks. Even if you're not worried about replay, you could be worried about some man-in-the-middle changing the display-name of the request while it's in transit. It's true, if the display-name is unsigned, a man-in-the-middle could do that. The problem is that sip-identity doesn't prevent man-in-the-middle attacks at all. A man-in-the-middle could just strip the Identity and Identity-Info headers, if it wanted. sip-identity only prevents impersonation.

So, I don't think signing the display-name helps. I think there are reasons why it makes sense for domains to have policies about domain names, and ways to enforce them. But it can enforce those policies whether the display-name is signed or not. The signature is for the benefit of verifiers, not the originating domain.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Friday, April 22, 2005 4:11 PM
> To: Cullen Jennings
> Cc: Jonathan Rosenberg; [email-masked]; Peterson, Jon
> Subject: Re: [Sip] UA and Display Names
> 
> 
> 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
> 
> Cullen Jennings wrote:
> > 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.
> > 
> > 
> > 
> > _______________________________________________
> > 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
> > 
> 

_______________________________________________
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: "Stastny Richard" <[email-masked]>
Date: Sun, 24 Apr 2005 00:07:25 +0200

Hi all,
 
I apoligize for jumping into this thead and also
that I was not able to follow this dicussion up to now,
so I may not be completely up-to-date.
 
As a user, what to I want to get out of a display name?
-is it a real name of a person, certified
-is it an alias or role name, certified (that means the identity can be retrieved)
-is it an alias, uncertified
-is the name suppressed (ala CLIR), but authorities are able to retrieve the identity
-is the name suppressed and cannot be retrieved (anonymous)
 
The last two are required, because it must be possible to make anonymous calls.
 
I want the name displayed and an indication what status it has, so I myself or my
Personal User Agent (PUA) can make a decision what to do with the call
(e.g. reject it). This is basically the ETSI UCI (Universal Communications Identifier)
approach.
 
If I also assume an open end-to-end architecture on the Internet inclúding
privately or enterprise owned SIP-servers participating in the communication,
the authentication can only be end-to-end. In addition, the system must
also be able to work in P2P networks.
 
I will never trust the signature or certificate of a SIP-server. Certificates
can only be end-to-end (user-to-user). This requires a (network) of trusted 
3rd parties issueing the certificates (eg stand-alone AUC for SIM-cards.) 
We all know that this is difficult to set-up, but IMHO no other possibility exists. 
 
In the horizontal layers model the identities have also to be independent
from the call control layer and the application layer in a separate layer and
end-to-end. All other approaches are are violating the independance of
layers and will fail.
 
regards
Richard

________________________________

Von: [email-masked] im Auftrag von Cullen Jennings
Gesendet: Sa 23.04.2005 02:12
An: Paul H Kyzivat
Cc: [email-masked]; Jon Peterson
Betreff: Re: [Sip] UA and Display Names

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.

On 4/22/05 4:11 PM, "Paul Kyzivat" <[email-masked]> wrote:

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