Eric Rescorla wrote:
At Sat, 07 Apr 2007 13:45:12 -0500,
Dean Willis wrote:
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.
I don't agree with that interpretation of the text. The fact that
you *registered* both a SIP URI and a SIPS URI does not mean
that other users should convert a sips: URI to a SIP one.
Here's the relevant text from page 7:
Although not mandated specifically in [RFC3261], the implication is
that a resource described by a SIPS URI can not be "downgraded" to a
SIP URI by just changing the scheme, unless it is the "last hop
exception" described in Section 3. This specification clarifies that
a resource described by a SIPS URI MUST NOT be "downgraded" to a SIP
URI by changing the scheme, or by sending the associated request over
a non secure link, except for cases where the "last-hop exception"
rule is in effect (in which case the Request-URI would be replaced by
a SIP URI).
I believe that paragraph has changed in the current pre-draft to say:
This specification mandates that a resource described by a SIPS
Request-URI can not be "downgraded" to a SIP URI when a proxy is
forwarding a request by changing the scheme, or by sending the
associated request over a non secure link. See Section 4.2.
This refers only to a PROXY making the downgrade, not a USER making the
downgrade.
Section 3.2 Routing says:
For example, consider the case of a UA that has registered with SIPS
contact header field. If a UAC later addresses a request using a SIP
Request-URI, the proxy will forward the request addressed to a SIP
Request-URI to the endpoint, as illustrated by message F13 in
Section 5.3 and in Section 5.4. The proxy forwards the request to
the UA using a SIP Request-URI and not the SIPS Request-URI used in
registration (and it does this by substituting the sip scheme to the
sips scheme in the registered contact header field binding). If the
proxy did not do this, and instead used a SIPS Request-URI, then the
response (e.g., a 200 to an INVITE) would have to include a SIPS
contact header field. That SIPS contact header field would then
force the other UA to use a SIPS contact header field in any mid-
dialog request, including the ACK (which wouldn't be possible if that
UA did not support SIPS).
The preceding says that IF a user converts SIPS to SIP, then the proxies
will forward the request. This is further supported in the following:
Section 4.1.2 page 12 says:
Because registering with a SIPS contact header field implies a
binding to both a SIPS Contact and a corresponding SIP Contact, a UA
MUST NOT include both the SIPS and the SIP version of the same
contact header field in a REGISTER: it MUST only use the SIPS version
in this case. Similarly, a UA SHOULD NOT register both a SIP contact
header field and a SIPS contact header field in separate
registrations as the SIP contact header field would be superfluous.
Note however that a UA could register first with a SIP contact header
field (meaning it does not support SIPS), and later register with a
SIPS contact header field (meaning it now supports SIPS).
If a UA wants to ensure that no requests are delivered without using
TLS on that last hop, the UA MUST use [I-D.ietf-sip-outbound].
If we are in proxyless scenario, then we aren't using outbound, and the
"last hop" is the UA to UA hop. Since the only way we have in the
current text to assure that TLS is used on this last hop is to use
outbound, and we aren't using outbound, then we have NO WAY to assure
that this hop is done using TLS.
Later in 4.1.2 we have:
Location services
are therefore free to map from SIP to SIPS URIs as appropriate (see
[RFC3261]/26.4.4). When Bob registers, it therefore does not really
matter if he is using a SIP or a SIPS AOR, since they both refer to
the same user.
All of these, taken together, say to me that it is reasonable for a user
who is handed a business card with only a SIPS URI on it to guess an
equivalent SIP URI and use it, and that the infrastructure will route
this request to the UAS. If that UAS is NOT using "outbound", then the
last hop may well be traversed without TLS.
Consequently, in the case that (unknown to the orignating user) there
ARE no proxies (such as a simple UAC-->Location Server(302)--->UAS flow,
the content of the request will be delivered unprotected toward the UAS.
If there is a tap on the Line (aka sniffer), then the conent of that
request will be revealed.
This turns out to be pretty important in a P2PSIP world, where there
might be a lot less proxies.
--
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
