> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Eric Rescorla > Sent: Sunday, April 13, 2008 8:31 AM > To: Dean Willis > Cc: [email protected] List; Michael Thomas > Subject: Re: [Sip] RFC 4474 and PSTN > > At Wed, 9 Apr 2008 23:17:38 -0500, > Dean Willis wrote: > > > > > > On Apr 9, 2008, at 11:53 AM, Michael Thomas wrote: > > > > > >> Now, assume JoeBob is instead named > "[EMAIL PROTECTED]". All > > >> of the above works fine, until somebody calls into > example.com's > > >> PSTN gateway from a spoofed Caller-ID of "18005551212" > and asks > > >> said gateway to connect them to messages.example.net > > >> > > > > > > So just don't sign it. Or sign it as @example.com. Or > just tell the > > > voice > > > mail provider not to create voice mail boxes for users > with [EMAIL PROTECTED] > > > like addresses. This really seems tenuous to me, Dean. > > > > I'm getting REALLY TIRED OF EXPLAINING THIS. Yeah, I know, > one must > > say things ten time to be heard once. But this is eleven . . . ;-) > > > > 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. > > > > In short, SRTP-DTLS requires RFC 4474 (for full function), > and PSTN > > interaction precludes RFC 4474. > > > > Something has to give. As I see it, we MUST pick at least > one of the > > following: > > > > 1) Change RFC 4474 so that it can be used with phone gateways. > > 2) Change DTLS-SRTP so that it doesn't depend on RFC 4474. > > 3) Decide that we can live without integrity protection of > the media > > key on calls transiting PSTN gateways, and document this. > > > > We already have a strong argument for amending RFC 4474 so > that SBCs > > that tweak the SDP don't break the Identity signature. If > we do this, > > add the "not really an identity" flag, and mod DTLS-SRTP to > account > > for the changes, then I think we have a full solution. > > Dean, > > I don't think that this analysis is correct. > > 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. > > > Let's start by looking at a simpler case, Web security. In the > classic Web security case, the server has a cert and the client > does not. At the completion of the TLS handshake, each side > knows the following: > > - The client knows it has a secure connection to the server. > - The server knows it has a secure connection to *someone*. > > There are two very important (in fact, the most common) cases > where this is precisely what you want: > > (1) When the server does not care who the client is (for instance, > in software download, where the client cares about getting > an accurate copy but the server does not care who it gives > copies to.) > (2) When the server has some other means of authenticating the > client (for instance, when you're doing e-commerce and the > client authenticates via password or credit card). > > So, in these situations we don't ordinarily say that we're not > getting "full function" but rather that this is the design > goal. > > > 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. > > 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].
I think this analysis is optimistic regarding Alice's behavior. Taking a less optimistic approach: As shown in your diagram, Alice generates a message that is not signed (due to misconfiguration or some other reason). Due to Alice's already-defective configuration, Alice may not expect Bob's message to be signed, and thus the attacker could simply strip Bob's signature, replace Bob's a=fingerprint, and successfully be a MitM. Furthermore, Alice cannot assume that Bob implements Connected-Identity, so Alice can't really assume that Bob *will* generate a signature at all. Or do we require Connected-Identity in the DTLS framework, and require receipt of that Connected-Identity-signed message before the call is completed (using security-preconditions, perhaps)? -d > 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. > > 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. > > -Ekr > > > [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. > _______________________________________________ > 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 _______________________________________________ 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
