On Jun 4, 2007, at 5:34 PM, Francois Audet wrote:
Ok, so it has nothing to do with Request-URI then (which is what I
tought
we were talking about).
Well, we're still not connecting quite yet.
It has _EVERYTHING_ to do with Request-URI.
It is coincidence that I'm populating what the RURI will
be after retargetting with a REGISTER. It could have been
any other mechanism. The important part is what comes
out into the Request-URI of the P1->P2 link.
I don't believe that using transport=tls in Contact for
Registration will generally work.
(as you read my inline responses below, ask yourself what
=tls has to do with what you wrote - I think I can substitute =tcp,
which we _do_ allow, and everything but the comments about
mutual or server auth still stand)
There are 2 cases:
From == To in REGISTER (First Party Registration)
-------------------------------------------------
In this case, if we use SIP-Outbound, we DO already
have a solution.
Surely you're not suggesting proxies do outbound between them.
You're latching onto the endpoint case. I'm talking about a server to
server case.
With SIP-outbound, the connection used by the registration
process is kept alive and reused for both incoming and
outgoing requests.
It has the advantage that it will support environments
where server-provided certificates are used since
the TLS connection will only be establishable by the
client.
A a bonus, SIP-outbound also solves NAT and FW traversal, if
there happens to be one.
Their proposed solution of using a transport parameter
will not work for server-provided certificates as the
server will not be able to establish a connection with
the client. Since server-provided certificates is by far
the most commone deployment scenario (as opposed to
Mutual TLS) for UAs, this is a big problem.
Their proposed solution wouldn't work either if there is
a NAT or Firewall. Again, big problem.
Their proposed solution would therefore ONLY be
suitable for environments where Mutual TLS is used, and
where there are no NATs or Firewall.
The SIP-outbound mechanism also works with Mutual TLS.
Therefore, for this case, I do not believe that their
mechanism is general enough to be standardized.
This is described at lenght in the draft.
From != To in REGISTER (Third Party Registration)
-------------------------------------------------
Third party registration is problematic for both their
proposed solution, as well as for SIP-outbound.
For SIP-outbound, well, it plainly doesn't work.
For their proposed solution, it is a security problem
since it effectively allows a non-secure user (the "authority"
as you call it), to request that session be delivered securily.
Dr, Evil person could hijack the "authority" role and redirects
all sessions to wherever it wants, and the sessions would be
"secured" with Dr. Evil.
Furthermore, their proposed solution would not work in this
case either with server-provided certificates, or if there
is a NAT or Firewall. Again, big problem.
To me, it means that Third Party Registration is just plain
bad in a secure environment.
In fact, I don't like the idea of allowing third party
registration to allow a UAC with AOR in p1 domain to
register a contact in a different domain (p2 in this case).
That contact is effectively an AOR.
How would I solve the problem?
I would expect the other UA (sip:[EMAIL PROTECTED]) to do it's
own registration in it's own domain P2, according to the rules
of it's
own domain. If P2 is using server-provided certificates, it
would
work (with Outbound). If a NAT is present, it would works as
well.
Then, I would allow user "[EMAIL PROTECTED]" to log in securily
on the Proxy (with HTTPS for example), and request routing to
be done to another address (in this case,
sip:[EMAIL PROTECTED]@).
To ensure that P1 would use TLS to P2 (as they want), I'd just
put
a "User TLS" checkbox.
That seems to me to be a lot less broken that trying to squeeze
it
into third-party REGISTER.
This is getting closer to the P1->P2 hop, but its a bit of a herring
that
you've separated 1st and 3rd party registration. I could have
[EMAIL PROTECTED]
in both to: and from: and still point it at [EMAIL PROTECTED]
I understand where you are going with "make that a checkbox on
somebody's GUI" and
that's exactly what I'm saying isn't good enough. The preference
needs to be reflected in the URI.
For the registration case, binding things between P1 and P2, let me
try yet another way to say this.
It's in the field.
People are USING it.
We are trying to say "Don't do that" without giving an alternative
that works in that scenario.
We will be ignored unless we can present a clear and compelling
reason why someone
is putting life or limb at risk to do this (and I suspect we'll be
ignored even then).
I'm not sure I can make any such argument around just this transport
parameter. If we're
going to allow someone to say "udp" or "tcp" in this case, its rather
pointless to not let them
say tls (with the appropriate caveats around not having the anchor in
DNS to verify who
you're talking to).
I _can_ make an argument around the notion of putting state in that
doesn't point directly to you,
but that goes way way beyond just the transport parameter, and if
we're going to go there, we
need to start an entirely different conversation that will take the
transport parameter completely
off the table for _any_ transport.
RjS
-----Original Message-----
From: Robert Sparks [mailto:[EMAIL PROTECTED]
Sent: Monday, June 04, 2007 14:55
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?
Ok - we're closer, but not quite together yet.
Lets start with a different message from the UAC where the
RURI is simply
sip:[EMAIL PROTECTED]
The authority for [EMAIL PROTECTED] (the person that might send a
register request with that in the To: header) wants requests to go to
sip:[EMAIL PROTECTED]
and they want it to go over TLS. What they'd _like_ to do is
send a register request with a contact that says to use TLS,
or at most, send a single URI to the operators of P1 that
describes where to send requests that show up for [EMAIL PROTECTED]
What tools do we give them to make the statement they want to make?
RjS
On Jun 4, 2007, at 4:30 PM, Francois Audet wrote:
This is exactly where we are disagreeing.
How do you _tell_ P1 that you want to reach P2 using TLS
in the first
place.
As I said elsewhere in the thread, I don't think leaving this
unspecified ("you just do this with the configuration of the
proxy") is the right answer. If you have DNS, you tell P1 about P2
using DNS. If you don't have DNS, using the transport parameter in
the URI you hand it seems pretty natural. That's how
you're going to
tell it to use udp or tcp...
I think I finally understand what you are saying...
Say UAC sends request to Request-URI [EMAIL PROTECTED];transport=tls.
The transport parameter indicates that the resource in the
request URI
([EMAIL PROTECTED]) is the one that needs to be contacted with TLS.
Therefore, it
would be the P1 -> P2 link that would use TLS in this case
(since P2
owns that domain). And P2 could use whatever it wants for P2 ->
[EMAIL PROTECTED] And similarly, uac -> P1 (or P1 to any other proxy
between P1 and P2) could use whatever they want.
The use case would be where the UAC "trust" it own domain
and does not
feel it necessary to use TLS, and/or the UAC "trusts" the target
domain for being responsible of that happens inside the
target domain.
And finally, the UAC does not really care if there are
other types of
proxies in the middle (not responsible for a specific domain), that
may not use TLS.
While I understand that this is in theory something that could be
solvable, I'm not sure why it is such an interesting case.
Seems to me
it is only of value if the only "vulnerable" hop is the one between
the source and target domains, and if there are no other proxies
between them (e.g., no "Service provider").
In fact, it pretty much describes to me why you should be
using SIPS
in the first place.
Do we *really* want to reintroduce transport=tls for this case?
Side note: I just want to point out that RFC 2543 did NOT allow the
presence of the transport parameter at all in a Request-URI
and 2543
servers would ignore it or remove it.
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
