Authentication
Authentication
One of the bigger changes of Ocamlnet-4 is the focus on security
topics, which also includes authentication. There are now four modular
authentication frameworks:
- SASL (Simple Authentication and Security Layer). SASL focuses on
challenge/response password-checking. The IETF extended
many network protocols in order to support SASL. Among these protocols
there are SMTP, POP, IMAP, and LDAP.
- HTTP Authentication. Traditionally there were only two authentication
methods for HTTP ("basic" and "digest"), but recently the IETF paced
forward and defined not only principles for any HTTP method, but also
ported a number of SASL methods (SCRAM, updated DIGEST).
- GSSAPI (General Security Services API). This is a stricter approach
for an authentication and security framework than SASL. It is not
directly defined as a protocol, but as an API, which improves the
precision and extends the functionality. In particular, GSSAPI also
includes integrity and privacy protection of the application messages
as option. It is up to the application protocol how to adopt the API.
GSSAPI is often used for system authentication (e.g. by wrapping
the Kerberos suite), but not limited to that. Many SASL mechanisms
are also available as GSSAPI mechanisms. Note that there is some
confusion about the relationship between GSSAPI and Kerberos, and
sometimes GSSAPI is used as synonym for Kerberos. In reality, however,
GSSAPI means the API (and framework) that is used as primary API
for Kerberos. It is just not limited to it. GSSAPI is widely deployed
(e.g. MIT Kerberos and Heimdal for Linux/BSD/Unix/Windows,
and Windows integrates a version of GSSAPI with a proprietary interface
called SSPI).
Especially system-oriented protocols support the GSSAPI, e.g. SSH,
FTP, and ONC-RPC. There is also a somewhat questionable way of
using GSSAPI together with HTTP ("negotiate" method). Read more
about the GSSAPI here:
Gssapi.
- TLS (Transport Level Security). TLS is often misunderstood as a way
to encrypt TCP connections. However, this is just a consequence of
its primary purpose, namely authenticating the endpoints. Normally,
only the server is authenticated in the sense that an agency (the
trust center) approved the credentials (then called "certificate").
TLS includes options to strengthen this quite weak authentication:
Clients may only accept certain server certificates (e.g. those
with extended validation attributes, or from a certain trust center,
or with some other specific attributes). Also, it is possible that servers
authenticate clients, also using certificates. Read more about TLS
here:
Tls
Modularity
For all these frameworks, Ocamlnet defines mechanism types in a
modular way. There is a provider of the mechanism and a user (i.e. a
protocol interpreter). The user code can be written so it can generically
work with any mechanism of the expected type.
Technically, the mechanism type is usually an OCaml module type, and
the mechanism is an OCaml module. As OCaml supports first-class modules,
the mechanisms can be passed as normal function arguments to the user
code. Let us demonstrate this for the SASL mechanism SCRAM:
- SASL mechanisms are defined as this module type:
Netsys_sasl_types.SASL_MECHANISM
- The SCRAM mechanism is available for several frameworks. For SASL,
there is the module
Netmech_scram_sasl.SCRAM_SHA1 (more precisely,
this is SCRAM with SHA1 as hash function).
- In this example, let us use the POP network protocol. We can use
the POP protocol interpreter together with SCRAM as follows:
let user = ... in (* see below *)
let creds = ... in (* see below *)
let client = new Netpop.connect ... in
Netpop.authenticate
~sasl_mechs:[ (module Netmech_scram_sasl.SCRAM_SHA1 ) ]
~user
~creds
client in
(* now the user is logged in and access POP objects, e.g. *)
let channel = client#retr ~msgno:0 in
...
Of course, you can also use any other SASL method together with POP.
Note however, that POP servers usually do not implement all SASL
methods, but just a subset. Because of that it is good practice to
specify several methods in the
sasl_mechs argument. The POP client
will use the first mechanism of this list that is also supported by
the server. This is called mechanism negotiation. More about that
later.
Module types:
Mechanisms:
Credentials
We've left out what to pass as user and as creds in this example.
It depends on the framework how user names and how credentials can be
expressed:
- For SASL, user names are simply UTF-8 encoded strings. Credentials
can be specified in many forms (see the separate page about
Credentials). For Ocamlnet, SASL credentials are expressed
as list of credential elements, and every element includes a type,
a value, and optional parameters:
type credentials =
(string * string * (string * string) list) list
For clients, passwords are normally given in the cleartext form:
("password", password, [])
Note that the string "password" is the element type, and must always
be literally "password", and should not be confused with the actual
password which is the second value. For servers, passwords may be
given in different forms (i.e. after applying a key derivation function),
which saves computation time. See Credentials for SASL for details.
- HTTP Authentication expresses user names and credentials in the same
way as SASL.
- GSSAPI can use several schemes for identifying users. Credentials are
opaque in the API. It is not specified how credentials look like, and
there are private mechanism-specific functions covering how to submit
and how to check credentials. This is usually no problem for system
authentication where the credentials are implicitly known (e.g. as
Kerberos tickets), but it is impractical for application-level identity
checking. In Ocamlnet GSSAPI mechanisms can be either written in OCaml,
or the system libraries can be used. In the former case, the credentials
are usually specified when the GSSAPI object is instantiated (in a
mechanism-specific way). In the latter case, there is so far no way to
specify credentials from OCaml code (but this may change in the future,
as there is a GSSAPI extension for specifying passwords).
See Credentials for the GSSAPI for details.
- TLS uses certificates as (extended) user names, and credentials are
public/private key pairs. The public key is embedded in the certificate.
Normally certificates and private keys are stored in specially encoded
files.
See Credentials for TLS for details.
Cleartext passwords
Some warnings about using "mechanisms" that only transmit a cleartext
password, including
- the HTTP "basic" authentication (or even form-based password submission)
- the PLAIN SASL mechanism
- protocol-specific login methods (e.g. for POP or FTP)
Even if TLS is enabled for the underlying transport channel, it is a very
bad idea to use such methods, simply because the server will get the
password in the clear. This allows a number of attack vectors that are
very dangerous:
- Phishing: the client is tricked into connecting to the wrong server.
This server may even have a valid TLS certificate from a trust center
(criminals are not systematically excluded here). You can only be safe
if you also deploy a strong check on the server certificate.
- The server may be compromised so that the passwords are intercepted
directly after they were sent by the client.
- As good key derivation functions are computationally expensive, password
databases cannot be protected well (it would consume too much CPU).
Cleartext passwords are like an invitation to hackers:
Don't use them
at all.
Password checking with challenge/response mechanisms
The other password-based mechanisms are much better:
- SCRAM (best and newest)
- DIGEST (widely available)
- CRAM (try to avoid)
If the client connects to the wrong server this server will not get
the password directly. The client only proves that it knows the
password without transmitting it. DIGEST and SCRAM add even more
protection:
- Both "salt" the challenges. This makes it more difficult to crack
the password if an attacker can spoof the authentication exchange.
- Both authenticate the server, i.e. the client can check whether the
server has access to the legitimate password database.
- SCRAM even implements a fairly expensive key derivation function.
The interesting point is that only the client needs to actually
run this function. The server can simply store the derived key
in the password database. If an attacker gets access to this database,
it is very hard to crack the passwords, because the attacker can
only try out passwords at a low rate.
Note that SASL does not protect the TCP connection. It is advisable to
run SASL over TLS, because:
- this encrypts the connection
- this prevents man-in-the-middle attacks (if basic server authentication
is enabled for TLS)
- this prevents subtle downgrade attacks, e.g. a man-in-the-middle
could otherwise modify the protocol stream so that a weaker authentication
scheme is used than possible
Public key mechanisms
At the moment, these mechanisms are only indirectly available via:
- TLS, or
- GSS-API system authentication (so far available, e.g. LIPKEY)
Mechanism negotiation
There are more or less two common ways how client and server negotiate a certain
authentication mechanism:
- The "relaxed" way, used for SASL and HTTP: The server offers a few
authentication options, and the client picks one.
- The "strict" way, used for GSSAPI (in the form of SPNEGO) and TLS:
There is a multi-step negotiation protocol
between client and server. Both parties can express preferences. The
protocol is protected, so that a man-in-the-middle cannot take influence
on the outcome.
The "relaxed" negotiation is unprotected, which may have a serious effect
on the overall security of the mechanism. In particular, a man-in-the-middle
can run a downgrade attack, so that client and server negotiate a weaker
mechanism than they actually support. This is in particular dangerous when
the mechanism is downgraded to a plaintext mechanism, as the attacker can
then easily sniff the password.
In particular you should keep in mind that the HTTP negotiation is always
relaxed, and that it is often not possible to turn completely off cleartext
authentication. This means that offering more secure options makes only
sense when the communication channel is secure (i.e. when TLS is on). Or
in other words: you should always use TLS when authentication comes into
play.
