Re: [dispatch] Identity Adhoc - Nov 9th: Notes available

[Jon Peterson <[e-mail]>]

>> The "media steering" use cases that challenge this design are 
>> predicated on an intermediary with no necessary relationship to the 
>> originating or terminating administrative domain unilaterally 
>> modifying SDP in transit, usually in order to force layer 3 routing 
>> of media to pass through one or more anchor points in a network - 
>> perhaps for the sake of drawing the traffic across a managed circuit 
>> with carefully-managed quality, or to facilitate lawful intercept, or 
>> what have you. It is that requirement which I have consistently 
>> argued is equivalent to exposing this mechanism to a 
>> man-in-the-middle attack.
> how is that different from a MiTM attacking SDP on the path from UA
> to a 4474-enable proxy?
I'm not sure how to answer your question except to say that it is a 
fundamental difference in the protection scope of the mechanism. The 
path between the user agent and the RFC4474-enabled proxy must be 
secured in some fashion, it's true, and there are a number of ways that 
security might be provided that can either allow for the presence of 
other intermediaries in the administrative domain or not, depending on 
the SIP deployment of the domain (RFC4474 does talk about this a bit). 
If those protections aren't in place, then of course any adversary can 
alter the signaling arbitrarily with fear of detection. Once an Identity 
header is in place, however, any subsequent modifications to the 
signaling that could lead to impersonation (in so far as the threat of 
impersonation is defined in the draft) are supposed to show up as 
violations. That's the protection that the Identity mechanism affords.

So the difference is that in one case, there's supposed to be security, 
and in the other case there isn't.
>>   If we removed enough
>> protections in the design of RFC4474 to enable media steering by 
>> "good" intermediaries, we are effectively also enabling any malicious 
>> entities to change those aspects of SIP requests as well.
> I'm wondering if  RFC4474 can prevent MiTM as it is not  guaranteed to 
> provide
> end-to-end protection in the typical case.
No mechanism can "prevent" a man-in-the-middle, it can merely detect it. 
RFC4474 provides its protections within its defined scope, which is  
from an authentication service in the administrative domain to the 
terminating user agent. If the path between the originating user agent 
and the authentication service is insecure and vulnerable, as discussed 
above, then yes, RFC4474 doesn't provide end-to-end protection.
>>
>> I do not find the requirement for NAT traversal unacceptable, but I 
>> do consider the requirement for media steering highly dubious at best.
> Some while ago I would have thought that in this typical case there
> are two administrative zones under respective control with a pipe in
> between. Then it shall be manageable to put a SDP-manipulating closer
> to UA than 4474 processing. In the meantime I think it became hard to
> find a SIP path which in between two 4474 entities has nothing that
> rewrites SDP.
You are not the first one to make this observation, but I don't think 
this information is very useful in drafting the sorts of requirements in 
Mr. Elwell's document. The stated requirement for "media steering" 
assumes something much more specific than simply wanting to rewrite SDP. 
An intermediary that wants to rewrite SDP may have one of several 
relationships with the originating and terminating user agents or 
administrative domains. The "media steering" use cases invariably assume 
an entity acting unilaterally, without necessarily the knowledge or 
consent of either side of the transaction - it acts by virtue of being 
in the path of signaling, even if only as an ALG. If we design a 
security mechanism that allows an entity to act with that sort of 
impunity, it may facilitate some few beneficial services but it will 
also facilitate a variety of attacks. I believe we can do better - we 
can find ways to allow intermediaries to perform the services they'd 
like to perform without acting unilaterally. Certainly at the time 
RFC4474 was under development, we believed that mechanisms like 
session-policy would eventually provide a way for intermediaries to 
force user agents to conform with intermediary policy, including session 
dependent policy cases for SDP. If we're going to dedicate design energy 
to solving problems in this neighborhood, one could argue that solving 
for these building blocks first (allowing intermediaries to modify 
signaling in a collaborative manner rather than unilaterally) will make 
the path to an identity solution much, much easier. From a requirements 
perspective, this is much closer to what I'd like to see expressed than 
something like "media steering," which basically equates to reducing the 
protection space.

Jon Peterson
NeuStar, Inc.

> -jiri
>
>