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

From: Daniel Migault <[email-masked]>
Date: Tue, 1 Sep 2020 16:54:15 -0400

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

---

From: Daniel Migault <[email-masked]>
Date: Thu, 3 Sep 2020 22:58:01 -0400

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 [email-masked] 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 <[email-masked]> wrote:

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

-- 
Daniel Migault
Ericsson

---

From: Marco Tiloca <[email-masked]>
Date: Mon, 14 Sep 2020 18:13:53 +0200

Hi,

Please, find below some comments. I think the document is overall well
written and in a good shape.

Best,
/Marco

[General]

* Refer the AIF adopted draft rather than the individual submission.

* Some references are included twice side by side, e.g. RFC 4949 and RFC
7800.

[Section 1]

* Add an inline reference to RFC 8446 for TLS 1.3. I think it's good
adding also references to CoAP and CBOR(-bis).

[Section 2.2.1]

* In the paragraph on "TLS:Known(RPK/PSK)-MQTT:none", the last two
sentences can clarify that they apply to TLS 1.2. As to the analogous
alternative provision of the token in PSK mode for TLS 1.3, that can
point to "identity" in the "identities" entry of "Pre-Shared Key"
ClientHello Extension.

[Section 2.2.4.1]

* Section 2.2.4 said that the two-byte integer length indicates the
amount of following bytes within Authentication Data. However this
section refers to the two-byte length as only the token length, i.e. it
does not seem to cover also the MAC/Signature (whose length might be
assumed from the used algorithm), even though that's still part of
Authentication Data. Could you please confirm or clarify?

* It's worth making it explicit that the PoP key is used to compute the
MAC or the client signature.

* s/and, the server/and the server

* Remove the final closed parenthesis.

[Section 2.2.4.2]

* Shouldn't the Authentication Data in the AUTH message from the server
start with a 2-byte server nonce length?

* Like for the AUTH message from the client, see the comment above for
Section 2.2.4.1 about what the 2-byte length covers (i.e., here too I
would have expected it to cover also the MAC/signature, not just the nonce).

* Like for the comment above for Section 2.2.4.1, it's worth making it
explicit that the PoP key is used to compute the MAC or the client
signature.

[Section 2.2.5]

* s/RS MUST verify/the RS MUST verify

* Please, add references for HS256 and Ed25519.

[Section 3]

* s/to all topic3/to all 'topic3'

[Section 6.1]

* s/as a UTF-8/is a UTF-8

================================

On 2020-09-01 22:54, Daniel Migault 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
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se

---

From: Cigdem Sengul <[email-masked]>
Date: Sat, 19 Sep 2020 16:05:32 +0100

Hello,
Thank you, Daniel, Marco and Francesca for your reviews. Much appreciated.
I will start by responding to Daniel first.
Comments/Responses are inline.

> A) Are there existing implementations of the protocol?

[ Cigdem: This is still as I've explained in the previous IETF meeting:
 Implementation using the HiveMQ CE is a Java-based open source MQTT broker
that fully supports MQTT 3.x and MQTT 5.
https://github.com/michaelg9/HiveACEclient
<https://github.com/michaelg9/HiveACEclient>

The Mosquitto prototype was only v3.1.1:
https://github.com/ciseng/ace-mqtt-mosquitto
]

> required for full conformance with the provisions of BCP 78 and BCP 79 have

 [Cigdem: I will check with the others again, but do not expect issues.]

> C)  Miscellaneous warnings: ( from the nits button on the datatracker)
[Cigdem: Opened the issue, will fix in the next submission:
https://github.com/ace-wg/mqtt-tls-profile/issues/65
<https://github.com/ace-wg/mqtt-tls-profile/issues/65>

> I also suggest you check with the IANA everything is fine.

[ Cigdem: OK]

> I am fine leaving it at is in any

[ Cigdem: When first writing this draft, I've taken the Client
Authorization Server concept, from the now-expired actors
document. https://tools.ietf.org/html/draft-ietf-ace-actors-07
<https://tools.ietf.org/html/draft-ietf-ace-actors-07>

However, I could not find out what the workgroup replaced it with, if it
did.

> There is a nit "to both to"

[Cigdem: Will change: "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'. "

to:  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] with the profile
   parameter to 'mqtt_tls'.

Can remove "both to"
https://github.com/ace-wg/mqtt-tls-profile/issues/65
<https://github.com/ace-wg/mqtt-tls-profile/issues/65>
]

> with terminology or usage so I

[Cigdem:  I used the two interchangeably because the ACE framework document
says:
" When this specification uses the term "access token" it is assumed to be a
      PoP access token token unless specifically stated otherwise."

Btw, there is a typo in the ACE framework document: token appears twice in
the sentence.
]

> Same comment regarding the PoP token.

[Cigdem : Same response as above. If needed I can change to PoP access
token]

> method is pre-agreed. Maybe some

[Cigdem: Yes, I assumed the flow you mentioned:
If the client is using PSK to authenticate then, I assume Client Hello
includes pre_shared_key (as described in RFC 8446: 2.2.  Resumption and
Pre-Shared Key (PSK)).
For clients that want to do RPK,  I assumed they will do  "post_handshake_auth"
and the server will do a CertificateRequest, but if the client declines or
fails to authenticate, will expect authentication over MQTT:ace.

If the client TLS handshake includes PSK/RPK authentication information,
then the AS will look for whether a token has been submitted via authz-info.

Next, after processing the MQTT CONNECT message, it finds another token,
then it overwrites all the permissions set-up in TLS handshake.

I can add: "If the client fails to authenticate over TLS, the AS falls back
to  TLS:Anon-MQTT:ace."

Would that be more clear?

]

> TLS:Known(PSK/RPK-MQTT:None. Am I

[Cigdem: Yes, that is correct. If the client wants to authenticate over TLS
then it must use the authz-info to push the token.
(This is a must for RPK, and also a MUST depending on how it performs PSK)

Does it need to be more clear?

]

>    authentication over TLS (i.e.  TLS:Known(RPK/PSK)-MQTT:none).
[ Cigdem: Then I assume the previous comment is resolved.
]

> [Cigdem: Yes, you are correct. Made a note to simplify the language.
https://github.com/ace-wg/mqtt-tls-profile/issues/66
]

> even if they also support

[ Cigdem: Yes, this is clarified in Section 6 as:
"MQTT v5.0 clients are NOT RECOMMENDED to use the flows described in this
section."

We actually do not stop MQTTv5 clients to do password/username-based
authentication (we just don't want them to overload these flags for ace
authentication. So, preventing these flags to be used may be too much.
]

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

[That's a typo - will fix.
QoS1 and QoS2 messages which (1) have not been completely acknowledged or
(2) are pending transmission to client.
]

> unless there are reasons for not

[Cigdem: Yes, both options are supported and identified by length.
If the RS finds all the information it needs in the AUTH data to verify PoP
then it's doing TLS-session based verification.
If the RS needs more data, then it does challenge/response.
The draft says: "If the
   Authentication Data contains only the two-byte integer token length
   and the token, the RS MUST respond with an AUTH packet"

Since there is a MUST, I thought it was clear RS must support both options.
I can add "RS MUST support both options".

]

> normative here and MUST implement
[Cigdem:  Not sure, but for algorithms, I always find
"mandatory-to-implement" terminology rather than MUST.
]

> pick a single designation.
[Cigdem: Yes, they may be used interchangeably.
As my earlier suggestion, should use "PoP access token" instead?
]

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

> point what: "tstr" stands for.

[Cigdem: Noted the typo. tstr stands for text string. As it was not defined
AIF draft either, I assumed it iscommon knowledge.
I did lookup when I was writing it and found the definition here:
https://tools.ietf.org/html/draft-ietf-cbor-cddl-03
<https://tools.ietf.org/html/draft-ietf-cbor-cddl-03>
Should I be adding references to cddl?
]

> would like we check this is not a

[Cigdem: I think I should add an explanation that if the requirement comes
from MQTT standart, the draft uses "must".
All the musts for the profile are MUST.
]

> whether the text below needs to be
[CS: If the client doesn't have a valid token, it won't connect.
Once connected, the clients can send subscribe messages to several topics.
A subset of subscription requests may fail due to authorisation errors for
clients with valid tokens (their token does not cover that subscription
request).

Or the session is long, and client token may have expired (became invalid)
when the first publish message on this topic arrives at the RS.
So, RS has to check if subscriber tokens are valid.
]

> but I suspect this is due to a nit.

[Cigdem: Not sure I understand the concern in this sentence: "But the
subscription will
be considered for topics mentioned
in the  Topic Filters and mentioned
in the token."

Example: I asked to subscribe to "a/b" and [c/d], my token has the
following scopes ["a/*, c/*]
My subscription is granted for a/b and c/d, as a/b is a subset of a/* and
c/d is a subset of c/*, respectively.
]

> any warning or initiate the
[Cigdem: The messages with "Not authorized" acknowledgements should serve
as the warning.

]

> re-ask whether we shoudl not have
[Cigdem: Yes, I remember we opted for NOT RECOMMENDED, MQTT v5 clients
using this will just get a reduced set of functionality if they do, but
should not be harmed.
I think that's why we did not use MUST NOT. I am open to other views.
]

> "The" of the initial sentence has
[Cigdem: Both are typos. I will wait to make all toke/pop token/access
token uniform.
]

> the client and the broker.
[Cigdem: if the token cannot be validated at RS, the connection does not
succeed regardless of what the authentication method is.
That paragraph is trying to say that using MQTT v3.1.1 the RS cannot hint
to the client that its token is accepted or rejected. The client needs to
try to connect with TLS and see. ]

> tokenless or without token
[Cigdem: I can add it.]

> request [email-masked] see

[Cigdem : Will fix the Section number - puzzled how I got that wrong
OK for the rest]

> lost, but I am wondering if that
[Cigdem: We say: "The RS SHOULD implement
   administrative policies to limit misuse of the session continuation
   by the Client." This would include capping session lengths, but may be I
should say it more explicitly.
]
Thanks,
--Cigdem

---

From: Cigdem Sengul <[email-masked]>
Date: Sun, 20 Sep 2020 15:02:45 +0100

Hello Marco,
Thank you for the review. My responses are inline.
Kind regards,
--Cigdem

[Section 1]
> adding also references to CoAP and CBOR(-bis).
  [CS: Added to https://github.com/ace-wg/mqtt-tls-profile/issues/65
<https://github.com/ace-wg/mqtt-tls-profile/issues/65>, will be fixed in
the next submission]

> alternative provision of the token in PSK mode for TLS 1.3, that can point
> to "identity" in the "identities" entry of "Pre-Shared Key" ClientHello
> Extension.
>
>
[CS: I think it is better to change the wording to match what is defined
for TLS 1.3, as it is the recommended version.
Created new issues at https://github.com/ace-wg/mqtt-tls-profile/issues/69
 Will fix. ]

>
> [Section 2.2.4.1]
>
> * Section 2.2.4 said that the two-byte integer length indicates the amount
> of following bytes within Authentication Data. However this section refers
> to the two-byte length as only the token length, i.e. it does not seem to
> cover also the MAC/Signature (whose length might be assumed from the used
> algorithm), even though that's still part of Authentication Data. Could you
> please confirm or clarify?
>

[CS: This is because the Authentication Data explained under 2.2.4  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.
So, we have the total length of the entire Authentication Data,
Token length + token  + (total length - token length) of MAC data.
I hope this is more clear.

Do you think I should repeat what binary data is at the subsections rather
than explaining in 2.2.4?
]

> * Remove the final closed parenthesis.
[CS: Added to https://github.com/ace-wg/mqtt-tls-profile/issues/65
<https://github.com/ace-wg/mqtt-tls-profile/issues/65>, will be fixed in
the next submission]

> start with a 2-byte server nonce length?
[CS: the client is calculating a MAC over its nonce and server nonce and
sending it back, with the information of its nonce.
I assumed the RS would remember its nonce length]

> Section 2.2.4.1 about what the 2-byte length covers (i.e., here too I would
> have expected it to cover also the MAC/signature, not just the nonce).
>

[CS: Has my previous explanation clarified this?

client_nonce length + nonce
(the size of AUTH DATA - client_nonce_length)  of MAC  of
(client_nonce+server nonce)

[Section 6.1]
> * s/as a UTF-8/is a UTF-8

  [CS: Added to https://github.com/ace-wg/mqtt-tls-profile/issues/65
<https://github.com/ace-wg/mqtt-tls-profile/issues/65>, will be fixed in
the next submission]

> Ace mailing [email-masked]://www.ietf.org/mailman/listinfo/ace
>
>
> --
> Marco Tiloca
> Ph.D., Senior Researcher
>
> Phone: +46 (0)70 60 46 501https://www.ri.se
>

---

From: Marco Tiloca <[email-masked]>
Date: Sun, 20 Sep 2020 18:45:23 +0200

Hello Cigdem,

Thanks, please see my replies inline.

Best,
/Marco

On 2020-09-20 16:02, Cigdem Sengul wrote:
>     * Some references are included twice side by side, e.g. RFC 4949
>     and RFC 7800. 
>
>      
>
>     [Section 1]
>
>     * Add an inline reference to RFC 8446 for TLS 1.3. I think it's
>     good adding also references to CoAP and CBOR(-bis).
>
>
>  
> <https://github.com/ace-wg/mqtt-tls-profile/issues/65>, will be fixed
> in the next submission]  
>
>  
>
>     [Section 2.2.1]
>
>     sentences can clarify that they apply to TLS 1.2. As to the
>     analogous alternative provision of the token in PSK mode for TLS
>     1.3, that can point to "identity" in the "identities" entry of
>     "Pre-Shared Key" ClientHello Extension.
>
>
> [CS: I think it is better to change the wording to match what is
> defined for TLS 1.3, as it is the recommended version.
>     * Section 2.2.4 said that the two-byte integer length indicates
>     the amount of following bytes within Authentication Data. However
>     this section refers to the two-byte length as only the token
>     length, i.e. it does not seem to cover also the MAC/Signature
>     (whose length might be assumed from the used algorithm), even
>     though that's still part of Authentication Data. Could you please
>     confirm or clarify?
>
>
> Do you think I should repeat what binary data is at the subsections
> rather than explaining in 2.2.4?
> ]

==>MT
So the Authentication Data includes some <Length ; Content> binary data,
possibly followed by some extra data (here a MAC/Signature). Correct?

I think it's worth clarifying this when introducing the Authentication
Data, and say what is part of the binary data here in Section 2.2.4.1.
<==

>
>
>     * It's worth making it explicit that the PoP key is used to
>     compute the MAC or the client signature. 
>
>
> <https://github.com/ace-wg/mqtt-tls-profile/issues/65>, will be fixed
> in the next submission]  
>  
>
>     [Section 2.2.4.2]
>
>     * Shouldn't the Authentication Data in the AUTH message from the
>     server start with a 2-byte server nonce length?
>
> [CS: the client is calculating a MAC over its nonce and server nonce
> and sending it back, with the information of its nonce. 

==>MT
I was referring to the AUTH packet from the server, including its RS
challenge.

The message is still including Authentication Data, and in any other
case this seems to start with a 2-byte length field, as also described
in Section 2.2.4.

If that length field is actually optional, I can see it might be omitted
here, since the client is supposed to get always an 8-byte nonce from
the server.
<==

>  
>
>
>     * Like for the AUTH message from the client, see the comment above
>     for Section 2.2.4.1 about what the 2-byte length covers (i.e.,
>     here too I would have expected it to cover also the MAC/signature,
>     not just the nonce).
>
>

==>MT
Yes, I think similar clarifications would help here in Section 2.2.4.2.
<==

>
>
>     * Like for the comment above for Section 2.2.4.1, it's worth
>     making it explicit that the PoP key is used to compute the MAC or
>     the client signature.
>
>
>     [Section 2.2.5]
>
> <https://github.com/ace-wg/mqtt-tls-profile/issues/65>, will be fixed
> in the next submission]    
>  
>
>
>>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
Marco Tiloca
Ph.D., Senior Researcher

---

From: Cigdem Sengul <[email-masked]>
Date: Sun, 20 Sep 2020 22:18:22 +0100

Hello Marco,
Responses inline.

> Data, and say what is part of the binary data here in Section 2.2.4.1.
[CS:  I think I may introduce ASCII art to explain this.
The content of Authentication Data for 2.2.4.1 is: Token length (2B)
+token+Mac computed over the content from the TLS exporter.
i.e, it is inclusive of the MAC. T

Actually, Authentication Data is defined before the subsections 2.2.4.1 and
2.2.4.2, under 2.2.4, because it is common to both subsections, just its
content varies. The text says:
"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."

Then, the subsection explains what is in the Authentication Data content
(ie. binary data part) and may include additional length fields.
I think this is where the confusion stems from - the multiple length
fields.
]

> The message is still including Authentication Data, and in any other case
> this seems to start with a 2-byte length field, as also described in
> Section 2.2.4.
>
> here, since the client is supposed to get always an 8-byte nonce from the
> server.
> <==
>
> [CS: That was the reason - the spec defined the nonce as 8-byte. And as it
did not make its size optional, the Authentication Data does not include
the nonce size.
]

---

From: Daniel Migault <[email-masked]>
Date: Mon, 21 Sep 2020 11:06:34 -0400

Hi Cigdem,

Please find my quick answer. Note these answers/comments are based on your
response and what I remember from the document. That should be sufficient
to clear most of them. I preferred to post the response earlier.

Yours,
Daniel

On Sat, Sep 19, 2020 at 11:05 AM Cigdem Sengul <[email-masked]>
wrote:

>  Implementation using the HiveMQ CE is a Java-based open source MQTT
> broker that fully supports MQTT 3.x and MQTT 5.
<mglt>
Thanks. I have updated the shepherd writeup.
</mglt>

>  [Cigdem: I will check with the others again, but do not expect issues.]
<mglt>
Please note that all co-author must provide a statement on the mailing
list.
</mglt>

> However, I could not find out what the workgroup replaced it with, if it
I guess the response may depend on where the draft will be reactivated or
not.
</mglt>

>    [I-D.ietf-ace-oauth-authz] with the profile
works for me. Thanks.
</mglt>

> [Cigdem:  I used the two interchangeably because the ACE framework
> document says:
Thanks for the clarification.
</mglt>

> [Cigdem : Same response as above. If needed I can change to PoP access
<mglt>
I am fine either ways.
</mglt>

> and the server will do a CertificateRequest, but if the client declines
> or fails to authenticate, will expect authentication over MQTT:ace.
>
<mglt>
Unless I am missing something in TLS 1.3 or in ACE. The client can
authenticate with a Post Handshake Client Authentication or during the TLS
base handshake (appendix E.1.2). In the second case ,  I do not see any
specific extensions that the client provides to indicate it supports the
client authentication during the handshake. It seems the server logic that
decides to send a CertificateRequest
</mglt>

> I can add: "If the client fails to authenticate over TLS, the AS falls
> back to  TLS:Anon-MQTT:ace."
>
<mglt>
This means that MQTT server will send a CertificateRequest, If an empty
Certificate is received from the client and the client has provided a
post_handshake extension, the MQTT server will try a post handshake
exchange.
In both cases, the client authentication may fail because the server is
unable to verify the signature or because no signature is provided.  If the
signature fails, TLS exchange is aborted. So MQTT authentication is only
considered if the client has not been authenticated via TLS due to the
absence of a signature. In this case, it will use ace authentication during
the CONNECT message.

If TLS client is authenticated, the MQTT server will look for at authz_info
right after the TLS exchange. Then looking at the CONNECT.

Am I correct ?

I think that originally, my comment was here as I expected that a
server could support a single mode, but it seems the MQTT server needs to
support all modes. Correct ? If so, maybe that could be clarified as well
as the specific logic of the server.

</mglt>

> [Cigdem: Yes, that is correct. If the client wants to authenticate over
> TLS then it must use the authz-info to push the token.
<mglt>
If I got it right sounds it might be clear enough.
</mglt>

> [ Cigdem: Then I assume the previous comment is resolved.
yes.
</mglt>

> If the RS finds all the information it needs in the AUTH data to verify
> PoP then it's doing TLS-session based verification.
<mglt>
I think, that would be preferred to add the clarification.
</mglt>

> "mandatory-to-implement" terminology rather than MUST.
<mglt>
I do not have strong feeling, but how I see this is 1) you define a
protocol and 2) you have protocols that MUST be implemented. These protocol
will have to evolve over time and MUST will move to MUST- -> SHOULD ->
SHOULD NOT -> MUST NOT. AT east I am probably biased with how IPsec does.
</mglt>

> [Cigdem: Noted the typo. tstr stands for text string. As it was not
> defined AIF draft either, I assumed it iscommon knowledge.
<mglt>
I would say so unless there is a strong reason not to.
</mglt>

> All the musts for the profile are MUST.
<mglt>
So must has also a different meaning than MUST in IETF language. So all
must cannot be given that meaning. I suspect that either we put MUST or add
an explanation line that clarify the meaning (origin) of the must.
</mglt>

> c/d is a subset of c/*, respectively.
<mglt>
Maybe I misread the sentence you quoted.
</mglt>

>    by the Client." This would include capping session lengths, but may be
> I should say it more explicitly.
> ]
> Thanks,
> --Cigdem
>
>
>>
>>

-- 
Daniel Migault
Ericsson

---

From: Cigdem Sengul <[email-masked]>
Date: Tue, 22 Sep 2020 21:37:46 +0100

Dear Daniel,

Thank you very much for the responses. Mine are inline as well.
Kind regards,
--Cigdem

> decides to send a CertificateRequest

[Cigdem: TLS 1.3:
""When the client has sent the “post_handshake_auth” extension (see Section
4.2.6), a server MAY request client authentication
at any time after the handshake has completed by sending a
CertificateRequest message. The client MUST respond with the
appropriate Authentication messages (see Section 4.4). If the client
chooses to authenticate, it MUST send Certificate,
CertificateVerify, and Finished. If it declines, it MUST send a Certificate
message containing no certificates followed by
Finished."

So, my understanding the client may not authenticate during
post_handshake_auth. Cllient authentication over TLS can be configured
optional at the server, and the server can tolerate an empty certificate
list. In this case, I assumed that the server checks the client
verification result and falls back to authenticating via MQTT connect.

Again, if any of the handshake fails - PSK/RPK aborts (different than empty
certificate list), authentication fails.
]

> absence of a signature. In this case, it will use ace authentication during

[Cigdem : Yes, actually, this is what I described above. Due to absence of
a certificate, I suggest it can fall back to CONNECT]

>
> If TLS client is authenticated, the MQTT server will look for at
> authz_info right after the TLS exchange. Then looking at the CONNECT.
>

[Cigdem: If TLS client managed to authenticate, then the MQTT server may
have already used what was submitted through authz_info.
i.e., if it is through RPK, it would assume to find it mathching rpk bound
to the pre-submitted token via authz-info.]

> as the specific logic of the server.

[Cigdem: I assumed some flexibility, i.e PSK or RPK; if client does not
submit an RPK, fall back to CONNECT.
If this is not acceptable, I can clarify more strictly a single mode]

>> [Cigdem: I think I should add an explanation that if the requirement
>> comes from MQTT standart, the draft uses "must".
[Cigdem: This seems to be creating a confusion with others too. Then I
remove must/should etc. language, and just say: "If the client is allowed
to publish to the topic, the RS publishes the message to all valid
subscribers of the topic."]

---

From: Daniel Migault <[email-masked]>
Date: Tue, 22 Sep 2020 21:31:53 -0400

Hi Cigdem,

Thanks for the resposnes. Please find my comments inline.

Yours,
Daniel

On Tue, Sep 22, 2020 at 4:37 PM Cigdem Sengul <[email-masked]>
wrote:

>> Please find my quick answer. Note these answers/comments are based on
>> your response and what I remember from the document. That should be
>> sufficient to clear most of them. I preferred to post the response earlier.
>>
>> Yours,
>> Daniel
>>
> ""When the client has sent the “post_handshake_auth” extension (see
> Section 4.2.6), a server MAY request client authentication
> CertificateVerify, and Finished. If it declines, it MUST send a
> Certificate message containing no certificates followed by
> Finished."
>
> Again, if any of the handshake fails - PSK/RPK aborts (different than
> empty certificate list), authentication fails.
> ]
>
<mglt>
Just one clarification. TLS 1.3 provides two ways to authenticate the
client. One way is sending a certificaterequest during the TLS handshake
and another way is to send it after the handshake occurs. The ability to
support the first authentication is not advertised by the TLS client. The
ability to support the second is advertised with the post_handshake_auth
extension. I just wanted to make sure we agreed there are two ways.
</mglt>

> a certificate, I suggest it can fall back to CONNECT]
<mglt>
You are correct. What might need to be specified is that the server MUST
support the two ways to authenticate the client. It MUST try during the
handshake and if the client as not provided the sufficient credentials and
the client has the post_handshake_auth, it MUST send one after the
hanshake. The reason I think that maybe more text is needed is that I have
the impression  a  minimal TLS server implementation may not necessary
support both authentications. This would prevent  the use of an TLS
implementation that only supports post_authentication for example.
Similarly, I am wondering if the MQTT client does not have similar
requirements regarding the support of TLS authentication as well as the
CONNECT or if it may support only one. I tend to think that the client may
only support only one way.

To sum up, I am just trying to evaluate how to prevent a situation where
the client will not be abel to authenticate itself to the server.
</mglt>

> <mglt>I think we agree.</mglt>

> If this is not acceptable, I can clarify more strictly a single mode]
<mglt>
So just re-stating my previous comment. I think we may rovide some text so
minimal or restricted implementations of MQTT / TLS guarantee the
interoperability between client and server.
</mglt>

> subscribers of the topic."]

<mglt>
looks clearer to me as well.
</mglt>
-- 
Daniel Migault
Ericsson

---

From: Cigdem Sengul <[email-masked]>
Date: Wed, 23 Sep 2020 14:10:34 +0100

Hello Daniel,

My responses are as follows:

<mglt>
> extension. I just wanted to make sure we agreed there are two ways.

[Cigdem: Yes, I agree. In both cases, what I read is: "If the client does
not send any certificates (i.e., it sends an empty
   Certificate message), the server MAY at its discretion either
   continue the handshake without client authentication or abort the
   handshake with a "certificate_required" alert."
I suggest continue the handshake and fallback to MQTT Connect
authentication for the RPK case.
]

> the client will not be abel to authenticate itself to the server.

[Cigdem: I think what I would prefer is that: the MQTT client will support
one way (one of PSK, or RPK, or over MQTT Connect then).
The server MAY support multiple ways.
Given we recommend the MQTT Connect for client authentication, the server
MUST implement that.
(That's why if RPK fails, MQTT connect can be fallback.)

If we agree, I will revise the document.
]

Kind regards,
--Cigdem

---

From: Daniel Migault <[email-masked]>
Date: Wed, 23 Sep 2020 13:58:43 +0000

Hi Cigdem,

This works for me. Thanks for the responses.

Yours, Daniel
________________________________
From: Ace <[email-masked]> on behalf of Cigdem Sengul <[email-masked]>
Sent: Wednesday, September 23, 2020 9:10 AM
To: Daniel Migault <[email-masked]>
Cc: Ace Wg <[email-masked]>
Subject: Re: [Ace] WGLC draft-ietf-ace-mqtt-tls-profile

Hello Daniel,

<mglt>
Just one clarification. TLS 1.3 provides two ways to authenticate the client. One way is sending a certificaterequest during the TLS handshake and another way is to send it after the handshake occurs. The ability to support the first authentication is not advertised by the TLS client. The ability to support the second is advertised with the post_handshake_auth extension. I just wanted to make sure we agreed there are two ways.
</mglt>

[Cigdem: Yes, I agree. In both cases, what I read is: "If the client does not send any certificates (i.e., it sends an empty
   Certificate message), the server MAY at its discretion either
   continue the handshake without client authentication or abort the
   handshake with a "certificate_required" alert."
I suggest continue the handshake and fallback to MQTT Connect authentication for the RPK case.
]

[Cigdem : Yes, actually, this is what I described above. Due to absence of a certificate, I suggest it can fall back to CONNECT]

<mglt>
You are correct. What might need to be specified is that the server MUST support the two ways to authenticate the client. It MUST try during the handshake and if the client as not provided the sufficient credentials and the client has the post_handshake_auth, it MUST send one after the hanshake. The reason I think that maybe more text is needed is that I have the impression  a  minimal TLS server implementation may not necessary support both authentications. This would prevent  the use of an TLS implementation that only supports post_authentication for example.
Similarly, I am wondering if the MQTT client does not have similar requirements regarding the support of TLS authentication as well as the CONNECT or if it may support only one. I tend to think that the client may only support only one way.

To sum up, I am just trying to evaluate how to prevent a situation where the client will not be abel to authenticate itself to the server.
</mglt>

[Cigdem: I think what I would prefer is that: the MQTT client will support one way (one of PSK, or RPK, or over MQTT Connect then).
The server MAY support multiple ways.
Given we recommend the MQTT Connect for client authentication, the server MUST implement that.
(That's why if RPK fails, MQTT connect can be fallback.)

Kind regards,
--Cigdem