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

[Samuel Weiler <[e-mail]>]

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