Re: [rtcweb] IdP and universal trust

Bernard Aboba <bernard_aboba@hotmail.com> Thu, 29 March 2012 12:45 UTC

Return-Path: <bernard_aboba@hotmail.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 E166921F8B14 for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 05:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.38
X-Spam-Level:
X-Spam-Status: No, score=-101.38 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
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 cYgCJY+Y4x48 for <rtcweb@ietfa.amsl.com>; Thu, 29 Mar 2012 05:45:51 -0700 (PDT)
Received: from blu0-omc4-s5.blu0.hotmail.com (blu0-omc4-s5.blu0.hotmail.com [65.55.111.144]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE1121F8AC1 for <rtcweb@ietf.org>; Thu, 29 Mar 2012 05:45:50 -0700 (PDT)
Received: from BLU0-P2-EAS10 ([65.55.111.135]) by blu0-omc4-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Mar 2012 05:45:49 -0700
X-Originating-IP: [130.129.20.41]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <blu0-P2-EAS10401F750CA9A684CE265C93480@phx.gbl>
References: <CABkgnnWwaAgF5YQ0dP45yeYetRjBuuSt2C9epHtcTcUqeRkd+g@mail.gmail.com>
Content-Transfer-Encoding: quoted-printable
From: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: text/plain; charset="us-ascii"
In-Reply-To: <CABkgnnWwaAgF5YQ0dP45yeYetRjBuuSt2C9epHtcTcUqeRkd+g@mail.gmail.com>
Date: Thu, 29 Mar 2012 14:46:22 +0200
To: Martin Thomson <martin.thomson@gmail.com>
MIME-Version: 1.0 (1.0)
X-OriginalArrivalTime: 29 Mar 2012 12:45:49.0592 (UTC) FILETIME=[DE6CD180:01CD0DA9]
Cc: Randell Jesup <randell-ietf@jesup.org>, "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] IdP and universal trust
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: Thu, 29 Mar 2012 12:45:52 -0000

There is a more basic problem here, which is that "legacy" scenarios are typically about reaching an E.164 number.   Given that IdP (or PKI for that matter) cannot be used to prove ownership of an E.164 number, such as +14255551212@example.com, it is difficult to see how identity can be provided by any mechanism for the legacy cases, and MITM attacks seem intrinsic to the scenario.  For example, +14255551212@example.com is equivalent to +14255551212@eviltwin.example.net so that first-party IdPs are not authoritative for E.164 numbers, and MITM attacks have long been acknowledged as possible within the SIP DTLS/SRTP framework (e.g. eviltwin.example.net can change the E.164 URI and resign the message via RFC 4474 without being detected).



On Mar 29, 2012, at 13:26, "Martin Thomson" <martin.thomson@gmail.com> wrote:

> On 29 March 2012 08:08, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:
>> Yeah I've been trying to figure out if there's some advantage to having a gateway be able to indicate "gateway@telco.com".com", once there is an IdP model.  I would think it's a major pita to deploy such a thing on gateways, unless there's a very popular IdP they could know everyone would trust.  It would actually be easier to just give the gateway a real TLS cert for DTLS to use, from a major CA, since gateways are the types of systems real certs would be reasonably possible to install on.
> 
> This is an important point, and I think that perhaps you missed the
> distinction. Iff third party assertions are permitted, then the
> problem that you refer to - namely, finding someone that others trust
> - is somewhat difficult.  On the other hand, it is also true that you
> can gain multiple assertions and increase the chances of finding an
> acceptable IdP.
> 
> What seems more likely is that IdPs are only going to be authoritative
> for their own domain.  The overall story is a lot easier to tell.
> This has the nice quality that you don't have to trust the IdP, you
> only have to trust their CA.
> 
> --Martin
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb