Re: DISCUSS: draft-ietf-sip-dtls-srtp-frameworkdraft-ietf-sip-dtls-srtp-framework

Eric Rescorla wrote:

>> 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. 

If the certificate is self-signed and nonetheless accepted in the
DTLS handshake, then anybody can forge a signature pretending it
comes from Alice, including the MITM attacker (auto-issued
certificates would have the same property). Or did I miss
something?

> 
> 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.
> 

This is because neither self-signed certificates (at least those that do 
not acquire the "trust anchor" status by "some other means") nor 
auto-issued certificates are allowed in SSL/TLS. Otherwise, 
impersonation is possible. Or did I miss something?

I guess the draft document might proceed only if the man-in-the-middle 
attack is referred to in the security considerations for self-signed 
certificates.

Regards,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email protected]

_______________________________________________
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