-----Original Message-----
From: Robert Sparks [mailto:rjsparks at nostrum.com]
Sent: Monday, June 04, 2007 11:08
To: Audet, Francois (SC100:3055)
Cc: Dean Willis; SIP IETF
Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last
thoughts on transport=tls?
UAC -----> Proxy 1 ------> Proxy 2 ------> UAS
How (if they don't have DNS) do they specify the use of TLS between
Proxy1 and 2?
More specifically - if Proxy1 retargets an initial request to
Proxy2 based on either
configuration or a registered contact, what's the RURI of
the emitted request going to be?
Then, what should it record route with?
I'm not sure I understand what we are trying to achieve here.
Say UAC sends initial INVITE.
It chooses TLS for transport. No transport parameter. UAC does not
use SIPS and therefore does not expect TLS on each hop.
Proxy 1 forwards the request to proxy 2. If may or may not
use TLS (although it should use TLS if possible). It inserts
a Record-Route (or modifies Request-URI). In either cases, it does
not need to put a transport parameter.
If you put Request-URI of
sip:uas at example.com;transport=tls, to me, it
means the link between Proxy 2 and UAS would use TLS. I.e., the
parameter would apply to the
resource identified in the URI. (I'm assuming
Record-Routing is used
here).
The first hop (between UAC and Proxy 1) is basically what you would
select before sending the message (or if a Route header was
used, it
would be in the Route header). To me, it's self-evident in
the actual
transport anyways.
I don't understand the last sentence - especially in the
record-route/ route case.
I'm just saying the first hop is whatever is selected when you
sent the message. Since it's the first hop, there the parameter would
be useless.
Everytime I run into this issue, it seems to me that basically what
people are asking for is just a way to select TLS for the
first hop.
We don't need protocol on the wire for this: just a config
option in
the UAC.
This is not what I'm pointing at.
I'm trying to understand what you are pointing at. Is it
in-dialog requests? Is it forcing a specific hop (not the first or
last one) to be TLS, but not all the hops?
I think I'm missing something...
2) Some have indicated they operate in large enterprise-like
networks, where the endpoint has an ephemeral address,
one for which there's no way to populate NAPTR/SRVs
to indicate
a use of TLS when reaching that endpoint.
Additionally, the endpoint has a cert (!). They are
required
to register a contact that causes them to be reached
with TLS, and are using transport=tls to do so.
Surely they need to register with TLS for this to be secure.
The transport could be self-evident again, from the one used while
performing the registration.
So the unusual case here is that it _is possible_ (and even
meaningful) for the proxy to open a new connection to the UA
if the old one is gone. Are you saying that you would like
the proxy/registrar to remember that it should use TLS when
it did so as a side-effect of the registration arriving over TLS?
That would be a way we could go (and we should go all the way
and ignore what's in contact altogether if we go here), but
you will have to explicitly make 3rd party registration and
any registration that installs state that doesn't point
exactly to the registering instance illegal. (I know several
people think this is a good idea, but I don't think we've
made that the official position of the working group yet have we?)
I was not thinking specifically of the Mutual-TLS case which is what
you are pointing to.
In the server-provided certificate case, the client would be
responsible
to re-establish the TLS connection. The way to do this for
server-provided
certificate environments is using sip-outbound which does exactly what
you said (i.e., ignore the contact). The the registrar doesn't
"remember" anything: it just uses existing connections.
I tought that was agreed (in Montreal). I don't see any other way
to be
honest.
Now, you do bring up a really good point for environments where people
use Mutual-TLS between a proxy and a UA. I guess we could still use an
outbound
model for this case. Or we could use some indication in the protocol.
Not sure it's worth it to add a transport parameter for that. Seems to
me to
be overly complex, and it wouldn't allow you to indicate that you
support many different transport.
The third party registration case with the transport parameter is
weird
to
me. It would allow a UA to send a Registration unseculily (over TCP or
UDP), and
create a binding for a third party using TLS. Seems like it would make
the TLS
connection pointless (unless somehow the first party is secure some
other way).