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

[Jiri Kuthan <[e-mail]>]

Jon Peterson wrote:
> 
>>> 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?


What is all if it then good for if we don't have guarantee for e2e
integrity protectino and have quite likely (Though not lovely) chance
that ALGs will break even identity?

To me having a partial protection of SDP along the SIP path sounds
remarkably similar to the concept of partial pregnancy.


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

Even if there are other technologies (let's assume for a while that TLS
can be relied upon along the whole path) that can cover the whole path,
what's integrity in 4474 then good for?

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

I understand the benefit. The point is that Identity appears meaningful
even without that (to the point I know who is calling) and the cost is
that it breaks whenever there is an ALG in the path, which happens quite
frequently.


> 
> So the difference is that in one case, there's supposed to be security, 

I'm worried that covering SDP along a piece of the path is not eliminating
MiTM attacks and therefore doesn't provide better 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.


That's my problem -- we only have partial integrity protection  and for
this limited benefit  we don't get over ALGs.

>>>
>>> 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'm afraid the attacks are there anyhow. Use of STUN, for example, exposes
the whole architecture to MiTM attack even if there is SDP protection
end-to-end in combination with hop-by-hop TLS encryption. TLS implementations
are for some reason quite rare. In other words if there is somone in position
to rewrite packets as sent from a UA, SDP protection between two proxy servers
will not stop him.


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

The problem I see is it reduces protection space but it does not reduce
the problem space. With TLS we could be getting protection along the whole
path on a hop-by-hop basis so the residual security risk is that
a legitimate SIP element on the path between 4474 issuer and verifier
changes SDP.

Why do you think that any negotiation consensus-producing facility would
fly better than adoption of the policy framework?

Or do you rather think along the lines of setting the user expectations?
(a la a new error code "18x hang up now and upgrade to nat-free IPv6
or media encryption, otherwise you will be in the middle of a call that
may be intercepted by parties with legitimitate as well as illegitimate
interest to do so" with obligation that all evil parties send this sort
of message...?)

OR advisory SDP protection which makes recepients alert of a change but
doesn't yet mandate the protocol stack to throw broken traffic away?

or a BCP that creates a VPN tunnel, producing security and consensus to
use some public address for public trAFFIC?

I really don't know what your suggestion above means.

The point is really as with NAT's IP address rewriting, there is SDP
rewriting and assuming in protocol design that these things don't
exist will probably do bigger harm (such as unusability of 4474)
then accepting it as matter of fact.

-jiri

> 
> Jon Peterson
> NeuStar, Inc.
> 
>> -jiri
>>
>>
>