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

Commentary: Each commit in this pull request handles one outstanding issue . Specifically : ( 1 ) Made DTLS profile normative , clarified exceptions to adopting that draft ( 2 ) Made JSON array base64 - encoded to be used as a single scope value ; ( 3 ) explained retained messges ) . 
 This seems good enough to merge and upload
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 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.
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.
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.  In order to use an asymmetric key (i.e., Raw Public Key), the
client MUST add a "req_cnf" object carrying either its raw public key
or a unique identifier for a public key that it has previously made
known to the AS.  The media type is 'application/ace+json'.  The AS
uses JSON in the payload of its responses to the Client and the RS.
On receipt of the token request, AS verifies the request.  For
asymmetric cryptography, the AS MUST check if the client that it
communicates with is associated with the RPK in the "req_cnf"
parameter before issuing an access token to it.
If the AS successfully verifies the access token request and
authorizes the Client for the indicated audience (i.e., RS) and
scopes (i.e., publish/subscribe permissions over topics as described
in scope), the AS issues an access token (Figure 1 (B)).  The
response includes the parameters described in Section 5.8.2 of I-
D.ietf-ace-oauth-authz, and specifically, the "ace_profile" parameter
is set to "mqtt_tls".  The returned token is a Proof-of-Possession
(PoP) token by default.  This document follows RFC7800 for PoP
semantics for JWTs.
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).  For the asymmetric case, the PoP token MUST include the
'rs_cnf' parameter containing the information about the public key to
be used by the RS to authenticate as described in I-D.ietf-ace-oauth-
params.  The authorization server MUST ascertain that the RPK
specified in "rs_cnf" belongs to the resource server that the client
wants to communicate with.  For the symmetric case, the AS adds a
"cnf" parameter to the access information, containing the RFC7517
encoded key element, i.e., the shared secret that is to be used
between the client and the RS.
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.
On receipt of the token request, AS verifies the request.  If the AS
successfully verifies the access token request and authorizes the
Client for the indicated audience (i.e., RS) and scopes (i.e.,
publish/subscribe permissions over topics as described in scope), the
AS issues an access token (Figure 1 (B)).
The response includes the parameters described in Section 5.8.2 of I-
D.ietf-ace-oauth-authz.  For RPK, the parameters are as described in
Section 3.2.1 of the I-D.ietf-ace-dtls-authorize.  For PSK, the
document follows Section 3.3.1 of the I-D.ietf-ace-dtls-authorize.
In both cases, if the response contains an "ace_profile" parameter,
this parameter is set to "mqtt_tls".  The returned token is a Proof-
of-Possession (PoP) token by default.
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, the
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).  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. "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 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. "identity" in
the "identities" field in the client's "pre_shared_key" extension
in TLS 1.3).
The TLS session setup is similar to the one described in the I-
D.ietf-ace-dtls-authorize, and if TLS 1.2 is used, RFC7925 describes
how TLS can be used for constrained devices, alongside recommended
cipher suites.  Additionally, TLS 1.2 implementations SHOULD use
"Extended Master Secret" RFC7627 to include handshake transcript into
the master secret (RFC 7627 describes alternative conditions that
must be met to defend against the same attacks without the
extension).  TLS implementations SHOULD use the SNI (Server Name
Indication) RFC6066 and APLN (Application-Layer Protocol Negotiation)
RFC7301 extensions.
This document supports TLS with Raw Public Keys (RPK) RFC7250 and
with Pre-Shared Keys (PSK).
In the RPK mode, the Client proves that it can use the RPK bound to
the token, and the Broker shows that it can use a certain RPK.  The
Broker needs access to the token to complete this exchange.
Therefore, for the RPK mode, the client must upload the access token
to the Broker as specified in app-authzinfo before initiating the
handshake.  The client MUST use its correct public key in the TLS
handshake and MUST specify this public key in the
SubjectPublicKeyInfo structure of the TLS handshake as described in
RFC7250.  The handshake only finishes if the Client and the Broker
are able to use their respective keying material.  While RFC 7250
allows independent negotiation of client and server use of raw public
keys, this document assumes that if RPK is used, it is negotiated to
be used by both parties.
An implementation that supports the RPK mode of this profile MUST at
least support the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
RFC7251.  Implementations of this profile MUST implement support for
the x25519 key-exchange group RFC8422,RFC8446.
In the PSK mode, the Client and the Broker show with the TLS
handshake that they can use the keying material that is bound to the
access token.  By default, the AS generates a symmetric proof-of-
possession key for the Client.
To use TLS 1.3 with pre-shared keys, the Client follows the PSK key
extension specified in RFC8446 using the key conveyed in the "cnf"
parameter of the AS response.  The same key is bound to the access
token in the "cnf" claim.  The Client can upload the access as
specified in app-authzinfo before initiating the handshake.  The
token MAY be, alternatively, provided as an "identity" in the
"identities" field in the client's "pre_shared_key" extension.
In PreSharedKey mode, the knowledge of the shared secret by the
Client and the Broker is used for mutual authentication between both
peers.
This document supports TLS with Raw Public Keys (RPK) RFC7250 and
with Pre-Shared Keys (PSK).  The TLS session setup follows I-D.ietf-
ace-dtls-authorize, as the profile applies to TLS equally well I-
D.ietf-ace-extend-dtls-authorize.  When there are exceptions to the
DTLS profile, these are explicitly stated in the document.  If TLS
1.2 is used, RFC7925 describes how TLS can be used for constrained
devices, alongside recommended cipher suites.  Additionally, TLS 1.2
implementations MUST use "Extended Master Secret" RFC7627 to
incorporate the handshake transcript into the master secret.  TLS
implementations SHOULD use the SNI (Server Name Indication) RFC6066
and APLN (Application-Layer Protocol Negotiation) RFC7301 extensions.
This document follows the procedures defined in Section 3.2.2 of I-
D.ietf-ace-dtls-authorize with the following exceptions.  The client
MUST upload the access token to the Broker using the method specified
in app-authzinfo before initiating the handshake.
This document follows the procedures defined in Section 3.3.2 of I-
D.ietf-ace-dtls-authorize with the following exceptions.
To use TLS 1.3 with pre-shared keys, the Client follows the PSK key
extension specified in RFC8446 using the key conveyed in the "cnf"
parameter of the AS response.  The same key is bound to the access
token in the "cnf" claim.  The Client can upload the token as
specified in app-authzinfo before initiating the handshake.  The
Client MUST indicate during the handshake which previously uploaded
access token it intends to use.  To do so, it MUST create a
"COSE_Key" or "JWK" structure with the "kid" that was conveyed in the
"rs_cnf" claim in the token response from the AS and the key type
"symmetric".  This structure is then included as the only element in
the "cnf" structure and used as a PSK identity in TLS.  As an
alternative to the access token upload, the client can provide the
most recent access token, JWT or CWT, as a PSK identity.
In contrast to I-D.ietf-ace-dtls-authorize, a client MAY NOT support
the cipher suite TLS_PSK_WITH_AES_128_CCM_8, but for TLS 1.2, MUST
support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as recommended in
RFC7525.
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
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.
The AUTH packet to continue authentication includes the
Authentication Method, which MUST be set to "ace" and Authentication
Data.  The Authentication Data MUST NOT be empty and contains an
8-byte nonce as a challenge for the Client
(authdata_challenge_broker_challenge).
The Client responds to this with an AUTH packet with a reason code
"0x18 (Continue Authentication)".  Similarly, the Client packet sets
the Authentication Method to "ace".  The Authentication Data in the
Client's response is formatted as shown in
authdata_challenge_client_response and includes the client nonce
length, the client nonce, and the signature or MAC computed over the
RS nonce concatenated with the client nonce using PoP key in the
token.
The AUTH packet to continue authentication includes the
Authentication Method, which MUST be set to "ace" and Authentication
Data.  The Authentication Data MUST NOT be empty and contains an
8-byte RS nonce as a challenge for the Client
(authdata_challenge_broker_challenge).
The Client responds to this with an AUTH packet with a reason code
"0x18 (Continue Authentication)".  Similarly, the Client packet sets
the Authentication Method to "ace".  The Authentication Data in the
Client's response is formatted as shown in
authdata_challenge_client_response and includes the the 8-byte Client
nonce, and the signature or MAC computed over the RS nonce
concatenated with the Client nonce using PoP key in the token.
During the CONNECT, if the Will Flag is set to 1, the Broker MUST
authorize the publication of the Will Topic and message using the
token's scope field.  The token or its introspection result MUST also
be cached to allow a Client's future PUBLISH and SUBSCRIBE packets.
The scope field contains the publish and subscribe permissions for
the Client.  The Broker uses the scope to match against the Topic
Name in a PUBLISH packet (including Will Topic in the CONNECT) or a
Topic Filter in a SUBSCRIBE packet.
The scope in the token is a single value.  For a JWT, the single
scope has an internal structure of a JSON array, and for a CWT, this
information is represented in CBOR following the I-D.ietf-ace-aif.
Using the Concise Data Definition Language (CDDL) RFC8610, the
specific data model for MQTT is: MQTT-OASIS-Standard-v5.  By default,
Wildcard Subscriptions are supported, and so, the topic filter may
include special wildcard characters.  The multi-level wildcard, '#',
matches any number of levels within a topic, and the single-level
wildcard, '+', matches one topic level.  The Broker MAY signal in the
CONNACK explicitly whether wildcard subscriptions are supported by
returning a CONNACK property "Wildcard Subscription Available".  A
value of 0 means that Wildcard Subscriptions are not supported.  A
value of 1 means Wildcard Subscriptions are supported.
The scope field contains the publish and subscribe permissions for
the Client.  Therefore, the token or its introspection result MUST be
cached to allow a Client's future PUBLISH and SUBSCRIBE packets.
During the CONNECT, if the Will Flag is set to 1, the Broker MUST
also authorize the publication of the Will Topic and message using
the token's scope field.  The Broker uses the scope to match against
the Topic Name in a PUBLISH packet (including Will Topic in the
CONNECT) or a Topic Filter in a SUBSCRIBE packet.
The scope in the token is a single value.  For a JWT, the single
scope is base64url encoded string with any padding characters
removed, which has an internal structure of a JSON array.  For a CWT,
this information is represented in CBOR.  The internal structure
follows the I-D.ietf-ace-aif.  Using the Concise Data Definition
Language (CDDL) RFC8610, the specific data model for MQTT is: MQTT-
OASIS-Standard-v5.  By default, Wildcard Subscriptions are supported,
and so, the topic filter may include special wildcard characters.
The multi-level wildcard, '#', matches any number of levels within a
topic, and the single-level wildcard, '+', matches one topic level.
The Broker MAY signal in the CONNACK explicitly whether wildcard
subscriptions are supported by returning a CONNACK property "Wildcard
Subscription Available".  A value of 0 means that Wildcard
Subscriptions are not supported.  A value of 1 means Wildcard
Subscriptions are supported.
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 the previous section,
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., a client
sending a PUBLISH for 'topic2/a' would be allowed, as the scope array
includes the '["topic2/#",["pub"]]'.
The Client MAY reauthenticate as a response to the PUBACK and SUBACK
that signal loss of authorization.  The Clients MAY also proactively
update their tokens, i.e., before they receive a packet with a "Not
authorized" return code.  To start reauthentication, the Client MUST
send an AUTH packet with the reason code "0x19 (Re-authentication)".
The Client MAY reauthenticate as a response to the PUBACK and SUBACK
that signal loss of authorization.  The Clients MAY also proactively
update their tokens, i.e., before they receive a packet with a 'Not
authorized' return code.  To start reauthentication, the Client MUST
send an AUTH packet with the reason code '0x19 (Re-authentication)'.
fails, the Broker MUST send a DISCONNECT with the reason code "0x87
(Not Authorized)".
fails, the Broker MUST send a DISCONNECT with the reason code '0x87
(Not Authorized)'.
The messages to be retained are indicated to the Broker by setting a
RETAIN flag in a PUBLISH packet.  This way, the publisher signals to
the Broker to store the most recent message for the associated topic.
Hence, the new subscribers can receive the last sent message from the
publisher for that particular topic without waiting for the next
PUBLISH packet.  The Broker MUST continue publishing the retained
messages as long as the associated tokens are valid.
The messages to be retained are indicated to the Broker by setting a
RETAIN flag in a PUBLISH packet.  This way, the publisher signals to
the Broker to store the most recent message for the associated topic.
Hence, the new subscribers can receive the last sent message from the
publisher for that particular topic without waiting for the next
PUBLISH packet.  The Broker MUST continue publishing the retained
messages as long as the associated tokens are valid.  In the MQTT
standard, if QoS is 0 for the PUBLISH packet, the Broker may discard
the retained message any time.  For QoS>1, the message expiry
interval dictates how long the retained message is kept.  However, it
is important that Broker avoids sending messages indefinitely for the
Clients that never update their tokens (i.e., the Client connects
briefly with a valid token, sends a PUBLISH packet with RETAIN flag
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.