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

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

RFC4474 signatures are optional in this draft, isn't it?

I agree that RFC4474 signatures introduce end-to-end authentication that 
has the potential to counter MITM (man-in-the-middle) attacks. I thougth 
the discussions of this draft pertained to use cases without such 
end-to-end signatures.

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

Maybe. Worse, I am reluctant to trust those who claim to understand 
security issues! Protocol security issues are reasonably understandable 
after the fact, when attackers applied their skills and creativity on 
fielded implementations.

Attackers skills and creativity has the potential to create MITM schemes 
(e.g. with sophisticated application-level proxies) when end-to-end 
cryptographic authentication is missing from a protocol arrangement.


Anyway, turning more to the point of document progress, I must admit 
that the security considerations section indeed DOES refer to MITM 
("active attack") in the last paragraph of introductory section 8. I beg 
apologies for my earlier unsupported critique.

> -Ekr
> 

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