Subject: on relays (was RE: [Simple] Security Review of draft-ietf-simple- message-sessions-07)

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 8 Sep 2004 21:07:54 -0400

Sam,

Next topic. Relays (your recommendation #4).

While I recognize that other messaging protocols developed here in the IETF
have made relays an integral part of their operation, I'm very reluctant to
make relays mandatory for MSRP, as compelling as the transport security
argument may be.

First of all, let me be clear that I'm talking about MSRP relays, not
SIP-layer relays like SIP proxy servers. SIP proxies can and should play a
number of important roles in allowing MSRP endpoints to discover one
another, exchange SDP necessarily to the establishment of MSRP, provide
security properties (like hop-by-hop TLS, as described in RFC3261 26.3.2.2),
and implement various sorts of operator policies that are irrespective of
the -contents- of the MSRP session. All of that stuff is very important, has
to be provided by an intermediary, and is totally unrelated to whether or
not MSRP relays even exist.

The presence of relays in the operation of a protocol like RTP or MSRP is a
cause of latency, additional single points of failure, additional state
being kept in the network, and additional security concerns (because even
relays could misbehave) - all of the general problems that arise when you
don't follow the end-to-end model. In my view, the main reason why MSRP
relays exist at all is NATs - they facilitate NAT traversal. There are also
some other corner-cases, like IM logging in accordance with enterprise
policies, aggregating transport-layer connections between service providers,
and so on. But primarily, MSRP relays exist to compensate for a lack of
network-layer connectivity/addressibility between MSRP endpoints.

While it might seem attractive to say that MSRP endpoints could always use
TLS to connect to a relay that they trust, the same way we do this in SIP,
and thus guarantee that TLS can always be used for MSRP, there are many
levels of trust:

- You can trust a relay to forward your messages
- You can trust a relay not to modify your messages
- You can trust a relay  not to read your messages

Any relay that could pass the simplest empirical test has to forward your
messages, at least. But if you're concerned about a relay modifying or
reading your messages, you'll need to use something like S/MIME to prevent
that. S/MIME credentials (even self-signed certs) could have been passed at
the SIP/SDP layer during the establishment of the session in a secure manner
that neither SIP relays nor MSRP relays would be able to thwart. [As an
aside, of course, S/MIME can also provide the necessary end-to-end
authentication through relays, to speak to your second point in
recommendation #4 below.]

But this shows the core issue I have with mandating relay use for its
security properties. You've introduced another entity could be
eavesdropping, and thus you have to use S/MIME to send messages through
relays if you want real security. But if you use S/MIME, you already have
the end-to-end security that you need - you can just use S/MIME between the
endpoints without relays. So what is the security property we really gain
from relays?

These gradations of trust are much more important when considering MSRP
relays than they are in considering SIP relays. You are only required to
trust a SIP proxy server with one piece of salient information, really -
that you want to have a session with a particular someone. You trust the SIP
proxy with the identity of that particular someone because you have to -
that SIP proxy is the only entity that knows how to reach that particular
someone. Once the SIP proxy has connected you to that someone, its job is to
get outta your way and let you chat. The only reason I need to trust an MSRP
proxy is so that it can get me around a network-layer discontinuity (or to
fulfill some operator policy corner-case). I don't want or need to trust it
with the contents of my messages; it shouldn't need to have to inspect them
to provide me network-layer connectivity with someone. If I don't need that
NAT traversal job done, I don't want to run the risk or the cost (in latency
or operational expense) of dealing with an MSRP relay at all. If the
end-to-end model hasn't already been broken for some other reason (by a NAT,
or something), I don't want to break it unnecessarily.

I think the practice of using S/MIME in the absence of relays is described
pretty well already in the fifth and sixth paragraphs of the Security
Considerations of the MSRP spec. The threat model of relays is described in
the MSRP relay draft, in Section 8.3. 

Does that seem reasonable?

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: Wednesday, September 08, 2004 8:21 AM
> To: [email-masked]
> Cc: Ted Hardie; [email-masked]
> Subject: [Simple] Security Review of
> draft-ietf-simple-message-sessions-07
> 
> 
[snip]
> >>
> >> 4)  Reconsider the decision to split relay functionality 
> into its own
> >>     draft.  I agree that for many configurations it is 
> impossible to
> >>     get good transport security without relay operation.  
> Rather than
> >>     relaxing the requirement for transport security, I believe that
> >>     the working group should come to the conclusion that 
> relay mode is
> >>     an integral part of the protocol.   Also, the current 
> split does
> >>     not work well because authentication to a relay is 
> different than
> >>     authentication to a peer.  In authenticating to a 
> relay, you are
> >>     authenticating to a specific service running on a 
> host.  However
> >>     when you authenticate to a peer, you are authenticating to a
> >>     specific IM principal.  The current draft does not 
> properly handle
> >>     this distinction  and I don't think a split proposal 
> can easily do
> >>     so.  Note that I have not evaluated the security of the relay
> >>     proposal, but I have considered what security is possible to
> >>     achieve given solutions to the relay problem.
>  

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