At Fri, 06 Apr 2007 12:36:29 -0500, Dean Willis wrote: > > > I'm pre-reviewing Francois' latest sips draft, and I'm perplexed. > > Presume a UA wishes to receive only SIPS requests and not SIP requests. > > This is important if we do not wish to reveal information about the UAS > (most critically the identity of the user at this UAS) -- to > packet-sniffers on the wire between UAC and UAS. > > > Previously it could do this by registering only a SIPS contact and not a > SIP, and by using a SIPS AOR in registration. > > Because registering with a SIPS contact header field implies a > binding to both a SIPS Contact and a corresponding SIP Contact . . . > > means we simply can't satisfy this use case. > > Just waiting for a request and then rejecting it if it didn't come in > over TLS would not meet the requirement, since the plain text of the > request would already have been sent, potentially compromising > information about the UAS. > > Do we have a problem?
It's probably useful here to take an analogy from the Web. Amazon.com, to take one example, runs two web sites: - The HTTP-based one which runs their catalog. - The HTTPS-based one which they use for checkout. If you're shopping and you go to checkout, they redirect you to the HTTPS site. If you try to just go to the HTTPS site to shop they redirect you to the HTTP site. If you mistakenly try to do checkout with HTTPS, I suspect it pukes (many sites do), even though the exposure has already happened. This is sort of a necessary side effect of being willing to run both HTTPS and HTTP. If you're never willing to run HTTP, then you need your server not to listen on port 80. But actually this only helps against passive attacks, since if a stupid person tries to contact you over HTTP the attacker can just pose as you. And of course if you're running on some sort of shared hosting server, then the problem is even worse since the hosting server may allow HTTP for others but not you. So, even the refuse to listen on port 80 doesn't work. The only real defense against this sort of downgrade is to only give people URLs that start with https: and assume that they will do the right thing. So, mapping into the SIP domain, things look much more like the hosting service example. You are connected to a SIP proxy which may server SIP/TLS *and* SIP for other people. So, you can certainly tell the proxy "don't accept anything for me not over TLS" but as you say that only takes effect after he's received the request. As long as the proxy is willing to do SIP-not-over-TLS then you can always be subject to this problem (and even if it doesn't there's always the active attack I described above) and there's no instruction you could give the proxy that would help (though the instruction could of course restrict the proxy to talking to YOU via SIP/TLS). As with https: the fix is that your AOR has to somehow signal to everyone that you expect to be contacted over TLS. This is what sips: does (though of course it's not the only way to do it). -Ekr _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
