Hi Samuel, the authors of this draft have reviewed it in order to address your comments:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-cs-18 Could you please have a look at this revision and let them know whether you are happy with it? Thanks, Gonzalo On 04/02/2013 9:08 PM, Samuel Weiler wrote: > 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 > >
