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].
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
