[Simple] Security Review of draft-ietf-simple-message-sessions-07

[Robert Sparks <[e-mail]>]

Folks:

At Ted's request, Sam Hartman performed a security review of the MSRP 
base specification.
Sam's identified some things we need to do, and several things we need 
to talk about.
The chairs, our technical advisor, or the editors of these drafts will 
be sending messages to
the list responding to these points individually over the next few 
days, either with proposed text
or starting a discussion on the topic.

Please read this carefully and send your comments to the list.

Thanks,

RjS

Begin forwarded message:

>> 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:[e-mail] 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:[e-mail]?
>>    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.


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