Re: [hybi] -09: security considerations

Iñaki Baz Castillo <ibc@aliax.net> Mon, 20 June 2011 08:40 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 972C111E80D9 for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.66
X-Spam-Level:
X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=0.017, 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 bxh7fzcztxCq for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:40:33 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A307111E8102 for <hybi@ietf.org>; Mon, 20 Jun 2011 01:40:33 -0700 (PDT)
Received: by qyk9 with SMTP id 9so1617796qyk.10 for <hybi@ietf.org>; Mon, 20 Jun 2011 01:40:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.7.212 with SMTP id e20mr3707716qce.192.1308558858218; Mon, 20 Jun 2011 01:34:18 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Mon, 20 Jun 2011 01:34:18 -0700 (PDT)
In-Reply-To: <BANLkTimq2CiSjiS=+yiLmhg9yxACgAZViA@mail.gmail.com>
References: <4DFB8571.4090802@stpeter.im> <BANLkTinuHWwwbXs8b+K9=vN+M=2ZDyy0CQ@mail.gmail.com> <BANLkTim+YUp20v9-8uQVoCV9--gMA4wqLA@mail.gmail.com> <BANLkTinE7VZTZDyyMfw3CZSMevHw-GqTWw@mail.gmail.com> <BANLkTimq2CiSjiS=+yiLmhg9yxACgAZViA@mail.gmail.com>
Date: Mon, 20 Jun 2011 10:34:18 +0200
Message-ID: <BANLkTi=VpkfgVLvNzZZPNC79MTWtzKweNQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Diogo Pereira <diogo.pereira@ist.utl.pt>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] -09: security considerations
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: Mon, 20 Jun 2011 08:40:34 -0000

2011/6/20 Diogo Pereira <diogo.pereira@ist.utl.pt>pt>:
> 2011/6/20 Greg Wilkins <gregw@intalio.com>om>:
>> Also HTTP has BASIC and DIGEST authentication, while WS does not
>> (although it could very easily support these).
>
> I think this is implicitly allowed:
>
>  "1.  If the status code received from the server is not 101, the
>       client handles the response per HTTP procedures." (p. 30)
>
> So in response to a 401 the client could resend the handshake request
> with an Authorization header.

The question is: should the browser prompt the human user for
user/pass as when a 401 is received before accessing to a web page?

Imagine this case:


- www.domain.org => 1.1.1.1:80

- ws.domain.org => 1.1.1.2:443

- I open http://www.domain.org in my browser, fill some login form and
retrieve websocket connection data, including an user and pass (for
Digest).

- My JavaScript is then provisioned (via JavaScript WebSocket API
????) with ws connection data: server ip, port, Digest user/passwd.

- My web browser starts the ws connection with ws.domain.org:443. It
receives 401 with Digest (so I need a nonce from the server before
using my user/passwd).

- JavaScript code automatically accepts the Digest chanllenge,
generates a Digest response with the provided user/passwd and the
retrieved Digest nonce, and re-send the HTTP GET request (all of this
without prompting the user).

- If the JavaScript code would not be proviosioned with user/pass,
then upon receipt of the 401 it should prompt the user.



So, if all this stuff is not clearly specified (and I think passing
user/pass to the JavaScript WebSocket connection API does not exist)
then using HTTP Digest (or Basic) will be not useful or feasible, and
I expect than using cookies and all that "pure just-web stuff" will be
the only way. Please, take into account that a websocket server could
run in a separate server, so using cookies mechanism is not so
feasible. Neither I think that cookies (a workaround to simulate
sessions in HTTP protocol) are the best way to go.

IMHO the draft should do much more effort in authentication process.
Please don't let the door open to ugly and/or propietary
authentication solutions.


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