Subject: [rtcweb] Identity and PSTN gateways

From: Harald Alvestrand <[email-masked]>
Date: Tue, 03 Apr 2012 14:58:53 +0200

One thing that has come up repeatedly in the discussion is the claim 
that "you can't have a verified identity when you talk to someone via a 
telephone gateway" (and therefore <insert your favourite security 
mechanism here> is not needed / not an added benefit / other claim).

I think this is a fallacy.

Sure, as people have commented numerous times, telephone numbers are 
identities; they're being used as such every time someone prints them on 
a business card or a billboard.

When you're connecting via a gateway to the PSTN, the gateway operator 
gives you a guarantee that you're being connected to the right person; 
that's what gateways are for.

This makes for a fairly simple mapping to the "identity / identity 
provider" model we've been bandying about for the "full-blown" IdP / 
endpoint case:

The identity is the telephone number.
The identity provider (one of many possible ones for the number) is the 
gateway operator.

Thus - if you call a telephone number via a gateway, you would perform a 
DTLS key exchange with the gateway, and an identity verification 
exchange with the gateway operator; you would then guarantee that the 
gateway operator vouches for this being a legitimate gateway function 
that you can reach for that number.

That's just about the best guarantee you can get when talking to the 
telephone system. But if we're using the IdP + DTLS-SRTP version, the 
exchange guarantees you that:
a) nobody is listening in between you and the gateway (even if they 
snooped your signalling)
b) the gateway operator vouches for the gateway being the right gateway 
to reach that number

Seems like a little bit better than what you get with SDES. Only a little.

                        Harald

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 3 Apr 2012 15:05:26 +0200

3 apr 2012 kl. 14:58 skrev Harald Alvestrand:

> One thing that has come up repeatedly in the discussion is the claim that "you can't have a verified identity when you talk to someone via a telephone gateway" (and therefore <insert your favourite security mechanism here> is not needed / not an added benefit / other claim).
> 
> Sure, as people have commented numerous times, telephone numbers are identities; they're being used as such every time someone prints them on a business card or a billboard.
> 
> When you're connecting via a gateway to the PSTN, the gateway operator gives you a guarantee that you're being connected to the right person; that's what gateways are for.
> 
> This makes for a fairly simple mapping to the "identity / identity provider" model we've been bandying about for the "full-blown" IdP / endpoint case:
> 
> The identity provider (one of many possible ones for the number) is the gateway operator.
> 
> Thus - if you call a telephone number via a gateway, you would perform a DTLS key exchange with the gateway, and an identity verification exchange with the gateway operator; you would then guarantee that the gateway operator vouches for this being a legitimate gateway function that you can reach for that number.
> 
> That's just about the best guarantee you can get when talking to the telephone system. But if we're using the IdP + DTLS-SRTP version, the exchange guarantees you that:
> a) nobody is listening in between you and the gateway (even if they snooped your signalling)
> b) the gateway operator vouches for the gateway being the right gateway to reach that number
> 

Now we will have to separate "PSTN-emulating" gateways that accept calls to all phone numbers but play a prompt saying "You gotta be kidding me - calling a phone number?" from REAL gateways that have a connection to the PSTN world. 

Will guys connecting with SS7 have a certificate signed by the ITU as a "TRUE" PSTN provider and the voip guy in the basement next door just have a "Best effort fourth-tier PSTN service" certificate?

I think that any identity of any PSTN gateway just identifies the gateway as a server. Not as a service.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Apr 2012 15:31:33 +0200

2012/4/3 Harald Alvestrand <[email-masked]>:
> DTLS key exchange with the gateway

A super gateway like in in this figure:

  http://public.aliax.net/WebRTC/WebRTC_SIP_Interop_DTLS-EKT-SRTP.png

Taking into account that SIP-PSTN gateways into most of the SIP PSTN
providers don't support SRTP or ICE, how long will take the scenario
you mean to become real and widely adopted/implemented? IMHO 10 years.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 03 Apr 2012 15:50:43 +0200

On 04/03/2012 03:31 PM, Iñaki Baz Castillo wrote:
> 2012/4/3 Harald Alvestrand<[email-masked]>:
Real: 1 year.

Widely adopted: Just in time to see the PSTN shut down because nobody 
uses it any more :-)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Apr 2012 15:52:39 +0200

2012/4/3 Harald Alvestrand <[email-masked]>:
> Real: 1 year.
>
> Widely adopted: Just in time to see the PSTN shut down because nobody uses
> it any more :-)

Hope you are right :)

Anyhow I still want to interoperate with SIP devices, regardless they
are not boring PSTN gateways ;)

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Lu, Hui-Lan (Huilan)" <[email-masked]>
Date: Tue, 3 Apr 2012 09:11:53 -0500

It seems the same problem exists when a TURN relay is involved in an inter-browser call. The endpoints cannot verify each other's identity directly. They need to trust the relay to interconnect them and not to do anything evil, such as snooping.

Huilan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Olle E. Johansson
> Sent: Tuesday, April 03, 2012 9:05 AM
> To: Harald Alvestrand
> Cc: [email-masked]
> Subject: Re: [rtcweb] Identity and PSTN gateways
> 
> 
> > One thing that has come up repeatedly in the discussion is the claim that
> "you can't have a verified identity when you talk to someone via a
> telephone gateway" (and therefore <insert your favourite security mechanism
> here> is not needed / not an added benefit / other claim).
> >
> identities; they're being used as such every time someone prints them on a
> business card or a billboard.
> >
> DTLS key exchange with the gateway, and an identity verification exchange
> with the gateway operator; you would then guarantee that the gateway
> operator vouches for this being a legitimate gateway function that you can
> reach for that number.
> >
> Now we will have to separate "PSTN-emulating" gateways that accept calls to
> all phone numbers but play a prompt saying "You gotta be kidding me -
> calling a phone number?" from REAL gateways that have a connection to the
> PSTN world.
> 
> Will guys connecting with SS7 have a certificate signed by the ITU as a
> "TRUE" PSTN provider and the voip guy in the basement next door just have a
> "Best effort fourth-tier PSTN service" certificate?
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Apr 2012 17:18:02 +0200

> The identity provider (one of many possible ones for the number) is the

The difference here is that the identity provider is not making an
authoritative statement about a namespace that it controls.  That
means that you need to trust the gateway provider.  Third-party,
non-authoritative assertions of this sort require an additional layer
of trust, which adds to their fragility.

When alvestrand.no asserts that [email-masked] is who he says he
is, then we are able to rely on that assertion because we have
identified alvestrand.no.  By definition, alvestrand.no controls that
namespace.

We could apply the same policy to a gateway and gain a lower value
assertion than the one you seek.  That is,
[email-masked] is a valid identifier within the
namespace that alvestrand.no controls, but it is fundamentally
different to [email-masked].

The only problem is that I don't know how to explain this distinction
to my grandmother any more than I could explain that
[email-masked] and [email-masked] are different
people.

> b) the gateway operator vouches for the gateway being the right gateway to

The problem here is that it requires that you trust the gateway
provider in order to believe b).

> Seems like a little bit better than what you get with SDES. Only a little.

If you can get b), then it's arguably better.  If not, then you get
the same level of assurance, though eavesdropping requires insertion
of a media gateway (which is made easier with EKT).

--Martin

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Apr 2012 17:21:06 +0200

> It seems the same problem exists when a TURN relay is involved in an inter-browser call. The endpoints cannot verify each other's identity directly. They need to trust the relay to interconnect the…

TURN relays UDP packets.  Since DTLS operates at a higher layer, it
passes through the relay unmodified.  TURN isn't a problem.

Sure, the relay can copy packets, but it is no better off than any
other on-path attacker.

--Martin

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 3 Apr 2012 15:30:38 +0000

Inaki,

I remember that you have mentioned that "WebRTC is not SIP" and "IMHO we should stop talking about SIP in this WG" and your related mail thread is http://www.ietf.org/mail-archive/web/rtcweb/current/msg02744.html.  Of course, lot of +1 for your mail ;-)

AFAIK in WebRTC, SRTP-DTLS makes more sense.  Having said that, you can prove web folks that SRTP-DTLS is not suitable for web and SDES is better :-)

Apart from this, I wish single secured RTP key-exchange mechanism for WebRTC as it reduces the number of combination in WebRTC gateways design as well.

Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Iñaki Baz Castillo
>Sent: Tuesday, April 03, 2012 7:23 PM
>To: Harald Alvestrand
>Cc: [email-masked]

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Apr 2012 17:50:18 +0200

> I remember that you have mentioned that "WebRTC is not SIP" and "IMHO we should stop talking about SIP in this WG" and your related mail thread is http://www.ietf.org/mail-archive/web/rtcweb/curren…

Sure I remember :)

And I still say the same, sure. Security is a need for WebRTC and
interop with SIP should not make it worse. But IMHO SDES-SRTP (with
the adition of secure signaling HTTPS/WSS) is a good solution, the
very same for ICE which is ***poorly*** implemented in SIP world.

Of course interoperability between WebRTC and SIP is a good point, and
that's a good reason to allow SDES-SRTP.

> AFAIK in WebRTC, SRTP-DTLS makes more sense.  Having said that, you can prove web folks that SRTP-DTLS is not suitable for web and SDES is better :-)

I don't say that SRTP-DTLS is bad, not at all. I agree that it MUST be
the preferred option for a WebRTC communication.

> Apart from this, I wish single secured RTP key-exchange mechanism for WebRTC as it reduces the number of combination in WebRTC gateways design as well.

You probably would be happy building the
Super-SIP-Media-B2BUA-DTLS-EKT-SDES-ICE-Capable-WebRTC-Gateway, but
not me ;)

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 3 Apr 2012 11:51:13 -0400

On Tue, Apr 3, 2012 at 9:05 AM, Olle E. Johansson <[email-masked]> wrote:

>
> Now we will have to separate "PSTN-emulating" gateways that accept calls
> to all phone numbers but play a prompt saying "You gotta be kidding me -
> I agree with you that you can only identify the gateway. Above this, I
think the whole discussion is pointless since there are no security
guarantees within PSTN. A million of people can be listening in. You can be
connected to a completely different number then the one you've dialed due
to LNP, call routing rules, call forwarding, or anything else. If you are
dialing internationally your traffic often goes over unsecured public
internet. So far, 99.999% of all phone calls were unsecured, tapped into,
recorded and listen by anybody who possessed even the moderate desire to do
so. If you start talking about calls coming from PSTN, you have even less
guarantees about accuracy of the caller ID information. You are currently
trying to secure the edge and provide identity on top of this mess.
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Apr 2012 17:53:47 +0200

2012/4/3 Roman Shpount <[email-masked]>:
> I agree with you that you can only identify the gateway. Above this, I think
> the whole discussion is pointless since there are no security guarantees
> within PSTN. A million of people can be listening in. You can be connected
> to a completely different number then the one you've dialed due to LNP, call
> routing rules, call forwarding, or anything else. If you are dialing
> internationally your traffic often goes over unsecured public internet. So
> far, 99.999% of all phone calls were unsecured, tapped into, recorded and
> listen by anybody who possessed even the moderate desire to do so. If you
> start talking about calls coming from PSTN, you have even less guarantees
> about accuracy of the caller ID information. You are currently trying to
> secure the edge and provide identity on top of this mess.

I don't understand why we are trying to resolve eternal PSTN problems in rtcweb.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 3 Apr 2012 11:58:14 -0400

> the preferred option for a WebRTC communication.

I actually would say that SRTP-DTLS is bad. It adds latency to call setup,
provides a bunch of features nobody needs, and does not map to SDES-SRTP
without re-encrypting the traffic. It has no deployed base and makes
interop a lot harder. Unfortunately this is the ony thing that provides
anything even remotely qualifying as secure communications right now. I
would prefer to see a new key exchange protocol designed instead of
DTLS-SRTP. I know that there is effort to patch DTLS-SRTP to fix call setup
delays, but all those patches will only make interop harder, since they
increase the number of necessary tests.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 3 Apr 2012 12:01:35 -0400

On Tue, Apr 3, 2012 at 11:53 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> think
> I do not, even though you repeatedly say that you want to fix the Internet
via WebRTC. All I am saying that the PSTN gateway cannot provide identity
on behalf of the phone number. PSTN phone number is not an identity and we
should never display something that says "You have a secure communication
with +1800YOURBANK". You can only say "You have a secure communication with
ACME Telecom Phone Gateway"
_____________
Roman Shpount

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 3 Apr 2012 18:25:46 +0200

3 apr 2012 kl. 18:01 skrev Roman Shpount:

> I do not, even though you repeatedly say that you want to fix the Internet via WebRTC. All I am saying that the PSTN gateway cannot provide identity on behalf of the phone number. PSTN phone number is not an identity and we should never display something that says "You have a secure communication with +1800YOURBANK". You can only say "You have a secure communication with ACME Telecom Phone Gateway" 

Exactly. Thanks.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Apr 2012 18:59:49 +0200

> via WebRTC.

Disallowing plain and hyper-unsecure RTP is not fixing Internet, IMHO ;)

> All I am saying that the PSTN gateway cannot provide identity on
> behalf of the phone number. PSTN phone number is not an identity and we

And for sure you are 100% right. PSTN is insecure by nature (signed: a
telco worker).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Igor Faynberg <[email-masked]>
Date: Tue, 03 Apr 2012 13:12:06 -0400

I cannot quite agree with Iñaki, although I do need to qualify this. 
(Maybe we don't disagree after all.)

POTS has been as secure as anything could be (short of attacks involving 
splicing the twisted pair or cable), but all kinds of games played with 
gateways have made it vulnerable as far as caller identification is 
concerned.  But here--at least in the US--there are strong regulations 
that protect the POTS end-points (i.e., consumers).

The major point though is that wireless networking has been sufficiently 
secure in 3G and 4G. To this end, a mobile phone with the SIM 
application is a strong authentication device, and there are many 
interesting way to bootstrap this into IdP services.  We had a very 
interesting discussion during the BrowserID session, which came I think 
very closely to this point.

Igor

On 4/3/2012 12:59 PM, Iñaki Baz Castillo wrote:
> ...

---

From: Randell Jesup <[email-masked]>
Date: Tue, 03 Apr 2012 16:00:54 -0400

> It seems the same problem exists when a TURN relay is involved in an inter-browser call. The endpoints cannot verify each other's identity directly. They need to trust the relay to interconnect the…

That shouldn't be the case if you're using DTLS-SRTP (i.e. TURN server 
doesn't decrypt/re-encrypt; if it does then it's a MITM).  If it's 
SDES-SRTP, then the TURN server could tap off the encrypted traffic for 
later analysis by whomever has the key, or be supplied with the key to 
do realtime decode-and-forward, analysis or traffic modification.

-- 
Randell Jesup
[email-masked]

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 3 Apr 2012 22:47:51 +0200

2012/4/3 Randell Jesup <[email-masked]>:
>> It seems the same problem exists when a TURN relay is involved in an
>> inter-browser call. The endpoints cannot verify each other's identity
>> directly. They need to trust the relay to interconnect them and not to do
>> anything evil, such as snooping.
>
>
> doesn't decrypt/re-encrypt; if it does then it's a MITM).

> If it's
> later analysis by whomever has the key,

And who has the key? The trusted HTTPS server.

> or be supplied with the key to do
> realtime decode-and-forward, analysis or traffic modification.

And who has the key? The trusted HTTPS server.

So what is the real problem? the trusted HTTPS server when attacked.
The *same* is true in case of DTLS-SRTP when the HTTPS server or the
identity provider (via TLS again) is attacked.

Please read the mail "On DTLS-SRTP trust model (and consideration for
SDES-SRTP)" from Fabio. DTLS is not the panacea.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Randell Jesup <[email-masked]>
Date: Tue, 03 Apr 2012 18:13:09 -0400

On 4/3/2012 4:47 PM, Iñaki Baz Castillo wrote:
> 2012/4/3 Randell Jesup<[email-masked]>:

> identity provider (via TLS again) is attacked.

Ah, but Identity Provider != Service Provider.  (It may be the same, but 
for smaller entities it wouldn't be - typically the Idp's will be "big 
sites" that act as primary email hosts, like Google.)  Yes, it's 
well-known in the discussion that if the service provider == Idp then 
the Idp can MITM you (or at least make things more complex; it may be 
possible to use key-chaining to reduce risk some).

> SDES-SRTP)" from Fabio. DTLS is not the panacea.

Nothing is.  :-)

-- 
Randell Jesup
[email-masked]