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

[Sam Hartman <[e-mail]>]

 Hi.  First I should warn you that I'm not currently on the simple
mailing list.  I'm happy to work with chairs, document authors and
other participants to answer questions about my security review, but
I'd like to ask them to address me individually as you have done.





>>>>> "Peterson," == Peterson, Jon <[e-mail]> writes:

    Peterson,> Sam,

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

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

It was certainly obvious to me that MSRP depends on a rendezvous mechanism and I did take this into account.

    Peterson,> The mapping of MSRP URLs to SIP URIs is perhaps the
    Peterson,> foremost of the related issues you raise (your
    Peterson,> recommendation #3). To really understand the reliance
    Peterson,> of MSRP on SIP, you have to look at the way SIP and RTP
    Peterson,> interact for establishing multimedia calls. In a VoIP
    Peterson,> scenario, for example, SDP contains the IP and port to
    Peterson,> which RTP will be sent - this identifies an RTP
    Peterson,> endpoint.  


Understood.  I also understood that SDP served the same purpose with
MSRP.

An MSRP URL serves the same function as an
    Peterson,> RTP IP/port; it is not intended to be a user identity
    Peterson,> as such, user identities are exchanged and authorized
    Peterson,> and so on at the SIP layer. 

I agree that one of the purposes  that MSRP URLs serve is as endpoint
locators.   I agree that they  are not usernames.

However I believe that MSRP URLs  are part of the
authentication/authorization process.  Quoting my review:

 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.   

Section 3 makes the claim that MSRP URLs are involved in
authentication:

    Alice and Bob generally choose their MSRP URLs in such a way that
    is
       difficult to guess the exact URL.  Alice and Bob can reject
    requests
       to URLs they are not expecting to service, and can correlate the
          specific URL with the probable sender. 

I believe this claim is completely accurate.  There is no way within
MSRP  to determine the identity of a message sender  other than by
having received some higher level mapping of a sip: or im: URL to an
msrp: URL.    I believe this requires you to carefully consider the
mapping of higher level URLs to msrp: URLs.  If you decide to have
this mapping  you need to consider things like how msrp: URLs are
chosen and what requirements  you have for protecting them.  You could
alternatively look at ways of changing MSRP so that your URLs are
really just locators and are not involved in authorization and
authentication.




Talk of difficulties
    Peterson,> "mapping" SIP URIs to MSRP URLs, therefore, I think,
    Peterson,> mistakes the applicability of MSRP a bit, just as I'd
    Peterson,> say if someone suggested we needed a way to "map" RTP
    Peterson,> IP/ports to SIP URIs. 

Note that I'm talking about forward mapping--going from sip to msrp,
not reverse mapping from msrp: back to sip:.  There are things you
could do to your protocol like allowing msrp: URLs in signed parts of
message/cpim content.  I'd recommend solving such problems by avoiding
them rather than by needing reverse mapping.


    Peterson,> The relationship of a SIP URI to
    Peterson,> an MSRP URL is totally transient and contingent, just
    Peterson,> as the relationship between a SIP URI and any given RTP
    Peterson,> endpoint IP/port is contingent (I may use this phone
    Peterson,> today, but some different phone tomorrow). 

I completely agree.

What binds a
    Peterson,> SIP URI to an RTP IP/port, temporarily, is SIP itself -
    Peterson,> a SIP INVITE is sent containing SDP that advertises
    Peterson,> where to send RTP. That RTP endpoint is meaningful only
    Peterson,> for the duration of the session resulting from the SDP
    Peterson,> offer/answer. The resulting binding is just as secure
    Peterson,> as SIP is - if SIP is used with integrity protection
    Peterson,> and confidentiality over the SDP body, then the binding
    Peterson,> between the identity in SIP and the RTP endpoint is a
    Peterson,> secure binding. All of this applies as well to
    Peterson,> MSRP. Without some SIP-like means of securely
    Peterson,> exchanging endpoint identifiers, then yes, the
    Peterson,> relationship between an end user's identity and an MSRP
    Peterson,> URL would be very uncertain. With the applicability
    Peterson,> more firmly in mind, though, I don't think there is
    Peterson,> really any "mapping" problem here.

There is certainly mapping here and it seems that the security
    implications and properties of the mapping are under specified.

I agree no general mechanism is required for doing this mapping other
than invite/offer.


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

You need  channel security and end-to-end security.  You are correct
    that CPIM chooses S/MIME for end-to-end security.

TLS is an appropriate solution for channel security  if you happen to
    have a TLS infrastructure available.  As your draft points out,
    this infrastructure is not particularly compatible with   MSRP in
    peer-to-peer mode.
My point about compatibility with other similar IETF protocols is at a
    different level.   Within the IETF, we have a responsibility to
    make security easy.  That means that we need to make sure that we
    minimize the number of authentication infrastructures we expect an
    organization to deploy.  If I'm an organization and I've already
    deployed IMAP and SMTP, I may decide I want to have  instant
    messaging and so I may want to deploy MSRP.  If deploying MSRP
    requires me to deploy a new authentication infrastructure,  then
    it seems like the IETF has probably done something wrong.  If MSRP
    had requirements that made it impossible to take advantages of the
    same authentication and channel security as other similar
    protocols, that would be a justification.  As far as I can tell,
    that's not the case; the only reason we cannot use these other
    authentication infrastructures with MSRP is because the SIMPLE
    working group has chosen not to specify them.

Also, note that you don't really have a binding between the identities
exchanged at the upper layer and at the MSRP layer's channel security.
The problem is that to protect against a man-in-the-middle, you need
to actually bind your authentication to the cryptographic keys.  IN
TLS, this means that one party's cert needs to be verified, for other
authentication systems you need to do something else.  So, no I don't
believe that authentication at the SIP layer leads to authentication
at the MSRP layer.  Authentication at the SIP layer can be part of
various forms of authentication at the MSRP layer.


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

Except as noted above, yes.    By the way if you feel that a
conference call would be beneficial I'd be happy to do that.

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