6 Jul
2011
6 Jul
'11
2:15 p.m.
6 jul 2011 kl. 10.23 skrev Martin Hoffmann:
Agree. It's not complete.
Both.
If the client
initiated the connection without a client certificate, you can't reuse that one. If
you requested a client cert and that matches the Contact the client provided you with, you
are allowed to use it.
Olle E. Johansson wrote:
Because RFC
5630 says that if a Route header has SIPS the contact also has to be SIPS.
As mandated by [RFC3261], Section 12.1.1:
If the request that initiated the dialog contained a SIPS URI in
the Request-URI or in the top Record-Route header field value, if
there was any, or the Contact header field if there was no Record-
Route header field, the Contact header field in the response MUST
be a SIPS URI.
6 jul 2011 kl. 00.35 skrev Iñaki Baz Castillo:
RFC 3261, section 4:
| A call made to a SIPS URI guarantees that secure, encrypted transport
| (namely TLS) is used to carry all SIP messages from the caller to the
| domain of the callee. From there, the request is sent securely to
| the callee, but with security mechanisms that depend on the policy of
| the domain of the callee.
It's like in HTTP world:
- http:// means HTTP over TCP.
- https:// means HTTP over TLS over TCP.
Since HTTP just works over TCP, there is no reason for a ;transport
param. But SIP protocol can work over different transport layers (TLS
is not a transport layer).
You can not compare sips with https. Sorry.
https puts a requirement for TLS all the way.
SIPS: in RFC3261 did not. It's simply a request, a proposal. Now if you
don't want to change the
properties of the original request, but still require your
infrastructure to use TLS for the next hop you do not want to change
to a SIPS: uri, which will put a new requirement for the rest of the
signalling. You want to add an attribute like ";transport=tls".
Why? We are talking about the URI in the (Record-) Route header here,
which _only_ indicates how to get to the next hop. If you put a SIPS URI
in there, this has no consequence whatsoever for the complete path. Yes, SIPS: is really messy and hard to
understand.
I'd argue it's completely broken like so many things in SIP. IETF went
out to publish a document to fix it. After much argueing, this became
RFC 5630 and people are confused as ever. How would you guys
handle a Contact: with SIPS: ?
In a dialog or in a registration? Can you reuse a connection like
outbound? I guess not, since you have to verify the endpoint
certificate.
If you reuse a connection you'd have done that already earlier. Most
likely, the client opened the conneciton to you in the first place.
One final word: What Iñaki and me are argueing here is what the standards
say. What we probably don't agree on is what this means in practice. For
me as someone who regularly has to bring different SIP implementations
together, it means pretty much nothing. You'd never find SIPS URIs in
the wild but plenty of transport=tls. (Or well, not really, nobody is
using TLS in practice anyways.)
Exactly. And when testing at SIPit (Nils, Daniel and I) we found that most phones
doesn't bother with verification of the server cert anyway. Just put a padlock on the
screen and be happy - WE ARE SECURE!
/O