@iluom wrote:
I would like to share a point where I was recently involved in an architecture audit review.
The initiative was device authentication by an OAuth Authentication server by using x.509 certificates.
The server exposes a REST based API for the Authentication and registration. The server has white-listed some CA's and it issues an JWT token if successfully authenticates the device. The device can use it like normal JWT access token to access resources from other resource servers.
Here the point is they (dev team) named it as "Mutual TLS Authentication"
I think it's incorrect. It's not a mutual TLS authentication. My opinion is it's simply "X.509 or Digital Certificate based Authentication of an endpoint" because theoretically a M-TLS authentication happens during TLS handshake. It’s not the case here. ...
It's simply a client certificate-based authentication which is a type of authentication mechanism used by clients to authenticate themselves to a server:
...
can anyone share your thoughts?
...
Mouli,
I recognize your frustration in the use of terminology, and agree that the dev team has mis-used the term Mutual TLS. However, I think we should go deeper into the discussion. In fact, not only is the described situations not mutual, it may also not also be TLS authentication.
Given the use of a third-entity authentication server that tissues tokens, we are no longer dealing with X.509 authentication between the two servers; we are seeing token-based authentication. This is true even it the token is verified using the X.509 certificate of the authentication server.
This situation is not TLS authentication at all.
The authentication is based on trusting that the token-issuing server has properly authenticated the entity to which it issued the token. The two trusting servers are both relying on the token issuing server; neither of them is directly authenticating the other using each server's X.509 certificate. This is a form of transitive trust (trust of a third intervening party), as opposed to direct authentication.
Next, using an X.509 certificate to establish a TLS connection is most often done in only one direction, wherein the client authenticates the signature of the server's signed token, using the server's X.509 certificate. To use mutual authentication, each server sends a signed token to the other, and both servers authenticate the received token as signed by with other server's X.509 certificate. And this process must use the X.509 certificates issued to each server, not a third party's X.509 certificate (in your example the OAuth server).
We also need to distinguish between the two uses of X.509 certificates in TLS: authentication and establishing a trusted encryption channel. Recall that very purpose of SSL and now TLS is to establish the encryption relationship, not for authentication. The most common use of TLS, to set up a client-server https link, does not really perform authentication. Instead, the client accepts the server's X.509 certificate as valid, and responds with the necessary TLS handshakes to set up the session keys for the remainder of that TLS session. Depending on the situation, it may not even be necessary for the server's X.509 certificate to be signed by a PKI CA server that the client browser trusts. I have, in the past, set up https (old SSL days) where the web server used a self-signed X.509 certificate.
Trustworthy server-to-server communication does, indeed, require mutual authentication. The means each server must authenticate to the other. Once they each agree they know and trust each other, THEN the TLS key establishment process can proceed.
So, in your case, do the two servers use the JWT tokens from the OAuth server to authenticate each other, and then use their own X.509 certificates to establish the session encryption keys? Once mutual trust has been established, it may be sufficient to use only one of the server's X.509 certificate to establish the session encryption keys.
I apologize for the wordiness, but I hope this clarifies an admittedly confusing topic that munges together X.509, OAUTH, authentication, and encryption.
