Subject: [Simple] MSRP relay implementation issue; domains & scalability

From: Ruud Klaver <[email-masked]>
Date: Thu, 06 Sep 2007 10:51:26 +0200

Hi,

I am planning on implementing a MSRP relay according to the
specification and have come across an issue. In the interest of
scalability I would like a pool of relays to be able to service users
from several domains.

However, the current specification has no provision for the
authenticating endpoint to supply a domain, only a username and
assword. In practice, this means running a separate server instance for
 each domain, which is not very scalable.

My question is, what would be the preferred solution to this?

-- 
Ruud Klaver
http://www.ag-projects.com

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Adam Roach <[email-masked]>
Date: Thu, 13 Sep 2007 17:07:08 -0500

> My question is, what would be the preferred solution to this?

I think the key problem you're going to run into here isn't with user 
authentication, but with server authentication. In particular, relay 
connections are required to be over TLS; and, the certificate presented 
by the relay must match the name used by the client to connect to that 
relay. This problem is very similar to the difficulty found in running 
multiple https virtual hosts on a single web server. The traditional 
solution in that case is to use multiple IP addresses on the same host, 
so that the HTTP server knows which certificate to present based on the 
IP address the request arrives on.

Fortunately for MSRP, the problem is a little bit easier -- for https, 
using a port number other than 443 is a significant hardship, which is 
why most people use IP addresses instead of ports to disambiguate 
multiple domains hosted on a single server. For MSRP, this isn't an 
issue. So, instead of using IP addresses to determine which certificate 
to present, MSRP servers can simply listen on a different *port* for 
each domain they service, and use the port number to determine which 
certificate to present.

Now, since you already need to use multiple ports to determine which 
certificate to present, it becomes pretty obvious that you can also use 
the destination port to determine which domain the username is scoped to.

Of course, the usernames themselves are simply a quoted string -- so, 
for example, if you wanted to make the _usernames_ to be of the form 
"user@domain", that will work -- it's a private matter of how you 
provision your system, and doesn't require any protocol support. 
However, doing this isn't really even necessary, for the reasons I 
describe above.

/a

---

From: Ruud Klaver <[email-masked]>
Date: Mon, 17 Sep 2007 11:03:28 +0200

Hi Adam Roach,

> However, doing this isn't really even necessary, for the reasons I

Thank you for the suggestions, and yes the TLS certificate is domain
specific as well and needs to be dealt with. However, this makes your
second suggestion unusable, as the TLS certificate needs to be presented
to the client before it authenticates.

To be honest I had already considered your first suggestion myself, but
it does not seem the most elegant of solutions, especially when
servicing a lot of domains.

It was suggested to me that TLS includes an extension that allows the
connecting client to indicate the name of the server it is contacting
(section 3.1 of RFC 3546). This would allow the MSRP relay to present
the client with the correct certificate for a domain and further
authenticate it within that domain. However, this would rely on some
support of the connecting client. Wouldn't this solution be preferable
to having a relay listen on lots of different ports?

---

From: Adam Roach <[email-masked]>
Date: Mon, 17 Sep 2007 10:40:32 -0500

> to the client before it authenticates.

I guess I wasn't particularly clear about that use case: if, for some 
reason, the internal architecture of your software makes it difficult to 
get information about which domain the request is associate with up to 
the level that performs authentication, it is trivial to encode the 
domain as part of the username field. This is never _necessary_, but it 
may simplify your design.

> to having a relay listen on lots of different ports?

It would -- but I suspect most clients won't implement this specific SSL 
feature. If you think this is particularly important, I would propose 
that you put together a "best current practices" internet-draft that 
describes client and server behavior to support MSRP relay multi-homing 
on a single IP address and port.

Although it's basically the same demultiplexing as I was describing with 
port numbers, I want to make sure you don't overlook this:  if you use 
the "server_name" extension during TLS establishment, then the indicated 
domain can be used to scope the username presented by the client.

More generally: *whatever* mechanism you use to determine what server 
cert to present (IP address, port number, server_name, etc) can be used 
to scope the client username.

/a

---

From: Ruud Klaver <[email-masked]>
Date: Tue, 18 Sep 2007 09:53:39 +0200

> to scope the client username.

I suppose I wasn't too clear on this, but I was indeed looking for some
solution that would resolve both issues, as they basically boil down to
the same problem in my view.

Again, thanks for the suggestions.