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

[Cigdem Sengul <[e-mail]>]

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
]


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

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

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

[ Cigdem: OK]



> 2.  Authorizing Connection Requests
>
>    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>
>

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



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

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


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

[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.
]


> [...]
>
>    '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>
>

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


>
> 2.2.  Client Connection Request to the Broker (C)
>
> 2.2.1.  Client-Server Authentication over TLS and MQTT
>
>
>    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
>  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>
>

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

]


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

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

]



>
> 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>
>
[ Cigdem: Then I assume the previous comment is resolved.
]



>
> 2.2.3.  Transporting Access Token Inside the MQTT CONNECT
>
>    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>
>
> [Cigdem: Yes, you are correct. Made a note to simplify the language.
https://github.com/ace-wg/mqtt-tls-profile/issues/66
]




> [...]
>
>    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>
>

[ 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.
]


>
> [ ... ]
>    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>
>

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

>
> [...]
>
> 2.2.4.  Authentication Using AUTH Property
>
>    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>
>

[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".

]


>
> [ ... ]
> 2.2.5.  Token Validation
>
>
>    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>
>
[Cigdem:  Not sure, but for algorithms, I always find
"mandatory-to-implement" terminology rather than MUST.
]

>
>   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>
>
[Cigdem: Yes, they may be used interchangeably.
As my earlier suggestion, should use "PoP access token" instead?
]


>
> [ ... ]
>
> 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
>
>
>  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>
>

[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?
]


>
> 3.1.  PUBLISH Messages from the Publisher Client to the Broker
>
>
>    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>
>

[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.
]

>
> [ ... ]
>
> 3.2.  PUBLISH Messages from the Broker to the Subscriber Clients
>
>    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>
>
[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.
]


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

[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.
]



>
>
> 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>
>
[Cigdem: The messages with "Not authorized" acknowledgements should serve
as the warning.

]

>
> 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
>    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>
>
[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.
]

>
> 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>
>
[Cigdem: Both are typos. I will wait to make all toke/pop token/access
token uniform.
]

>
>    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>
>
[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. ]


>
> [...]
>
> 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>
>
[Cigdem: I can add it.]

>
> [...]
>
> 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>
>

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

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


>
>
> 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
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>