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

[Jon Peterson <[e-mail]>]

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