On Apr 13, 2008, at 10:31 AM, Eric Rescorla wrote: > At Wed, 9 Apr 2008 23:17:38 -0500, >> > > Dean, > > I don't think that this analysis is correct. >
That's entirely possible. Thank you for helping sort it out. > First, you claim "SRTP-DTLS requires RFC 4474 (for full function)". > That's not quite correct, and I think it's worth walking through > the security analysis. > ... background elided > Now, turning to the more complicated voice case. First, the the > fingerprint and RFC 4474 signature (and the RFC 4916 counterpart) > plays the same role here as does the certificate in the ordinary TLS > handshake, namely it provides authentication for one side of the > connection. It's quite possible to have a secure connection where only > one side is authenticated, so long as the authenticated side does not > care about the other side's identity. And there are a number of such > cases, especially in B2C settings. For instance, if I call Fidelity, I > care that I'm not talking to an attacker, but they only care that they > call not be hijacked, because they're going to ask me for a PIN > anyway. This is more or less how all PSTN-based security works > now, because you can't trust CNID. More on this later. Since the call has already been authenticated (4474 provides an "authentication service", no?) Fidelity might well NOT ask you for a pin. > > > You write: > > We need to sign it, because SRTP-DTLS relies on the signature in > order > to protect the fingerprint of the media key from MITM attacks. > > This isn't quite correct. As long as one side verifies the other > side's identity, than MITM attacks get blocked, because an MITM attack > requires replacing keys in both directions with the attacker's > key. Consider the following example, in which Alice is calling Bob, > but for some reason her fingerprint isn't signed: > > > Alice Attacker Bob > ---------------------------------------------------------- > Fingerprint=X (unsigned) -> > Fingerprint=A (unsigned) -> > > <- Fingerprint=Z (signed, Bob) > <- Fingerprint=Z (signed, Bob) > > So, Bob has no reliable way of knowing Alice's identity. However, > that's not sufficient to mount an MITM attack, which required that the > attacker to replace Bob's key Z with his own key A. But he can't do > that without replacing Bob's fingerprint, which would require the > ability to sign a message from Bob [0]. > 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? Alice sends an INVITE along with key fingerprint and SDP. PAS replaces the fingerprint and SDP pointing PAS, than adds an Identity header. Bob received the INVITE, responds with a 200 OK with his own SDP and fingerprint. PAS also replaces the SDP and fingerprint in the 200 OK. Next, Alice and Bob each independently DTLS handshake with PAS, while thinking they're talking directly to each other. The call has been intercepted, and the victim's don't know. While the preceding isn't the use case for which DTLS-SRTP was built, it shows the simplest possible structure in which it can be subverted by A MITM that is abusing a position of trust. It's far more interesting to think about cases where a trust anchor hasn't turned evil. 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. 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. 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. 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. RFC 4474 in responses would also be darned useful. > > Now, let's turn to the PSTN case, the simplest of which is shown in > Figure 2 of draft-schwartz-sip-e164-ownership-01, namely, someone on > the PSTN calls someone on IP network. As has been widely noted, there > is no technical reason that the PSTN GW can't RFC 4474 sign the From > line, (though it's not clear what that means from the RP's > perspective), but even if the GW doesn't sign, we still have > significant security properties as long as it *verifies* the called > parties signature. As noted, the called parties' response can be altered by an evil proxy in the middle, since the fingerprint in the 200 OK response isn't integrity protected by an RFC 4447 identity header (meaning there is no signature!). We can't rely on identity matching, since SIP's retargeting model is likely to throw the INVITE to just about anybody. So about all the GW can do is verify that the media key fingerprint matches the media -- but since the media key fingerprint can be altered by the attacker, the only reassurance GW has is that's it is talking securely to SOMEBODY, where SOMEBODY might be an attacker, or might be a legitimate retarget. This is kind of like using single-ended TLS to secure HTTP when there's no requirement for a match between the certificate name in the response and the AOR. It doesn't work. > Moreover, since the GW doesn't really know the > caller's identity (because you can't trust the PSTN identity > assertions) this is the best set of properties one could hope for, no > matter what SIP mechanisms we create. Even if there were some > mechanism by which the GW could say "I received this over the > PSTN and the CNID said X", and the relying party trusted the > RP not to lie, it still can't believe this assertion because > the GW's information is untrustworthy. But if we had a way to provide integrity protection over the fingerprint provided by GW, we'd be better off. This has nothing to do with identifying the original caller. I see this as an unfortunate entanglement of the identity of the caller with the identity of the party generating the fingerprint. When there is a gateway involved, these identities DO NOT MATCH, but the current framework approach assumes they do (due to its use of RFC 4474). > [0] But wait, you say. In SIP we don't have any restrictions on > who the call gets retargeted to, so the attacker could just send > his own key with a (valid) RFC 4474 identity pointing to his real > identity. This is absolutely true, and either Alice (or her UI > needs) to notice this, or we need a secure retargeting mechanism, > but this is a separate technical issue. The requirement right > now is that the right identity shows up in Alice's display, and > we get that right. > The attacker doesn't have to send an RFC 4474 Identity header, because he's attacking the response, not the request, as far as the GW is concerned. And RFC 4474 doesn't protect responses. -- 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
