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

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 19 Apr 2005 19:30:57 -0400

Jonathan,

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

Regardless of whether or not the display-name is validated by the authentication service, I don't think that including the display-name in the signature actually has any perceptible effect on the security of the mechanism. What threat does this protect against? Let's assume for the sake of argument that an authentication service can and does validate the display-name, and produces the Identity header per the current guidelines of sip-identity-04 (thus not including the display-name). What can an impersonator then do? There's no question that a man-in-the-middle might change the display-name after a message is signed by the auth service, but that isn't an impersonator, that's a man-in-the-middle; said man-in-the-middle could also change, say, the Organization, User Agent, Subject, and so on of the request, since none of those are included in the Identity header. An impersonator could of course capture the signaling and try to replay it with a changed display-name; however, there are other mechanisms provided in sip-identity-04 mechanism that would detect this replay - it wouldn't work. As such, I don't think including it in the signed hash actually has any practical effect.

If you agree that the "include it" part is actually inert from a security perspective, then I might propose as a refinement:

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

The difference between this and the mechanism in sip-identity-04 is that sip-identity-04 says "reject the message" instead of "decline to sign it". Ultimately, if a user agent provides a bogus addr-spec, I would expect the auth service to reject the message, not forward it along. I can't see why this should be any different for the display-name, if the domain has a policy about 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. 

I agree with you, but I thought this is where we previously disagreed, so I am a bit surprised. A domain's policy could be that any user can register under any AoR without providing credentials and furthermore claim any From header field value for outbound requests. If that is their policy, I think it is reasonable for a domain to generate an Identity header for any request claiming any AoR in the From header field, since the request meets the domain's policy. I look at the absence of a display-name policy as being roughly the same - treat the absence of policy as if the request meets policy.

I had thought the issue was that you wanted the verifier to use the presence of the display-name in the signature as a hint that the domain actually has a policy. That's what I found problematic.

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

I think that in order for sip-identity-05 to make this REQUIRED, we would need to have some specification of what that "indicator" of the appropriate display-name would be which we could normatively reference. In the absence of that... I suppose this seems to me like a matter for future work.

Jon Peterson
NeuStar, Inc.

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

_______________________________________________
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: "Dan Wing" <[email-masked]>
Date: Wed, 20 Apr 2005 13:12:36 -0700

> Regardless of whether or not the display-name is validated by 
> the authentication service, I don't think that including the 
> display-name in the signature actually has any perceptible 
> effect on the security of the mechanism. What threat does 
> this protect against? Let's assume for the sake of argument 
> that an authentication service can and does validate the 
> display-name, and produces the Identity header per the 
> current guidelines of sip-identity-04 (thus not including the 
> display-name). What can an impersonator then do? There's no 
> question that a man-in-the-middle might change the 
> display-name after a message is signed by the auth service, 
> but that isn't an impersonator, that's a man-in-the-middle; 
> said man-in-the-middle could also change, say, the 
> Organization, User Agent, Subject, and so on of the request, 
> since none of those are included in the Identity header. An 
> impersonator could of course capture the signaling and try to 
> replay it with a changed display-name; however, there are 
> other mechanisms provided in sip-identity-04 mechanism that 
> would detect this replay - it wouldn't work.

sip-identity-04 says the replay window is 3600 seconds, so
the impersonator need only act within an hour of the original
message.  

As to Call-ID duplication, mentioned in the draft
as the other primary replay detection mechanism, an on-path 
impersonator could ensure his Call-ID is processed first (by
starving the network of bandwidth for the original message)
which would cause the legitimate message to be deemd the 
duplicate.  This reminds me of RST floods to get access
to r-services authenticated systems.

I don't see the replay protection as being adequate 
protection for this threat; the display-name should also 
be signed.

> As such, I don't 
> think including it in the signed hash actually has any 
> practical effect.
> 
> If you agree that the "include it" part is actually inert 
> from a security perspective, then I might propose as a refinement:
> 
> (F') If the display name is present but unauthorized, decline 
> to sign the message. If the display-name is present and 
> authorized, sign the message normally (without display-name).
> 
> The difference between this and the mechanism in 
> sip-identity-04 is that sip-identity-04 says "reject the 
> message" instead of "decline to sign it". Ultimately, if a 
> user agent provides a bogus addr-spec, I would expect the 
> auth service to reject the message, not forward it along. I 
> can't see why this should be any different for the 
> display-name, if the domain has a policy about it.

That refinement is fine.

I do still see a need to sign the display name.

-d

> I agree with you, but I thought this is where we previously 
> disagreed, so I am a bit surprised. A domain's policy could 
> be that any user can register under any AoR without providing 
> credentials and furthermore claim any From header field value 
> for outbound requests. If that is their policy, I think it is 
> reasonable for a domain to generate an Identity header for 
> any request claiming any AoR in the From header field, since 
> the request meets the domain's policy. I look at the absence 
> of a display-name policy as being roughly the same - treat 
> the absence of policy as if the request meets policy.
> 
> I had thought the issue was that you wanted the verifier to 
> use the presence of the display-name in the signature as a 
> hint that the domain actually has a policy. That's what I 
> found problematic.
> 
> I think that in order for sip-identity-05 to make this 
> REQUIRED, we would need to have some specification of what 
> that "indicator" of the appropriate display-name would be 
> which we could normatively reference. In the absence of 
> that... I suppose this seems to me like a matter for future work.
> 
> Jon Peterson
> NeuStar, Inc.
>