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
