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:

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:

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:

Cleartext passwords

Some warnings about using "mechanisms" that only transmit a cleartext password, including

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:

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:

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:

Note that SASL does not protect the TCP connection. It is advisable to run SASL over TLS, because:

Public key mechanisms

At the moment, these mechanisms are only indirectly available via:

Mechanism negotiation

There are more or less two common ways how client and server negotiate a certain authentication mechanism:

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.