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

Jonathan Rosenberg jonathan.rosenberg at skype.net
Fri Feb 18 15:34:27 CET 2011


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.

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




More information about the RTC-Web mailing list