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