[RTW] Criteria for what one can do in Javascript vs what one has to do inside the browser

[Ted Hardie]

Howdy,

On Fri, Feb 18, 2011 at 6:34 AM, Jonathan Rosenberg
<jonathan.rosenberg at skype.net> wrote:
> In my view the STUN/ICE solution is most definitely proof-of-possession.
> It works under the assumption of a trusted intermediary (the web server
> and/or a network behind it). If user A wants to connect to user B, this
> connection is only permitted through an out-of-band introduction of A to B
> through the trusted intermediary. The introduction manifests in the form
> of a one time use token which is then sent directly from A to B in the
> handshake.
>
> As you say, it is unfortunate that STUN calls these "username" and
> "password" as they are not that; however as you know this is a consequence
> of the evolution of STUN from its original purpose of an unauthenticated
> NAT probing technology to a p2p handshake technique for ICE.
>

I agree that the STUN/ICE context with time-of-use creation acts pretty
close to proof-of-possession.  But the long term credential mechanism
in STUN itself (5389 version) looks much closer to a standard username
and password,
with the realm and cookie mechanism giving you the opportunity to deal in
specific durations.

The original context of my comment was in thinking through how
same-origin policies limit the options for sharing context among
servers, though,
and to think about what better options might eventually be available
without raising too
much worry for cross-site attacks.  My main point wasn't to argue about
whether STUN qualified for proof-of-possession  or not, but to say I think
proof of possession (however arrived at) is likely our best bet here.

To restate this, we're talking about the web server providing
proof-of-possession
style credentials (one time username/password or some other style)
to each party, and those parties using that as authorization to join or
setup a specific session whether the host they talk to do so qualifies
under same origin or not.  Getting that right without enabling cross-site
attacks is not going to be simple, but I think it is the best way forward.

regards,

Ted Hardie




> Thanks,
> Jonathan R.
> --
> Jonathan D. Rosenberg, Ph.D.                   SkypeID: jdrosen
> Skype Chief Technology Strategist
> jdrosen at skype.net                              http://www.skype.com
> jdrosen at jdrosen.net                            http://www.jdrosen.net
>
>
>
>
> On 2/17/11 5:36 PM, "Harald Alvestrand" <harald at alvestrand.no> wrote:
>
>>On 02/17/2011 11:20 PM, Ted Hardie wrote:
>>> I'm thinking of the URLAUTH mechanism described by LEMONADE:
>>> http://tools.ietf.org/search/rfc4467
>>>
>>> That's a limited-use proof-of-possession model for authorization, with
>>>no
>>> authentication implied (just as anyone in possession of a pawn ticket
>>> can redeem the item out of pawn).  STUN is a user-name and password
>>> model either long term or short term.  The short-term method can use
>>>some
>>> out-of-band mechanism to assign time-limited username/passwords.
>>The reason I think of this as a proof-of-possession mechanism is that in
>>the use I'm most familiar with, both the username and password are
>>random strings generated at the time-of-use; they are carried in fields
>>named "username" and "password" in SDP / Jingle, but that doesn't mean
>>they are tied to an user in the traditional sense - that's what makes
>>them "short-term".
>>
>>It would be nice if the STUN spec had called the fields something
>>different, but that's what you get from not wanting to reinvent
>>protocols all the time....
>>
>>                      Harald
>>
>>_______________________________________________
>>RTC-Web mailing list
>>RTC-Web at alvestrand.no
>>http://www.alvestrand.no/mailman/listinfo/rtc-web
>
>
>