Eric Rescorla wrote:
You give the caller the sips: URI and I think the draft makes clear
that if you have a sips: URI you MUST NOT use SIP w/o TLS. The question
is what a proxy should do if a request comes in without TLS.
I'm not finding that. What I'm finding is text that says a user who is
given a sips: URI can deduce a sip: URI from that and use it.
If you give people HTTPS and they try to contact the server over
HTTP (recall that the servers need to support both TLS and non-TLS)
the server can do one of three things:
- Respond to the request anyway.
- Redirect the request
- Throw an error.
The damage of the data being sent over the net to the server is already
done.
Right. The problem I'm trying to describe is -- do we need guidelines
that prevent this damage from being done?
The HTTPS equivalent use case is:
Assume you are given an HTTPS URL for something. If you deduce an
equivalent HTTP URL for that target and exercise it, any information
sent is subject to interception by packet sniffers. If the HTTPS URL was
for a "login" service, you might have just given away your password.
Going back to the SIP case, the proxy has three options:
- Forward the request to the client anyway.
- Redirect to the SIPS AOR
- Throw an error.
Again, the damage of the data being sent in the clear over the net
to the proxy is already done. The text you quote above implies
the first choice, but it's not clear there's anything wrong with
that, especially as you can ensure that the connection from the
registering user to the proxy is secure.
The only way to ensure that the connection from the proxy to the
registering user is secure is to "upgrade" the connection to SIPS. Just
using TLS won't work, because there are possibly additional proxies
between the proxy/registrar and the user. But upgrading to SIPS in a
midstream proxy has issues that Francois and Jonathan have pointed out
(like surprising the UAC, which might not support SIPS) or requires some
B2BUA procedure from the proxy (like my old kludge-proxy did).
In the HTTP case as described above, we have a mitigating factor
provided by TCP. Since HTTP and HTTPS both require a TCP connection and
listen on different ports, the worrried server could just turn off its
HTTP port. The client would fail to do a TCP open with the HTTP port,
and would thus never send the sensitive information unprotected.
SIP has UDP, so there's no "open". Instead, (if a user or UAC deduces an
equivalent SIP URI and uses it), the sensitive information could well
just be blurted out, unprotected, in a UDP packet. And the only one
listening for that packet is the interceptor, who is now a happy camper.
Perhaps something like:
A user or a UAC that has been presented a SIPS: URI for a correspondent
MUST NOT deduce an equivalent SIP URI and use it. Instead, they MUST use
the SIPS URI. The rationale for this that the issuer of the SIPS URI
chose SIPS instead of SIP because they need to have a higher level of
security exercised when contacting them, and their callers are required
to respect that need. If the user or UAC instead uses the equivalent
SIP URI, there is a risk of disclosure to non-trusted intermediaries of
information sensitive to the holder of the URI, such as their currently
registered Contact.
--
Dean
_______________________________________________
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
