Re: [dispatch] Identity Adhoc

Sure, but I'm taking it one bite-size issue at a time, starting with the biggest bite. :) 

Some of the things SBC's change *should* fail a 4474-type signature I think.  And some of them are either not that commonly done, or are done in the originating or terminating domain anyway where changing them doesn't matter for the mechanism (e.g., transcoding).

-hadriel

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Thursday, November 19, 2009 12:31 AM
> To: Hadriel Kaplan
> Cc: Jon Peterson; Jiri Kuthan; dispatch@ietf.org
> Subject: Re: [dispatch] Identity Adhoc - Nov 9th: Notes available
> 
> 
> 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: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] 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
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch