Re: [rtcweb] More on authorization and endpoint authentication
Eric Rescorla <ekr@rtfm.com> Fri, 05 August 2011 13:41 UTC
Return-Path: <ekr@rtfm.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 2AA0721F8B80 for <rtcweb@ietfa.amsl.com>; Fri, 5 Aug 2011 06:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSM5ujuIKlHJ for <rtcweb@ietfa.amsl.com>; Fri, 5 Aug 2011 06:41:58 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB8B621F8B29 for <rtcweb@ietf.org>; Fri, 5 Aug 2011 06:41:57 -0700 (PDT)
Received: by wyg8 with SMTP id 8so1310806wyg.31 for <rtcweb@ietf.org>; Fri, 05 Aug 2011 06:42:12 -0700 (PDT)
Received: by 10.227.172.73 with SMTP id k9mr1929192wbz.30.1312551732101; Fri, 05 Aug 2011 06:42:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.63.11 with HTTP; Fri, 5 Aug 2011 06:41:52 -0700 (PDT)
In-Reply-To: <BLU152-W15D1D8903A1053AA4D74B9933C0@phx.gbl>
References: <CABcZeBM2hgNkBgvB=8uw_CKuQ+=F=TPBtJq16SyvQ=SKPNVY+A@mail.gmail.com> <BLU152-W15D1D8903A1053AA4D74B9933C0@phx.gbl>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 05 Aug 2011 06:41:52 -0700
Message-ID: <CABcZeBOTtF4rz7X2tmumwCL85v2k-ghzagYD4_F204Su-KVKtw@mail.gmail.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] More on authorization and endpoint authentication
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: Fri, 05 Aug 2011 13:41:59 -0000
On Thu, Aug 4, 2011 at 5:13 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote: > Eric Rescorla said: > >> P2: Allow anyone to place a call provided that it goes to >> *@ford.com. >> >> The browser evaluates this (in the simplest case) by connecting to >> ford.com's SIP server and verifying that it is indeed ford.com > > These two statements are *not* equivalent. The first statement relates to > the To: field; > the second relates to authentication of the identity of the server to which > the browser connects. > These elements are orthogonal and should not be conflated. Yes, you're right that I've elided some steps here. In order for the browser to meaningful enforce a restriction on who you can call, it needs to either (a) directly verify the endpoint, at least as far as the domain or (b) trust that the adjacency it is connected to will route messages correctly. So, what I had in mind here (again, in the simplest case) was that the browser would connect to ford.com *and* use To: foo@ford.com, thus having confidence that the message is routed correctly. Another alternative would be to connect to some trusted SIP proxy and use To: foo@ford.com. Yet another alternative would of course be RFC 4474 Identity. However, the point I was trying to make is that this is distinct from letting the Web server that provided the page route the messages itself. You might imagine not trusting the page but nevertheless be willing to allow it to provide you with an address which you can independently verify and derference. Best, -Ekr
- [rtcweb] More on authorization and endpoint authe… Eric Rescorla
- Re: [rtcweb] More on authorization and endpoint a… Bernard Aboba
- Re: [rtcweb] More on authorization and endpoint a… Harald Alvestrand
- Re: [rtcweb] More on authorization and endpoint a… Eric Rescorla
- Re: [rtcweb] More on authorization and endpoint a… Ted Hardie
- Re: [rtcweb] More on authorization and endpoint a… Igor Faynberg