Re: [hybi] About authentication mechanism

["Bob Gezelter" <[e-mail]>]

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