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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf