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

RFC 4117 shows how to do transcoding in a way that doesn't introduce a 
MiTM. It does put more burden on the endpoints, and it does mean that 
the SPs must allow arbitrary media types to flow between the endpoints, 
but if we wanted real media security that is what we would do.

And of course it only *formally* removes the MiTM. It still depends on 
one end or the other trusting (and vouching for) the transcoding service.

	Paul

Hadriel Kaplan wrote:
> 
>> -----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.
> 
>  
>> 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