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
