Session PEERing for Multimedia INTerconnect (SPEERMINT) Security Threats and Suggested Countermeasures
RFC 6404

Note: This ballot was opened for revision 09 and is now closed.

(Gonzalo Camarillo) Yes

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Adrian Farrel) No Objection

(Russ Housley) No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2011-03-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
2.3.1.  Threats to SF Confidentiality

   o  Password cracking - the challenge-response authentication
      mechanism of SIP can be attacked with offline dictionary attacks.

Did you mean SIP Digest? If yes, please say so.

      With such attacks, an attacker tries to exploit weak passwords
      that are used by incautious users.

(Tim Polk) (was Discuss) No Objection

Comment (2011-03-02)
No email
send info
SQL injection is mentioned first in section 4. Suggest adding a quick description in section 2 somewhere.

Section 4.5 only talks about IPsec and (D)TLS. Have SIP folks given up entirely on message oriented protection?

(Dan Romascanu) No Objection

(Peter Saint-Andre) (was Discuss, No Objection) No Objection

Comment (2011-03-27 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Overall this document appears to provide a helpful summary of the relevant security issues.

Are the suggested countermeasures meant to be exhaustive? (Even I can think of additional countermeasures, such as limiting authentication attempts and obscuring certain error messages to help mitigate directory harvesting attacks.) It would be good to explain whether or not the list is exhaustive.

Regarding denial of service attacks, please expand "DoS" on first use and cite RFC 4732.

Various other acronyms are not expanded on first use (e.g., SSP).

Citations are not provided for several technologies (e.g., ZRTP).

The document contains several statements that are dubious (e.g., that scalability requirements lead SSPs to use UDP instead of TCP -- perhaps they need to write better code?) or that might not be true for much longer (e.g., that DNSSEC has not been widely deployed on the Internet -- at least qualify this by saying "at the time of this writing"). As far as I can see, these statements are not material to the recommendations provided in this document, and could be safely removed.

[this comment is from Alexey Melnikov]

In Section 2.3.1, do you mean "SIP digest" in the text about "the challenge-response authentication mechanism of SIP can be attacked with offline dictionary attacks"?

(Robert Sparks) (was Discuss) No Objection

(Sean Turner) (was Discuss) No Objection