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

Commentary: Implementing responses to Genart review
Clients use the MQTT PUBLISH packet to publish to a topic.  This
document does not protect the payload of the PUBLISH packet from the
Broker.  Hence, the payload is not signed or encrypted specifically
for the subscribers.  This functionality may be implemented using the
proposal outlined in the I-D.ietf-ace-pubsub-profile.
To provide communication confidentiality and Broker authentication to
the MQTT clients, TLS is used, and TLS 1.3 RFC8446 is RECOMMENDED.
This document makes the same assumptions as Section 4 of the I-
D.ietf-ace-oauth-authz regarding Client and RS registration with the
AS and setting up the keying material.  While the Client-Broker
exchanges are only over MQTT, the required Client-AS and RS-AS
interactions are described for HTTPS-based communication RFC7230,
using 'application/ace+json' content type, and unless otherwise
specified, using JSON encoding.  The token MAY be a reference or JSON
Web Token (JWT) RFC7519.  For JWTs, this document follows RFC7800 for
PoP semantics for JWTs, and the mechanisms for providing and
verifying proof-of-possession are detailed in connect_v5.  The
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.
Clients use the MQTT PUBLISH packet to publish to a topic.  The
mechanisms specified in this document do not not protect the payload
of the PUBLISH packet from the Broker.  Hence, the payload is not
signed or encrypted specifically for the subscribers.  This
functionality may be implemented using the proposal outlined in the
I-D.ietf-ace-pubsub-profile.
To provide communication confidentiality and Broker authentication to
the MQTT Clients, TLS is used, and TLS 1.3 RFC8446 is RECOMMENDED.
This document makes the same assumptions as Section 4 of the I-
D.ietf-ace-oauth-authz regarding Client and RS registration with the
AS and setting up the keying material.  While the Client-Broker
exchanges are only over MQTT, the required Client-AS and RS-AS
interactions are described for HTTPS-based communication RFC7230,
using 'application/ace+json' content type, and unless otherwise
specified, using JSON encoding.  The token MAY be a opaque reference
to authorization information or JSON Web Token (JWT) RFC7519.  For
JWTs, this document follows RFC7800 for PoP semantics for JWTs, and
the mechanisms for providing and verifying proof-of-possession are
detailed in connect_v5.  The 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.
Secured transport profile of MQTT.  MQTTS runs over TLS.
A construct provided by the underlying transport protocol that is
being used by MQTT.  It connects the Client to the Server.  It
provides the means to send an ordered, lossless, stream of bytes
in both directions.  This document uses TLS as tranport protocol.
If the network connection is not closed normally, the Broker sends
a last Will message for the Client if the Client provided one in
its CONNECT packet.  If the Will Flag is set in the CONNECT flags,
then the payload of the CONNECT packet includes information about
the Will.  The information consists of the Will Properties, Will
Topic, and Will Payload fields.
If the Network Connection is not closed normally, the Broker sends
a last Will message for the Client if the Client provided one in
its CONNECT packet.  The situations in which the Will message is
published include disconnections due to I/O or network failures
and the server closing the Network Connection due to a protocol
error.  If the Will Flag is set in the CONNECT flags, then the
payload of the CONNECT packet includes information about the Will.
The information consists of the Will Properties, Will Topic, and
Will Payload fields.
If the Client is resource-constrained or does not support HTTPS, a
separate Client Authorization Server may carry out the token request
on behalf of the Client, and later, onboard the Client with the
token.  The interactions between a Client and its Client
Authorization Server for token onboarding and support for MQTTS-based
token requests at the AS are out of the scope of this document.
If the Client is resource-constrained or does not support HTTPS, a
separate Client Authorization Server may carry out the token request
on behalf of the Client, and later, onboard the Client with the
token.  The interactions between a Client and its Client
Authorization Server for token onboarding and support for MQTT-based
token requests at the AS are out of the scope of this document.
The first step in the protocol flow (Figure 1 (A)) is the token
acquisition by the Client from the AS.  The Client and the AS MUST
perform mutual authentication.  The Client requests an access token
from the AS as described in Section 5.8.1 of the I-D.ietf-ace-oauth-
authz.  The document follows the procedures defined in Section 3.2.1
of the I-D.ietf-ace-dtls-authorize for RPK, and in Section 3.3.1 of
the same document for PSK.  However, the content type of the request
is set to 'application/ace+json', and the AS uses JSON in the payload
of its responses to the Client and the RS.  As explained earlier,
implementations MAY also use "application/ace+cbor" content type.
The first step in the protocol flow (Figure 1 (A)) is the token
acquisition by the Client from the AS.  The Client and the AS MUST
perform mutual authentication.  The Client requests an access token
from the AS as described in Section 5.8.1 of the I-D.ietf-ace-oauth-
authz.  The document follows the procedures defined in Section 3.2.1
of the I-D.ietf-ace-dtls-authorize for RPK (Raw Public Keys RFC7250),
and in Section 3.3.1 of the same document for PSK (Pre-Shared Keys).
However, the content type of the request is set to 'application/
ace+json', and the AS uses JSON in the payload of its responses to
the Client and the RS.  As explained earlier, implementations MAY
also use "application/ace+cbor" content type.
This document follows RFC7800 for PoP semantics for JWTs (CWTs can
also be used).  The PoP token includes a 'cnf' parameter with a
symmetric or asymmetric PoP key.  Note that the contents of the web
tokens (including the 'cnf' parameter) are to be consumed by the RS
and not the Client (the Client obtains the key information in a
different manner).  The RPK case is handled as described in in
Section 3.2.1 of the I-D.ietf-ace-dtls-authorize.  For the PSK case,
the referenced procedures apply, with the following exceptions to
accommodate JWT and JOSE use.  In this case, the AS adds a "cnf"
parameter to the access information carrying RFC7517 object that
contains either the symmetric key itself or a key identifier that can
be used by the RS to determine the secret key it shares with the
Client.  The JWT is created as explained in Section 7 of RFC7519, and
the JWT MUST include RFC7516.  If CWT/COSE is used this information
MUST be inside the "COSE_Key" object, and MUST be encrypted using a
"COSE_Encrypt0" structure.
This document follows RFC7800 for PoP semantics for JWTs (CWTs can
also be used).  The AS includes a 'cnf' parameter to the PoP token,
to declare that the Client possesses a particular key and RS can
cryptographically confirm that the Client has possession of that key.
The 'cnf' parameter is REQUIRED if a symmetric key is used, and MAY
be present for asymmetric proof-of-possession keys, as described in
I-D.ietf-ace-oauth-params.
Note that the contents of the web tokens (including the 'cnf'
parameter) are to be consumed by the RS and not the Client (the
Client obtains the key information in a different manner).  The RPK
case is handled as described in in Section 3.2.1 of the I-D.ietf-ace-
dtls-authorize.  For the PSK case, the referenced procedures apply,
with the following exceptions to accommodate JWT and JOSE use.  In
this case, the AS adds a "cnf" parameter to the access information
carrying RFC7517 object that contains either the symmetric key itself
or a key identifier that can be used by the RS to determine the
secret key it shares with the Client.  The JWT is created as
explained in Section 7 of RFC7519, and the JWT MUST include RFC7516.
If CWT/COSE is used this information MUST be inside the "COSE_Key"
object, and MUST be encrypted using a "COSE_Encrypt0" structure.
TLS:Known(RPK/PSK),MQTT:none: This specification supports client
authentication with TLS with Raw Public Keys (RPK) RFC7250 and
with Pre-Shared Keys (PSK) following the procedures described in
I-D.ietf-ace-dtls-authorize.  For the RPK, the Client MUST have
published the token to the "authz-info" topic.  For the PSK, the
token MAY be published to the "authz-info" topic, or MAY be,
alternatively, provided as a "PSK identity" (e.g. an "identity" in
the "identities" field in the client's "pre_shared_key" extension
in TLS 1.3).
TLS:Known(RPK/PSK),MQTT:none: This specification supports client
authentication with TLS with RPK and PSK following the procedures
described in I-D.ietf-ace-dtls-authorize.  For the RPK, the Client
MUST have published the token to the "authz-info" topic.  For the
PSK, the token MAY be published to the "authz-info" topic, or MAY
be, alternatively, provided as a "PSK identity" (e.g. an
"identity" in the "identities" field in the Client's
"pre_shared_key" extension in TLS 1.3).
The Client MUST authenticate the Broker during the TLS handshake.  If
the Client authentication uses TLS:Known(RPK/PSK), then the Broker is
authenticated using the respective method.  Otherwise, to
authenticate the Broker, the client MUST validate a public key from a
X.509 certificate or an RPK from the Broker against the 'rs_cnf'
parameter in the token response.  The AS MAY include the thumbprint
of the RS's X.509 certificate in the 'rs_cnf' (thumbprint as defined
in I-D.ietf-cose-x509).  In this case, the client MUST validate the
RS certificate against this thumbprint.
The Client MUST authenticate the Broker during the TLS handshake.  If
the Client authentication uses TLS:Known(RPK/PSK), then the Broker is
authenticated using the respective method.  Otherwise, to
authenticate the Broker, the Client MUST validate a public key from a
X.509 certificate or an RPK from the Broker against the 'rs_cnf'
parameter in the token response, which contains information about the
public key used by the RS to authenticate if the token type is "pop"
and asymmetric keys are used as defined in I-D.ietf-ace-oauth-params.
The AS MAY include the thumbprint of the RS's X.509 certificate in
the 'rs_cnf' (thumbprint as defined in I-D.ietf-cose-x509).  In this
case, the Client MUST validate the RS certificate against this
thumbprint.
The Broker MUST verify the validity of the token (i.e., through local
validation or introspection, if the token is a reference) as
described in token_validation.  If the token is not valid, the Broker
MUST discard the token.  Depending on the QoS level of the PUBLISH
packet, the Broker returns the error response as a PUBACK, PUBREC, or
DISCONNECT packet as explained below.
If the QoS level is equal to 0, and the token is invalid or the
claims cannot be obtained in the case of an introspected token, the
Broker MUST send a DISCONNECT packet with the reason code '0x87 (Not
authorized)'.  If the PUBLISH payload does not parse to a token, the
RS MUST send a DISCONNECT with the reason code '0x99 (Payload format
invalid)'.
The Broker MUST verify the validity of the token (i.e., through local
validation or introspection, if the token is a reference) as
described in token_validation.  If the token is not valid, the Broker
MUST discard the token.
Depending on the QoS level of the PUBLISH packet, the Broker returns
the error response as a PUBACK, PUBREC, or DISCONNECT packet.  If the
QoS level is equal to 0, and the token is invalid or the claims
cannot be obtained in the case of an introspected token, the Broker
MUST send a DISCONNECT packet with the reason code '0x87 (Not
authorized)'.  If the PUBLISH payload does not parse to a token, the
RS MUST send a DISCONNECT with the reason code '0x99 (Payload format
invalid)'.
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.
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.
Note that, according to the MQTT standard, the Broker uses the Client
Identifier to identify the session state.  In the case of a Client
Identifier collision, a client may take over another client's
session.  Given that clients provide a token at each connection,
clients will only send or receive messages to their authorized
topics.  Therefore, while this issue is not expected to affect
security, it may affect QoS (i.e., PUBLISH or QoS messages saved for
Client A may be delivered to a Client B).  In addition, if this
Client Identifier represents a Client already connected to the
Broker, the Broker sends a DISCONNECT packet to the existing Client
with Reason Code of '0x8E (Session taken over)' and closes the
connection to the Client.
Note that, according to the MQTT standard, the Broker uses the Client
Identifier to identify the session state.  In the case of a Client
Identifier collision, a Client may take over another Client's
session.  Given that the Broker MUST associate the Client with a
valid token, a Client will only send or receive messages to its
authorized topics.  Therefore, while this issue is not expected to
affect security, it may affect QoS (i.e., PUBLISH or QoS messages
saved for Client A may be delivered to a Client B).  In addition, if
this Client Identifier represents a Client already connected to the
Broker, the Broker sends a DISCONNECT packet to the existing Client
with Reason Code of '0x8E (Session taken over)' and closes the
connection to the Client.
On receiving the PUBLISH packet, the Broker MUST use the type of
packet (i.e., PUBLISH) and the Topic name in the packet header to
match against the scope array items in the cached token or its
introspection result.  Following the example in scope., a client
sending a PUBLISH for 'topic2/a' would be allowed, as the scope array
includes the '["topic2/#",["pub"]]'.
On receiving the PUBLISH packet, the Broker MUST use the type of
packet (i.e., PUBLISH) and the Topic name in the packet header to
match against the scope array items in the cached token or its
introspection result.  Following the example in scope, the Client
sending a PUBLISH for 'topic2/a' would be allowed, as the scope array
includes the '["topic2/#",["pub"]]'.
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 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.
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.
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 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.