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

From: Jim Schaad <[email-masked]>
Date: Mon, 2 Mar 2020 13:11:33 -0800

Hannes,

I am having a bit of an issue over the last paragraph below and I am not sure exactly where the boundary is supposed to be between OAuth and ACE anymore.  From the comments that you made during the development of the ACE OAuth framework, there was a big effort to try and make sure that the framework can be used with JSON, and with HTTP.  I have implemented a version of the protocol that is using both JSON and HTTP in order to get the necessary POP keys for my MQTT client/server pair.   

That said, I also am planning to be on the call next Monday.

Jim

-----Original Message-----
From: Ace <[email-masked]> On Behalf Of Hannes Tschofenig
Sent: Friday, February 28, 2020 12:59 AM
To: Cigdem Sengul <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03

Hi Cigdem,

Thanks for your quick response.

>From the text you cited regarding MQTT v5 it is not backwards compatible to version 3.1.1. The exact impact of working between two devices of different versions has not been described in the spec either. The follow sentence in your introduction can easily give readers the impression that the two versions are backwards compatible. Here is the sentence:

" It is expected that MQTT
   deployments will retain backward compatibility for MQTT v3.1.1
   clients, and therefore, this document also describes a reduced set of
   protocol interactions for MQTT v3.1.1 - the OASIS Standard
   [MQTT-OASIS-Standard].
"

Maybe you want to change the wording a little bit.  I think the reason why you want to describe a solution for v3.1.1 is that this is the widely deployed version.

Regarding the broker term: It is probably a matter of taste but I would refer to the terms used in the spec and would not replicate the terminology from the OASIS MQTT specs in the draft. Someone who implements the draft will have to become familiar with MQTT anyway. But that’s just me. For example, I often see people using the term “certificate authorities (CA)” in their write-ups. RFC 5280 defines and uses the term “certification authority (CA)". While the two sound and look similar only one is actually correct.

I noticed you have put a normative dependency on [I-D.palombini-ace-coap-pubsub-profile]. I don't think it is necessary because it is not a requirement to implement the spec. You could use it on top of it -- or you could use something else as well. I would move it to the informative part. The added benefit of doing that is that you do not block your spec till that draft becomes RFC. On the other hand, RFC 6749, RFC 7800, and I-D.ietf-ace-cwt-proof-of-possession cannot be informative references when you use PoP tokens in your solution.

You might be interesting to hear that there is currently no way to obtain the keys for a PoP token over HTTP, which your solution requires. The virtual interim meeting in the OAuth group should probably be of interest to you.

Ciao
Hannes

From: Cigdem Sengul <[email-masked]>
Sent: Tuesday, February 25, 2020 3:10 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ace] draft-ietf-ace-mqtt-tls-profile-03

Hello Hannes,

We used  broker as it is a widely accepted term in the MQTT Community for "server" e.g., majority of the provider would list also a broker implementation to refer to their server implementation.

With respect to whether 3.1,1 clients talking to v5, there may be some issues. This is what the spec says:

Non-normative Comment
If the Server distributes Application Messages to Clients at different protocol levels (such as MQTT V3.1.1) which do not support properties or other features provided by this specification, some information in the Application Message can be lost, and applications which depend on this information might not work correctly.

The spec also defines a protocol version error message:
If the [Client's] Protocol Version [in the CONNECT packet] is not 5 and the Server does not want to accept the CONNECT packet, the Server MAY send a CONNACK packet with Reason Code 0x84 (Unsupported Protocol Version) and then MUST close the Network Connection

So, whether a broker provides dual support would depend on the provider. E.g., the Mosquitto broker supports the different protocol versions.

Thanks,
--Cigdem

On Tue, Feb 25, 2020 at 10:01 AM Hannes Tschofenig <mailto:[email-masked]> wrote:
Hi Cigdem, Hi Anthony, Hi Paul,

Why are you using the term MQTT broker? My understanding of the MQTT spec is that there are only clients and servers - nothing more.

Is a MQTT v3.1.1 client able to talk to a MQTT v5 server? Would a MQTT v3.1.1 client talk to a MQTT v5 client via a server that supports both v3.1.1 and v5?

Ciao
Hannes

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
Ace mailing list
mailto:[email-masked]
https://www.ietf.org/mailman/listinfo/ace
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________
Ace mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ace

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 9 Mar 2020 20:01:04 +0000

Hi Cigdem,

Following the OAuth virtual interim meeting call today I wonder whether it makes sense to describe how the key transport with the PoP token using the communication between the client and the authorization server over the HTTP interface works.

Ciao
Hannes

From: Hannes Tschofenig
Sent: Friday, February 28, 2020 11:08 AM
To: Cigdem Sengul <[email-masked]>
Cc: [email-masked]
Subject: RE: [Ace] draft-ietf-ace-mqtt-tls-profile-03

  *   I plan to join. I  have been aware of the issue, but could not follow how it was planned to be resolved.
  *   I was looking at this: draft-ietf-oauth-pop-key-distribution

Yes, that’s what the group wanted to do. Now, new ideas showed up on the radar that are incompatible with that approach that offer a much tighter integration with HTTP signing.

Ciao
Hannes

---

From: Cigdem Sengul <[email-masked]>
Date: Mon, 9 Mar 2020 23:28:53 +0000

Hello Hannes,

I will summarise below what I understood and clarify where I got confused
(which I tried to in the interim meeting)
 and then would need the group feedback for the next steps.

I became aware that the key distribution may be an issue after the
e-mail thread: "Transporting different types of cnf objects - CBOR vs JSON"
that spanned June-Oct, 2019, in the ace mailing list, where you wrote:
"We have standardized the transport of this additional information in ACE for
use with CoAP but for HTTP we decided to do the work on OAuth, where it got
stuck because the IoT-interested people are not there and the Web folks
want something else."

Then, I was under the impression that I would need to wait for the
draft-ietf-oauth-pop-key-distribution
<https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-07>.
(Even though the prototype implementation I used worked with HTTP/JSON
equivalent for COAP/CBOR in draft-ietf-ace-oauth-authz )

That's why is responded to this email thread saying I am aware of the
issue.
After Jim's email, I understood that the issue may be resolved.

For the MQTT-TLS profile, the following is needed:
1) To be able to use HTTP to talk to AS for /token and /introspect
interfaces. I was aware that this was supported now
in draft-ietf-ace-oauth-authz:
    "If the RS is online, validation can be handed over to the AS using
token introspection (see messages D and E) over HTTP or CoAP".
    In 5.6 Token endpoint: "The endpoint may, however, be exposed over
HTTPS as in classical OAuth or even other transports."

2) mqtt_tls draft introduces the ace+json media type, as  Jim wrote: "I
would argue that the first draft using such a media type would be the
right place
to specify it. " in the thread "Transporting different types of cnf objects
- CBOR vs JSON".

3)  What I wasn't aware, and realised after Jim's email was that
draft-ietf-ace-oauth-params, which defines the cnf and rs_cnf
parameters say, supports JSON:
"Note that although all examples are shown in CBOR [RFC7049],
JSON [RFC8259] MAY be used as an alternative for HTTP-based
   communications, as specified in [I-D.ietf-ace-oauth-authz]."

I may be missing something but what is left for MQTT-TLS profile to define
when  draft-ietf-ace-oauth-authz  +   draft-ietf-ace-oauth-params put
together?

Kind regards,
--Cigdem

On Mon, Mar 9, 2020 at 8:01 PM Hannes Tschofenig <[email-masked]>
wrote:

> Hi Cigdem,
>
>
>
> Following the OAuth virtual interim meeting call today I wonder whether it
> makes sense to describe how the key transport with the PoP token using the
> communication between the client and the authorization server over the HTTP
> interface works.
>
>
>
> Ciao
>
> Hannes
>
>
>
>
>
> *From:* Hannes Tschofenig
> *Sent:* Friday, February 28, 2020 11:08 AM
> *To:* Cigdem Sengul <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* RE: [Ace] draft-ietf-ace-mqtt-tls-profile-03
>
>
>
>    - I plan to join. I  have been aware of the issue, but could not
>    follow how it was planned to be resolved.
>    - I was looking at this: draft-ietf-oauth-pop-key-distribution
>
>
>
> Yes, that’s what the group wanted to do. Now, new ideas showed up on the
> radar that are incompatible with that approach that offer a much tighter
> integration with HTTP signing.
>
>
>
> Ciao
> Hannes
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>