> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of > Cullen Jennings > > Based on the discussion I've seen so far, the primary use case for > this modification is to allow the SBC to do media steering so it can > steer the RTP through a path that provides better QoS. As you say, > this could be achieved by modifying the SDP and changing RFC 4474 to > allow that, but there are probably some other approaches we should be > considering as well, including ones that may need to be done outside > of SIP. If there's consensus that this is the problem that needs > solving, then I'll get with the SIP, SIPPING, and MMUSIC chairs and > figure out a process for how to evaluate the various options and get > this moving forward. If this isn't the primary use case, then I think > we probably need some more discussion to get a clearer idea of what > the problem is.
Part 3 of this series: Signing the MIME body. This is probably the big one in terms of being contentious. For some MIME bodies, signing it presents no issue for current B2BUA's, as far as I know - notably a MESSAGE request body for UI rendering. A MESSAGE has no Contact, so just avoiding Call-ID signing as described in part-1 of this thread should be good enough. As we all know, RFC 4474 signs the MIME body of the request. It does this because: There is little purpose in establishing the identity of the user that originated a SIP request if this assurance is not coupled with a comparable assurance over the media descriptors. While I don't disagree that assuring the media *identity* is highly valuable, I don't believe 4474 gives that assurance per se by signing just descriptors, and I happen to think there *is* value in establishing the identity of a user that originated a SIP request regardless anyway. The main issue is of course application/sdp. For direct-connection models, where the authenticating domain is sending the request directly to the verifying domain, there's no issue. I personally don't see the need for rfc4474 much in those cases anyway, because mutual-TLS can be used at the transport layer, which would provide a lot more significant security benefits than just 4474 does - plus it would generally scale better. But anyway, there's no issue in those cases. The sticky part is when the request goes through intermediate domains, such as transit providers. There are plenty of B2BUA's which modify it, for a whole bunch of reasons. Most of them are for reasons specific to an originating or terminating domain, where rfc4474 would not really be an issue. One notable exception I can think of is when transcoding is performed by media-servers inside intermediate domains. But the biggest one is undoubtedly SBC-type systems at the borders of those intermediate domains. One argument proposed by some is that these intermediate domains would just verify the signature, change SDP, and re-sign. While that may be technically possible for E.164 number URI's, it would present a significant start-up problem of needing everyone to do it; and obviously doesn't work for non-E.164 URI's. Another argument is that domains using intermediates for request routing essentially rely on and expect a chain-of-trust domain model, and may not even care about a 4474 signature if the signing domain is not their local link to that chain. While I don't disagree that is the current situation, at some future time as more and more peering interconnect happens, this chain will become brittle. The question is what types of threats it will face... Clearly there is an argument to be made that such intermediate domains are indistinguishable from a MitM. Much of the IETF community is concerned with MitM attacks, but I don't think providers or even average users are too concerned about that - or rather, if something can become a MitM between or among the providers, it's a much bigger deal than just your media frankly. They expect and need to be able to ferret that out regardless of 4474. What they're more concerned with, imho, is insecure ends of that trust chain creating spam or fraud. In other words, that some enterprise or provider at the end is less secure about who it lets create requests to begin with. You can think of this in the context of email I think. I don't live in that world, but my guess is that more people are concerned with spammers generating email through open relays or bots, than they are about an active MitM intercepting emails for the purpose of modifying their contents en route. The reason I think it's important to understand that fear factor difference, is that 4474 attempts to provide protection for both things at the same time: request originator user identity, and MitM modification/replay protection. That is in fact why I wrote the baiting attack draft, to both point out that one does not even need to be a real MitM to act like one, and that even *with* rfc4474 it's not stopped. It will take something different to stop it. Furthermore, it should be quite clear that signing SDP isn't enough - IP addresses for media are obviously spoof-able. And if it's a MitM you're worried about and it can see the SDP, there's a fairly good chance it can successfully spoof and intercept that media addressing too. Afaik, only SRTP using signed fingerprints or IBE/IBS can truly prevent that, which is why Kai and Dan's drafts only need to sign the fingerprints instead of the whole SDP. To put this another way - most of us would laugh at the idea of putting SRTP security-descriptions keys in the SDP and signing that with RFC 4474, because it is weak and would lead to a false sense of security; but that's the same as RFC 4474 signing of normal SDP is today. So... I propose that once again the originator of the request be given an option: it can sign the MIME body, or not, based on its preference. This can be done in another parameter or param value of the Identity-Info header, similar to the Contact one proposed in part-2 of this thread; and again this parameter does not need to be signed itself because forging it or removing it implicitly breaks the signature calc anyway. The authenticator can likewise decide if it wants to accept a request with this parameter or not. The semantics of this are such that the authenticator is saying "me.com verified user [EMAIL PROTECTED] generated this request with these To, From, and Date, but not necessarily the SDP." This would be useful for spam avoidance, but not much more. (just as 4474 arguably is) If a srtp fingerprint is also signed, then it means a lot more. Alternatively, we could just recommend that such an originator simply send offerless-Invite's, since that is perfectly legal in 4474 and avoids this issue. But somehow I don't think that would be such a good idea. ;) -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
