Re: [Sip] DISCUSS: draft-ietf-sip-dtls-srtp-frameworkdraft-ietf-sip-dtls-srtp-framework

[Eric Rescorla <[e-mail]>]

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