The document discusses access control challenges in the Internet of Things (IoT), emphasizing the need for improved security and privacy. It covers various authorization frameworks such as OAuth2, UMA, and ACE, detailing how they apply to device-to-device communications and specifically in constrained environments. Additionally, it addresses the MQTT protocol's role in ensuring secure data exchange and the importance of token management for maintaining privacy.

1. Access Control in the
Internet of Things
01.04.2019
Cigdem Sengul

2. MQTT-ACE
2
IoT promises a smart future
Things Networks
TV
White
Space
Data, Applications
Oxford
Flood
Network
connect to , generate enabling new

3. 3
But, it needs to improve
its reputation
Not easy to use
Not secure
Not private
or interoperable

4. Access control is the decision to
grant access to a resource.
• Who can perform which access rights on
which resource?
• What are the applicable rules and
policies? (context)
• What are the requestor claims? (subject)
• How are access control decisions
enforced? (object)
4
Let’s start with
the essentials…

5. There is no easy solution
5
End-devices vary in their
capabilities
Various communication
patterns and network
architectures
Multiple protocols
(proprietary or standards)

6. Authorization standards
NOMINET IOT PRIVACY
6
Current standards are based on web
authorization, OAuth2
Not all IoT specific – mostly not fitted
to device-to-device scenarios
1. OAuth2 device flow
2. UMA (User Managed Access,
Kantara)
3. ACE (IETF workgroup on
Authentication and Authorization in
Constrained Environments) Source: xkcd

7. OAuth2
If you have ever seen one of
these, then you have used
OAuth2
Note this app is asking the user to
give access rights for specific
information/actions
End-user is basically connecting
application A to application B, to
login and share data under certain
limitations.
Alice-to-Alice sharing
7This Photo by Unknown Author is licensed under CC BY-SA

8. OAuth2
Authorization framework for
delegated access
Access permissions are
captured in tokens
Several flows:
1. Authorization code grant
(shown in the figure)
2. Implicit grant
3. Client credential grant
4. Password grant
OAUTH2 BACKGROUND
8
Resource
owner
(User Agent)
Resource
server
Authorization
server
Client
1. Requests
authorization
2. Authorizes app
3. Gets proof (code)
4. Returns code 5. Sends code
6 Gets token
7. Uses token to
access
resource
8 Introspects
token

9. Limiting access
via scopes
Scope
• Represents permissions asked by
the client
• Captures user consent
OAUTH2 BACKGROUND
9
Scopes
to allow

10. Access token
Opaque to the client
OAuth doesn’t prescribe scopes, or
define a format for tokens
Common formats
JWT (JSON Web Token)
CWT (CBOR Web Token)
Defines
Iss: Issuer Sub: Subject Aud: Audience
OAUTH2 BACKGROUND
10
This Photo by Unknown Author is licensed under CC BY-SA

11. Bearer vs PoP tokens
Bearer token
• Give access to the bearer of this token, no
additional checks (over TLS)
PoP (Proof-of-possession) token
• An access token may be bound to a
cryptographic key, which is then used by the
RS to authenticate the client
• AS is the trusted third party that binds PoP
keys (symmetric or asymmetric keys) to
access tokens.
OAUTH2 BACKGROUND
11
Client
Generates public
– private key pair
Authorization
server
Sends public key
with token
request
Public key in
access token
Client uses private
key for proof-of-
possession with RS
PoP ASYMMETRIC KEYS
Client
Authorization
server
Generates keyKey in access
token; returns
key+ access
token
Client uses key for
proof-of-possession
with RS
PoP with SYMMETRIC KEYS
Token request

12. OAuth2 Device Flow
Designed for devices are input
constrained e.g., smart TVs, digital
picture frames etc.)
User performs the authorization
request on a secondary device, such
as smart phone
Requirements on the device:
1. Connected to the internet
2. Able to make HTTPS requests
3. Able to display a code
12
Device client
Authorization
server
End-user at
Browser
1. Client ID
2. Verification code
User code
Verification URI
5. Poll with
verification code
3. User code
Verification URI
4. User authenticates
6. Access token

13. UMA – OAuth2 for Alice-to-Bob
sharing
RO shares his data selectively with others;
controls access proactively through policies
Division of responsibilities. RS hosts resources,
AS decides who can access them.
RO introduces RS to AS
AS discovery with a permission ticket:
When requesting party (RP) attempts to access
resources without a token, she is directed to
AS along with a ticket obtained from the AS.
13

14. Authorization and Authentication in
Constrained Environments
Based on several building blocks:
OAuth2, CoAP, CBOR-based secure
message format COSE, CBOR web
token, TLS/DTLS
Introduces:
1. Proof-of-possession token
2. Similar to UMA, AS discovery with
request creation hints
3. authz-info endpoint: To transport
the access token to RS
ACE
14
ACE Framework

15. Summary of Authorization Approaches
• OAuth2 device flow is Alice-to-Alice sharing
• UMA focuses on Alice-to-Bob sharing, but
HTTP-based
• ACE focuses on potentially offline clients,
and RS’es and CoAP-based
• Tokens-based approach, token as a result of
“policies”
• Tokens are generated via independent
authorization servers
• AS discovery may be supported
NOMINET IOT PRIVACY
DifferencesCommonalities

16. MQTT-ACE
PRESENTATION TITLE - CHAPTER
16

17. In a nutshell
• MQTT is a publish/subscribe protocol, with a broker
managing the data exchange between publishers
and subscribers
• MQTT runs over TCP and supports TLS
• MQTT messages
• CONNECT: First message an MQTT client sends to the
broker
• PUBLISH: Can be sent by a publisher or broker
• SUBSCRIBE
• Topic subscriptions: Topic Filter (including wild
cards) + QoS (Quality of Service)
MQTT-ACE
17
Background: MQTT
Client:
PUBLISH
home/temp
Client 1
Subscriber to home/temp
Client 2
Subscriber to home/temp
MQTT broker
Client 3
Publisher of home/temp
Subscriber home/light
Client 4
Publisher of home/light
Client:
PUBLISH
home/light
Broker:
PUBLISH
home/temp
Broker:
PUBLISH
home/tem
Broker:
PUBLISH
home/temp

18. Basic Broker algorithm:
On receipt of a new PUBLISH message:
1. check publisher token
2. if valid:
3. for each subscriber:
4. check subscriber token
5. if valid: send new message
7. else: disconnect subscriber
8. else: disconnect publisher
MQTT-ACE
18
MQTT with ACE protection
Client:
PUBLISH
home/temp
Client 1
Subscriber to home/temp
Client 2
Subscriber to home/temp
MQTT broker
Client 3
Publisher of home/temp
Subscriber home/light
DISCONNECT
Broker:
PUBLISH
home/temp
Access token valid Token expired
Access token valid

19. The connection between client and broker
is secured by TLS.
• After TLS session set-up:
(*) Token transported in CONNECT
• Before TLS session set-up:
Token published to “authz-info” topic
unauthorized, and used in TLS session
establishment
MQTT-ACE
19
Passing
tokens to the
broker
Photo by Jordan Rowland on Unsplash

20. Method 1 (MQTT v3.1)
Default auth method: ace_mqtt_tls (not in
packet)
Username: Access token
Password: Signature/MAC for PoP
Method 2 (MQTT v5)
Auth method: ace_mqtt_tls
Auth data: empty or token(+mac)
If empty: AS discovery
Else token verification:
If Token + signature/MAC, just verify
If only Token, use the challenge protocol
Token in CONNECT
MQTTv3.1MQTTv5

21. Handling errors
Any token expiry detection, send
DISCONNECT message with error code ‘Not
Authorized’
If QoS >= 1, then PUBACK/SUBACK messages
can return error ’Not Authorized’
AUTH packet for ’Re-authentication’ avoiding
disconnection.
Any token expiry detection, disconnect below
the MQTT layer (TCP/TLS disconnection)
No explanations
Better than silently failing, because there is no
other way to tell the client it has to renew its
token
21
MQTT v5MQTT v 3.1

22. Security and privacy
considerations
Token lifetime, caching and revocation decisions
• When permissions change dynamically,
unauthorized requests may slip through
Require vigilant monitoring for unsecured
endpoints like “authz-info”
Privacy is not guaranteed.
• RS is a central trusted party and has access
to potentially sensitive information
• Payload encryption requires careful key
management
• No privacy for properties like topic name
22
Photo by Michael Dziedzic on Unsplash

23. Conclusions
• OAuth2-based tokens can protect MQTT communication
• Broker/RS must still be trusted
• How would you relax trust assumptions?
THE END 23