Re: [secdir] secdir review of draft-ietf-mmusic-sdp-cs-17

[Gonzalo Camarillo <[e-mail]>]

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
> 
>