Howdy, On Fri, Feb 18, 2011 at 6:34 AM, Jonathan Rosenberg <jonathan.rosenberg@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@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net
On 2/17/11 5:36 PM, "Harald Alvestrand" <harald@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@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web