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

[Jiri Kuthan <[e-mail]>]

Francois Audet wrote:
> So, in summary: SDP (and other) modification should only be done on a UA's behalf  by its administrative domain, otherwise, it's unsafe.


Hi Francois,

I'm not quite yet sure what administrative domain means?

The picture I'm having in my mind is using say iptel.org service (located
in Central Europe in a facility administered by iptel.org's administrator)
from an IETF meeting (administered by the IETF team) to my family
(located within what a German ISP administers).

-jiri

> 
> Seems reasonable to me.
> 
> We seem to recycle the same arguments over and over again....
> 
> On Nov 16, 2009, at 22:45 , 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. If we removed enough protections in the design of RFC4474 to enable media steering by "good" intermediaries, we are effectively als
o enabling any malicious entities to change those aspects of SIP requests as well.
>>
>> I do not find the requirement for NAT traversal unacceptable, but I do consider the requirement for media steering highly dubious at best.
>>
>> 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
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>