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

[Harald Alvestrand <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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 
drop-kicked).

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.