6 Jul
2011
6 Jul
'11
12:05 p.m.
2011/7/6 Martin Hoffmann <martin.hoffmann(a)telio.ch>ch>:
After re-checking RFC 2543 and RFC 3261:
- In RFC 2543 "sips" schema does not exist, neither ";transport=tls".
The only it says is that a request can be sent via TLS by setting
"TLS" as Via transport:
RFC 2543 - 13.1.4 Hop-by-Hop Encryption
SIP requests and responses MAY also be protected by security
mechanisms at the transport or network layer. No particular mechanism
is defined or recommended here. Two possibilities are IPSEC [34] or
TLS [35].
- In RFC 3261 "sips" schema is defined and mandates SIP over TLS over
TCP (as neither SCTP over TLS or DTLS were defined in 2002, but leaves
the door open for using new secure mechanism when schema is "sips").
- RFC 3261 shows *NO* example of ";transport=tls", not al all, and it
clearly states that "sips" must be used.
- RFC 3261 just talks about "tls" in ;transport param in the BNF section:
transport-param = "transport=" ( "udp" / "tcp" /
"sctp" / "tls"
/ other-transport )
and this is becase, as RFC 5630 explains:
The "tls" parameter has not been eliminated from the ABNF in
[RFC3261], Section 25, since the parameter needs to remain in the
ABNF for backward compatibility in order for parsers to be able to
process the parameter correctly. The transport=tls parameter has
never been defined in an RFC, but only in some of the Internet drafts
between [RFC2543] and [RFC3261].
- And RFC 3261 says:
The use of
"transport=tls" has consequently been deprecated, partly because
it was specific to a single hop of the request. This is a change
since RFC 2543.
but in RFC 2543 there is no mention AT ALL to ";transport=tls",
neither "tls" is
mentioned as a valid value for the URI transport param. In fact, BNF
in RFC 2543 says:
transport-param = "transport=" ( "udp" | "tcp" )
So after "re-reading" all the specifications (RFC 2543, RFC 3261 and
RFC 5630) it's fully CLEAR for me that using ;transport=tls is
*incorrect*. It seems that such value has been used in some draft
between RFC 2543 and RFC 3261 (without including them!!). But since
RFC 3261 (which is what we use) there is no ;transport=tls at all. So
implementations should leave using it (because they are using
something that does not exist).
Now it somebody still thinks that ;transport=tls is valid, he should
at least point to any alive specification showing it :)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Main cause of
the confussion ever after RFC 5630, is the fact that
such RFC does not want to cover the ;transport=tls case in deep (which
exists anyway as RFC 2543 and RFC 3261 mention it).
Why would it need to. There is _no_ transport=tls in 2543 and 3261 says
explicitely "don't use it; we just kept it in to stipulate long-winded
future discussions" (already it doesn't say the latter bit). The purpose
of 5630 was to explain the whole SIPS thing. Obviously, it failed.
Just to repeat it once more (because this is fun): The use of the value
"tls" for the transport URI parameter has never been mandated by any SIP