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

[Jiri Kuthan <[e-mail]>]

Cullen Jennings wrote:
> 
> If we all believe the only thing SBC rewrite is the IP and port of the 
> media, I'm sure we can solve this in no time flat. 

I think there are certainly many who believe this is a reasonable thing
to do ....

> Unfortunately, when a
> solution to solve that problem have been presented, it has become clear 
> that SBC change much more than that.

... and it would be probably more efficient than trying to overload the work
with other interesting features.

what are the next steps then?

-jiri


> 
> Cullen <in my individual contributor role>
> 
> On Nov 18, 2009, at 12:11 PM, Hadriel Kaplan wrote:
> 
>>
>> Forget the NAT traversal piece, or even media steering, and just tell 
>> me what signing the IP Address/port in the SDP buys you.  Not the 
>> whole SDP, just the IP/ports.  Imagine if the media IP/ports were in a 
>> SIP header, and tell me why we MUST sign that header to get "SIP 
>> Identity".
>>
>> My claim is signing those IP/ports is neither necessary nor sufficient 
>> for the purposes of SIP Identity nor media identity.  It's an emperor 
>> with no clothes, except we end up getting the bill for the clothing.
>>
>> It is not sufficient because it does not prove the authenticity and 
>> identity of the media.  And I don't just mean in an academic sense of 
>> "prove".  Not only can the media IP/ports still be spoofed and even 
>> intercepted - but nothing prevents me from just sending media from 
>> another address/port to get you to listen to my advertisement, 
>> instructions to call my number to "verify your credit card", or whatever.
>>
>> Only a media-plane mechanism will be sufficient for media identity, 
>> such as DTLS-SRTP.
>>
>> It is not necessary because, given a mechanism such as DTLS-SRTP 
>> (which *is* necessary for the property of media identity), signing the 
>> IP/ports is superfluous.  It's making the mistake of confusing IP with 
>> an identity, vs. a routing identifier. (ie, the argument HIP makes)
>>
>> -hadriel
>>
>>> -----Original Message-----
>>> From: [e-mail] [mailto:[e-mail]] On
>>> Behalf Of Jon Peterson
>>> Sent: Monday, November 16, 2009 3:45 PM
>>>
>>> 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.
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>