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

Francois Audet wrote:
>  
>> No, that's not at all the main reason.  RFC4474 is already 
>> not end-to-end.  It's signed by a middlebox in the 
>> originating domain, and verified by a middlebox in the 
>> terminating domain.  There is ample opportunity to change the 
>> SDP at either of those domains to perform lawful intercept. 
> 
> End-to-end means from end domain to end domain. So 4474 is
> end-to-end.
> 
> Again, if enterprise A wants to talk to enterprise B, without
> some service provider spying or redirecting media for their
> own potentially nefarious purposes, then 4474 is a perfect
> way to ensure that you are talking to who you think you are
> talking to.
> 
> The fact that these enterprise may or may not be using their
> own SBCs to deal with NAT traversal and topology hiding is
> not relevant.
> 
>> The main reason to change SDP is to steer the media, for 
>> numerous reasons.
> 
> It should be up to the Enterprise to decide if it is willing
> to deal with a man-in-the-middle. If it does not, then it
> can use 4474.
> 
> If it does, then it's not end-to-end security. This is probably
> acceptable to many enterprises, provided that they can trust
> their service provider.
> 
> So again, perhaps what we need is a non end-to-end secure identity.
> Perhaps something that requires a broker/service provider.

I think that there is a lot of confusion around putting together
identity and integrity. It is not that I must have one for the other.
I can have identity without integrity of SDP and still be in position
to accept/decline a call based on who is calling me. If I'm worried
about media confidentiality, I can add zRTP.

As long as identity remains clearly separated from other stuff, we can
do quite some things. Most of the confusion seems to come from packaging
it with other functionalities. 4474 without integrity of the IP:port
in SDP would work, DERIVE (as e2e representaive) would work, certainly
many other things as well.

Let's face it,  integrity of whole SDP payload is illusive and any
functionality  relying upon it undeployable.

-jiri


> 

_______________________________________________
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