Re: francois' comments and why RFC4474 not used in the field

> > -----Original Message-----
> > From: Dean Willis [mailto:[email protected]]
> > Sent: Thursday, April 02, 2009 11:55 PM
> > 
> > Well we certainly can't expect transcoding to be compatible with e2e
> > crypto.
> 
> Nope, and why I do not include that function as being 
> compatible with it.  I do think some form of signaling 
> caller-id may be useful in that case, but clearly media 
> identity is not possible short of speaking in pig-latin.

It is true that we cannot provide edge-to-edge *authenticated* media
through a transcoder when that transcoder is operated by someone other
than an edge.  That is because e2e authenticated media is keyed with
DTLS-SRTP, which we would only trust edge-to-edge.

But we can provide __identity__ over the media path, even with transcoding.

Identity across a transcoder only requires the transcoding function allows the
identity through.  AS AN EXAMPLE, if we used the ICE technique in
http://tools.ietf.org/html/draft-wing-sip-identity-media-02#section-4.3, the
transcoder could permit the ICE messages to pass, unmolested and unmodified,
across the transcoder.  The transcoder would perform its normal transcoding
function with the RTP packets.  I am saying "as an example" because we may not
want to use ICE for this purpose; I have other ideas for how this might be
done which may be more appealing.  

-d

> > So are there any legitimate use cases for requiring that 
> > the protocol supports MITM rewriting of SDP?
> 
> We already gave you some.  But really the question can just 
> be flipped around: is there a security property of the SDP's 
> IP/port that you feel is important to protect, such that we 
> can't allow it to be changed?  Do you feel an IP:port is an 
> identity, or is somehow actually a secure indicator of 
> anything? 
>
> I mean there's plenty of other important things in 
> SIP we're not protecting with 4474 - maybe we should just 
> sign the entire SIP message, just in case.  But we don't, 
> because we know it wouldn't work in the real world, and 
> because most of them have little security value to protect.
> 
> SDP is not "the user content", as a mime text attachment in a 
> SIP MESSAGE or email would be.  It is not "the prized 
> possession" from the user.  In particular the indicated 
> IP:port to send IP packets to/from is not.  The IP is not an 
> application nor user identity; and it is spoofable, 
> interceptable, reputable, etc.  You yourself have argued 
> about SIP's dependence on the IP:port in SDP being an 
> architectural shortcoming, and here we are trying to make 
> sure it's cryptographically dependent!  IPsec learned this 
> the hard way when it had to encapsulate itself in UDP due to 
> the pseudoheader and NATs, SIP learned it due to NAT's, a 
> whole host of things may learn it in the v4/v6 transition if 
> it happens (oh, did we mention that as another SDP re-writing 
> case?).  
>  
> > Perhaps is lots of calls started failing because they 
> > endpoints detect
> > that a MITM attack on their signaling/media has occurred, and did so
> > in a way that makes that failure evident to the MITM, then we'd see
> > fewer MITMs making that mistake.
> 
> If calls started failing because of 4474, I'm fairly sure it 
> would be 4474 that would be turned off, not the SDP 
> re-writers.  Because they're not an MITM attack on users or 
> calls - it's a MITM attack on the IETF's principles.  But 
> then again, there's no need to turn 4474 off - it can just be 
> removed by a MITM. 
> 
> -hadriel

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip