Re: secdir review of draft-ietf-simple-msrp-sessmatch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I also note that the security considerations, in addition to
having some fairly disingenuous language about the impact of
this change, seems to fail to mention MSRPS URIs and what, if
any, impact this would have on them.

There are no impacts to MSRPS URIs. I assumed it would be implicitly understood since MSRPS URIs are not mentioned in the draft.

However, we could explicitly make it clear by modifying the first sentences of section 5:
	
"The change of session matching procedure does not impact the format of MSRP URIs,
	disregarding if the "msrp" scheme or the "msrps" scheme is used.
However, MSRP endpoints can only check that the session-id part of the MSRP URI..."

The conflict here is that with MRSPS authentication, the name in the certificate is checked against the domain name in the URI, which was OK when the URI in the message was required to be the same. By allowing the domain name in the message to change, this draft removes man-in-the-middle protection from MSRPS.

The document notes that a SIP MitM can already direct the user to another destination. However, if the peers use MSRPS with the current authentication scheme, the MitM will not be able to be a part of the resulting MSRPS session, since he can't authenticate as one of the endpoints. If only the session ID is used in comparisons, the MitM can patch himself in by changing the domain in the MSRPS URI. (Which actually seems to be the intended use case for this draft.)

So the current document does introduce a new MitM vulnerability to MSRPS.

--Richard
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]