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

[Jiri Kuthan <[e-mail]>]

Jon Peterson wrote:
> 
> I was not arguing against NAT traversal, actually. From the start of the 
> SIP identity work, we considered support for NAT traversal as a 
> requirement. Of course, the authors of RFC4474 assumed that something 
> roughly like ICE would take over this role, and obviously the deployment 
> situation is bit more complicated (we similarly hoped that GRUU would 
> make it unnecessary for intermediaries to modify Contact headers, and so 
> on). Regardless, I still believe we need to have a reasonable story for 
> how an identity mechanism will accommodate NAT traversal.
> 
> To rehash arguments that have circulated in this discussion many times, 
> one must distinguish the NAT traversal case from the "media steering" 
> requirement that has motivated much of the re-examination of identity. 
> RFC4474 signatures are applied not by the user agent (at least not in 
> the typical case), but rather by a server operated by the user agent's 
> administrative domain. The administrative domain can more or less modify 
> signaling arbitrarily before adding an Identity header per RFC4474. 
> Thus, some sort of intermediary that modifies SIP signaling for the sake 
> of NAT traversal can work with RFC4474, provided that the intermediary 
> acts before the Identity header is added.
> 
> While it can therefore be argued that RFC4474 does not rule out 
> intermediary-based NAT traversal entirely, it does protect against any 
> intermediary altering SDP once a request has left the originating 
> administrative domain with an Identity header. 
> 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?

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

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

-jiri


> 
> Jon Peterson
> NeuStar, Inc
> 
> Jiri Kuthan wrote:
>> I think it is worth mentioning and doublechecking a problem we touched
>> in this conversation, which is SIP servers modifying SDP to facilitate
>> NAT traversal. I think Jon P. has said this was unacceptable use-case not
>> good enough as motivation for work related to it, because it exposes
>> such calls to MiTM attacks. Is that right, Jon?
>>
>> -jiri
>>
>> Mary Barnes wrote:
>>>
>>> Hi all,
>>>
>>> I have uploaded Jim McEachern's notes from the Identity Adhoc yesterday:
>>> http://www.softarmor.com/dispatch/IETF76/Meeting%20notes/Identity-AdHoc-Notes-jmce.doc 
>>>
>>>
>>> Regards,
>>> Mary.
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>