Subject: RE: [Simple] Message Sessions: Security as a motivation

From: [email-masked]
Date: Tue, 8 Apr 2003 17:22:30 +0300

> -----Original Message-----
 > From: ext Ben Campbell [mailto:[email-masked]]
 > Sent: 08 April, 2003 05:22
 > To: Adam Roach
 > Cc: [email-masked]'
 > Subject: RE: [Simple] Message Sessions: Security as a motivation
 > 
 > 
 > Actually, I mispoke myself a little. I meant to say, it takes a key
 > exchange either way, without actually committing to say PK :-)
 > 
 > The key exchange mechanisms are not well defined in the 
 > existing draft.
 > That is something that needs fixing ASAP, and as I mentioned in SF I
 > welcome the input of others on the matter.

Also, the draft does not include much discussion on the fact that msrp/tls by no means ensures e2e security when relays are used. Using TLS as the e2e security mechanism would be the best alternative in many scenarios. Perhaps it could be possible to add a "tunnel mode" for the MSRP relays?

Cheers,
Aki

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

---

From: [email-masked]
Date: Wed, 9 Apr 2003 09:54:02 +0300

> From: ext Adam Roach [mailto:[email-masked]]
 > Sent: 08 April, 2003 18:18
 > To: Niemi Aki (NMP/Helsinki); Ben Campbell; Adam Roach
 > Cc: [email-masked]
 > Aki Niemi writes:
 > > Also, the draft does not include much discussion on the fact 
 > > that msrp/tls by no means ensures e2e security when relays 
 > > are used. Using TLS as the e2e security mechanism would be 
 > > the best alternative in many scenarios.
 > 
 > I agree. Down with relays! ;-)
 > 
 > > Perhaps it could be 
 > > possible to add a "tunnel mode" for the MSRP relays?
 > 
 > You mean kind of like the HTTP "CONNECT" request?

Yes. In fact, the current draft says nothing about the case where an end point needs to use a relay, but doesn't want to host. There is only the ambiguous case with two relays, but even there both ends really intend to host. And BIND is for the hosting case, while the HTTP CONNECT equivalent is missing.
 
 > I think that might be going a bit overboard. It also probably
 > defeats most of the policy that one would deploy a relay to
 > address anyway.

I agree that in the hosting case at least, the tunneling approach has some serious drawbacks since it would basically allow a UA to host any server behind the relay.

What I would like to enable is the simple scenario where a UA is behind a NAT/FW that blocks outbound TCP connections, but would like to connect to a public chat server for a multiparty message session. Currently the draft allows only for an option where the UA itself uses a relay to host, and forces the chat server to be the "active" party in establishing the connection.

The tunnel approach here would both enable TLS end2end, and not require the UA itself to host at a relay.

Of course, using HTTP CONNECT would be the obvious alternative, but if we intend to make MSRP a complete solution, it needs an equivalent function anyway, IMO.

 > In another thread, I suggested that the draft simply
 > mandate that MSRP messages received on a secure connection
 > must be sent on a secure connection. It's not e2e (that's
 > what S/MIME is for), but it does give you encryption whenever
 > the messages are on a network.

This is also a reasonable approach and should definitely be in the draft in any case.

Cheers,
Aki

---

From: Adam Roach <[email-masked]>
Date: Wed, 9 Apr 2003 12:53:36 -0500

[email-masked] [mailto:[email-masked]] writes:

> Yes. In fact, the current draft says nothing about the case 
> where an end point needs to use a relay, but doesn't want to 
> host. There is only the ambiguous case with two relays, but 
> even there both ends really intend to host. And BIND is for 
> the hosting case, while the HTTP CONNECT equivalent is missing.

I don't think I quite understand what you're saying.
Using a relay is inherently a way of hosting the
MSRP session; you're just establishing an additional
node through which the MSRP traffic will travel.
An assertion that "an end point needs to use a relay,
but doesn't want to host" would seem to be nonsensical
to me.

Could you tell me what beneficial property is afforded the
network by your proposal? In other words: what is the
problem you're trying to solve?

/a

---

From: [email-masked]
Date: Tue, 15 Apr 2003 10:05:57 +0300

> Sent: 09 April, 2003 20:54
 > To: Niemi Aki (NMP/Helsinki); Adam Roach; Ben Campbell
 > Cc: [email-masked]

I see your point. This is actually how the current draft defines relays, i.e., that they adopt the hosting duties of an endpoint. However, I think what I'm ultimately after is a way to make the relay pair case (Ch. 6.8.4) work better. Currently, the draft claims that such a case would occur rarely, but I don't believe this is so. It may be very commonplace that two endpoints both sit behind a firewall. And I don't like the fact that there is no VISIT sent in this case, but the connection registration is implicit somehow.

I think what is needed is that the relay can both host and proxy. Note that the tunnel mode that I suggested could be an additional feature of a proxy.
 
 > problem you're trying to solve?

The way that the relay pair case would then work is that the active endpoint would concede not to host, and send its VISIT to its MSRP proxy. Same credentials as for BIND could be used for authentication, and the MSRP proxy would simply forward the VISIT to its final destination.

Cheers,
Aki