Ok, so it has nothing to do with Request-URI then (which is what I
tought
we were talking about).
I don't believe that using transport=tls in Contact for
Registration will generally work.
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.
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.
> -----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
