Last Call Review of draft-ietf-simple-msrp-sessmatch-
review-ietf-simple-msrp-sessmatch-secdir-lc-barnes-2010-06-20-00

Request Review of draft-ietf-simple-msrp-sessmatch
Requested rev. no specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2010-06-21
Requested 2010-06-09
Authors Christer Holmberg, Staffan Blau
Draft last updated 2010-06-20
Completed reviews Secdir Last Call review of -?? by Richard Barnes
Assignment Reviewer Richard Barnes 
State Completed
Review review-ietf-simple-msrp-sessmatch-secdir-lc-barnes-2010-06-20
Review completed: 2010-06-20

Review
review-ietf-simple-msrp-sessmatch-secdir-lc-barnes-2010-06-20

I have reviewed this document as part of the security directorate's  


ongoing effort to review all IETF documents being processed by the  


IESG.  These comments were written primarily for the benefit of the  


security area directors.  Document editors and WG chairs should treat  


these comments just like any other last call comments.






This document changes the URI matching algorithm used in MSRP.  MSRP  


sessions are typically initiated using SDP bodies in SIP.  These SDP  


bodies contain MSRP URIs that the peers use to contact each other.   


When one peer receives a request to initiate a session, he verifies  


that the URI being requested is one that he initiated in SDP, thereby  


using the URI as a shared secret to authenticate that the originator  


of the session actually received the SDP body in question.






According to the current SDP specification, this comparison is  


performed over the whole URI; this document restricts the comparison  


to the "session-id" component, omitting the host, port, and transport  


components.  The goal of the document is to facilitate a certain class  


of man-in-the-middle attack, namely to allow a signaling intermediary  


to insert a media intermediary.  The restriction on the URI comparison  


is needed in order for the media intermediary not to have to modify  


URIs in MSRP packets to reflect the modifications to URIs in SDP  


bodies performed to redirect traffic through the media intermediary.




I have a few significant reservations about this document:



This extension makes it more difficult for MSRP entities to secure  


their communications against attackers in the signaling path.  The  


current model provides a basic integrity protection, in that signaling  


intermediaries cannot redirect traffic to an arbitrary third party;  


they must at least advise the third party about how to modify MSRP  


packets.  The proposed modification would remove even this cost.   


Moreover, it raises the cost of providing integrity protection to  


messages, since Alice must now employ both integrity and  


confidentiality protections on an end-to-end basis; if her messages  


are only integrity-protected, then a proxy can remove the integrity  


protection and redirect traffic without it being observable to Alice.






The document needs to clarify what the impacts are for authentication  


in secure modes of MSRP.  In particular:


-- The distinction between "self-signed" and "public" certificates is  


inappropriate.  The proper distinction is between the name-based  


authentication in Section 14.2 of RFC 4975 and the fingerprint-based  


authentication in Section 14.4.  


-- In either case, changing the host name need not result in an  


authentication failure, since the media intermediary can simply  


authenticate as itself to both endpoints, having changed the  


respective MSRP URIs appropriately.


-- There is currently no requirement that a endpoint identity in the  


To-Path URI matches the endpoint identity authenticated at the TLS  


layer, because these two are required to be the same.  This document  


changes that assumption, and should note that these two identities can  


differ. 





The document also precludes any name-based multiplexing, where a  


single MSRP process (single IP address and port) directs requests to  


different virtual recipients based on the domain name in the To-Path  


header.  (In analogy to Host-based multiplexing in HTTP, which is very  


widely deployed.)  Since with this extension, the domain in the To- 


Path is completely unpredictable from the recipient's perspective, it  


is useless to the recipient.






The document has no backward-compatibility.  MSRP implementations that  


do not support this extension will not be able to receive MSRP  


sessions from implementations that do.   In that regard,  this  


document seems more like an new version of MSRP rather than an update.