Empirische Untersuchung zur M2M-Authentifizierung

Machine-to-machine (M2M) authentication is a crucial aspect of the Internet of Things (IoT) as it enables devices to communicate securely with each other. In this empirical study, various authentication protocols were investigated, including LDAP, SAML, OAuth2 and Kerberos.

Code parts for this project can be found on GitLab.

LDAP

LDAP (Lightweight Directory Access Protocol) is a widely used directory access protocol that is used to store and retrieve information. However, it can be complex, especially when it comes to setup. Nevertheless, it offers a robust and flexible solution for authentication.

To set up the LDAP server, this instructions were used. However, as the creation of a group or user with .ldif files is very error-prone, it is recommended to install an Apache2 server and manage the accounts via the GUI (see Link). No password can be added to a user account via the GUI, which is why an additional CLI tool is required. Unfortunately, the standard configuration leads to many bugs, which is why it must be replaced by this.

• Note: If .ldif files are to be read in with the command ldapadd -x -D cn=admin,dc=example,dc=com -W -f example.ldif and the error message "ldapadd: attributeDescription "dn": (possible missing newline after line 5, entry "ou=people,dc=wfp2,dc=example,dc=com"?)" is displayed, the problem is the lines between the entries that are supposedly empty. A space or several spaces lead to this problem. Instead, \n\n is provided between the account configurations.

To use public key authentication, a key pair must first be generated. Once the key pair has been generated, it can be added to the LDAP server using the ldapadd command. The private key remains on the device, while the public key is stored on the LDAP server. During authentication, the public key is then checked against the private key on the device.

There are three different types of authentication in LDAP:

• Anonymous Authentication Mechanism of Simple Bind is used for anonymous authentication of a client. This can be useful if data should be accessible to all users. With the command ldapsearch -x -LLL -H ldap://ldap.wfp2.example.com -b dc=wfp2,dc=example,dc=com dn, for example, all entries of the LDAP server can be retrieved, allowing the structure of the groups and users to be viewed. It should be noted here that a DNS server with the domain wfp2-example.com has been set up.

ldapsearch

• In contrast to the above command, ldapwhoami -x -H ldap://ldap.wfp2.example.com -D "cn=ubuntumachine1001,ou=people,dc=wfp2,dc=example,dc=com" -W can be used to authenticate and then authorize a user in the CLI. With this command, it should also be noted that the -W parameter requires the password to be entered in extra. If -w is used instead, the password can be specified directly in the command (-w <password>). This authentication is called "Name/Password Authentication Mechanism of Simple Bind".

• The third group "Unauthenticated Authentication Mechanism of Simple Bind" allows only one user name to be entered. In this case, the password field remains empty.

ldapwhoami

With the command ldapsearch -x -H ldap://ldap.wfp2.example.com -D "cn=ubuntumachine1001,ou=people,dc=wfp2,dc=example,dc=com" -W -b "dc=wfp2,dc=example,dc=com" the user ubuntumachine1001 queries all available LDAP accounts. It should be noted here that ubuntumachine1001 is not an admin user.

ldapsearch

An M2M authentication using LDAP with the help of a password is therefore possible, but is not recommended. LDAP also provides the ability to authenticate a user using an asymmetric key. The protocol also supports challenge-response procedures.

Regarding the security of LDAP, it should be noted that with a high probability the Apache2 server has the largest chess site. Since usernames can be read out without authorization, brute force methods can be used here.

SAML

SAML (Security Assertion Markup Language) is an XML-based standard used for authentication and authorization. It has been found that SAML is difficult to set up, especially when it comes to creating your own SAML identity provider. Since this did not work with the help of various online instructions, Auth0 was used as an alternative. Auth0 is a cloud-based identity management service that offers a user-friendly interface and supports all common authentication methods (password, token, challenge-response, public-key-crypto).

An X.509 certificate is used for public key authentication in SAML. The private key remains (as usual) on the client device while the certificate is issued and deposited by the SAML Identity Provider. During authentication, the certificate is then checked against the private key on the device.

Note 1: For token-based authentication, several parameters (client_id, client_secret, audience, grant_type) must be passed. Since these have to be stored on the machine - like a password - there is no added value apart from the higher security against brute force attacks.

SAML settings

Note 2: The configuration of SAML is tedious, as there are many sources of error due to the different keys and endpoints. In addition, a lot of data is provided in each request or response, which should be processed in a production environment for security reasons.

SAML response

OAuth2

OAuth2 is an authorization framework that allows users to securely share their access to their data with third-party applications. In this context, GitHub and Auth0 were used as authorization servers. It was not possible to host the authorization server locally because there were no open source libraries available. Compared to SAML, OAuth2 is very user-friendly. Setting up the server was very quick and easy with GitHub and Auth0.

However, GitHub has the disadvantage that only the credentials for existing GitHub accounts can be used. For machine-to-machine (M2M) authentication, this means that only one password authentication is possible. Auth0, as with SAML, allows all common authentication options to be used.

In OAuth2, public key authentication is achieved by using JWT (JSON Web Tokens). A JWT contains a header that contains information about the algorithm used, and a body that contains the actual data. The header and body are then signed with the device's private key. When verifying the validity of the token, the token is verified with the public key of the device.

mTLS

mTLS (Mutual Transport Layer Security) is a method of mutual authentication that ensures that both parties exchanging information are who they claim to be by verifying that they both have the correct private key.

In detail, mTLS works very similar to the TLS protocol. However, there is an additional step before the key exchange. The client sends its public key and certificate to the server, which identifies it from the server to confirm that the request comes from a known client and has the private key that corresponds to the client's shared public key.

In contrast to TLS, an internal certification authority is required to implement mTLS. This is provided by the X.509 Certificates for all clients and servers, so that each certificate has the same root certificate. Authentication is based on this match. The root certificate is self-signed in this case. The advantage of mTLS is that various attacks, such as on-path attacks, credential stuffing, are unsuccessful.

mTLS provides more security than TLS because it verifies the identity of both the server and the client. However, it is more compute-intensive than TLS, making it less suitable for scenarios where lower latency is a priority over Zero Trust security.

Kerberos

Kerberos is a network authentication protocol based on a ticket-granting ticket system originally designed for Windows Active Directory. Kerberos can be easily set up and used in Ubuntu. However, it is important to note that Kerberos requires the use of domain names (for a "simple" configuration), which is why a DNS server must be set up in addition. For a configuration without DNS server, see Link (not tested).

For the configuration of the Kerbers server, the steps in of this manual were carried out. The client requires this library to be able to request a ticket. With the command kinit <username> a ticket can be requested from the Kerberos Key Distribution Center (KDC) and displayed with klist.

Officially, Kerberos only supports password authentication. With additional "plug-ins" this can be extended by a Challenge-Response-Process or a Public-Key Cryptography.

With regard to Kerberos, it should also be mentioned that there is the tool Kerbrute, which can read Kerberos accounts and read passwords using dictionary attacks, for example. However, Kerberos can be configured so that the account is blocked after a certain number of incorrect entries.

Finally, it is important to note that Kerberos is only used for authentication and not for managing user groups, Linux UIDs and GIDs, home directories, etc. Therefore, another network source is normally used for this information, such as an LDAP or Windows server. In addition, Kerberos user principals must be manually added to the Kerberos server so that they can log in. This can be done with the kadmin.local commands.

Fwknop

Fwknop (Firewall Knocking Operation) is a tool that allows you to control access to a server by sending "knocks" to the server to open a temporary port. This is particularly useful in environments where Zero Trust principles are applied. Unlike many other services, fwknop is a program that does not require a port, which is why it is very well protected against external vulnerabilities.

The so-called "knock" consists of exactly one IPv4 packet, which is sent to the server and dropped by it, because there is no corresponding FW rule. fwknop takes this dropped package and checks if the provided keys are valid. If these are valid, an IP-Tables rule is opened for a certain time (e.g. 5sec), in which the client has time to connect to the service. The disadvantage of fwknop is that due to the limited number of bytes in an IPV4 packet, keys such as RSA4096 do not have space among the other parameters.

This tool is basically a great idea for M2M communication. However, it must also be said that fwknop has not been further developed, which is why it only works on Ubuntu16 machines.

Summary

This empirical study has shown that there are many different ways to authenticate in M2M environments, each with its own advantages and disadvantages. It is important to consider the specific requirements and conditions of your environment in order to find the best solution for your needs.

Protocoll	Setup-Complexity	Security gaps	User-friendliness	Authentication methods	Comments
LDAP	Average	nmap <LDAP Server> has only found vulnerabilities in the Apache server (2.4.52)	CLI is not user-friendly / web interface is user-friendly	Passwords, challenge/response procedure, public key cryptography	Works well when it works once
SAML	Average	Not applicable	High user-friendliness	Passwords, Challenge/Response Methods, Public Key Cryptography	Setting up the identity provider via Auth0 worked quickly and easily
	High	N/A	N/A	N/A	the attempt to host the identity provider locally was abandoned after many failed attempts
OAuth2	Low	Not applicable	User-friendly	Passwords, Challenge/Response Methods, Public Key Cryptography	Simple setup when using GitHub or Auth0 as authorization server
Kerberos	Low	Kerbrute (brute force attacks)	User-friendly	Passwords	Simple setup, but designed specifically for Windows Active Directory
Fwknop	Average	N/A	User-friendly	Passwords, public key cryptography with keys up to 2048 bit	Simple setup, but only works in Ubuntu16

Fields marked "Not applicable" indicate that the responsibility lies with the external identity providers and not with the internal service providers.

Use-Case 1 - all machines have the same rights and are managed by a group

Using mTLS (Mutual TLS) for authentication between machines is a good idea as long as no external services are used. However, if external services are used, the certificates must be compatible to ensure successful communication.

The Zero Trust principle and Port Knocking are also suitable methods for controlling access to the machines. Access to the machines is only possible after a certain security process has been successfully completed.

Use-Case 2 - Machines are located in different locations and are managed by different groups

In this case, it is recommended to use SAML or OAuth2 to manage the identity and access rights of the machines. Both protocols allow a fine-grained configuration of the rights.

While SAML is often considered more secure due to its XML-based structure and wide use, OAuth can offer advantages due to its simplicity and ease of use, especially when it comes to managing user privileges.

The choice between SAML and OAuth2 depends on the specific requirements and available resources.