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

Commentary: A few notes looking at the diff from -13 to -14 as last called .
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)).
On receipt of the token request, the 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)).
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.
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.
TLS:Anon,MQTT:ace: The token is transported inside the CONNECT
packet and MUST be validated using one of the methods described in
app-authzinfo.  This option also supports a tokenless connection
request for AS discovery.  As per I-D.ietf-ace-oauth-authz, a
separate step is needed to determine whether the discovered AS URI
is authorized to act as an AS.
TLS:Anon,MQTT:ace: The token is transported inside the CONNECT
packet and MUST be validated using one of the methods described in
app-authzinfo.  This option also supports a tokenless connection
request for AS discovery.  As per the I-D.ietf-ace-oauth-authz, a
separate step is needed to determine whether the discovered AS URI
is authorized to act as an AS.
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).
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).
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.
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 omit support
for 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.
This document supports TLS with Raw Public Keys (RPK) RFC7250 and
with Pre-Shared Keys (PSK).  The TLS session setup follows the 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 the "Extended Master Secret" extension
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 so the TLS handshake authenticates as much of the
protocol context as possible.
This document follows the procedures defined in Section 3.2.2 of the
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.
To use TLS 1.3 with pre-shared keys, the Client utilizes 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.  When
using a previously uploaded token, 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 the
encoded value of that "cnf" structure 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 omit support
for the cipher suites TLS_PSK_WITH_AES_128_CCM_8 and
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, but for TLS 1.2, MUST support
TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 for PSK and
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for RPK, as recommended in
RFC7525 (and adjusted to be a PSK cipher suite as appropriate).
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.
is important that the 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.