Draft: draft-ietf-ace-mqtt-tls-profile

Commentary: caption capitalization and comma placement
Client-AS and RS-AS MAY also use protocols other than HTTP, e.g.
Constrained Application Protocol (CoAP) RFC7252 or MQTT; it is
recommended that TLS is used to secure these communication channels
between Client-AS and RS-AS.  Implementations MAY also use
"application/ace+cbor" content type, and CBOR encoding RFC8949, and
CBOR Web Token (CWT) RFC8392 and associated PoP semantics to reduce
the protocol memory and bandwidth requirements.  For more
information, see RFC8747.  A JWT token uses JOSE, while a CWT token
uses COSE RFC8152 for security protection.
Client-AS and RS-AS MAY also use protocols other than HTTP, e.g.,
Constrained Application Protocol (CoAP) RFC7252 or MQTT; it is
recommended that TLS is used to secure these communication channels
between Client-AS and RS-AS.  Implementations MAY also use
"application/ace+cbor" content type, and CBOR encoding RFC8949, and
CBOR Web Token (CWT) RFC8392 and associated PoP semantics to reduce
the protocol memory and bandwidth requirements.  For more
information, see RFC8747.  A JWT token uses JOSE, while a CWT token
uses COSE RFC8152 for security protection.
An entity that prepares and endorses authentication and
authorization data for a Client, and communicates using HTTPS to
the AS.
An entity that prepares and endorses authentication and
authorization data for a Client, and communicates to the AS using
HTTPS.
The MQTT protocol operates by exchanging a series of MQTT Control
packets.  Each packet is composed of a Fixed Header, a Variable
Header (depending on the control packet type) and a Payload.
The MQTT protocol operates by exchanging a series of MQTT Control
packets.  Each packet is composed of a Fixed Header, a Variable
Header (depending on the control packet type), and a Payload.
The Broker stores and indexes all tokens received to the "authz-info"
topic in its key store (similar to the I-D.ietf-ace-dtls-authorize).
This profile follows the recommendation of Section 5.10.1 of the I-
D.ietf-ace-oauth-authz, and expects that the Broker stores only one
token per proof-of-possession key, and any other token linked to the
same key overwrites an existing token.
The Broker stores and indexes all tokens received to the "authz-info"
topic in its key store (similar to the I-D.ietf-ace-dtls-authorize).
This profile follows the recommendation of Section 5.10.1 of the I-
D.ietf-ace-oauth-authz and expects that the Broker stores only one
token per proof-of-possession key, and any other token linked to the
same key overwrites an existing token.
This section describes how the Client transports the token to the
Broker inside the CONNECT packet.  If this method is used, the Client
TLS connection is expected to be anonymous, and the Broker is
authenticated during the TLS connection setup.  The approach
described in this section is similar to an earlier proposal by
Fremantle et al fremantle14.
This section describes how the Client transports the token to the
Broker inside the CONNECT packet.  If this method is used, the Client
TLS connection is expected to be anonymous, and the Broker is
authenticated during the TLS connection setup.  The approach
described in this section is similar to an earlier proposal by
Fremantle, et al fremantle14.
mqtt5_connect_message shows the structure of the MQTT CONNECT packet
used in MQTT v5.0.  A CONNECT packet is composed of a fixed header, a
variable header and a payload.  The fixed header contains the Control
Packet Type (CPT), Reserved, and Remaining Length fields.  Remaining
Length is a Variable Byte Integer that represents the number of bytes
remaining within the current Control Packet, including data in the
Variable Header and the Payload.  The Variable Header contains the
Protocol Name, Protocol Level, Connect Flags, Keep Alive, and
Properties fields.  The Connect Flags in the variable header specify
the properties of the MQTT session.  It also indicates the presence
or absence of some fields in the Payload.  The payload contains one
or more encoded fields, namely a unique Client Identifier for the
Client, a Will Topic, Will Payload, User Name and Password.  All but
the Client Identifier can be omitted depending on the flags in the
Variable Header.  The Client Identifier identifies the Client to the
Broker, and therefore, is unique for each Client.  It must be noted
that the Client Identifier is an unauthenticated identifier used
within the MQTT protocol and so is not bound to the access token.
mqtt5_connect_message shows the structure of the MQTT CONNECT packet
used in MQTT v5.0.  A CONNECT packet is composed of a fixed header, a
variable header, and a payload.  The fixed header contains the
Control Packet Type (CPT), Reserved, and Remaining Length fields.
Remaining Length is a Variable Byte Integer that represents the
number of bytes remaining within the current Control Packet,
including data in the Variable Header and the Payload.  The Variable
Header contains the Protocol Name, Protocol Level, Connect Flags,
Keep Alive, and Properties fields.  The Connect Flags in the variable
header specify the properties of the MQTT session.  It also indicates
the presence or absence of some fields in the Payload.  The payload
contains one or more encoded fields, namely a unique Client
Identifier for the Client, a Will Topic, Will Payload, User Name, and
Password.  All but the Client Identifier can be omitted depending on
the flags in the Variable Header.  The Client Identifier identifies
the Client to the Broker, and therefore, is unique for each Client.
It must be noted that the Client Identifier is an unauthenticated
identifier used within the MQTT protocol and so is not bound to the
access token.
network connection is closed according to Will QoS, and Will retain
parameters and MQTT Will management rules.  To avoid publishing the
Will Messages in the case of temporary network disconnections, the
Client specifies a Will Delay Interval in the Will Properties.
disconnections explains how the Broker deals with the retained
messages in further detail.
network connection is closed according to Will QoS, Will retain
parameters, and MQTT Will management rules.  To avoid publishing the
Will Messages in the case of temporary network disconnections, the
Client specifies a Will Delay Interval in the Will Properties.
disconnections explains how the Broker deals with the retained
messages in further detail.
The Broker MAY support session continuation, e.g. if the Broker
requires it for QoS reasons.  In this case, if a CONNECT packet is
received with Clean Start set to 0 and there is a Session associated
with the Client Identifier, the Broker MUST resume communications
with the Client based on the state from the existing Session.  In its
response, the Broker MUST set the Session Present flag to 1 in the
CONNACK packet to signal session continuation to the Client.  The
session state stored by the Client and the Broker is described in
disconnections.
The Broker MAY support session continuation, e.g., if the Broker
requires it for QoS reasons.  In this case, if a CONNECT packet is
received with Clean Start set to 0 and there is a Session associated
with the Client Identifier, the Broker MUST resume communications
with the Client based on the state from the existing Session.  In its
response, the Broker MUST set the Session Present flag to 1 in the
CONNACK packet to signal session continuation to the Client.  The
session state stored by the Client and the Broker is described in
disconnections.
When reconnecting to a Broker that supports session continuation, the
Client MUST still provide a token, in addition to using the same
Client Identifier, and setting the Clean Start to 0.  The Broker MUST
still perform proof-of-possession validation on the provided token.
If the token matches the stored state, the Broker MAY skip
introspecting a token-by-reference and use the stored introspection
result.  The Broker MUST also verify the Client is authorized to
receive or send MQTT packets that are pending transmission.  When a
Client connects with a long Session Expiry Interval, the Broker may
need to maintain the Client's MQTT session state after it disconnects
for an extended period.  Brokers SHOULD implement administrative
policies to limit misuse.
When reconnecting to a Broker that supports session continuation, the
Client MUST still provide a token, in addition to using the same
Client Identifier and setting the Clean Start to 0.  The Broker MUST
still perform proof-of-possession validation on the provided token.
If the token matches the stored state, the Broker MAY skip
introspecting a token-by-reference and use the stored introspection
result.  The Broker MUST also verify the Client is authorized to
receive or send MQTT packets that are pending transmission.  When a
Client connects with a long Session Expiry Interval, the Broker may
need to maintain the Client's MQTT session state after it disconnects
for an extended period.  Brokers SHOULD implement administrative
policies to limit misuse.
with Reason Code of '0x8E (Session taken over)', and closes the
connection to the Client.
with Reason Code of '0x8E (Session taken over)' and closes the
connection to the Client.
The Broker MUST verify the validity of the token either locally (e.g.
in the case of a self-contained token) or MAY send a request to the
introspection endpoint of the AS (as described for HTTP-based
interactions in Section 5.9 of the I-D.ietf-ace-oauth-authz).  The
Broker MUST verify the claims in the access token according to the
rules set in Section 5.10.1.1 of the I-D.ietf-ace-oauth-authz.
The Broker MUST verify the validity of the token either locally
(e.g., in the case of a self-contained token) or MAY send a request
to the introspection endpoint of the AS (as described for HTTP-based
interactions in Section 5.9 of the I-D.ietf-ace-oauth-authz).  The
Broker MUST verify the claims in the access token according to the
rules set in Section 5.10.1.1 of the I-D.ietf-ace-oauth-authz.
The Broker MUST check for token expiration whenever a CONNECT,
PUBLISH or SUBSCRIBE is received or sent.  The Broker SHOULD check
for token expiration on receiving a PINGREQUEST.  The Broker MAY also
check for token expiration periodically, e.g. every hour.  This may
allow for early detection of a token expiry.
The token expiration is checked by checking the 'exp' claim of a JWT
or introspection response or via performing an introspection request
with the AS as described in Section 5.9 of the I-D.ietf-ace-oauth-
authz.  Token expirations may trigger the Broker to send PUBACK,
SUBACK and DISCONNECT packets with return code set to "Not
authorized".  After sending a DISCONNECT, the network connection is
closed, and no more messages can be sent.
The Broker MUST check for token expiration whenever a CONNECT,
PUBLISH, or SUBSCRIBE is received or sent.  The Broker SHOULD check
for token expiration on receiving a PINGREQUEST.  The Broker MAY also
check for token expiration periodically, e.g., every hour.  This may
allow for early detection of a token expiry.
The token expiration is checked by checking the 'exp' claim of a JWT
or introspection response or via performing an introspection request
with the AS as described in Section 5.9 of the I-D.ietf-ace-oauth-
authz.  Token expirations may trigger the Broker to send PUBACK,
SUBACK, and DISCONNECT packets with return code set to "Not
authorized".  After sending a DISCONNECT, the network connection is
closed, and no more messages can be sent.
In the case of a Client DISCONNECT, if the Session Expiry Interval is
set to 0, the Broker doesn't maintain session state but MUST keep the
retained messages.  If the Broker maintains session state, the state
MAY include token and its introspection result (for reference tokens)
in addition to the MQTT session state.  The MQTT session state is
identified by the Client Identifier and includes state on client
subscriptions; messages with QoS levels 1 and 2, and which have not
been completely acknowledged or are pending transmission to the
Client; and if the Session is currently not connected, the time at
which the Session will end and Session State will be discarded.  The
token/introspection state is not part of the MQTT session state, and
proof-of-possession is required for each new connection, regardless
of whether MQTT session continuation is used.
In the case of a Client DISCONNECT, if the Session Expiry Interval is
set to 0, the Broker doesn't maintain session state but MUST keep the
retained messages.  If the Broker maintains session state, the state
MAY include the token and its introspection result (for reference
tokens) in addition to the MQTT session state.  The MQTT session
state is identified by the Client Identifier and includes state on
client subscriptions; messages with QoS levels 1 and 2, and which
have not been completely acknowledged or are pending transmission to
the Client; and if the Session is currently not connected, the time
at which the Session will end and Session State will be discarded.
The token/introspection state is not part of the MQTT session state,
and proof-of-possession is required for each new connection,
regardless of whether MQTT session continuation is used.
set to 1 and QoS>1, disconnects and never connects again).
Therefore, the Broker MUST use the minimum of token expiry and
message expiry interval to discard a retained message.
set to 1 and QoS>1, disconnects, and never connects again).
Therefore, the Broker MUST use the minimum of token expiry and
message expiry interval to discard a retained message.
In MQTT v3.1.1, after the Client published to the "authz-info" topic,
the Broker cannot communicate the result of the token validation as
PUBACK reason codes or server-side DISCONNECT packets are not
supported.  In any case, an invalid token would fail the subsequent
TLS handshake, which can prompt the Client to obtain a valid token.
In MQTT v3.1.1, after the Client has published to the "authz-info"
topic, the Broker cannot communicate the result of the token
validation because PUBACK reason codes or server-side DISCONNECT
packets are not supported.  In any case, an invalid token would fail
the subsequent TLS handshake, which can prompt the Client to obtain a
valid token.
The Client SHOULD set the Clean flag to 1 to always start a new
session.  If the Clean flag is set to 0, the Broker MUST resume
communications with the Client based on the state from the current
Session (as identified by the Client Identifier).  If there is no
Session associated with the Client Identifier the Broker MUST create
a new session.  The Broker MUST set the Session Present flag in the
CONNACK packet accordingly, i.e. 0 to indicate a clean session to the
Client and 1 to indicate session continuation.  The Broker MUST still
perform proof-of-possession validation on the provided Client token.
MQTT v3.1.1 does not use a Session Expiry Interval, and the Client
expects that the Broker maintains the session state after it
disconnects.  However, stored Session state can be discarded as a
result of administrator policies, and Brokers SHOULD implement the
necessary policies to limit misuse.
The Client SHOULD set the Clean flag to 1 to always start a new
session.  If the Clean flag is set to 0, the Broker MUST resume
communications with the Client based on the state from the current
Session (as identified by the Client Identifier).  If there is no
Session associated with the Client Identifier, the Broker MUST create
a new session.  The Broker MUST set the Session Present flag in the
CONNACK packet accordingly, i.e., 0 to indicate a clean session to
the Client and 1 to indicate session continuation.  The Broker MUST
still perform proof-of-possession validation on the provided Client
token.  MQTT v3.1.1 does not use a Session Expiry Interval, and the
Client expects that the Broker maintains the session state after it
disconnects.  However, stored Session state can be discarded as a
result of administrator policies, and Brokers SHOULD implement the
necessary policies to limit misuse.
RS-Client PUBLISH authorization failure: When RS is forwarding
PUBLISH packets to the subscribed Clients, it may discover that
some of the subscribers are no more authorized due to expired
tokens.  These token expirations MUST lead to disconnecting the
Client rather than silently dropping messages.
RS-Client PUBLISH authorization failure: When the RS is forwarding
PUBLISH packets to the subscribed Clients, it may discover that
some of the subscribers are no more authorized due to expired
tokens.  These token expirations MUST lead to disconnecting the
Client rather than silently dropping messages.
After the Broker validates an access token and accepts a connection
from a client, it caches the token to authorize a Client's publish
and subscribe requests in an ongoing session.  Broker does not cache
any invalid tokens.  If a client's permissions get revoked, but the
access token has not expired, the Broker may still grant publish/
subscribe to revoked topics.  If the Broker caches the token
introspection responses, then the Broker SHOULD use a reasonable
cache timeout to introspect tokens regularly.  The timeout value is
application-specific and SHOULD be chosen to reduce the risk of using
stale introspection responses.  When permissions change dynamically,
it is expected that AS also follows a reasonable expiration strategy
for the access tokens.
After the Broker validates an access token and accepts a connection
from a client, it caches the token to authorize a Client's publish
and subscribe requests in an ongoing session.  The Broker does not
cache any invalid tokens.  If a client's permissions are revoked, but
the access token has not expired, the Broker may still grant publish/
subscribe to revoked topics.  If the Broker caches the token
introspection responses, then the Broker SHOULD use a reasonable
cache timeout to introspect tokens regularly.  The timeout value is
application-specific and SHOULD be chosen to reduce the risk of using
stale introspection responses.  When permissions change dynamically,
it is expected that AS also follows a reasonable expiration strategy
for the access tokens.