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

At Thu, 06 Nov 2008 01:02:10 -0500,
Thierry Moreau wrote:

> Eric Rescorla wrote:
> > 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?

Yes. The fingerprints in the SIP messages preclude certificate
substitution.


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

But in DTLS-SRTP the fingerprints in the SIP messages (signed
via RFC 4474) substitute for the certificate chain.


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

I think you misunderstand the security issues, as discussed above.

-Ekr
_______________________________________________
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