At Thu, 06 Nov 2008 10:04:43 -0500, Suresh Krishnan wrote: > > Hi Eric, > Thanks for the quick response. > > Eric Rescorla wrote: > >> 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. > > I agree with everything you have said, and I this is the same > understanding I had from the draft. The case I was concerned about > involves the attacker impersonating Bob towards Alice, since he can > modify the fingerprint and the certificates, thus becoming capable of > intercepting their communications. This attack is not detectable by Bob.
But then the attacker isn't *intercepting* their communications. Alice calls Bob and ends up talking to someone but she knows that she doesn't know who. The point is you can't use this to mount an MITM attack. -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
