Subject: [Sip] Review of draft-ietf-sip-media-security-requirements-00

From: Richard Barnes <[email-masked]>
Date: Mon, 08 Oct 2007 09:06:28 -0400

-------------------------------------------------------
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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Fries, Steffen" <[email-masked]>
Date: Thu, 11 Oct 2007 08:37:10 +0200

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.
> 
> 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.
> 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip