Re: [Ace] Certificate processing for MQTT

Hello Jim,

Thank you for your email. I am in the process of revising the document for
the December update agreed in Singapore, so these comments are extremely
helpful.
Comments are inline.

On Thu, Dec 5, 2019 at 6:19 AM Jim Schaad <ietf@augustcellars.com> wrote:

> I got to the point of needing to start producing and validating
> certificates
> for MQTT and started running into some questions as well as starting to
> pickup some odd information that this document does not point to.
>
> 1.  Should probably reference the mqtt(s) URI scheme, I am however somewhat
> irritated that it is not a registered scheme with IANA.
>

Indeed, we used MQTT over TLS to mean MQTTS, though it is not mentioned
explicitly in the MQTT v5 OASIS spec,
but here: https://github.com/mqtt/mqtt.github.io/wiki/URI-Scheme
Do you suggest we reference this?
The latest I know: "The URI scheme has been discussed by the technical
committee a few times. The proposal was to produce a committee note rather
than make it a formal part of the spec."
based on this - https://github.com/mqtt/mqtt.github.io/issues/41
I will see if I can find more information from OASIS.

2.  Has OASIS done anything sort of document for certificate validation.  As
> an example is there an OID defined for extended key usage?
>

This is what is mentioned in the MQTT v5 for authenticating the AS with a
certificate:
"Implementations providing MQTT service for multiple hostnames from a
single IP address should be aware of the Server Name Indication extension
to TLS defined in section 3 of [RFC6066]
<https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#RFC6066>.
This allows a Client to tell the Server the hostname of the server it is
trying to connect to."

I also found the following information when first writing the draft:
https://www.oasis-open.org/committees/download.php/50161/X-MQTT-Security.txt
that goes into some detail but did not cite it because it did not look
official. However, it at least mentions things like TLS versions and
certificate types.

>
> 3.  What should be said about matching data in the response from the AS and
> the certificate.  What should be said about matching for raw public keys.
> I
> think that later is easy as it should just match the rs_cnf returned from
> the AS, but I don't know what should be said for certificates.
>

At the moment I have the following text:

The Broker MUST be authenticated during TLS handshake.  If the Client
   authentication included TLS:Known(RPK/PSK), then the Broker is
   authenticated using the respective method.  For the other Client
   Authentication cases, to authenticate the Broker, the client MAY
   either have the ability to receive and validate a server-side
   certificate or an RPK from the Broker checked against the 'rs_cnf' parameter
   in the token.

The reason why I did not go into more detail for TLS/certificate use
on the server-side,

was because MQTT OASIS standard recommends it but does not go into
detail (as discussed in the previous points).

And my experience with mqtt brokers that they define how to set it up
in their config pages:

e.g., HiveMQ with BoringSSL
https://www.hivemq.com/docs/4.2/hivemq/security.html (HiveMQ is what
Edinburgh colleagues are implementing ACE mqtt-tls profile with now).

or Mosquitto with OpenSSL https://mosquitto.org/man/mosquitto-conf-5.html

 https://mosquitto.org/man/mosquitto-tls-7.html

My assumption was that for MQTT developers who have opted for a
certain MQTT implementation and want to use server-side certificates,

they would continue configuring the server-side TLS as they always do,

and then use the ACE  plugin to do the client authentication/authorisation.

>
> 4.  With the definition of some guidance in COSE, should there be a field
> for doing certificates in the rs_cnf - returning a fingerprint not the
> entire certificate.
>

This is interesting - do you mean working with this draft:
https://tools.ietf.org/html/draft-ietf-cose-x509-04

 Thanks,
--Cigdem

>
> Jim
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>