[RTW] Criteria for what one can do in Javascript vs what one has to do inside the browser
Bernard Aboba
bernard_aboba at hotmail.com
Fri Feb 18 16:03:15 CET 2011
To be clear, we are not talking about just any STUN exchange.
For example, an unauthenticated binding request/response doesn't prove
anything.
I think we're talking about a STUN request which is authenticated with a
username/password attribute exchanged out-of-band (e.g. via offer/answer),
and which elicits a successful response (e.g. according to the criteria in
RFC 5245 Section 7.1.3.2) with a matching transaction ID and
the nominated flag set, no?
This in turn implies that the STUN Javascript API has to provide a high
level of control of the details of the STUN request and response.
-----Original Message-----
From: rtc-web-bounces at alvestrand.no [mailto:rtc-web-bounces at alvestrand.no]
On Behalf Of Jonathan Rosenberg
Sent: Friday, February 18, 2011 6:34 AM
To: Harald Alvestrand; Ted Hardie
Cc: rtc-web at alvestrand.no
Subject: Re: [RTW] Criteria for what one can do in Javascript vs what one
has to do inside the browser
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
_______________________________________________
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