doc/cha-auth.texi

   1 @node Authentication methods
   2 @chapter Authentication methods
   3 @cindex authentication methods
   4
   5 The initial key exchange of the TLS protocol performs authentication
   6 of the peers. In typical scenarios the server is authenticated to
   7 the client, and optionally the client to the server.
   8
   9 While many associate TLS with X.509 certificates and public key
  10 authentication, the protocol supports various authentication methods,
  11 including pre-shared keys, and passwords. In this chapter a description
  12 of the existing authentication methods is provided, as well as some
  13 guidance on which use-cases each method can be used at.
  14
  15 @menu
  16 * Certificate authentication::
  17 * More on certificate authentication::
  18 * Shared-key and anonymous authentication::
  19 * Selecting an appropriate authentication method::
  20 @end menu
  21
  22 @include cha-cert-auth.texi
  23
  24 @include cha-cert-auth2.texi
  25
  26 @include cha-shared-key.texi
  27
  28 @node Selecting an appropriate authentication method
  29 @section Selecting an appropriate authentication method
  30
  31 This section provides some guidance on how to use the available authentication
  32 methods in @acronym{GnuTLS} in various scenarios.
  33
  34 @subsection Two peers with an out-of-band channel
  35
  36 Let's consider two peers need to communicate over an untrusted channel
  37 (the Internet), but have an out-of-band channel available. The latter
  38 channel is considered safe from eavesdropping and message modification and thus
  39 can be used for an initial bootstrapping of the protocol. The options
  40 available are:
  41 @itemize
  42 @item Pre-shared keys (see @ref{PSK authentication}). The server and a
  43 client communicate a shared randomly generated key over the trusted
  44 channel and use it to negotiate further sessions over the untrusted channel.
  45
  46 @item Passwords (see @ref{SRP authentication}). The client communicates
  47 to the server his username and password of choice and uses it to
  48 negotiate further sessions over the untrusted channel.
  49
  50 @item Public keys (see @ref{Certificate authentication}). The client
  51 and the server exchange their public keys (or fingerprints of them)
  52 over the trusted channel.
  53 On future sessions over the untrusted channel they verify the key
  54 being the same (similar to @ref{Verifying a certificate using trust on first use
  55 authentication}).
  56 @end itemize
  57
  58 Provided that the out-of-band channel is trusted all of the above provide
  59 a similar level of protection. An out-of-band channel may be the initial
  60 bootstrapping of a user's PC in a corporate environment, in-person
  61 communication, communication over an alternative network (e.g. the phone
  62 network), etc.
  63
  64 @subsection Two peers without an out-of-band channel
  65
  66 When an out-of-band channel is not available a peer cannot be reliably
  67 authenticated. What can be done, however, is to allow some form of
  68 registration of users connecting for the first time and ensure that their
  69 keys remain the same after that initial connection. This is termed
  70 key continuity or trust on first use (TOFU).
  71
  72 The available option is to use public key authentication (see @ref{Certificate authentication}).
  73 The client and the server store each other's public keys (or fingerprints of them)
  74 and associate them with their identity.
  75 On future sessions over the untrusted channel they verify the keys
  76 being the same (see @ref{Verifying a certificate using trust on first use
  77 authentication}).
  78
  79 To mitigate the uncertainty of the information exchanged in the first
  80 connection other channels over the Internet may be used, e.g., @acronym{DNSSEC}
  81 (see @ref{Verifying a certificate using DANE}).
  82
  83 @subsection Two peers and a trusted third party
  84
  85 When a trusted third party is available (or a certificate authority)
  86 the most suitable option is to use
  87 certificate authentication (see @ref{Certificate authentication}).
  88 The client and the server obtain certificates that associate their identity
  89 and public keys using a digital signature by the trusted party and use
  90 them to on the subsequent communications with each other.
  91 Each party verifies the peer's certificate using the trusted third party's
  92 signature. The parameters of the third party's signature are present
  93 in its certificate which must be available to all communicating parties.
  94
  95 While the above is the typical authentication method for servers in the
  96 Internet by using the commercial CAs, the users that act as clients in the
  97 protocol rarely possess such certificates. In that case a hybrid method
  98 can be used where the server is authenticated by the client using the
  99 commercial CAs and the client is authenticated based on some information
 100 the client provided over the initial server-authenticated channel. The
 101 available options are:
 102 @itemize
 103 @item Passwords (see @ref{SRP authentication}). The client communicates
 104 to the server his username and password of choice on the initial
 105 server-authenticated connection and uses it to negotiate further sessions.
 106 This is possible because the SRP protocol allows for the server to be
 107 authenticated using a certificate and the client using the
 108 password.
 109
 110 @item Public keys (see @ref{Certificate authentication}). The client
 111 sends its public key to the server (or a fingerprint of it) over the
 112 initial server-authenticated connection.
 113 On future sessions the client verifies the server using the third party
 114 certificate and the server verifies that the client's public key remained
 115 the same (see @ref{Verifying a certificate using trust on first use
 116 authentication}).
 117 @end itemize
 118