Re: [rtcweb] Identity and PSTN gateways

"Lu, Hui-Lan (Huilan)" <huilan.lu@alcatel-lucent.com> Tue, 03 April 2012 14:12 UTC

Return-Path: <huilan.lu@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A7711E80B4 for <rtcweb@ietfa.amsl.com>; Tue, 3 Apr 2012 07:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKo36OvonoSr for <rtcweb@ietfa.amsl.com>; Tue, 3 Apr 2012 07:12:04 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 10C9611E80AF for <rtcweb@ietf.org>; Tue, 3 Apr 2012 07:12:03 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q33EBuP8005026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Apr 2012 09:11:56 -0500 (CDT)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q33EBsvR020367 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 3 Apr 2012 09:11:55 -0500
Received: from USNAVSXCHMBSB3.ndc.alcatel-lucent.com ([135.3.39.136]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 3 Apr 2012 09:11:54 -0500
From: "Lu, Hui-Lan (Huilan)" <huilan.lu@alcatel-lucent.com>
To: "'Olle E. Johansson'" <oej@edvina.net>, Harald Alvestrand <harald@alvestrand.no>
Date: Tue, 03 Apr 2012 09:11:53 -0500
Thread-Topic: [rtcweb] Identity and PSTN gateways
Thread-Index: Ac0Rmndy6ZpXOf2oTYK4HxbtfSFB0AAB53rg
Message-ID: <0E96A74B7DFCF844A9BE2A0BBE2C425F098C18B89B@USNAVSXCHMBSB3.ndc.alcatel-lucent.com>
References: <4F7AF40D.3010706@alvestrand.no> <A61DB206-1B56-44B5-AADE-E4A820D76B93@edvina.net>
In-Reply-To: <A61DB206-1B56-44B5-AADE-E4A820D76B93@edvina.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Identity and PSTN gateways
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Apr 2012 14:12:04 -0000

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: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
> Olle E. Johansson
> Sent: Tuesday, April 03, 2012 9:05 AM
> To: Harald Alvestrand
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Identity and PSTN gateways
> 
> 
> 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).
> >
> > 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.
> 
> 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
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb