> Suresh Krishnan provided a Gen-ART Review on 5-Nov-2008. While it > is a bit late, I would like to see a response to the "substantial" > concern that is raised. I have not taken the time to determine if > the man-in-the-middle attack is possible, and I hope the authors > can quickly tell if there is a concern or not. If there is a > concern, it needs to be corrected or documented in the security > considerations.
I don't believe this is a serious issue. A response to Suresh's complete review is below. > Summary: This draft is almost ready for publication as Proposed Standard, but > I have a few comments. > > Substantial > =========== > > Section 8.1: Responder identity > > When Bob does not respond with an UPDATE message, his identity is > not integrity protected. Absolutely correct. > The draft states that in such case, a MITM > attacker may tamper with the fingerprint but Bob would be aware of > this. It is not clear to me how Bob would be aware of this. Consider > the scenario where an attacker Eve (who can attack both the > signaling and media paths) has switched Bob's key fingerprint with > hers. She can receive encrypted media coming from Alice, decrypt it > for her own use and re-encrypt it for Bob and send it to him. How > will Bob detect this tampering? This is a classic single sided authentication situation. If Alice calls Bob and the attacker mounts a MITM attack, then it will not be able to impersonate Alice to Bob because it can't generate the correct RFC 4474 signature. Thus, either the attacker won't provide a valid signature (being anonymous from Bob's perspective) or it will produce a valid signature with its own identity. In either case, this isn't really a useful MITM attack since Bob thinks he's talking to the attacker, not to Alice. Note the analagous situation with SSL/TLS, where the attacker can mount an MITM attack, but only with an identity that doesn't match the identity that the client expects, so it's not useful. > Minor > ===== > > * draft-ietf-avt-dtls-srtp-05 needs to become a Normative reference instead > of an informative reference. Section 6.10 has the following text > > "Implementations of this specification MUST support DTLS-SRTP" > > making it impossible to implement this spec without implementing DTLS-SRTP. > This will also lead to a downref that needs to be called out. Good catch. It won't be a downref, though, since the other draft is also going to PS. > * Section 7: Call flow with STUN > > "Message (6): STUN connectivity-check response Bob -> Alice" > > Bob is responding to Message 5 instead of Message 3 as stated in the text. > Please replace. > > Editorial > ========= > > * SBC (expand at first use) : Probably add reference to > draft-ietf-sipping-sbc-funcs-07 > > * Section 6.10: s/less highly optimized/less optimized/ > > Typos > ===== > Section 1 Para 4: s/sigaling/signaling/ > > Section 6.7.2: s/appopriate/appropriate/ > > Section 6.9 Title: s/Encryptions/Encryption/ > > Section 7 Para 3: s/especialy/especially/ > > Section 8.6 para 2: s/taht/that/ > > Appendix A.3. : s/Reusage/Reuse/ > > Appendix A.18. : s/Negotation/Negotiation/ Thanks, I'll fix these. _______________________________________________ Sip mailing list https://www.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
