Re: [hybi] About authentication mechanism

"Bob Gezelter" <gezelter@rlgsc.com> Wed, 29 June 2011 12:41 UTC

Return-Path: <gezelter@rlgsc.com>
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 EA87511E8071 for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 05:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 SZZ9CfJTNVvU for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 05:41:41 -0700 (PDT)
Received: from smtpoutwbe05.prod.mesa1.secureserver.net (smtpoutwbe05.prod.mesa1.secureserver.net [208.109.78.207]) by ietfa.amsl.com (Postfix) with SMTP id DEE9F21F862A for <hybi@ietf.org>; Wed, 29 Jun 2011 05:41:41 -0700 (PDT)
Received: (qmail 4179 invoked from network); 29 Jun 2011 12:41:41 -0000
Received: from unknown (HELO localhost) (72.167.218.131) by smtpoutwbe05.prod.mesa1.secureserver.net with SMTP; 29 Jun 2011 12:41:41 -0000
Received: (qmail 21918 invoked by uid 99); 29 Jun 2011 12:41:41 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 141.157.214.30
User-Agent: Web-Based Email 5.5.06
Message-Id: <20110629054140.ef1fc80126c74c6c202a919c41c7bb0b.9ab03fb9ba.wbe@email03.secureserver.net>
From: "Bob Gezelter" <gezelter@rlgsc.com>
To: hybi@ietf.org
Date: Wed, 29 Jun 2011 05:41:40 -0700
Mime-Version: 1.0
Cc: 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 12:41:44 -0000

Indeed, session control and authentication have been an ongoing weakness
in the Internet protocol suite. With all due respect to those who wrote
the original RFCs, this weakness has been at the root of far too many
security breaches. However, to be fair, the authors of the original RFCs
saw them as a demonstration, not as a foundation for a global,
mission-critical information infrastructure.

An authentication scheme is NOT (emphatically NOT) what is needed within
the WebSocket protocol. What is needed is a framework for the inclusion
of authentication at the start of a connection, with the actual details
of the authentication specified not in terms of specific algorithms, but
in terms of a framework within which a authentication scheme must fit.
In programming, this goes under a number of different names, the oldest
of which is "exit routine".

The WebSocket protocol is not an applications-level protocol, but more
of an intermediate between a transport protocol and an applications
protocol upon which other protocols (generally distributed and custom)
will be operated over. It is in this context that I noted that IMHO,
multiplexing (e.g., John Tamplin's proposal) should be part of the base
RFC, not a later add-on.

This has implications at several levels. Some servers will require
authentication merely to open a base connection. Other servers will
allow anonymous base connections, but may require various degrees of
authentication for different multiplexed subchannels. A
WebSocket-connected service for TimeofDay may be anonymous, one for
pricing data may be lightly authenticated, and yet a third for actually
performing transactions may require a strong authentication scheme. The
acceptable technology for a particular authentication must be negotiated
by both sides of the connection.

However, since the WebSocket protocol is for program-to-program use, a
pop-up type query would not be appropriate for any number of reasons.
Rather (and this is something for the WebSocket API activity in the
WHATWG group), the appropriate callbacks/events should be defined to
facilitate whatever processing is needed to facilitate authentication
(e.g., a user pop-up dialogue, computations based upon an X.509
certificate, interrogation or retrieval of data from an external device
such as a USB memory device).

In summary, the WebSocket protocol does need a framework for
authentication, and to enable interoperaability, a registry of published
authentication schemes within that framework, with provisions for local
extensions. It does not need a specific authentication scheme as part of
the specification. Any such scheme should include provisions for
unauthenticated/anonymous connections.

- Bob Gezelter, http://www.rlgsc.com