[Ace] draft-ietf-ace-mqtt-tls-profile connections

Jim Schaad <ietf@augustcellars.com> Sun, 19 May 2019 05:41 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9D8971200F1; Sat, 18 May 2019 22:41:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CRS5HN38pvJr; Sat, 18 May 2019 22:41:17 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03B71200E9; Sat, 18 May 2019 22:41:13 -0700 (PDT)
Received: from Jude ( by mail2.augustcellars.com ( with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 18 May 2019 22:41:07 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: <draft-ietf-ace-mqtt-tls-profile@ietf.org>
CC: <ace@ietf.org>
Date: Sat, 18 May 2019 22:41:04 -0700
Message-ID: <001901d50e05$74847200$5d8d5600$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdUN/nFAwwwghp0WRR+des3k7n3V6A==
Content-Language: en-us
X-Originating-IP: []
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/1tbDDoS8cFOS0JE8V3oT7gSrf3E>
Subject: [Ace] draft-ietf-ace-mqtt-tls-profile connections
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 May 2019 05:41:18 -0000

I am having a problem understanding the flow of authentication.  This may
just be a problem with my preconceptions, but in that case it still needs to
get clarified in the document.

* So as a client I get a token from the AS.  For the first run, assume that
it has a RPK in it.
* I now connect to the server using TLS.  
   	Question #1 - Am I doing client authentication at this point in TLS?
This is what is happening for all of the current profiles, but it is not
clear that this is happening for this profile.  The answer appears to be
both yes and no.

* The connect message holds the token and an authentication value.  The
sentence starting "The client MAY apply ..." in the next to last paragraph
is totally confusing.  Do I get a choice to create a value or not?  Do I get
a choice as to which method I use (which would seem to be dictated by the
token type and not by client choice).

* I am flummoxed by the statement that there is sufficient randomness in the
payload when authenticating.  I presume that all that is being used for the
authentication input is the CONNECT message.  Given that the exact same
input would be used for two different logons, I do not understand how this
could be the case.  Impersonation would seem to be an issue in the event
that the connect message is ever captured (including by the server).  I
would strongly suggest that there is a requirement to include a value from a
tls-exporter to tie the authentication to a specific session.

*  Appendix B says that the broker will accept MQTT PUBLISH messages, does
it have to do a connect before doing the publish or not?  If the connect is
required then what is used for authentication?