RE: [Simple] Security Review of draft-ietf-simple-message-session s-07

["Peterson, Jon" <[e-mail]>]

Sam,

Thanks first of all for the good review of the protocol - you make a lot of
important points below, and I think we will definitely need to make some
changes to the MSRP specification as a result of your suggestions. Here's
some notes for starters. ;)

The most important of change, I think, is the applicability statement that
Robert sent out separately today. I think the root cause of a number of the
deficiencies you note below is that the reliance of MSRP on a higher-layer
rendezvous mechanism isn't as obvious as the authors hoped.

The mapping of MSRP URLs to SIP URIs is perhaps the foremost of the related
issues you raise (your recommendation #3). To really understand the reliance
of MSRP on SIP, you have to look at the way SIP and RTP interact for
establishing multimedia calls. In a VoIP scenario, for example, SDP contains
the IP and port to which RTP will be sent - this identifies an RTP endpoint.
An MSRP URL serves the same function as an RTP IP/port; it is not intended
to be a user identity as such, user identities are exchanged and authorized
and so on at the SIP layer. Talk of difficulties "mapping" SIP URIs to MSRP
URLs, therefore, I think, mistakes the applicability of MSRP a bit, just as
I'd say if someone suggested we needed a way to "map" RTP IP/ports to SIP
URIs. The relationship of a SIP URI to an MSRP URL is totally transient and
contingent, just as the relationship between a SIP URI and any given RTP
endpoint IP/port is contingent (I may use this phone today, but some
different phone tomorrow). What binds a SIP URI to an RTP IP/port,
temporarily, is SIP itself - a SIP INVITE is sent containing SDP that
advertises where to send RTP. That RTP endpoint is meaningful only for the
duration of the session resulting from the SDP offer/answer. The resulting
binding is just as secure as SIP is - if SIP is used with integrity
protection and confidentiality over the SDP body, then the binding between
the identity in SIP and the RTP endpoint is a secure binding. All of this
applies as well to MSRP. Without some SIP-like means of securely exchanging
endpoint identifiers, then yes, the relationship between an end user's
identity and an MSRP URL would be very uncertain. With the applicability
more firmly in mind, though, I don't think there is really any "mapping"
problem here.

Similarly, I think the rendezvous protocol can (and in the case of SIP,
does) provide the sort of functionality that you'd get from something like
SASL (your recommendation #5). Digest auth is built into SIP, there are ways
of doing EAP (and all that EAP potentially brings with it) in SIP. More
important, establishing the identity of the participants in a session is
SIP's responsibility, not the responsibility of something at the RTP/MSRP
layer, given the binding established by SIP described above. While there are
many threats that motivate channel security at the RTP/MSRP layer, I think
TLS and S/MIME, collectively, can address those threats for MSRP, and they
are documented in the MSRP specification. SIP/SDP can serve as a vehicle to
deliver keying information (even self-signed certificates) between
endpoints, as it does in the sdescriptions method of exchanging keys for
sRTP (which has your bearing on recommendation #6). The statement that SASL
should be used for 'compatibility with the other IETF messaging protocols'
strikes me as a little odd, given that CPIM MSGFMT was designed to provide
precisely that, and was specified in the IMPP WG to allow compatibility
between IETF instant messaging systems based on different technologies. It's
also worth noting that interworking between various IETF messaging protocols
will almost certainly entail the presence of gateways, which suggests that
an end-to-end security solution like S/MIME MSGFMT would be more suitable
than a transport security system.

Does that make sense, and persuade? This isn't to say that I imagine
everything above to be obvious from the text of the draft today; we may need
to make further clarifications beyond the applicability statement to get
this across. But does the underlying story work, in your opinion?

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Robert Sparks [mailto:[e-mail]]
> Sent: Wednesday, September 08, 2004 8:21 AM
> To: [e-mail]
> Cc: Ted Hardie; [e-mail]
> Subject: [Simple] Security Review of
> draft-ietf-simple-message-sessions-07
> 
> 
> 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
> 

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