|
Packit |
549fdc |
@node Authentication methods
|
|
Packit |
549fdc |
@chapter Authentication methods
|
|
Packit |
549fdc |
@cindex authentication methods
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
The initial key exchange of the TLS protocol performs authentication
|
|
Packit |
549fdc |
of the peers. In typical scenarios the server is authenticated to
|
|
Packit |
549fdc |
the client, and optionally the client to the server.
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
While many associate TLS with X.509 certificates and public key
|
|
Packit |
549fdc |
authentication, the protocol supports various authentication methods,
|
|
Packit |
549fdc |
including pre-shared keys, and passwords. In this chapter a description
|
|
Packit |
549fdc |
of the existing authentication methods is provided, as well as some
|
|
Packit |
549fdc |
guidance on which use-cases each method can be used at.
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
@menu
|
|
Packit |
549fdc |
* Certificate authentication::
|
|
Packit |
549fdc |
* More on certificate authentication::
|
|
Packit |
549fdc |
* Shared-key and anonymous authentication::
|
|
Packit |
549fdc |
* Selecting an appropriate authentication method::
|
|
Packit |
549fdc |
@end menu
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
@include cha-cert-auth.texi
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
@include cha-cert-auth2.texi
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
@include cha-shared-key.texi
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
@node Selecting an appropriate authentication method
|
|
Packit |
549fdc |
@section Selecting an appropriate authentication method
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
This section provides some guidance on how to use the available authentication
|
|
Packit |
549fdc |
methods in @acronym{GnuTLS} in various scenarios.
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
@subsection Two peers with an out-of-band channel
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
Let's consider two peers who need to communicate over an untrusted channel
|
|
Packit |
549fdc |
(the Internet), but have an out-of-band channel available. The latter
|
|
Packit |
549fdc |
channel is considered safe from eavesdropping and message modification and thus
|
|
Packit |
549fdc |
can be used for an initial bootstrapping of the protocol. The options
|
|
Packit |
549fdc |
available are:
|
|
Packit |
549fdc |
@itemize
|
|
Packit |
549fdc |
@item Pre-shared keys (see @ref{PSK authentication}). The server and a
|
|
Packit |
549fdc |
client communicate a shared randomly generated key over the trusted
|
|
Packit |
549fdc |
channel and use it to negotiate further sessions over the untrusted channel.
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
@item Passwords (see @ref{SRP authentication}). The client communicates
|
|
Packit |
549fdc |
to the server its username and password of choice and uses it to
|
|
Packit |
549fdc |
negotiate further sessions over the untrusted channel.
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
@item Public keys (see @ref{Certificate authentication}). The client
|
|
Packit |
549fdc |
and the server exchange their public keys (or fingerprints of them)
|
|
Packit |
549fdc |
over the trusted channel.
|
|
Packit |
549fdc |
On future sessions over the untrusted channel they verify the key
|
|
Packit |
549fdc |
being the same (similar to @ref{Verifying a certificate using trust on first use
|
|
Packit |
549fdc |
authentication}).
|
|
Packit |
549fdc |
@end itemize
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
Provided that the out-of-band channel is trusted all of the above provide
|
|
Packit |
549fdc |
a similar level of protection. An out-of-band channel may be the initial
|
|
Packit |
549fdc |
bootstrapping of a user's PC in a corporate environment, in-person
|
|
Packit |
549fdc |
communication, communication over an alternative network (e.g. the phone
|
|
Packit |
549fdc |
network), etc.
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
@subsection Two peers without an out-of-band channel
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
When an out-of-band channel is not available a peer cannot be reliably
|
|
Packit |
549fdc |
authenticated. What can be done, however, is to allow some form of
|
|
Packit |
549fdc |
registration of users connecting for the first time and ensure that their
|
|
Packit |
549fdc |
keys remain the same after that initial connection. This is termed
|
|
Packit |
549fdc |
key continuity or trust on first use (TOFU).
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
The available option is to use public key authentication (see @ref{Certificate authentication}).
|
|
Packit |
549fdc |
The client and the server store each other's public keys (or fingerprints of them)
|
|
Packit |
549fdc |
and associate them with their identity.
|
|
Packit |
549fdc |
On future sessions over the untrusted channel they verify the keys
|
|
Packit |
549fdc |
being the same (see @ref{Verifying a certificate using trust on first use
|
|
Packit |
549fdc |
authentication}).
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
To mitigate the uncertainty of the information exchanged in the first
|
|
Packit |
549fdc |
connection other channels over the Internet may be used, e.g., @acronym{DNSSEC}
|
|
Packit |
549fdc |
(see @ref{Verifying a certificate using DANE}).
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
@subsection Two peers and a trusted third party
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
When a trusted third party is available (or a certificate authority)
|
|
Packit |
549fdc |
the most suitable option is to use
|
|
Packit |
549fdc |
certificate authentication (see @ref{Certificate authentication}).
|
|
Packit |
549fdc |
The client and the server obtain certificates that associate their identity
|
|
Packit |
549fdc |
and public keys using a digital signature by the trusted party and use
|
|
Packit |
549fdc |
them to on the subsequent communications with each other.
|
|
Packit |
549fdc |
Each party verifies the peer's certificate using the trusted third party's
|
|
Packit |
549fdc |
signature. The parameters of the third party's signature are present
|
|
Packit |
549fdc |
in its certificate which must be available to all communicating parties.
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
While the above is the typical authentication method for servers in the
|
|
Packit |
549fdc |
Internet by using the commercial CAs, the users that act as clients in the
|
|
Packit |
549fdc |
protocol rarely possess such certificates. In that case a hybrid method
|
|
Packit |
549fdc |
can be used where the server is authenticated by the client using the
|
|
Packit |
549fdc |
commercial CAs and the client is authenticated based on some information
|
|
Packit |
549fdc |
the client provided over the initial server-authenticated channel. The
|
|
Packit |
549fdc |
available options are:
|
|
Packit |
549fdc |
@itemize
|
|
Packit |
549fdc |
@item Passwords (see @ref{SRP authentication}). The client communicates
|
|
Packit |
549fdc |
to the server its username and password of choice on the initial
|
|
Packit |
549fdc |
server-authenticated connection and uses it to negotiate further sessions.
|
|
Packit |
549fdc |
This is possible because the SRP protocol allows for the server to be
|
|
Packit |
549fdc |
authenticated using a certificate and the client using the
|
|
Packit |
549fdc |
password.
|
|
Packit |
549fdc |
|
|
Packit |
549fdc |
@item Public keys (see @ref{Certificate authentication}). The client
|
|
Packit |
549fdc |
sends its public key to the server (or a fingerprint of it) over the
|
|
Packit |
549fdc |
initial server-authenticated connection.
|
|
Packit |
549fdc |
On future sessions the client verifies the server using the third party
|
|
Packit |
549fdc |
certificate and the server verifies that the client's public key remained
|
|
Packit |
549fdc |
the same (see @ref{Verifying a certificate using trust on first use
|
|
Packit |
549fdc |
authentication}).
|
|
Packit |
549fdc |
@end itemize
|
|
Packit |
549fdc |
|