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

[Cullen Jennings <[e-mail]>]

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. Unfortunately, when  
a solution to solve that problem have been presented, it has become  
clear that SBC change much more than that.

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