At Sun, 13 Apr 2008 13:41:09 -0400, Hadriel Kaplan wrote: > > > > -----Original Message----- > > From: Eric Rescorla [mailto:[EMAIL PROTECTED] > > > > Well, I don't know what Dean is claiming, but what *I* am claiming > > is that MITM attacks aren't possible as long as at least one side > > uses 4474/4916 and the other side checks the signature. And that > > means that at least in the case of PSTN->SIP calls, we don't > > have an inherent MITM problem. > > Although unrelated to your general point above, the PSTN->SIP case > seems a bit odd to me in practice, for two reasons: 1) What is it > you expect a PSTN GW to do differently in these cases, vs. unsigned > cases? Since the PSTN GW has no way to pass on strength indications > on the PSTN, do you expect it to automatically terminate calls which > aren't 4916 signed? Or play some announcement such as "this call is > not secure"? (and do we honestly think they'd do that?)
Well, I don't actually expect them to do either, but that's fundamentally not my problem. We're offering a higher level of security than the PSTN is. If people making calls from the PSTN want to take advantage of that, they'll need to do some ugly stuff. > A > downgrade attack is trivially possible, and leaves the PSTN GW with > no idea if the called side could have actually done 4916 or not. That's not clearly true. As I understand the situation, when this is *your* PSTN gateway, or at least has a relationship with you so that it knows where to route calls to 1234. It's quite possible it could know the capabilities of your proxy. > So > should it just assume if it gets a fingerprint which isn't signed > then there is probably a MitM? (and also not do best-effort srtp > offers) That seems to me making the best the enemy of the good. There's certainly value in unauthenticated encryption against passive attackers. > 2) You said in your email that the retargeting case is orthogonal, > and that either Alice or her UI need to notice this. But if a PSTN > GW is representing Alice, I don't see how that's possible. [this > goes back to a previous thread] I'm not sure how a PSTN GW can know > what the right domain for Bob's signature should be. The PSTN GW > only knows a phone number, period. The 4916 signature may well be > signed by a common trusted CA, but that really doesn't mean what it > does in TLS, because there is no domain name verification possible > to the PSTN GW. In other words, the GW knows it's calling > +123456789, and foo.com signed rfc4916 as sip:[EMAIL PROTECTED], > with a cert for foo.com. The common CA did verify foo.com is truly > foo.com, but so what? The PSTN GW has no idea if the 123456789 at > foo.com is the same global +123456789 that the PSTN meant to reach, > or some legitimate open phone hosting service that happens to have > usernames which collide with Fidelity's E.164, or even just another > PSTN gateway. In other words, what stops me (bad guy), from getting > an account on foo.com with that number, and redirecting calls from > PSTN GW to my account? And this has what to do with RFC 4474 or DTLS-SRTP? This is a pure routing issue: the GW needs to know what proxy to contact for phone number X. That configuration could (or could not) contain an indicator of whether 4916 is expected and what certificate should be used. -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
