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

[Hadriel Kaplan <[e-mail]>]

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.