Hi Richard,
thank you for the detailed review of the draft. We already incorporated
suggestions and enhancements you proposed and are preparing an updated
version, which will be submitted soon.
Ciao
Steffen
> 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
>
_______________________________________________
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
