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

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 6 Apr 2005 19:39:32 -0400

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: Wed, 06 Apr 2005 20:47:36 -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 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.)

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.

	Paul