This document reviews draft-ietf-simple-message-sessions-07.txt. That
document specifies the MSRP protocol.
Protocol Overview
The MSRP protocol is a deceptively simple protocol for transporting
messages in an instant messaging session. It provides two operations:
a send request and a report request. Each request can generate a
response. Each endpoint is defined by a MSRP URL. The URL contains
the typical host and port, as well as a resource that identifies the
specific destination of a message. For example if Alice and Bob are
talking, they will both have MSRP URLs corresponding to their
identities. MSRP specifies the optional use of TLS for transport
level protection.
However the security picture is actually a lot more complicated.
First, the knowledge of the MSRP URL serves as authentication and
authorization information. Since clients do not typically have TLS
certificates, a server knows it is talking to the right party based on
the URL that party sends to and possibly based on the response URL
listed in the message. The URLs are used for authorization in that
layers above MSRP deal with preventing spam and so it is important
that only parties authorized to send messages have the MSRP URL. So
MSRP URLs need to be chosen with a strong random component and if
message integrity is desired, they need to be
transported with confidentiality.
SIP, the layer above MSRP is responsible for mapping SIP or CPIM URLs
into MSRP URLs to set up a message session. This mapping is security
critical because users are probably going to add SIP or CPIM URLs to
their contact lists. So, to securely establish a connection, the
combination of SIP and MSRP must securely map the user-entered URL to
an MSRP URL.
MSRP also involves S/MIME and CPIM identities. If S/MIME is used to
get end-to-end encryption then the names of the chosen certificates
must be verified. If message/cpim entities are sent, then the from
and to fields in these messages must be matched. Typically the cpim
identities will be instant inbox URLs although perhaps they could also
be SIP URLs in some cases.
One final identity is important for MSRP security. The MSRP
specification requires that if TLS is used, the server certificate be
for the hostname in the destination MSRP URL. This requirement for
the TLS identity has important security implications.
Security Requirements
The draft does not specify a set of security requirements. IT seems
reasonable to refer back to RFC 2779 for security requirements for
this protocol.
I explicitly choose to distinguish confidentiality protection at the
transport layer from end-to-end confidentiality/integrity protection.
RFC 2779 doesn't quite explicitly make this distinction, but it does
require both integrity protection and support for digital signatures.
This distinction seems reasonable for several reasons. First, other
IM protocols including XMPP and APEX support both levels of
protection. We've found with email that end-to-end encryption and
transport level encryption are both useful; it seems likely that we
will see the same thing with IM.
I also introduce the concept of parties sharing a deployed
authentication infrastructure. Ideally, we'd have some authentication
infrastructure we could use to exchange key material with anyone on
the Internet. In practice, we do not yet have this level of security
integration. However we should try to provide security in
environments where we can do so. Note that it is not acceptable to
force people to deploy a new authentication infrastructure for your
protocol if they already have an adequate infrastructure for some
other purpose. If you can work within that infrastructure, then you
significantly decrease deployment costs of making your protocol
secure.
1) In order to provide integrity protection, the protocol must
describe how identifiers entered by the user are securely mapped to
identifiers used in the protocol. The protocol must describe
necessary verifications of these mappings that recipients of messages
need to perform in order to make sure they all refer to the same
principal.
2) When two parties share an appropriate authentication
infrastructure,then the protocol will provide a way for them to get
hop-by-hop confidentiality and integrity.
3) When two parties share an appropriate authentication
infrastructure, then the protocol will provide a mechanism for
end-to-end confidentiality and integrity.
4) Even when no authentication infrastructure is shared, the protocol
will provide protection against passive attacks.
Security Evaluation
This document does not define, nor as far as I can tell, reference a
concrete procedure for mapping an instant inbox (im: URL) to a SIP
URL. If clients can enter in im: URLs, then the related protocols
must specify a mechanism for securely performing this mapping.
The protocol specifies how SDP is used to map SIP URLs to MSRP URLs.
I do not have enough information about practical SIP deployments to
know whether this mapping is secure in practice. IT seems possible
to secure this mapping if the SDP information is encrypted.
This document does not specify how to validate the certificates
encrypted or signed messages. How do I know that a particular
certificate corresponds to a particular principal? Should it include
an im: URL, a sip: URL, an msrp: URL or some combination? Where
should these addresses be placed?
If the MSRP protocol is used to transport message/cpim content, the
recipient needs to confirm that the sender address in the message/cpim
corresponds to the expected sender. This is especially important in
the case of signed messages. The protocol needs to specify a
procedure for securely mapping an im: URL found in the message/cpim
to the appropriate MSRP URL to validate the sender.
The assumption that certificates used for TLS authentication for MSRP
should belong to the host seems flawed. This might be a reasonable
assumption for the relay mode, but seems incorrect for the
peer-to-peer mode of the protocol. IN a peer-to-peer configuration,
there may be multiple instances of MSRP on a given host in
significantly different security domains. It seems necessary to
authenticate MSRP, SIP ,r IM peers rather than to authenticate hosts.
In practice, MSRP does not provide transport security in the
peer-to-peer mode. The protocol allows for the use of TLS. However
the spec points out that MSRP peers are not expected to have TLS
certificates or stable hostnames for these certificates to be bound
to. The lack of deployable transport security is a critical
deficiency in the peer-to-peer mode of
of MSRP. Transport security has proven an important part of securing
XMPP. Most other message transport protocols in the IETF, including
IMAP, SMTP, XMPP and APEX support transport security.
The protocol provides support for S/MIME for end-to-end security.
This is adequate to meet requirement 3 if the certificate naming
issues are addressed.
The protocol does not provide a mechanism to protect against passive
attacks unless sufficient authentication infrastructure is available
to use TLS.
Recommendations
1) Decide on procedures for mapping im: URLs to sip: URLs. These
procedures are not part of MSRP, but MSRP needs a normative
reference to them. Note that RFC 3861 does not really answer this
question. That specification tells you what machine to talk to in
order to deliver an instant message. It does not tell you what
sip: URL to present to that system.
2) Clearly state guidelines for dealing with the identities of message
recipients and senders in S/MIME messages and message/cpim
messages. Look at section 6 of draft-ietf-xmpp-e2e for examples of
the types of things such guidelines need to say.
3) Re-examine the decision to use msrp: URLs. It is my understanding
from the change history that previous versions of the draft simply
used sip: URLs. That would be much easier to deal with from a
security standpoint. If the working group does decide to use
msrp: URLs, then the mapping needs to be carefully considered.
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.
5) Support SASL authentication and security layers for transport
security in addition to TLS. This should be done for
compatibility with the other IETF messaging protocols. In
addition, some SASL modes such as digest-md5 or the user-to-user
Kerberos mechanism could work well for peer-to-peer
authentication. Providing implementers with this flexibility
would be good.
6) Support TLS in an anonymous mode for protection against passive
attacks. It's easy to do this given that you already support TLS
and will provide useful benefits.
7) Consider handling of messages that appear to come from the same
sender but are delivered over paths with different security
properties. For example, Alice is in a conversation with
im:bob at example.com over an MSRP session using both TLS and
end-to-end S/MIME. How should Alice's client handle a message
coming in over a different MSRP session using a different MSRP URL
for the sender if that sender also maps back to im:bob at example.com?
When is this acceptable from a security standpoint?
Architectural Considerations
While reviewing a document for security considerations, one often runs
into issues unrelated to security. I discovered two such issues with
this document:
1) No mechanism is provided for discovery of future extensions.
However, section 12 anticipates that future IETF action may define
such extensions. Significant experience has shown me that you
want at least minimal discovery in your protocol. You want to be
able to add a negotiation mechanism later and discover its
presence. I recommend that MSRP clearly specify behavior if a
client uses an undefined method. I recommend that this behavior
be sufficient to discover whether the peer implements some method
in the future.
2) Section 6 of RFC 3862 lists several application considerations that
applications using RFC 3862 need to address. RFC 3860 does not
address these considerations so MSRP must do so in order to
completely specify the use of message/cpim.