Subject: [Sip] closure on display-names & sip-identity

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 25 Apr 2005 15:08:49 -0400

Well, we've certainly had a lot of discussion of display-names for sip-identity, but I'm not sure that it has led us to any conclusion.

Partly, I think this is because we've had difficulty distinguishing three issues:

- The value of having authentication service policies for display-names
- The value of signing the display-name or adding some other indication that a policy was enforced
- The mechanics of actually signing display-names

Personally, I think the value of policy is necessarily limited. If a user agent recipient renders only what it sees in the display-name field, then authentication service policies necessarily will not prevent impersonation - impersonators can always create accounts with the desired display-name in a domain friendly or oblivious to their interests. What policies can do is prevent a user within a domain from associating an inappropriate display-name with a particular account. While this is no doubt helpful for certain kinds of domain, it is of limited use in preventing the sorts of global impersonation problems with which sip-identity is concerned.

A signature over the display-name has no intrinsic value from an impersonation-prevention perspective. It could of course serve as an indication that policy was enforced, but solving the signature problem is a lot of trouble to go through when a simple parameter of the Identity-Info header might serve the same purpose. Ultimately, I further believe that the absence of policy should entail consent in this case, and that therefore, an indicator is probably ultimately unnecessary. If the display-name is inappropriate, the authentication service should not validate the request - that's all the indication that we probably need.

To the mechanics of the signing process and related apparatus, I'll just say that it looks complicated to me. Internationalization concerns, opertational concerns (provisioning bit-exact correct display-names in clients), and the like make this potentially a long-term problem.

I have not yet heard any compelling argument that we need to this. As such, I would like to propose that we keep substantially the same wording that appears in sip-identity-04. Essentially, that would mean that domains MAY have policies, MAY reject requests that contain inappropriate display-names, but display-names do NOT appear in the Identity header hash and no further indication of the presence or absence of policy is present.

If you have substantive objections to this, please air them now.

Jon Peterson
NeuStar, Inc.

_______________________________________________
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: Mon, 25 Apr 2005 15:21:04 -0400

Jon,

I concede - you have countered the cases I have presented.

	Paul

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Apr 2005 16:26:20 -0700

On Mon, 2005-04-25 at 12:08, Peterson, Jon wrote:
> A signature over the display-name has no intrinsic value from an impersonation-prevention perspective. 

I disagree: it says at the very least that that display name is the one
that the signer saw as it passed by its stamper. If it is not added to
the hash, then you'll never know.

As I've said repeatedly: people are whistling in the dark if they think
that some sort of proscription in this draft, or withholding of signed
bits, or whatever else is going to stop UA's from displaying the display
name if it's there. They will, and you can count on that. In the end,
not signing the display name so that you could conceivably disavow 
that name later because you aren't able completely guarantee its
veracity is so many angels on a pinhead: it makes no operational
difference. We should err on the side of forensics here, not finger
wagging at developers or careful parsing of what the meaning of
"is" is.

So, I disagree with this, and the general philosophy that picks
winners and loser for the hash input. The more the merrier.

		Mike