[rtcweb] Identity and authorities (Re: SRTP and "marketing")

Harald Alvestrand <harald@alvestrand.no> Wed, 28 March 2012 14:42 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 83C1721E813B for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2012 07:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ALapgzmRXOpy for <rtcweb@ietfa.amsl.com>; Wed, 28 Mar 2012 07:42:25 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no []) by ietfa.amsl.com (Postfix) with ESMTP id 3BB3221E812F for <rtcweb@ietf.org>; Wed, 28 Mar 2012 07:42:25 -0700 (PDT)
Received: from localhost (localhost []) by eikenes.alvestrand.no (Postfix) with ESMTP id 7BA1C39E17A; Wed, 28 Mar 2012 16:42:24 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([]) by localhost (eikenes.alvestrand.no []) (amavisd-new, port 10024) with ESMTP id 5ET6duJa6uAw; Wed, 28 Mar 2012 16:42:23 +0200 (CEST)
Received: from [] (dhcp-5534.meeting.ietf.org []) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 0145039E088; Wed, 28 Mar 2012 16:42:22 +0200 (CEST)
Message-ID: <4F732350.3090306@alvestrand.no>
Date: Wed, 28 Mar 2012 16:42:24 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20120313 Thunderbird/3.1.20
MIME-Version: 1.0
To: Mahalingam Mani <mmanig@gmail.com>
References: <4F72D6B3.40803@bbn.com> <CAN8ZsXCtRcFG4a9MOFa-pgBBZG-yCXAJ47K4wh31JtprArgNjA@mail.gmail.com>
In-Reply-To: <CAN8ZsXCtRcFG4a9MOFa-pgBBZG-yCXAJ47K4wh31JtprArgNjA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------020302080109010309070300"
Cc: rtcweb@ietf.org
Subject: [rtcweb] Identity and authorities (Re: SRTP and "marketing")
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: Wed, 28 Mar 2012 14:42:26 -0000

Changing the subject line...

On 03/28/2012 12:55 PM, Mahalingam Mani wrote:
> On Wed, Mar 28, 2012 at 2:15 AM, Richard L. Barnes <rbarnes@bbn.com 
> <mailto:rbarnes@bbn.com>> wrote:
>     [...]
>     What I'm concerned about in the RTCWEB context is that without a
>     universal authentication/identity infrastructure, we will end up
>     *promising* a secure call, but not *delivering* it.  I haven't
>     done the analysis, but it does not seem implausible to me that
>     FireSheep-like vulnerabilities are lurking here.
> The choices of framework proposed in today's meeting still carry an 
> overall undercurrent of the same generic mechanism as a SAML-based 
> authentication and authorization.
> Even if a universal authentication infrastructure should exist - it 
> becomes a potential single point of failure (imagine that being the 
> defunct diginotar) or non-success (MS Passport).
> Too many trust-anchors (IdPs) is a problem as well for the single 
> end-user (non-enterprise). But in the end - would users prefer to go 
> with the trust-anchors they have come to associate with and have 
> gained a reputation for; or something completely new?
> Even with identity - the authoritative case proposes a <name>:<domain> 
> paradigm and in the 3rd party case too - assertions are based on 
> association of a user to domain - by an outside idP. Thus, there's 
> significant closeness in the identity form - regardless of whether it 
> is the most common RFC822 (email address), SIP URI (with a slight 
> exception of OpenID) or other URI forms.

This actually shows that the IdP proposal brings a dependency with it on 
the domain hierarchy.
This has real issues, the most important one perhaps being that domain 
identities can't be guaranteed over time; even when real-life 
organizational identities exist, it's not unusual to see the domain name 
change hands multiple times, either voluntarily (selling) or 
involuntarily (UDRP, court cases, forgetting to renew and being 

Not sure where discussion of this problem belongs; it might not be a 
problem if one never has to verify a stored identity.

I think the proposals bring significant value even in the absence of 
standardized identity verification - FireSheep is a good example, for 
instance; with HTTPS, FireSheep is powerless as long as it's not in 
cahoots with a corrupted CA - which defeats a huge subset of the set of 
potential attackers.