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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 5 Apr 2005 19:39:17 -0400

In Minneapolis, Jonathan raised the prospect that the Identity header field should contain a signature over the display-name portion of the >From header field value. This is attractive because SIP user agent implementations might render only that display-name to their users when an INVITE is received. Accordingly, securing display-name is very useful for human authorization decisions. After some cajoling, I hastily agreed that we could do this for sip-identity-05.

As I've worked towards a revision, though, I've become convinced that this is more complicated than I initially thought. At the root of the problem is the extremely rigid nature of the sip-identity mechanism. It is intentionally hostile to being "configurable" in any way; there are currently no reference indicators whose inclusion in the Identity signature is optional. If a reference indicator is present in the request, it appears in the identity-string (which is hashed and signed to form the contents of the Identity header field); if it isn't present in the request, the corresponding field of the identity-string is blank.

This does not interact well with identity-string elements that might or might not be added by the authentication service depending on its policies or capabilities. Unfortunately, it is difficult to anticipate how the operator of an authentication service might decide whether or not a human-readable free text field like the display-name is appropriate, and accordingly, we can't expect every authentication service operator to have such policies.

At a mechanism level, the problem is how we express all of the following conditions in the identity string:

- The display-name is present in the request, and it is has been authorized by the domain.
- The display-name is present in the request, but the domain has no authorization policies related to display-names.
- The display-name is not present in the request.

Here are a few options as to how we might approach this:

(A) If the display-name is present, include it in the identity string no matter what. Of course, then the problem is that the verifier has no way of knowing whether or not the domain actually employed any policies to validate the display-name. Accordingly, it really doesn't add much value for the verifier.

(B) If the display-name is present and authorized, include it, and also include some other flag somewhere in the message (in the Identity or Identity-Info headers, probably) noting that this authentication service enforces display-name policies. I am reluctant to start going down this path because it introduces variable reference indicators, which are a notorious source of bid-down attacks. That flag, wherever it resides, must then also be secured by the Identity header or it might be removed by someone replaying the message. Once we start going down this path, it also becomes something of a slippery slope - why not also have a flag for other common SIP headers that might optionally be included, and which could conceivably be evaluated by an authentication service? All of this makes the verification processing more complicated as well; the margin of error in the regeneration of the hash and string increases.

(C) If the display-name is present and authorized, include it. If the display-name is present but the domain has no display-name policies, then rather than include it, include some fixed value in the identity string like 'no-display-policies' in the slot that would ordinarily be occupied by the display-name value. That is kinda kludgey, but gets the message across to the verifier loud and clear.

(D) If the display-name is present and authorized, include it. If the display-name is present but unauthorized, then don't include it in the identity-string, and also strip it from the From header field of the request. This is undesirable because proxy server should not be mucking with the From header field unless they want to be called names like 'B2BUA' or what have you. Simplest from a verification perspective, though.

(E) Give up on including display-name. People should learn to make user agents that render addr-specs to their users instead of/in addition to display-names. Unlikely that any domain will have policies about this anyway (it certainly never caught on for email).

Any better ideas, or barring that, any preferences among the above?

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: Wed, 06 Apr 2005 17:31:08 -0400

> (E) Give up on including display-name. People should learn to make user agents that render addr-specs to their users instead of/in addition to display-names. Unlikely that any domain will have poli…

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.