is mTLS authentication alone considered secure for authentication

Question

We have recently engaged an external party to undertake a pen test on a recently implemented API. The API is considered internal although it itself is on AWS and is consumed from on-prem resources, the connectivity between the 2 is using multiple security devices to effectively create a single network.

The API is secured by mTLS, we do not check anything further than the validity of the client certificate. This pattern has been approved internally by our Group Security. The PKI infra is all internal and is behind a robust set of processes for issuance of certificates.

The following comment was made in the report;

While mTLS to allows the client and server to establish a secure connection with each other, it would be considered security best practice to include an additional layer of authentication or message signing to ensure that the requests have originated from a trusted source

I have never heard of this as a best practice and wanted to get the opinion of others that are likely to have more experience.

So, is mTLS alone sufficient for client authentication?

Answer 1

Summary: in your case, mTLS alone suffices for client authentication; but in principle, the pen-testers' suggestion is not invalid

Explanation: Based on the details provided in the question and your comments (here and here), this is your setup:

• there are two applications that talk to APIs
• each application has a different cert for each API that it talks to, no cert is shared between the applications and/or between an application and any two APIs
• no application acts as a proxy to other applications
• you're using mTLS as a means to authenticate the peers (clients/servers)

Since each cert is unique per application per conversation (app <-> API), it can be safely used to identify each application; there's no need for another layer of authentication.

Concerning the suggestion from the pen-testers, I'm not sure whether they based it on any info not present in your question, or they provided it as a general remark/best practice. However, in principle, there is a foundation for it:

• (m)TLS does not operate at the application (OSI) layer, which means that when it comes to application-level logging, getting authentication info per request isn't straightforward. This is a problem when it comes to incident response and forensics. Adding an application identifier that will "escord" each request, will make your life easier. This application identifier usually comes under the umbrella of authentication, because it should (ideally) be pre-approved before it's used (e.g. an API key or access token)

• there's the concept of multi-layer (or multi-level) authentication (MLA)¹. MLA suggests that you should use the same single factor authentication multiple times when a subject requests access to objects. MLA is used extensively in physical security (e.g. an employee accesses restricted building areas by using his id card to open each door leading to each restricted area, after he uses his id card to enter the building). MLA can also be used in cases where there's a TLS termination proxy between a client and an API and you implement zero trust security; there can be an initial client authentication using mTLS, but (because each client request is forwarded to the internal API) the API also has to authenticate the request origin before serving it

Nevertheless, it's clear that the last point does not apply to your case (I'm not sure about the first one, either). So, I don't see how the suggestion is relevant to your case, nor how beneficial it would be to add another layer of authentication.

---

¹ See here (link to a blog page of a company that I'm not affiliated with) and here for explanations on the concept of MLA

Answer 2

Yes, mutual TLS (mTLS) is sufficient for client authentication.

With mutual TLS, the client knows it is actually talking to the server, and the server is actually talking to the client. Both parties have to present a valid certificate. The actual security of this depends on the security of the certificate authority, how easy it is to obtain a valid certificate, and when the client and server consider a certificate valid. For example, certificate pinning can introduce further restrictions on which certificates are valid.

Some security professionals consider mTLS to be better than most other forms of authentication, such as API keys or credentials.

it would be considered security best practice to include an additional layer of authentication or message signing

This is not irrefutably true. There is no consensus that this is a security best practice.

It is perhaps a bit unclear for mTLS, but there is a consensus that single-sided TLS is secure, and you don't need additional (server) authentication or encryption on top of TLS. However, a number of incidents has also shown that it is hard to run a secure CA.

Answer 3

IMHO this can be an infrastructure question. Where is the list of valid client CAs? If it resides in a file on an external machine, could a rogue admin add an additional CA there? If the answer is yes, then despite the robustness of mTLS, you have a possibility of attack by adding new clients.