See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/331587509

JSON Web Token (JWT) based client authentication in Message Queuing

Telemetry Transport (MQTT)

Preprint · March 2019

CITATIONS READS

0 10,054

1 author:

Krishna Shingala
Norwegian University of Science and Technology
1 PUBLICATION 0 CITATIONS

SEE PROFILE

All content following this page was uploaded by Krishna Shingala on 01 April 2019.

The user has requested enhancement of the downloaded file.

 JSON Web Token (JWT) based client authentication
in Message Queuing Telemetry Transport (MQTT)

Krishna Shingala
[email protected]
arXiv:1903.02895v1 [cs.CR] 7 Mar 2019

August 2018

Abstract
This paper is an overview of JSON Web Token (JWT) and Transport Layer
Security (TLS) as two primary approaches for authentication of the things on the
Internet. JSON Web Token (JWT) is used extensively today for authorization
and authentication within the OAuth and the OpenId framework. Recently, the
Google Cloud IoT has mandated the use of JWT for both HTTP and Message
Queuing Telemetry Transport (MQTT) protocol based clients connecting to the
cloud service securely over TLS. MQTT is the protocol of choice in IoT devices
and is the primary focus of this paper as the application protocol. Another popular
cloud platform Amazon Web Service (AWS) uses the TLS mutual authentication for
client authentication. Any comparison provided here between the two approaches
is primarily from a constrained device client perspective.
1 Introduction
The JSON Web Token (JWT), defined by [RFC7519] enable digitally secure representa-
tion and exchange of claims between two or more parties on the internet.
The JSON Web Token (JWT) have been used in the OAuth framework for autho-
rization grants by the user of service to a third party. Such a grant enables third party
applications to have access to users resources on the service. The OAuth framework is ex-
tensively used for web and mobile phone applications, and is specified in the [RFC6749].
The use of JWT within the OAuth framework is specified in the [RFC7521].
Figure 1 demonstrates an example and simplified usage of JWT as access tokens used
by a third party application to get user authorized access to resources of another ser-
vice. Here LinkedIn is the third party application that requests access to users contacts
(resources) of the user’s Gail account.

Figure 1: Use of JWT as access tokens in OAuth

The OpenID Connect extends the OAuth, and use of JWT for authentication pur-
poses. The OpenId Connect specification is available at [OpenID].
The Google Cloud has now introduced use of JWT for an IoT protocol Message
Queuing Telemetry Transport (MQTT) for authentication. The MQTT specification is
available at [MQTT 3.1.1]. The Amazon Web Service (AWS), another popular cloud
service employs the TLS Client Certificates as the primary mechanism for authenticating
clients connecting to the IoT service. This paper discusses available mechanisms for
authentication with MQTT.

1
2 JSON Web Token
The JSON Web Token (JWT), defined by [RFC7519] enable digitally secure represen-
tation and exchange of claims between two or more parties on the internet. The claims
are described in the The JavaScript Object Notation (JSON) format. The claims can
then be encrypted, as JSON Web Encryption (JWE), or, can be digitally signed or mac
protected using the JSON Web Signature (JWS). The JWE specified in the [RFC7516].
The JWS specified in the [RFC7515]. The JSON format is specified in [RFC8259].
Figure 2 demonstrates example uses of JWT, JWS to be specific, for encoding a set
of claims. The JWS consists of three parts:
• the header, describes the primitives in JSON format used for securing the claims.

• the payload, or the body, describes the claims in JSON format.

• the signature or the message authentication code on the base64url encoded header
and the payload.

Figure 2: Use of JWT for authorization grant in the OAuth framework

Each field of the JWT is base64url encoded and separated by a ”.”. The base64url
is specified in the [RFC4648]. The issuer of the claims, described by the ”iss” field is
the SiT Cafe Elektro and the subject of the claim, described by the ”sub” field is free
lunch. Further, the time of issue of the claim, is described by the ”iat” (issued at)

2
field. Similarly, the expiration of the claim is encoded in the ”exp” field. The time
format used to represent values of both ”iat” and ”exp” fields are as defined by the ISO-
8601 standard. Here, the free lunch claim issued at Tuesday, August 21, 2018 10:05:50
AM UTC time and expires at Tuesday, August 21, 2018 12:05:50 PM UTC time. These
claims are message authenticated using HMAC using SHA-256(HS256) under the shared
secret ”blueberry”.
The HS256 scheme, uses the same key for signing and verification and is a message
authentication scheme. Signature schemes, based on public key cryptography schemes
use a signing key (private to the signer) to sign the messages and a verification key to
verify the signatures, and hence authenticate the peer. RSA and ECDSA schemes are
supported in JWT. The algorithms used for securing the JWT have been defined in the
[RFC7518]. In later sections, when referring to JWT based schemes is referred to, public
key based signature schemes are implied.
Clearly, the JWT server very useful for issue of digital tokens that, if valid, can be
exchanged for access to services.
It is important to note that JWS mus be exchanged on a secure channel to avoid
being stolen and misused by sniffing party. Transport Layer Security (TLS) is commonly
used for establishing a secure channel for exchange of the JWS as access tokens.

3 Message Queuing Telemetry Transport Protocol

The MQTT, an Advanced Open Standard for the Information Society (OASIS) standard,
is a lightweight protocol for machine to machine communication. All machines, referred
to as the client communicate through a central server referred to as the broker. The
publish-subscribe pattern is used for message exchange between the broker and the client.
The clients can be publishers, subscriber or both. All clients must identify themselves
uniquely when connecting to the broker. Figure 3 depicts two clients connecting to
the broker. One of the client is the data source and publishes data, while another is a
subscribes and subscribes to messages published message on a specific topic(s).
The [MQTT 3.1.1] defines many concepts and mechanisms to enable detection of
inactive clients, publishing the last will and testament of such clients, graceful discon-
nection etc. However, only the concepts necessary relevant for the discussion on client
authentication are described here.

3.1 Transport
The MQTT is defined over the TCP transport. TCP port 1883 is reserved for the MQTT
protocol. In case TLS is used for securing communication between the client and the
broker, then the TCP port 8883 is used.
A new specification,MQTT for Senor Networks (MQTT-SN), adapted for the UDP
transport has been defined. See [MQTT-SN 1.2] for details. This version is not discussed
in this paper.

3
 Figure 3: MQTT Protocol Overview

3.2 Publish and Subscribe

A client can publish data to a broker using the MQTT publish message. A broker can
similarly send data to a client via a publish message. Each publish message contains a
topic field that identifies the data being published, for example, whether the data is a
temperature measurement or a GPS may be segregated based on the topic. Similarly,
if the client is interested in receiving certain measurements, then it can subscribe to its
topic(s) of interest. The topic and payload are of variable length.
The specification does not mandate any topics nor format of the topics. However,
it does define wild card characters that permissible when subscribing to topics. The
specification also does not mandate any payload formats that shall be supported by the
clients.
Therefore, the specification leaves much to the implementation, and the clients must
comply with the broker that it wishes to communicate to.
It is worth noting that two client never talk to each other directly.

3.3 Client Authentication and Authorization

The [MQTT 3.1.1] defines optional authentication of the clients connecting to the broker
using user name and password of the connection request. The primitives used for the user
name and password is an implementation choice left to the entity that deploys the MQTT
based service. Based, on the configured access control policy on the broker, clients may
have authorization to publish and/or subscribe to only certain topics. The specification
does mention authentication of the clients using the TLS mutual authentication scheme.

4
Therefore, it is not necessary that all authentication schemes must use the user name
and password field of the connect request.
The choice of authentication and authorized access is left to the implementation
and not mandated by the specification. Some implementations of MQTT make issues
with leaving much to the implementation clear. These implementations, by default,
allow unauthenticated clients to publish data to authenticated subscribing clients that
authenticate the server using TLS. Therefore, the authentication of the server provides
little value to the subscribers.

3.4 Keep Alive

The specification defines a periodic keep alive message be sent by the client to the broker.
This is intended for the broker to detect any clients that are no longer reachable due to
battery failure, loss of network or other reasons.

4 MQTT Client Authentication Schemes

The specification of MQTT, allows for implementation specific client authentication
scheme. Section 3.3 already summarizes client authentication and authorization as de-
fined in the MQTT specification, [MQTT 3.1.1]. The specification focuses mostly on
client authentication and not broker (server) authentication. However, server authenti-
cation is assumed achievable using TLS server authentication schemes.
Before, we discuss the client authentication schemes, it is recommended to familiarize
with TLS. Knowledge of certificate authentication of the TLS server and the TLS client
will be particularly useful to appreciating how some of the schemes work, and to compare
them with the others. The version 1.2 specification of TLS is available at [RFC5246].
[Col18] provides a good overview of TLS and an excellent summary of attacks on TLS.
A servers to provide a quick refresh of server and client authentication during TLS
handshake.
Since, the specification leaves much to implementation and choice, all possibilities
are not considered and compared. This research is limited to comparing the schemes
listed below:

• User name and password

• Client Authentication using TLS

• Client Authentication using JWT

On note for the subsequent sections is that the service (the cloud) may consist of
many components. Components like the MQTT broker to communicate with the sen-
sor devices that implementMQTTclients, a user data base or an Identity and Access
Management (IAM) system for maintaining the users identity, authentication and au-
thorization information, a portal to register the users, a portal to monitor the users data
from the clients and/or the state of the clients etc. The service therefore is a composite

5
of various components. However, in this paper, only two components are considered, the
MQTT broker and the user data base or the IAM. Note that for the client, the broker
symbolizes the service.

4.1 User name and password

The MQTT specification [MQTT 3.1.1] provisions for user name and password fields in
the connect request message from the client. Both the fields are optional. And presence
of each field is individually indicated in the flags field of the message. See section 3.1 of
[MQTT 3.1.1] for details.
The figure 4 provides a simplified view of a client connecting to MQTT based service,
that uses the user name and password field for authentication. Authorization is derived
from the authentication of the user name.

Figure 4: MQTT Client Authentication: User name and password

4.2 Prerequisite
For this authentication scheme, following prerequisites must be fulfilled.

• User name and password are registered with the service.

• The user name and password have been provisioned in the client.

This method is simplistic, and requires the client to share its identity and secret to
the broker. And that once the credentials are compromised, any body could start im-
personating the client. If this scheme must really be used, then, at least two precautions
must be taken to:

• Encrypt the communication between the client and the broker.

• Authenticate the server before sending any credentials to it.

Both of these are easily addressed by use of TLS with server authentication scheme.

6
 Note that this method may never be deployed commercially, however, serves as a
good basis for understanding how use of resources on the brokers can be authorized by
a simple use of user name.
It should be noted that the specification uses the client id and the user name as
distinct concepts without much elaboration on intended use. One of the interpretations
could be that a single user can log in from multiple devices. With this interpretation one
could argue if the authentication is really the user authentication or client authentication.
However, it is mandated that the client id be unique across clients, and the password
field could be supplied even without the user name field. This leaves possibility of
individual client’s authentication open. It seems intentional to permit both models in
the specification. However, this is subjective to the readers understanding.

4.3 Client Authentication using TLS

The MQTT broker relies on the TLS client certificates to establish the identity of the
client, and authenticate it. The access control policies are applied based on the identity
of the client, the public certificate. The figure 5 illustrates the authentication of a MQTT
client authenticated using TLS before the MQTT connection. This method is not unique
to MQTT, and TLS based client authentication is available to any protocol that uses
TLS for establishing a secure channel. This method is already popularly used with the
HTTP based applications.

Figure 5: MQTT Client Authentication: TLS Client Authentication

4.4 Prerequisite
For this authentication scheme, following prerequisites must be fulfilled.

• The client is provisioned with its private key and public certificate. In addition,
root CA certificate is provisioned to authenticate the server.

• Client’s public certificate is registered with a service and necessary access control
policies attached.

7
 The Amazon Web Service (AWS) cloud service deploys this method as the default
and recommended mechanism to authenticate the both HTTP and the MQTT based
clients. The client certificates registered with the AWS are signed by a root CA that
AWS trusts. In fact, AWS implements its root CA based on the geographic region.
The certificate chain used by AWS is not very long.The documentation of integrating a
device to with the Amazon Web Service (AWS) IoT is available at [AWS IoT]. Protocol
specific documentation is available at [AWS IoT: Protocol]. Additional documentation
on security and identity is available at [AWS IoT: Security].
It is important to note that AWS employs many components, each component del-
egated a specific task. And achieving communication with the MQTT broker has the
prerequisite of setting up other components up correctly. An example of such a com-
ponent is configuration of the IAM component. Documentation is available at [AWS
IAM]. The AWS IAM provides a verify fine grain control of access control policies per
certificate.
This method, enjoys the merit of being a well established standard available to
application protocols. And therefore, could be more studied and attacked as against the
others schemes.
One observation from experience of implementing TLS mutual authentication on
Cortex-M based embedded device is that the RAM and CPU requirements when imple-
menting TLS peak the handshake are quite high. In fact TLS extension max fragment
length had to be enabled in order to reduce the RAM requirements for the input and
the out record sizes. Hence, this method can be resource intensive and impractical for
small embedded devices. This could be a reason why AWS may have opened up for
other possibilities for authentication of the IoT devices.

4.5 Client Authentication using JWT

The MQTT client sends the broker a JWT in the password field of the connect message
to the broker. This is the first message that the client send to the broker. The JWT
contained in the password field contains the claims like the time of issue, expiration
date and any other claim defined by the service and a signature of these claims, any
header fields. The signature servers as a proof of possession of the signing key or the
private key. The signature is verified using the verification key or the public key that is
already registered with the service. Therefore, the client’s identity is its public certificate.
However, this identity is never sent out during the communication. The JWT may
include a hint on the key to be used for verification. An illustration of this method is
depicted in the figure 6.

4.6 Prerequisite
For this authentication scheme, following prerequisites must be fulfilled.

• The client is provisioned with it a signing key (the private key). In addition, root
CA certificate is provisioned to authenticate the server.

8
 Figure 6: MQTT Client Authentication: JWT

• Client’s public certificate is registered with a service and necessary access control
policies attached.
This mechanism of authenticating the clients is used by the Google Cloud IoT Core
service. The service mandates inclusion of the audience claim identifying the project in
the JWT. The mandated header fields include the algorithm and type. The signature
schemes mandated to be supported for JWT are RS256 and ES256. The service does
not mandate the verification keys provisioned on the server for JWT to be signed by any
CA. These can be self signed. The Google cloud mandates refreshing the JWT at least
once every hour. It is not specified if any user or project specific claims can be included
in the JWT. Full documentation on how to integrate a device with the Google Cloud
IoT using Message Queuing Telemetry Transport (MQTT) is available at [GCS: IoT].
The documentation on use JWT for authentication is available at [GCS IoT: JWT].
Use of TLS is a must as otherwise, the JWT stand the risk of being stolen and
misused. The Google Cloud service mandates use of TLS. The server is authenticated
by the server certificate and also confidentiality of communication between the broker
and the client is ensured. One observation is that the service uses a long CA chain. This
has implications on bandwidth, RAM and time taken to verify the server on the client
side, which may be a small embedded device.
The client id format are mandated by the service. This is unlike the AWS service
that allows the developers to define the length.

5 Comparison of authentication schemes

This section compares the authentication schemes described in 4. Not all attributes used
for comparison are security properties or goals. However, these are included for as they
integrate the application layer protocol, and implementation details and challenges with
the schemes.
It is important to note that no formal security analysis has been performed for
comparing the schemes. Tamarin-prover available at [Tamarin prover] was investigated
for the purposes of analyzing use of TLS and JWT for MQTT together. However, the

9
investigation never materialized mostly because of time constraints. Also, there was no
straight forward way of combining protocols and primitives for analysis exist.

5.1 Confidentiality
Confidentiality here is considered not as a security goal, but rather whether it is a
prerequisite for authentication. The JWT based authentication described in the section
and 4.1 4.5 must be performed on a confidential, and server authenticated channel, to
be of any value. Else, the token or the credentials may be stolen and used by anybody
to get unauthorized access to the resources on the server.
The tokens are stateless, and do no include any client and/or protocol information.
Of course the access to resources are time limited, but, provide enough opportunity to
exploit the service by means of impersonating a legitimate client of the service.
The TLS client authentication scheme has no such requirement. However, as a
consequence, compromise the client’s privacy as a consequence. See 5.3 for details.

5.2 Server authentication

Again, this discussed more as a prerequisite rather than a goal for all the schemes.
Providing credentials to an unauthenticated server compromises not just the client, but
could end up having wider implications on the system. If a client provides its credentials
to an adversary, then, the adversary can impersonate the client publish messages that
can cause harm through the devices that subscribe to these published messages. Note
that the subscribers never authenticate the source of the published messages, but rather
rely on the server to take necessary measures for entity and message authenticity.

5.3 Client Privacy

Use of TLS client certificates for authentication described in 4.3 implies that the client’s
identity, its public certificate is sent as plain text. The TLS handshake is not complete
yet, and hence the keys needed for bulk encryption are no established yet. A method to
overcome this has been described in section of [Col18]. The method proposed is to first
establish a confidential link with the server, and then renegotiate the session. Renego-
tiation procedure is apart of the TLS, however, must be supported by both the server
and the client to successfully use this feature. Attacks that target this renegotiation
procedure are also detailed in [Col18].
The use of JWT for authentication described in 4.5 fairs better in this aspect, as the
the JWT is sent over TLS encrypted channel. Also, the client’s identity is never directly
transferred to the server. Rather the client identity and authentication is implied by a
valid signature on the token.

5.4 Credential/Key management

One of the major challenges with deployment of any security scheme is the key manage-
ment.

10
 In TLS based authentication scheme, each device, ideally, should be provisioned
with unique key pair - the private key, and the corresponding public certificate chain to
authenticate itself, and the root CA to be able to authenticate the server.
In JWT base authentication scheme, each device, ideally, should be provisioned with
he private key for signing the tokens and the root CA to be able to authenticate the
server during the TLS handshake.
For each scheme, it is recommended to have more than one key pair to be able to
revoke them in case of compromise.
Provisioning of private keys must be performed in a secure environment and man-
aging them is an existing challenge that still requires o be addressed. Further, checking
the revocation status of certificates may not be implemented in embedded devices. This
choice may then lead to continued communication of devices with a compromised server.
Millions of devices can hence be compromised due to a compromised server and impacts
of such large scale compromises are hitherto unknown as the IoT is still reach its full
potential. Updating the system of remote sensors can definitely have a cost impact on
the businesses.
Strong recommendations, clear guidelines and swift and transparent measures in case
of compromise by service providers may already be some of the steps that could be taken
by the service providers.

5.5 Requirement for Time Synchronization

Use of JWT based authentication requires implementing a time service. Use of time adds
the needed randomness in JWT tokens. Else, the signature scheme being deterministic
would always have the same signature. Further, use of time ensures freshness of the
authentication token.
TLS based scheme does not have any such requirements as nonce provided by server
and client are used during the handshake.
Connection is rejected by the Google cloud if the ”issued at time” did not match its
expectation. This means that there can be denial of service attacks launched by imper-
sonating a time server. Typically an Network Time Protocol (NTP) server is contacted
by an embedded device to get absolute time and typically, only a subset referred to
as the SNTP is implemented on these constrained devices. The specifications of NTP
and SNTP are available at [RFC5905] and [RFC4330] respectively. The [RFC4330] de-
scribes on security measures being too elaborate and/or complex to be used in simpler
devices - this being very true for small embedded devices. Use of JWT based authenti-
cation is hence creating dependency on another network based service that has its own
vulnerabilities.

5.6 Session interruption

The mandate by the Google cloud service to refresh the JWT token periodically. To
fulfill this requirement, the client must be disconnected and connected back with a fresh
token as there are no existing mechanisms to refresh the security token. This, therefore

11
translates into the requirement of reestablishing the TLS session. Such an interruption
may be undesirable in some use cases. Undesirable, due to latency introduced, or the
cost of creating a session or both.
While refreshing the token seems like a good idea when used as cookies in the browser
or in case authorization grants enable by OAuth. It is unclear what the objective is
refreshing the token when used for authentication of MQTT clients is. And therefore,
this additional cost and disruption becomes more undesirable.
If the security objective is established, then perhaps a scheme to enable refreshing
of tokens with interrupting the sessions could be useful.

5.7 Cost on the client

The client devices that comply with the authentication schemes dictated by the cloud
service, are many times constrained in terms resources (RAM, bandwidth, flash and
computational capacity and available power), and may further requirements on latency
on sending measurements or reacting to commands from the cloud (turn on light bulb)
for example.
A study of implementation cost of the various both the TLS and JWT based schemes
is needed and unavailable as of today.
Choice of deployment schemes like the length of CA used for the server certificates
has a direct impact on the constrained client. Google cloud service uses a very long ca
chain, that must be first received and stored by the wireless sensor and then validate.
The AWS uses only one CA for the servers.
Further, certain features like he resumption of TLS session may benefit the con-
strained devices, however, are not always supported by the cloud service due to chal-
lenges with sharing the session tickets across load balanced servers. An investigation of
how this could be better enabled in the servers, and hence be used by clients may be
useful.

5.8 Access Control

It is important to notice the subtle difference in when the IAM is contacted in the 5
and the 6. In JWT based scheme, since th client authentication is not established until
the MQTT connect request arrives from the client, the default access policy must be
configured correctly to ensure no opportunities for unauthorized access open up between
the TLS handshake completion and MQTT connection.
Further, in this scheme, it is unclear how clients may be authorized to allow only
certain protocols. Note that the protocols are typically are deployed in distinct port
numbers. Hence, for TLS based scheme, based on protocol port and the client certificate,
it may be possible to assert even before the handshake completes if the client should be
allowed access to the service on the port.

12
5.9 Known plain text attacks on TLS
The MQTT by design is lightweight with limited set of messages. Each message has
fixed header, may have variable header and may contain variable length payload.
Also, the order of the messages can be determined, the first message shall always be
the connect message. There is a periodic keep alive message etc.
The connect message fixed header and variable parts by specification, but the variable
parts are fixed for a particular client. The keep alive message has no variable components
and is sent out periodically.
Therefore, knowing the structure of the message, and most parts of the message, and
their use in the protocol could be exploited for chosen plain text attacks on the ciphers
used for the TLS connection with the broker.
Note that use of JWT in the initial connect message helps only in introducing certain
variation to the initial message. And this too, if an only if, the JWT itself introduced a
variable, like the time of issue or expiration and/ or other random component.
Therefore, a method to analyze the TLS with MQTT may be useful in determining
how secure the connection between the client and the broker really is.

5.10 End to end security

Most cloud providers including the AWS and the Google cloud claim end-to-end security.
In fact many practitioners have the notion that use of TLS implies that end-to-end
security is achieved. And this may be right.
However, consider the use case where an MQTT subscriber either turns on/off the
light based on luminosity or illumination detected by the publishing clients. The sub-
scribing client has no way of ensuring that each of the published message was in fact
valid. The validity here may be in sense of time, and or in sense of who is allowed to
publish illuminations. The trust is placed entirely on the server. This could, by design
of MQTT is the single point of failure.
Possibilities of using JWT in every publish message to asset the source of the message,
that the subscriber can verify independent of the server before processing the request
could be interesting to research.
Formally defining these security goals are recommended prerequisite to and analyze
solutions.

6 Conclusion
JWT brings about a new method of authenticating the client that can be easily integrated
in the existing implementations of the MQTT. However, this new mechanism does not
simplify any of the existing challenges of key management. Both TLS and MQTT
require use of public and private key pair to be provisioned into the devices. Google
infact recommends use of key rotation and can support up to 3 keys per device. And,
since both schemes rely on the root of trust via the CA chain for server authentication,
the two schemes inherit the risks involved with use of certificate chains. The JWT based

13
schemes does protect client privacy, and this is a clear advantage over the TLS scheme.
However, this advantage however be leveled with widespread support for TLS 1.3.
Cost of implementing JWT in constrained devices is not known entirely either. A
study of cost weighed against the benefits may be important to help make choices in
products.
All schemes rely on secure channel established using the TLS. TLS being a popular
and widely used security protocol on the internet, is most researched and also may be
most attacked. A compromise of TLS may impact either of the schemes. It is therefore
important to ensure that practitioners choose strong ciphers. It is also critical evaluate
and test the TLS library used in implementations. Also, building mechanisms to ensure
patching of any vulnerabilities found in implementations quickly may help mitigate some
of the risks in deployed products.
Also, enabling study of security protocols and primitives in an application proto-
col may be useful, and needed to expose any vulnerabilities exposed by the choice of
primitives or the nature of the application protocol. As mentioned in 5.9, MQTT being
predictable in payload sent from the client to the server may enable known plaint text
attacks on TLS. A good models and tool enabling such analysis may be worth research
to install faith in security measures deployed in IoT systems. Also, many times when
analyzing protocols, it is assumed that a fresh time stamp is just available in the system.
This may not be true for embedded devices. And an attack on time service of the device
may open up for new opportunities of attacks on the device. The most obvious category
being the denial of service attack.
More JWT based authentication schemes have been proposed for IoT devices. These
schemes are not limited or bound to use of any particular application protocol and are
targeted for smart home applications. For example, [OAuth for IoT] suggesting setting
up a personal OAuth servers on mobile phones that can issue tokens for the users things
connecting to the cloud. Another paper, [JWT based Auth], suggests use of the home
gateway device to issue security tokens to other devices to get needed authorized access
to services. Both these solution, may simplify the use key management problem for
constrained devices. These proposals may have not scale to use cases outside of smart
home and, may also be putting to much trust on devices like Gateways and mobile phones
which themselves are subject to being compromised easily. However, these proposals do
show that there are many possibilities to authenticating IoT devices and many varied
objectives, so one solution may not fit all use cases.

14
A Authentication with TLS
The figure 7 provides an overview of the handshake protocol of the TLS. The handshake
protocol is used for authentication and key establishment.

Figure 7: TLS Handshake

Source: [RFC2246]

For server authentication, the client connecting to the server is provisioned with a
root CA certificate. During the handshake, the server then sends its certificate along
with the certificate chain in the Certificate message that follows the ServerHello message.
The client can now verifies the signature and validity period of each of the certificates
in the certificate chain. The last certificate in the chain must either be the root CA that
the client is provisioned or signed by the this root CA.
The client cannot send its own certificate unless the server requests it using the
”CertificateRequest” message. When requested, the client, sends its certificate to the
server in the ”Certificate” message that follows the ”ServerHelloDone” in the 7. The
client is authenticated by the ”CertificateVerify” message that contains signature on
hash of all the handshake messages until this message.
Note that, the client cannot send its certificate if not requested by the server and,
cannot demand that the server sends it certificate. It can however, terminate the hand-
shake using the alert protocol.

15
Acronyms
AWS Amazon Web Service. 1, 2, 8, 9, 12, 13

CA Certificate Authority. 7–9, 11–13, 15

ECDSA Elliptic Curve Digital Signature Algorithm. 3

GPS Global Positioning System. 4

HTTP Hypertext Transfer Protocol. 7, 8

IAM Identity and Access Management. 5, 6, 8, 12

IoT Internet of Things. 1, 2, 8, 11, 14

JSON The JavaScript Object Notation. 2

JWE JSON Web Encryption. 2

JWS JSON Web Signature. 2, 3

JWT JSON Web Token. 1–3, 5, 8–14

MQTT Message Queuing Telemetry Transport. 1–9, 12–14

MQTT-SN MQTT for Senor Networks. 3

NTP Network Time Protocol. 11

OASIS Advanced Open Standard for the Information Society. 3

RSA Rivest–Shamir–Adleman. 3

SNTP Simple Network Time Protocol. 11

TCP Transmission Control Protocol. 3

TLS Transport Layer Security. 1–5, 7–15

UDP User Datagram Protocol. 3

16
References
[AWS IAM] AWS Identity and Access Management (IAM). Tech. rep. url:
https://aws.amazon.com/iam/.
[AWS IoT] AWS IoT Developer Guide. Tech. rep. url: https://aws.amazon.
com/documentation/iot/.
[AWS IoT: Protocol] AWS IoT Developer Guide. Tech. rep. url: https://docs.aws.
amazon.com/iot/latest/developerguide/protocols.html.
[AWS IoT: Security] AWS IoT Developer Guide: Security & Identity. Tech. rep. url:
https://docs.aws.amazon.com/iot/latest/developerguide/
iot-security-identity.html.
[Col18] Douglas Stebila Colin Boyd Anish Mathuria. Protocols for Au-
thentication and Key Establishment - pre publication draft. Springer,
2018.
[GCS IoT: JWT] Google Cloud: IoT: Using JSON Web Tokens (JWTs). Tech. rep.
url: https : / / cloud . google . com / iot / docs / how - tos /
credentials/jwts.
[GCS: IoT] Google Cloud: IoT: Using the MQTT Bridge. Tech. rep. url:
https : / / cloud . google . com / iot / docs / how - tos / mqtt -
bridge.
[JWT based Auth] Seung Wook Jung & Souhwan Jung. A Study on a JWT-Based
User Authentication and API Assessment Scheme Using IMEI in
a Smart Home Environment. Tech. rep. 2017. url: http://www.
mdpi.com/2071-1050/9/7/1099.
[MQTT 3.1.1] MQTT 3.1.1 Specification. Tech. rep. url: http://docs.oasis-
open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html.
[MQTT-SN 1.2] MQTT For Sensor Networks (MQTT-SN) Protocol Specification
Version 1.2. Tech. rep. url: http://mqtt.org/new/wp-content/
uploads/2009/06/MQTT-SN_spec_v1.2.pdf.
[OAuth for IoT] Moon-Seog Jun & Jungho Kang Namsu Hong Mansik KimOrcID.
Personal OAuth authorization server and push OAuth for Inter-
net of Things. Tech. rep. 2017. url: http://journals.sagepub.
com/doi/10.1177/1550147717712627.
[OpenID] OpenID Connect Core 1.0. Tech. rep. url: http://openid.net/
specs/openid-connect-core-1_0.html.
[RFC2246] Dierks & Allen. The TLS Protocol Version 1.0. RFC 2246. RFC
Editor, Jan. 1999. url: http : / / www . rfc - editor . org / rfc /
rfc2246.txt.

17
 [RFC4330] Mills. Simple Network Time Protocol (SNTP) Version 4 for IPv4,
IPv6 and OSI. RFC 4330. RFC Editor, Jan. 2006. url: http:
//www.rfc-editor.org/rfc/rfc4330.txt.
[RFC4648] Josefsson. The Base16, Base32, and Base64 Data Encodings. RFC
4648. RFC Editor, Oct. 2006. url: http://www.rfc- editor.
org/rfc/rfc4648.txt.
[RFC5246] Dierks & Rescorla. The Transport Layer Security (TLS) Protocol
Version 1.2. RFC 5246. RFC Editor, Aug. 2008. url: http://
www.rfc-editor.org/rfc/rfc5246.txt.
[RFC5905] Mills et al. Network Time Protocol Version 4: Protocol and Al-
gorithms Specification. RFC 5905. RFC Editor, June 2010. url:
http://www.rfc-editor.org/rfc/rfc5905.txt.
[RFC6749] Hardt. The OAuth 2.0 Authorization Framework. RFC 6749. RFC
Editor, Oct. 2012. url: http : / / www . rfc - editor . org / rfc /
rfc6749.txt.
[RFC7515] Jones et al. JSON Web Signature (JWS). RFC 7519. RFC Editor,
May 2015. url: http://www.rfc- editor.org/rfc/rfc7515.
txt.
[RFC7516] Jones & Hildebrand. JSON Web Encryption (JWE). RFC 7519.
RFC Editor, May 2015. url: http://www.rfc- editor.org/
rfc/rfc7516.txt.
[RFC7518] Jones. JSON Web Algorithms. RFC 7518. RFC Editor, May 2015.
url: http://www.rfc-editor.org/rfc/rfc7518.txt.
[RFC7519] Jones et al. JSON Web Token (JWT). RFC 7519. RFC Editor,
May 2015. url: http://www.rfc- editor.org/rfc/rfc7519.
txt.
[RFC7521] Campbell et al. Assertion Framework for OAuth 2.0 Client Au-
thentication and Authorization Grants. RFC 7521. RFC Editor,
May 2015. url: http://www.rfc- editor.org/rfc/rfc7521.
txt.
[RFC8259] Bray. The JavaScript Object Notation (JSON) Data Interchange
Format. RFC 8259. RFC Editor, May 2015. url: http://www.
rfc-editor.org/rfc/rfc8259.txt.
[Tamarin prover] Tamarin prover. Tech. rep. url: https : / / tamarin - prover .
github.io/.

18

View publication stats