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. SeeCredentials.saslfor 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.gssapifor 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.tlsfor 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.