Changes between Initial Version and Version 1 of Concepts-Authentication

Timestamp:

01/05/14 17:35:34 (10 years ago)

Author:

JoshC

Comment:

--

Concepts-Authentication

@@ +1 @@
+= Authentication =
+
+[[TOC(depth=3)]]
+
+This page discusses the concepts of authentication in OpenVPN.
+
+== Authentication basics ==
+
+OpenVPN needs to verify the authenticity of the remote side it is connecting to, otherwise there's no security provided at all. You don't want to let any random system connect to your VPN. Both ends authenticate the other, and the authentication must pass on both sides for a valid connection to be made.
+
+Depending on the mode and configuration, the following are possible methods to authenticate connections:
+
+* keypairs and certificates
+* username + password
+
+With TLS, the server always has its own key, an issued certificate, and the CA certificate; all clients must have a copy of this CA certificate as well. Clients can be authenticated using their own certificates, user credentials, or both at once as a form of 2-factor authentication.
+
+Note that the process of authenticating connections is available only in TLS modes. The other basic mode OpenVPN has is with a pre-shared key (PSK), and here the authentication is provided only by ownership of the symmetric key. The remainder of this page discusses authentication in TLS mode specifically.
+
+== Overview of the auth process ==
+
+The process of connecting and authenticating in TLS mode is described below.
+
+In short, the client & server exchange keypairs (although the client may be configured not to have one) and verify the presented certs. Any user credentials provided are then processed by the server. Finally, ccd files are checked and acted on. If all enabled authentication steps pass, the connection is allowed. Otherwise the connection is dropped or rejected somewhere during this process.
+
+== Authentication process details ==
+
+1. A client initiates a connection to the server
+2. The server responds by presenting its own cert chain to the client for verification:
+   A. The client uses its own copy of the CA cert to verify the received cert from the server
+   B. If this check fails, the connection is terminated
+   C. If a CRL is used by the client, the presented cert must not be listed as revoked
+3. If the client has its own keypair, then:
+   A. The client presents its cert chain to the server
+   B. The server verifies this cert against its own copy of the CA cert
+   C. If the server's verification of the client cert fails, the connection is terminated
+   D. If a CRL is used by the server, the presented cert must not be listed as revoked
+4. If the client is configured to send user credentials to the server, it does so over the now-authenticated TLS link
+5. If the server is configured to process user credentials, then:
+   A. Credentials must have been supplied by the client unless configured to make this optional
+   B. The program or plugin responsible for checking the user credentials is invoked
+   C. If the check fails, the client is told the auth was rejected and the connection is terminated
+6. If a ccd (client-config-dir) is used on the server, then:
+   A. If the named client is listed as disabled, the connection is terminated
+   B. If `ccd-exclusive` is used, then the namaed client must have a ccd entry or the connection is terminated
+7. At this point authentication by both sides is complete
+
+== Certificates vs. usernames ==
+
+Certificates are cryptographically signed by the CA, so these provide a strong level of security and authentication. By contrast, usernames are somewhat less secure given the types of passphrases often used, and the prolific re-use of same or similar passphrase.
+
+When the server is configured not to check client certificates, the entire security of the VPN relies on the security of the user credentials and the program checking them. When combined together, both valid certificates and valid credentials are required, which improves security.
+
+== Advanced authentication options ==
+
+Some advanced directives can be used in addition to the normal process. These include:
+
+=== tls-verify ===
+
+The `tls-verify` directive allows an additional program to review the presented cert's details. When `tls-export-cert` is also used, the program has access to the cert itself for any additional verification steps. Exiting non-zero causes the connection to be terminated.
+
+=== client-connect ===
+
+The `client-connect` script can also terminate a connection by exiting with a non-zero code. This script is normally used to do dynamic on-connect tasks or populate options to be pushed to the client, but it can be used as a form of authentication control using the exit code as well.