Re: [Ace] Certificate processing for MQTT

[Jim Schaad <[e-mail]>]

 

 

From: Cigdem Sengul <[e-mail]> 
Sent: Thursday, December 5, 2019 2:42 AM
To: Jim Schaad <[e-mail]>
Cc: [e-mail]; Ace Wg <[e-mail]>
Subject: 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 <[e-mail] <mailto:[e-mail]> > 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. 

 

[JLS] I would rather not make the reference to a WIKI page, a reference to a note would be just fine as that document could request the IANA registrations.  If they are really not interested in doing this we could always run a fast draft through the Independent Submission Editor.  The question would be which of the variants need to be documented.

 

 

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  <https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#RFC6066> [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.

 

[JLS] That looks to be recommendations on how to use TLS not recommendations about the certificates to be used in TLS.  I would agree that it does not look to be very official and subject to change so not referencing it makes sense.  Some of the info might be copied into this document.

 

 


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> 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> 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.
 
[JLS]  So none of these documents are addressing the biggest issue that I was worried about.
*         How should the identity check be done against the certificate?  Options would be the URI field in the alt name, but that requires that an agreed on URI exist.  The DNS name field in the alt name, which is fine as long as only the default ports are used but has problems otherwise.  Some field in the subject name, but that is highly discouraged by a number of people such as myself.  That is not to say that it is not done however.
*         A lesser issue would have been the use of an extended key usage – which is obviously not done because nobody ever defined one.   However, some might decide that id-kp-serverAuth would be needed because this is a TLS server, even it if it is not a WWW server. 
*         Are there any other required extensions that are to be in the certificate?
 
Issue that I would not worry about are:
*         What algorithms are permitted – this gets over taken by events so saying be smart is mostly fine with me.  
*         If there is a standardized way of dealing with revocation checking such as OCSP stapling or caching of certificates and CRLs.
*         The use of resumption of one type or another.
 
Those types of issues are of interest, but these are the types of things that can be negotiated.
 
In terms of doing the check against the rs_cnf value returned, one could check the public key even for a certificate.  This allows for the MQTT server to have a self-signed certificate and still have it being trusted.

 


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

 

[JLS] Yes that is the document that I was referring to.

 

Jim

 

 

 Thanks,

--Cigdem 


Jim


_______________________________________________
Ace mailing list
[e-mail] <mailto:[e-mail]> 
https://www.ietf.org/mailman/listinfo/ace