------------------------------------------------------- Document: draft-ietf-sip-media-security-requirements-00 Reviewer: Richard Barnes, BBN Review Date: 06 September 2007 -------------------------------------------------------
1. As a document proposing requirements for a security protocol, this document needs more discussion of the system being protected and the level of protection that the desired protocol is to support. Section 5 is a good start on this, and it should be moved forward to be just after the Terminology section.
2. I think the fundamental security requirement that you're driving at is that the protocol should have a mode of operation in which an attacker must mount active attacks on BOTH the signaling and media path in order to gain access to the keys being negotiated by the protocol, and that even in this case, the attack should be detectable by the endpoints. This is essentially what's being encoded in requirements R1, R2, and R17, but this should be made clearer in these requirements, and in the security analysis section (i.e., Section 5).
3. Requirements R23, R24, R25 are inappropriate for this document, in that they conflict directly with the security requirements (R1, R2, R17). A well-designed key-exchange protocol *should* be able to detect a middle-man, authorized or not. Lawful intercept should be handled outside of the key management protocol, as in draft-wing-sipping-srtp-key.
4. This document needs several more terms defined in the Terminology. The three I spotted were: "media path", "signaling path", and "perfect forward secrecy". PFS is already defined in the requirements; this text should just be moved to the Terminology section.
5. If we intend this document to move quickly toward RFC status, it seems like the evaluation appendices will have to be deleted, or at least the parts of them that refer to protocols that are not RFCs or not on their way.
6. Section 3.1 and 3.3 do not appear to be directly related to the requirements as stated. They should be moved to sections B.2 and B.3, respectively (like the text on SSRCs and ROCs).
7. Sections C.1 and C.3 should be deleted. Section C.1. is predicated on the notion that protocols require a PKI to be used, when in reality (as was discussed extensively on rtpsec), any protocol that can be used with a PKI can be used with self-signed certificates if both endpoints are willing. Section C.3. tries to evaluate whether solutions can do best-effort security, while ignoring the work that has been done on SDP capability negotiation.
*. (nit) Throughout, the word "keying" is used to mean the process of key negotiation/exchange or key management. It should be replaced by those terms as appropriate.
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
