Re: [hybi] About authentication mechanism

Iñaki Baz Castillo <ibc@aliax.net> Wed, 29 June 2011 08:05 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752D822800F for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 01:05:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level:
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vB5PhokfCEY for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 01:05:32 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id BCCE0228006 for <hybi@ietf.org>; Wed, 29 Jun 2011 01:05:32 -0700 (PDT)
Received: by qyk29 with SMTP id 29so721953qyk.10 for <hybi@ietf.org>; Wed, 29 Jun 2011 01:05:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.44.132 with SMTP id a4mr323590qcf.287.1309334732082; Wed, 29 Jun 2011 01:05:32 -0700 (PDT)
Received: by 10.229.240.15 with HTTP; Wed, 29 Jun 2011 01:05:31 -0700 (PDT)
In-Reply-To: <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com> <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com> <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com> <CALiegf=Y-kWG7piRnbDtKeh7Edj11OtQqHVCUq4N2_D1pXG8Qw@mail.gmail.com> <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com>
Date: Wed, 29 Jun 2011 10:05:31 +0200
Message-ID: <CALiegfm8aCsnav51DC=h4DmH+F0DAJUk69D4bbv_0GtvDjw3tw@mail.gmail.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
To: ifette@google.com
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jun 2011 08:05:33 -0000

2011/6/29 Ian Fette (イアンフェッティ) <ifette@google.com>:
> Pass an oauth token,

How? within the subprotocol itself?


> or have the WS server issue some challenge that the JS
> answers

Reinventing the wheel (HTTP Digest auth) but at WS subprotocol level?
So should the JavaScript client *code* perform the challenge in pure
and custom JavaScript code? I expect *lots* of future vulnerabilities
in WS.

Unfortunately it's common in this WG not to reuse existing
technologies (neither reusing DNS SRV for good
load-balancing/failover, neither reusing any existing authentication
mechanism). This is not good IMHO.


> (or presents to the user on behalf of the server if it's really
> necessary), many ways. This is not a new problem.

Even worse, it's not a new problem but it seems that WebSocket draft
authors don't want to deal with it. WebSocket world will become a
jungle.

So, is it really possible that WebSocket will be the first
client->server protocol without, at least, one solid authentication
mechanism specified? I just can't believe it. Please, WS is not like a
DNS query. WS is supposed to carry personal and private data.

Please don't take me wrong, but IMHO some other people with experience
in Internet protocols other than HTTP should also take a look to this
draft. I don't like the WWW-style of doing things this protocol is
acquiring. The fact that WWW world is a jungle doesn't mean that any
other new protocol (even when related to HTTP) should also be jungle.


I strongly disagree with the direction this draft is taking when
coming to authentication area in WebSocket protocol.

Regards.

-- 
Iñaki Baz Castillo
<ibc@aliax.net>