Re: [Firebird-devel] Security protocols in Firebird (was: User Authentication - a step back)

[Aleksey K. <kar...@cm...>]

> It will be interesting to have a look, what requirements we have from
> other popular authenticators (LDAP, NTLM). But it seems that some of
> them do require interaction with client. Anyway, we propose to review
> remote protocol for v.3.0 - at least to get SSL built into it. Lets try
> to do one big change, not many small. But this new protocol requires
> really much thinking before programming.

A little background.

There are plenty of authentication mechanisms/propocols invented so far, for
example,

-- kerberos v5
-- SSL/TLS/etc
-- NTLM
-- MD5 and other digest
-- others, including plain text password and no security.

Not all of them support data encryption and sealing, but many do.

In fact, LDAP isn't itself a authentication mechanism, it's just a Directory
Service (an access protocol to a directory service). Moreover, in order to
access LDAP directory, a client must authenticate itself to a LDAP server
using some method. So LDAP can be discussed as a storage for users entities,
recognized by the server, as ISC4.GDB is used for now.

Kerberos/NTLM use so called "third-party trust" ("shared secret" concept)
and widely used in local networks. One more server must be present on the
network, that both authenicating parties trust to (domain controller in case
of NT domain model).

SSL requires no trusted third party available on the run-time but uses
Public Key Infrastructure to check validity of certificates used.

These protocols have many different implementations, some better some worse,
however, the key question is interoperability of different implementations.

Inspite these protocols have entirely different internal algorithmic
details, the interface between an application willing to authenticate and a
security service, is common! So some clever people introduces unified
interface of commuticating between a security service and applications. That
interface is GSS-API (Generic Security Service API,
http://www.ietf.org/rfc/rfc2078.txt). Microsoft has its own variation,
called SSPI (Security Service Provider Interface) which syntactically
differ, but practically is the same thing.

Microsoft implementation of SSPI interfaces is most wide, and includes,
mostly importantly, Kerberos and SSL implementations (as well as several
other). Kerberos implementation using GSS-API is available, for example in
MIT Kerberos package and Solaris. GSS API is also used in Java-based
applications. It is stated that Microsoft and MIT Kerberos v5
implementations using GSS API are interoperable, as far as
Microsoft-specific extensions are not used. Unfortunately, I'm not aware of
good SSL GSS-API implementation at the moment.

Having looked at proposed SASL library, it turns to be yet another layer
switching between different security mechanisms. So it solves exactly the
same problem as GSS API does, but adds another layer atop of it with
associated organizational and technical costs. Integrating SASL interface,
inho, would be no simplier than GSSAPI or SSPI.

Considering changes required to the remote protocol, there is a question of
context semantics. Besides the security interface used, context semantics is
forced by a security protocol. Context semantics are "block" and "stream".
Block context semantics used in NTLM and Kerberos protocols. The transport
layer must be able to transmit packets, preserving their boundaries. The
second problem is the block-level interface usually limits size of block.
Stream semantics (used by SSL) looks simplier, an application protocol is
seen as a sequence of bytes, boundaries don't have to be preserved by
transport layer.

Firebird Remote interface is built of layers. First, application-level
packet (such as op_prepare) is set up in the buffer to transmit. When a
buffer is full of a command, it is delivered to the remote interface as a
whole. Depending of protocol used, remote implementation may transmit a
packet in some way. For example, TCP sockets interface converts an
application packet to the stream and copies it to the network. So above
layers use 1) block semantics and 2) stream semantics. Other protocols may
natively support block semantics, however, it is unlikely today to use
protocol other than TCP (except local shared memory connection).

So it is the question, where the encryption level must lie in the Remote
Interface architecture.

And of course, it is always possible to emulate block semantics over an
protocol with stream orientation (using record lengths as XDR does),
however, I am not sure if it's a feasible solution.

Regards,
Aleksey Karyakin