Re: [Ace] WGLC draft-ietf-ace-mqtt-tls-profile

[Daniel Migault <[e-mail]>]

Hi,

I reviewed the document and believe it is well written. I have some
comments/questions inline. I have also started the shepherd write up and
need the following elements to be performed or provided:

A) Are there existing implementations of the protocol?

B) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed

C)  Miscellaneous warnings: ( from the nits button on the datatracker)
  == Line 497 has weird spacing: '...rotocol  name ...'
  == Line 901 has weird spacing: '...rotocol  name ...'
  == The document seems to lack the recommended RFC 2119 boilerplate, even
if
     it appears to use RFC 2119 keywords. ( I think that is an error as I
can see the section 1.1.)
  == Unused Reference: 'RFC7250' is defined on line 1135, but no explicit
     reference was found in the text
 -- Unexpected draft version: The latest known version of
     draft-ietf-ace-oauth-authz is -34, but you're referring to -35.
 -- Unexpected draft version: The latest known version of
     draft-ietf-ace-oauth-params is -12, but you're referring to -13.
 -- Unexpected draft version: The latest known version of
     draft-ietf-ace-pubsub-profile is -00, but you're referring to -01.

D) The IANA section needs to be completed and you MAY start sending a
request for the expor
ted label. (See more details inline).
I also suggest you check with the IANA everything is fine.

Please find some comments inline to the current version of the draft.


Message Queuing Telemetry Transport (MQTT)-TLS profile of Authentication
     and Authorization for Constrained Environments (ACE) Framework
                   draft-ietf-ace-mqtt-tls-profile-07

[...]
2.  Authorizing Connection Requests

   This section specifies how Client connections are authorized by the
   MQTT Broker.  Figure 1 shows the basic protocol flow during
   connection set-up.  The token request and response use the token
   endpoint at the AS, specified in Section 5.6 of the ACE framework
   [I-D.ietf-ace-oauth-authz].  Steps (D) and (E) are optional and use
   the introspection endpoint, specified in Section 5.7 of the ACE
   framework.  The Client and the Broker use HTTPS to communicate to AS
   via these endpoints.  The Client and the Broker use MQTT to
   communicate between them.

   If the Client is resource-constrained, a Client Authorisation Server
   may carry out the token request on behalf of the Client, and later,
   onboard the Client with the token.
<mglt>
I understand the Client
Authorization Server as a proxy.
If that is not a well known term, I
am wondering if we need to have a
specific designation ? The current
designation might be confusing with
the AS, is not represented in the
figure and as far as I understand
is more related to a client than to
a server.  Client Authorization
Server Interface or Client
Authorization Server Client  ?

I am fine leaving it at is in any
case.

</mglt>

[...]

2.1.  Client Token Request to the Authorization Server (AS)

   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.6.1 of the ACE framework
   [I-D.ietf-ace-oauth-authz], however, it MUST set the profile
   parameter to 'mqtt_tls'.  The media format is 'application/ace+json'.
   The AS uses JSON in the payload of its responses to both to the
   Client and the RS.

<mglt>

This is perhaps my reading, but I
do expect however to bring a
contradiction to 5.6.1. This does
not seems the case here. I
understand that the ace_profile
MUST be set to mqtt_tls.

I am wondering if s/however ...
/with the profile set to mqtt_tls.
is not sufficient.

This is not a strong push from my
side either.

There is a nit "to both to"
</mglt>

   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), the AS
   issues an access token (Figure 1 (B)).  The response includes the
   parameters described in Section 5.6.2 of the ACE framework
   [I-D.ietf-ace-oauth-authz].  The returned token is a Proof-of-
   Possession (PoP) token by default.  This document follows RFC 7800
   [RFC7800] for PoP semantics for JWTs.  The PoP token includes a 'cnf'
   parameter with a symmetric or asymmetric PoP key.  Note that the

<mglt>

I am wondering if the PoP token
should not be the access token
instead ?  I would rather expect
the 'cnf' to contain the PoP, but I
must admit I am not too familiar
with terminology or usage so I
might be wrong.

</mglt>

[...]

   'cnf' parameter in the web tokens are to be consumed by the RS and
   not the Client.  For the asymmetric case, the PoP token may 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].

<mglt>
Same comment regarding the PoP token.
</mglt>

   The AS returns error responses for JSON-based interactions following
   Section 5.2 of RFC 6749 [RFC6749].  When CBOR is used, the
   interactions must implement Section 5.6.3 of the ACE framework
   [I-D.ietf-ace-oauth-authz].

2.2.  Client Connection Request to the Broker (C)

2.2.1.  Client-Server Authentication over TLS and MQTT

   The Client and the Broker MUST perform mutual authentication.  The
   Client MUST authenticate to the Broker either over MQTT or TLS.  For
   MQTT, the options are "None" and "ace".  For TLS, the options are
   "Anon" for an anonymous client, and "Known(RPK/PSK)" for Raw Public
   Keys (RPK) and Pre-Shared Keys (PSK), respectively.  Combined, client
   authentication has the following options:

   o  "TLS:Anon-MQTT:None": This option is used only for the topics that
      do not require authorization, including the "authz-info" topic.
      Publishing to the "authz-info" topic is described in
      Section 2.2.2.

   o  "TLS:Anon-MQTT:ace": The token is transported inside the CONNECT
      message, and MUST be validated using one of the methods described
      in Section 2.2.2.  This option also supports a tokenless
      connection request for AS discovery.

   o  "TLS:Known(RPK/PSK)-MQTT:none": For the RPK, the token MUST have
      been published to the "authz-info" topic.  For the PSK, the token
      MAY be, alternatively, provided in the "psk_identity".  The TLS
      session set-up is as described in DTLS profile for ACE
      [I-D.ietf-ace-dtls-authorize].

   o  "TLS:Known(RPK/PSK)-MQTT:ace": This option SHOULD NOT be chosen.
      In any case, the token transported in the CONNECT overwrites any
      permissions passed during the TLS authentication.

   It is RECOMMENDED that the Client follows TLS:Anon-MQTT:ace.

   The Broker MUST be authenticated 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



Sengul, et al.          Expires February 26, 2021               [Page 9]

Internet-Draft           MQTT-TLS profile of ACE             August 2020


   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.

<mglt>

I am considering two main ways to
authenticate the client
TLS:Anon-MQTT:ace and
TLS:Known(RPK/PSK)-MQTT:none. If a
server supports both it is unclear
to me how he can distinguish one
method of authentication versus the
other.

TLS:Known(PSK)-MQTT:none If the TLS
client provides a psk_identity, the
TLS server may take this as an
indication and lookup in the
authz-info to see if there is a
matching identity. This would
assume that that kid is mentioned
in the PoP.

TLS:Known(RPSK)-MQTT:none If the
client provides a
post_handshake_auth, this may be
taken as a hint that the client is
associated to a RPSK. The Broker
may instead chose to send a
CertificateRequest, and upon
receiving the Certificate message
verify there is a matching RPK.  If
the client does not provide the
post_handshake_auth, it is unclear
to me how the broker may
distinguish a
TLS:Known(RPSK)-MQTT:none from a
TLS:Anon-MQTT:ace.

In case there is no matching RPK, I
am wondering if the broker falls
back in a expected
TLS:Anon-MQTT:ace.

I might be missing something, but
it seems that the authentication
method is pre-agreed. Maybe some
text may be added here.

</mglt>

2.2.2.  authz-info: The Authorization Information Topic

   In the cases when the Client MUST transport the token to the Broker
   first,

<mglt>

Just to make sure I understand
properly, this corresponds to the
MQTT:None and the motivation to
publish the access token on the
authz_info topic to to further
proceed to an authentication. As a
result, the token is only provided
to the broker first to perform
TLS:Known(PSK/RPK-MQTT:None. Am I
missing something ?

</mglt>

the Client connects to the Broker to publish its token to the
   "authz-info" topic.  The "authz-info" topic MUST be publish-only
   (i.e. the Clients are not allowed to subscribe to it).  "authz-info"
   is not protected, and hence, the Client uses the "TLS:Anon-MQTT:None"
   option over a TLS connection.  After publishing the token, the Client
   disconnects from the Broker and is expected to reconnect using client
   authentication over TLS (i.e.  TLS:Known(RPK/PSK)-MQTT:none).

<mglt>
ok.
</mglt>

2.2.3.  Transporting Access Token Inside the MQTT CONNECT

   This section describes how the Client transports the token to the
   Broker (RS) inside the CONNECT message.  If this method is used, the
   Client TLS connection is expected to be anonymous, and the Broker is
   authenticated during the TLS connection set-up.  The approach
   described in this section is similar to an earlier proposal by
   Fremantle et al [fremantle14].

   After sending the CONNECT, the client MUST NOT send any packets other
   than DISCONNECT or AUTH that is in response to the broker AUTH until
   it has received a CONNACK.  Similarly, the server MUST NOT process
   any packets other than DISCONNECT or an AUTH that is sent in response
   to its AUTH before it has sent a CONNACK.

<mglt>

The wording seems quite complex. I
understand the text as saying: The
broker responds to a CONNECT from
the client with an AUTH.  A client
MUST only response to the broker
AUTH with DISCONNECT or AUTH.  Only
after receiving a CONNACK, the
client MAY start publishing or
receive subscription.

</mglt>

[...]

   The CONNECT message flags are Username, Password, Will retain, Will
   QoS, Will Flag, Clean Start, and Reserved.  Figure 8 shows how the
   flags MUST be set to use AUTH packets for authentication and
   authorisation, i.e. the username and password flags MUST be set to 0.
   An MQTT v5.0 RS MAY also support token transport using Username and
   Password to provide a security option for MQTT v3.1.1 clients, as
   described in Section 6.
<mglt>

Maybe that is clarified in section
6, but I am wondering if the text
clearly prevents the use of
username and password flags MUST
NOT be used with MQTT v5 client
even if they also support
MQTTv3.1.1 clients.

</mglt>

[ ... ]
   If necessary, the Broker MAY support session continuation, and hence,
   maintain and use client state from the existing session.  The session
   state kept at the server 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, QoS 1 and QoS 2 messages
   which have have not been completely acknowledged or 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.
<mglt>
have have

isn't "have" pending ... ?

and"," if .... or maybe the sentence may be split.

</mglt>

[...]

2.2.4.  Authentication Using AUTH Property

   To use AUTH, the Client MUST set the Authentication Method as a
   property of a CONNECT packet by using the property identifier 21
   (0x15).  This is followed by a UTF-8 Encoded String containing the
   name of the Authentication Method, which MUST be set to 'ace'.  If
   the RS does not support this profile, it sends a CONNACK with a
   Reason Code of '0x8C (Bad authentication method)'.

   The Authentication Method is followed by the Authentication Data,
   which has a property identifier 22 (0x16) and is binary data.  The
   binary data in MQTT is represented by a two-byte integer length,
   which indicates the number of data bytes, followed by that number of
   bytes.  Based on the Authentication Data, this profile allows:

   o  Proof-of-Possession using a challenge from the TLS session

   o  Proof-of-Possession via Broker generated challenge/response

<mglt>

At this stage it is unclear to me
how the RS knows or selected PoP of
its choice.

>From 2.2.4.1 it seems the
distinction is performed form the
length. It also means that both
method MUST be supported by the RS,
and the method is selected by the
client.

It might worth clarifying here
unless there are reasons for not
doing it I am missing.

</mglt>

[ ... ]
2.2.5.  Token Validation

   The RS MUST verify the validity of the token either locally (e.g. in
   the case of a self-contained token) or the RS MAY send an
   introspection request to the AS.  RS MUST verify the claims according
   to the rules set in the Section 5.8.1.1 of the ACE framework
   [I-D.ietf-ace-oauth-authz].

   To authenticate the Client, the RS validates the signature or the
   MAC, depending on how the PoP protocol is implemented.  HS256 and
   Ed25519 are mandatory to implement depending on the choice of

<mglt>

Seems to me that mandatory is
normative here and MUST implement
may be used instea

</mglt>

  symmetric or asymmetric validation.  Validation of the signature or
   MAC MUST fail if the signature algorithm is set to "none", when the
   key used for the signature algorithm cannot be determined, or the
   computed and received signature/MAC do not match.

[...]

2.2.6.1.  Unauthorised Request: Authorisation Server Discovery

   If the Client does not provide a valid token or omits the

<mglt>

I have not checked but it seems
that we are using different
designation for the token/access
token / PoP token. Maybe one should
pick a single designation.

</mglt>

[ ... ]

2.2.6.2.  Authorisation Success

   On success, the reason code of the CONNACK is '0x00 (Success)'.  If
   the Broker starts a new session, it MUST also set Session Present to
   0 in the CONNACK packet to signal a clean session to the Client.
   Otherwise, it MUST set Session Present to 1.  In case of an invalid
   PoP token, the CONNACK reason code is '0x87 (Not Authorized)'.

<mglt>
Same comment regarding the PoP token.
</mglt>

[ ...]

3.  Authorizing PUBLISH and SUBSCRIBE Messages

   To authorize a Client's PUBLISH and SUBSCRIBE messages, the Broker
   uses the scope field in the token (or in the introspection result).
   The scope field contains the publish and subscribe permissions for
   the Client.  The scope is a JSON array, each item following the
   Authorization Information Format (AIF) for ACE
   [I-D.bormann-core-ace-aif].  The specific data model for MQTT is:

 AIF-MQTT = AIF-Generic<topic_filter, permissions>
 AIF-Generic<topic_filter, permissions> = [* [topic_filter,permissions]]
 topic_filter = tstr
 permissions = [+permission]
 permission = "pub"/"sub"

<mglt>

I suspect that we will need to have
I-D.bormann-core-ace-aif out to
move this document.  white space is
missing after topic_filter, , maybe
that is to fit the line space
limit.  It is unclear to me at that
point what: "tstr" stands for.

</mglt>

                       Figure 5: AIF-MQTT data model

   Topic filters are implemented according to Section 4.7 of MQTT v5.0 -
   the OASIS Standard [MQTT-OASIS-Standard-v5] and includes special
   wildcard characters.  The multi-level wildcard, '#', matches any
   number of levels within a topic, and the single-level wildcard, '+',
   matches one topic level.

   An example scope field may contain:

 [["topic1", ["pub","sub"]], ["topic2/#",["pub"]], ["+/topic3",["sub"]]]

                          Figure 6: Example scope

   This access token gives publish ("pub") and subscribe ("sub")
   permissions to the 'topic1', publish permission to all the subtopics
   of 'topic2', and subscribe permission to all topic3, skipping one
   level.  If the Will Flag is set, then the Broker MUST check that the
   token allows the publication of the Will message (i.e. the Will Topic
   filter is found in the scope).

3.1.  PUBLISH Messages from the Publisher Client to the Broker

   On receiving the PUBLISH message, the Broker MUST use the type of
   message (i.e.  PUBLISH) and the Topic name in the message 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 message to 'topic2/a' would be allowed, as
   the scope array includes the '["topic2/#",["pub"]]'.

   If the Client is allowed to publish to the topic, the Broker must

<mglt>

I have the impression MUST would be
acceptable too.  I am not saying
"must" is not acceptable but I
would like we check this is not a
mistake.

</mglt>

[ ... ]

3.2.  PUBLISH Messages from the Broker to the Subscriber Clients

   To forward PUBLISH messages to the subscribing Clients, the Broker
   identifies all the subscribers that have valid matching topic
   subscriptions (i.e. the tokens are valid, and token scopes allow a
   subscription to the particular topic).  The Broker sends a PUBLISH
   message with the Topic name to all the valid subscribers.

   The Broker MUST NOT forward messages to the unauthorized subscribers.

<mglt>

from the text above these
subscribers seems more to me non
valid subscribers (for a topic).

I have the impression that invalid
token will not generate a CONNACK
in which case the RS will not even
possibly send a PUBLISH message.
If I am correct, I am wondering
whether the text below needs to be
mentioned

</mglt>

   There is no way to inform the Clients with invalid tokens that an
   authorization error has occurred other than sending a DISCONNECT
   message.  The Broker SHOULD send a DISCONNECT message with the reason
   code '0x87 (Not authorized)'.

3.3.  Authorizing SUBSCRIBE Messages

   In MQTT, a SUBSCRIBE message is sent from a Client to the Broker to
   create one or more subscriptions to one or more topics.  The
   SUBSCRIBE message may contain multiple Topic Filters.  The Topic
   Filters may include wildcard characters.

   On receiving the SUBSCRIBE message, the Broker MUST use the type of
   message (i.e.  SUBSCRIBE) and the Topic Filter in the message header
   to match against the scope field of the stored token or introspection
   result.  The Topic Filters MUST be equal or a subset of at least one

<mglt>

I have the impression that Topic
Filters MAY contain multiple
filters. and must match one filter
in the scope of the token not to be
rejected. But the subscription will
be considered for topics mentioned
in the  Topic Filters and mentioned
in the token.

The current text is not clear to me
but I suspect this is due to a nit.

</mglt>

   of the 'topic_filter' fields in the scope array found in the Client's
   token.

[ ... ]

4.  Token Expiration and Reauthentication

[...]

   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.7 of the ACE framework
   [I-D.ietf-ace-oauth-authz].  Token expirations may trigger the RS to
   send PUBACK, SUBACK and DISCONNECT messages with return code set to
   'Not authorized'.  After sending a DISCONNECT message, the network
   connection is closed, and no more messages can be sent.  However, as
   a response to the PUBACK and SUBACK, the Client MAY reauthenticate.
   The Clients MAY also proactively update their tokens, i.e. before
   they receive a message with a 'Not authorized' return code.

<mglt>

Just for my knowledge, there is no
possibility for the broker to send
any warning or initiate the
re-authentication.

</mglt>

[...]

   Authorized' return code to the Client.

6.  Reduced Protocol Interactions for MQTT v3.1.1

   This section describes a reduced set of protocol interactions for the
   MQTT v3.1.1 Clients.  An MQTT v5.0 Broker MAY implement these
   interactions for the MQTT v3.1.1 clients; MQTT v5.0 clients are NOT



Sengul, et al.          Expires February 26, 2021              [Page 19]

Internet-Draft           MQTT-TLS profile of ACE             August 2020


   RECOMMENDED to use the flows described in this section.  Brokers that
   do not support MQTT v3.1.1 clients return a CONNACK packet with
   Reason Code '0x84 (Unsupported Protocol Version)' in response to the
   connection requests.

<mglt>

I guess this has been discussed and
RECOMMENDED was preferred over MUST
NOT. If that is the case, I do not
recall the reason... and maybe
re-ask whether we shoudl not have
MUST NOT instead.

</mglt>

6.1.  Token Transport

   As in MQTT v5.0, The Token MAY either be transported before by
   publishing to the "authz-info" topic, or inside the CONNECT message.

<mglt>

It seems that Token is another
variant of access token/token...

I also suspect that the context As
in MQTT has been added after the
initial sentence and the starting
"The" of the initial sentence has
not been changed.

</mglt>

   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 messages 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.

<mglt>

Just for my understanding, a
published ticket that cannot be
validated ( not able to decrypt,
not able to authenticate, ..." will
be rejected in which case the PSK
RPK would be unknown to the broker.
The broker will not fallback to a
TLS:Anon as there is only one
method that is pre-agreed between
the client and the broker.

</mglt>

[...]

6.2.  Handling Authorization Errors

[...]
   o  CONNECT without a token: It is not possible to support AS
      discovery via sending a tokenless CONNECT message to the Broker.
      This is because a CONNACK packet in MQTT v3.1.1 does not include a
      means to provide additional information to the Client.  Therefore,
      AS discovery needs to take place out-of-band.  CONNECT attempt
      MUST fail.

<mglt>
The last sentence might be missing
tokenless or without token

</mglt>

[...]

7.  IANA Considerations

   This document registers 'EXPORTER-ACE-MQTT-Sign-Challenge' from
   Section 2.2.4.1 in the TLS Exporter Label Registry TLS-REGISTRIES
   [RFC8447].
<mglt>

This is section 12 I think.

There is a Recommended section. I
suspect you can ask for "Y".

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels
shows  a DTLS-OK column.

I believe you can start sending a
request [e-mail] see
section 17 of 8447.
</mglt>


   In addition, the following registrations are done for the ACE OAuth
   Profile Registry following the procedure specified in
   [I-D.ietf-ace-oauth-authz].

   Note to the RFC editor: Please replace all occurrences of "[RFC-
   XXXX]" with the RFC number of this specification and delete this
   paragraph.

   Name: mqtt_tls

   Description: Profile for delegating Client authentication and
   authorization using MQTT as the application protocol and TLS For
   transport layer security.

   CBOR Value:

   Reference: [RFC-XXXX]


8.  Security Considerations

[...]
   For MQTT v5.0, when a Client connects with a long Session Expiry
   Interval, the RS may need to maintain Client's MQTT session state
   after it disconnects for an extended period.  For MQTT v3.1.1, the
   session state may need to be stored indefinitely, as it does not have



Sengul, et al.          Expires February 26, 2021              [Page 23]

Internet-Draft           MQTT-TLS profile of ACE             August 2020


   a Session Expiry Interval feature.  The RS SHOULD implement
   administrative policies to limit misuse of the session continuation
   by the Client.

<mglt>

I am wondering if the broker could
not set a maximum session time and
let the client reconnect at least
for publisher clients. If MQTT is
running over TLS ( and TCP) the
broker might be able to detect when
subscriber are not present anymore.
This may result in messages being
lost, but I am wondering if that
would make sense.

</mglt>


On Tue, Sep 1, 2020 at 4:54 PM Daniel Migault <[e-mail]> wrote:

> Hi,
>
> This email starts a 2 weeks Working Group Last Call for
> draft-ietf-ace-mqtt-tls-profile. Please review the document available
> here [1] and provide your feed backs by September 15 2020.
>
> Yours,
> Jim and Daniel
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/
>
>
> --
> Daniel Migault
> Ericsson
>


-- 
Daniel Migault
Ericsson