>From discussions during and since IETF 74, I see that the problem space might be divided up as follows.
Problem 1. Securing a call and its media. I need to know where a call and its secure media have come from or where they have gone to, i.e., the party I am talking to, the party I am exchange session-based IM or files with. I need to know the domain of that other party, and perhaps also the identity of the party itself. For some cases, I might just need to know that the other party is an agent of a particular enterprise, whereas in other cases I need to know the particular user. I want the assertion of identity to come from an entity I trust to be able to make that assertion, which in many situations rules out intermediate domains that happen to be on the path of the call. RFC 4474, in conjunction with DTLS-SRTP for real-time media and equivalents for other media, solves that problem, except where there are intermediate domains that modify signed parts of the SIP request, in particular the SDP port/address. We have NAT traversal, media steering, topology hiding, etc. as reasons the SDP gets modified. We have a divergence of opinion on which are these happen in practice, which of these are legitimate and whether we can somehow induce the proponents of these practices to clean up their act. I would say a majority of people accept that such changes do take place in practice, and some of those people accept that, whether or not these changes are legitimate, we will not be able to persuade people to stop. I think people accept that, if the media is secured (e.g., by SRTP), the signing of the IP address and port in SDP adds no security value. Proposals from Dan Wing and Kai Fischer both seem to solve this particular problem. 2. As above, but with unsecured media. We have a divergence of opinion whether there is value in RFC 4474 signing the IP address and port for media, when the media itself is not secured. I subscribe to the view that it adds very little value, for reasons Hadriel has stated several times. Therefore I don't think the practice of intermediaries changing the IP address and port is a problem worth solving. 3. Delivery of SIP messages with content not related to calls (e.g., MESSAGE, SUBSCRIBE, NOTIFY and PUBLISH requests). I just need to be sure where the content comes from. RFC 4474 provides a solution to this, although again it won't work through intermediaries that change signed parts of the request. However, such requests (unless they happen to be call-related requests that also deliver other content) do not contain SDP and are often not passed through intermediate domains in the same way that call-related requests (such as INVITE) are, so RFC 4474 might be a sufficient solution as it stands. Therefore do we need two separate solutions: one for securing signalling to the extent necessary to authenticate the certs used for media security (with a reasonable level of replay protection); and RFC 4474 as it stands for protecting a substantial part of a request? The two solutions could be used together where appropriate. John _______________________________________________ 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
