Ekr,
Your analysis really misses the point others are making here.
This isn't a call between Alice and Bob - it is a call between
+12125551212 and +19725551313. If the identities of the two parties are
telephony ones, then RFC 4474 does not provide the same integrity
protection available to non-telephony SIP URIs, no matter how you spin
it. This is because without some new mechanism and protocol, there is
no difference between an identity assertion of:
sip:[EMAIL PROTECTED]
or
sip:[EMAIL PROTECTED]
However, there may be a small MitM difference. And this is a DTLS-SRTP
issue since it relies on integrity protection of RFC 4474 to prevent
MitM attacks, and most VoIP endpoints in the world today use telephony
identities.
Thanks,
Alan
Eric Rescorla wrote:
> At Sun, 13 Apr 2008 15:25:20 -0500,
> Dean Willis wrote:
>
>> On Apr 13, 2008, at 10:31 AM, Eric Rescorla wrote:
>>
>>> At Wed, 9 Apr 2008 23:17:38 -0500,
>>> 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.
>>
>
> But that's exactly the point I'm making. Even if you *don't* RFC 4474 sign,
> then Fidelity can ask you for a PIN, and this is still secure.
>
>
>> 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.
>
>
>
>> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
>
>> 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.
>
>
>
>
>> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
>
>> 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.
>
> 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.
>
> -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
>
>
>
_______________________________________________
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
