Subject: Re: [hybi] About authentication mechanism

From: "Bob Gezelter" <[email-masked]>
Date: Wed, 29 Jun 2011 05:41:40 -0700

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 29 Jun 2011 15:01:28 +0200

(now correctly replying to the list address):

> unauthenticated/anonymous connections.

It makes lot of sense. I agree that an authentication framework should
be needed (better than a single authentication mechanism) and, of
course, an API for managing it from the client side.

The problem is that the WG seems not to want to cover this area at
all, and instead let the authentication process at WS subprotocol
level, leaving all the possible challenge computation at pure
JavaScript level (danger danger).

The fact that there is no broad consensus in the need of this
mechanism, neither interest, does not justify publishing the protocol
as it is. Come on WG, if nobody in the WG would care about which
encoding to use in WebSocket protocol, would the protocol born without
specifying it??? This is a protocol specification, not a FAQ, there
cannot be black holes.

-- 
Iñaki Baz Castillo
<[email-masked]>