On Apr 14, 2008, at 11:54 AM, Eric Rescorla wrote: > > >> Let's reduce this to what I see as the simplest use case: Alice calls >> Bob through a single domain proxy server that is also an RFC 4474 >> authentication service. >> >> Alice----->---PAS----->Bob >> >> Typically, Alice sends an INVITE along with key fingerprint and >> normal >> SDP, PAS slaps authenticates her and sticks on an Identity header >> signing her INVITE, and sends it to Bob. Bob 200s with SDP and a key >> fingerprint. DTLS happens, Alice and Bob compare the key presented in >> DTLS with the key fingerprint sent in SDP, and everybody is happy. >> >> But what if PAS were evil? > > I don't understand the relevance of this use case: the basic premise > of DTLS-SRTP authentication (and of RFC 4474) is that the AS is > trusted. I don't merely mean that we rely on them; I mean that they > control the namespace.
It's there as an example on what the responsibilities of the devices are and how the protocol functions. > > > >> Assume a more complex case, where each of Alice and Bob have their >> own >> PAS, and an evil proxy EP sits in the middle. >> >> >> Alice------>PASA------EP------->PASB-----Bob >> >> Here, Alice sends an INVITE with fingerprint and PASA signs it. EP >> passes the request to PASB, which passes it to Bob. Bob replies >> with a >> 200 OK with fingerprint. Note that Bob's 200 OK cannot have an >> identity signature over that fingerprint, since RFC 4474 doesn't work >> on responses. PASB forwards this on to EP, which replaces the SDP and >> fingerprint. Alice then DTLS handshakes with EP, and is quite happy. >> Bob starts to handshake with EP, but since EP isn't in possession of >> Alice's cert, Bob detects the miskey and realizes the call has been >> intercepted. The protocol works against the attack, because Alice's >> fingerprint was integrity protected by PASA and could not be modified >> by EP. > > Once again, I think you're thinking about this as a DTLS-SRTP issue, > but that's fundamentally wrong. It's not about DTLS-SRTP at all, > it's about endpoint authentication. No, it's about using key fingerprints to determine whether or not an MITM has intercepted the media. A fingerprint in the signaling is enough to detect a MITM who operates purely on the media path. But a MITM may attack the signaling as well. We therefore integrity protect the fingerprint in the signaling using an RFC 4474 signature. If you have a fingerprint that is not integrity protected, then an MITM who influences the signaling can introduce a media relay and intercept the media. > > > At the completion of the SIP exchange (never mind the media) in > the above example, the parties have the following information: > > - Bob knows he has received a call from Alice (authenticated > by RFC 4474) > - Alice knows she tried to call Bob and got someone, but has > absolutely no idea who. I'm with you here. > > > If Alice wants cryptographic endpoint authentication of the called > party, she needs to insist on RFC 4916. Again, this has nothing > to do with DTLS-SRTP. It's just the logic of the SIP authentication > framework. Right. But that's not the problem -- can either Alice or the party she;s talking to (who may or may not be Bob) detect that an attacker has tapped the call? With a fingerprint, they can. Without a fingerprint, they can't. So if the attacker is able to influence the signaling to change the fingerprint, they can't. > > > To see this, consider that even though Bob's UA has detected > the attack and hung up the phone, Alice is still talking to > EP and there is no cryptographic way for her to tell she's > not talking to Bob. That's true. Of course, assuming we're only talking a "phone tap" and not an impostor, Bob could say "Gee Alice, it looks like we have no security on this line, so contact me by some other means" and hang up. Or Bob could employ an out-of-band mechanism to talk to Alice. > > > Now, there are multiple ways to imagine implementations handling these > issues. One way is through UI. Bob's UA would be justified in putting > up some sort of "caller ID verified" icon linked to the RFC 4474 > info. Alice's would have have an "unverified" icon. Another way would > be for Alice to instruct her UA that this call required 4916 and that > it should hang up if it didn't get it. (Admittedly, this would work > better if RFC 4474 could just be used with the OK). > > >> But let's replace Alice with a gateway. This is basically the case >> from 8.4 of draft-ietf-sip-dtls-framework -- "Single-Sided- >> Verification" done backwards, with no integrity protection on the >> forward channel (GW to BOB). The 8.4 case has no verification in the >> other direction. >> >> >> GW------>PASA------EP------->PASB-----Bob >> >> >> GW sends an INVITE containing SDP and fingerprint to PASA. Since GW >> is >> a gateway, PASA cannot add an Identity header that provides integrity >> protection for the fingerprint. PASA forwards the request to EP. EP >> replaces the SDP and fingerprint ands sends it on to PASB. PASB sends >> the request to Bob, who generates a 200 OK with fingerprint and SDP >> then sends the request back to PASB. Since this is a response, PASB >> cannot add an Identity header. EP then replaces the SDP and >> fingerprint. and sends the response on through PASA to GW. GW and Bob >> then each DTLS handshake with EP, and the dirty deed is done. > > Where this has gone wrong is that it's not in fact single-sided > autentication: it's unauthenticated communication. Neither side > has required that the other side authenticate itself. So, of > course it's subject to MITM attack. > And that's exactly the scenario we get when a call comes from a PSTN gateway, because 1) we can't RFC 4474 sign a phone identity coming through an gateway, and 2) we can't RFC 4474 sign a response. There's no authentication at either and, and consequently no way to integrity protect the key fingerprint. > >> Surely Bob could then offer connected-identity and send an UPDATE or >> reINVITE along with integrity protection back through the chain to A. >> EP could delay this or discard it, and by the time things have timed >> out, GW and Bob have been talking for a long time with their media >> intercepted. > > It's not Bob's job to enforce this. It's Alice's, or rather her > UA's. It's Bob's job to do 4916, but Alice needs to check that > she's talking to the right person or else no security mechanism > can work. The questions of "who you are talking to" and "has a 3rd party modified the signaling between you and the party you are talking to" are independent. > > >> While there are a lot of ways one could precondition this thing to >> death, the easiest fix is to eliminate this scenario by finding a way >> to apply integrity protect the initial INVITE from GW. The simplest >> approach I can see to doing that is to tweak RFC 4474 so that it can >> be applied to PSTN gateways. > > I have no idea what this actually means, but in any version of it > I can conceive, it doesn't do anything useful. One could use security preconditions with connected-identity to establish no media flow until RFC 4474 identity exchange has occurred in both directions. But it is MUCH EASIER To just allow PASA to put an Identity header on the call from the gateway. > > > 1. If Alice really cares who she is talking to, she *must* require > authentication of the person on the other end of the connection, > whether by 4916, an extended 4744, S/MIME, or by some alternate > mechanism (e.g., PINs over the channel). Whether or not Alice > sends her ientity to the other side or not is totally irrelevant > to this question, as indicated above. > > 2. An RFC 4474 signature from the PSTN gateway doesn't do anything > useful for Bob unless Bob can trust the *identity* claimed > in that signature. Again, this isn't about DTLS-SRTP, but > purely about the semantics of the PSTN. Not true. Bob's trust of the key fingerprint is based on his trust not of the identity presented in the From:, but on his trust of the identity creating the RFC 4474 Identity signature. > Say, for the sake of argument, that Alice's GW *did* sign > with [EMAIL PROTECTED] This stops EP from changing > the fingerprint while retaining the signature, but it just > inserts its own fingerprint, changes the identity to > [EMAIL PROTECTED], which it does own, and resigns. The > problem here is that Bob has no way of a priori knowing that > there is any important difference between these two identities, > and so he's not really doing endpoint auth. That presumes that Bob trusts signatures from ep.com. Does he have reason to so trust? Can he even validate the signature from ep.com? Assuming that this fools Bob into accepting the call, will Bob and Alice discover the deception when he says "Gee, Alice, normally you call me from example.com. HAve you changed to a new provider?" > > > Note, however, that this is a consequence of only looking at > the LHS. If Bob's UA was configured to show "Alice" > for [EMAIL PROTECTED] and "Unknown" for [EMAIL PROTECTED] > (e.g., via an address book) then this would all work fine. > > So, absent some way for Bob (the RP) to know which AS should be > signing a given E.164 number, I don't see any useful change to > RFC 4474 that helps against this class of attack. > Once again, all that Bob is really looking at here is the RHS, especially if he he's been told to ignore the LHS through some sort of flag. > >> RFC 4474 in responses would also be >> darned useful. > > I agree with that. > > > I'd like to just recap the basic security logic of authenticated > channels. > > 1. If both sides require the other side to authenticate, then > integrity attacks are not possible. > 2. If Alice requires Bob to authenticate but not vice versa, > than an attacker can pose as Alice to Bob, but cannot > pose as Bob to Alice. This is *not* a MITM attack because > Alice cannot be attacked, only Bob. > 3. If neither side requires the other to authenticate, then > you can have an MITM attack. > > > Where I think your analysis is wrong is principally in two respects: > > 1. A verified attestation of a meaningless identity is not a useful > form of authentication. Thus, it's useless for Bob to have a 4474 > signature from the PSTN gateway unless he knows that that E.164 > number can only be signed by that gateway. If he will accept as > equally valid a signature from any GW (and importantly, treat those > two entities as the same), then he is not in fact requiring > authentication in any meaningful way. Above, you're treating as > single-sided authentication cases which really are unauthenticated. > Well, if Bob accepts signatures from just any old domain, he's certainly screwed. > 2. If you, as one side of the conversation, wish to know who you are > talking to, you need to enforce it yourself. You can't get it as a > side effect of offering your own credentials. As I've repeatedly said, the problem is not in knowing who you;re talking to. It's in knowing whether somebody else is listening in. -- Dean _______________________________________________ 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
