Last Call Review of draft-ietf-mmusic-sdp-cs-17
review-ietf-mmusic-sdp-cs-17-secdir-lc-weiler-2013-02-07-00
Request | Review of | draft-ietf-mmusic-sdp-cs |
---|---|---|
Requested revision | No specific revision (document currently at 23) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2013-02-01 | |
Requested | 2013-01-25 | |
Authors | Miguel Angel García , Simo Veikkolainen | |
I-D last updated | 2013-02-07 | |
Completed reviews |
Genart Last Call review of -17
by Alexey Melnikov
(diff)
Genart Telechat review of -18 by Alexey Melnikov (diff) Secdir Last Call review of -17 by Sam Weiler (diff) |
|
Assignment | Reviewer | Sam Weiler |
State | Completed | |
Request | Last Call review on draft-ietf-mmusic-sdp-cs by Security Area Directorate Assigned | |
Reviewed revision | 17 (document currently at 23) | |
Result | Has issues | |
Completed | 2013-02-07 |
review-ietf-mmusic-sdp-cs-17-secdir-lc-weiler-2013-02-07-00
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 allows SIP endpoints to negotiate the use of a circuit-switched (e.g. PSTN) channel. It presents a mechanism for correlating an incoming circuit-switched connection with a given SDP/SIP session by sending a nonce or a static string. Summary: I would like to see a stronger authentication mechanism defined to replace the static string or "plaintext password" nonce. I am content with the analysis of security weaknesses: an attacker could trick someone into initiating a potentially expensive PSTN call, and the correlation mechanism is weak. I am not content with the use of a mere nonce or static string for correlation. That is the equivalent of sending plaintext passwords, and I suspect we have better mechanisms available that could allow for mutual endpoint authentication, making it statistically unlikely for a man-in-the-middle to participate successfully in the correlation exchange. The document makes a case for using short strings/nonces (e.g. a caller-ID string or 10 DTFM digits). I suspect both that those lengths could be extended without great pain and that some stronger authentication mechanisms could work with such short strings, especially given the ability to send longer keying material in the packet-switched SDP session. Non-security observation: I'm worried that the architecture of the current correlation mechanism will have some unintended consequences. From section 5.2.3: The endpoints should be able to correlate the circuit-switched bearer with the session negotiated with SDP in order to avoid ringing for an incoming circuit-switched bearer that is related to the session controlled with SDP (and SIP). As I understand it, some of the defined variants of the correlation scheme require answering the call (e.g. the DTMF scheme) before knowing whether or not the channel corresponds to a SIP session. If it does not, then what? The call is already answered, which gives a surprising user experience. Feel free to tell me I'm off base with this one. -- Sam