[Ace] Comments on draft-ietf-ace-mqtt-tls-profile
Jim Schaad <ietf@augustcellars.com> Wed, 22 May 2019 21:58 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F5A12008C; Wed, 22 May 2019 14:58:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFfrkIadmGRT; Wed, 22 May 2019 14:58:39 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24CFD12004A; Wed, 22 May 2019 14:58:39 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 22 May 2019 14:58:32 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: draft-ietf-ace-mqtt-tls-profile@ietf.org
CC: ace@ietf.org
Date: Wed, 22 May 2019 14:58:28 -0700
Message-ID: <009c01d510e9$7eada030$7c08e090$@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: AdUQzMqhylusiqU3Ql2wSCD6gJTtgw==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/1c1UtuXRpnsNTiKQkoUfMQqxdV4>
Subject: [Ace] Comments on draft-ietf-ace-mqtt-tls-profile
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: Wed, 22 May 2019 21:58:42 -0000
Thanks for the updates from my last message. This has helped quite a bit. 1. A discussion of the use of raw public keys rather than certificates for the server may be in order. This can refer to the same RPK issues from the current DTLS document. It may also be that this just uses normal certificate processing and that should be noted as well, but some discussion of deciding if the subject name/alt name matches the token returned from the AS. For the connect message there are a couple of issues that need to be thought about. 2. What items are required to be in the connect message. The response to my last message suggested that a client identifier is required to be present but that is not documented. 3. It is not completely clear what portions of the CONNECT message are being covered by the signature/MAC value. As an example, is the password field omitted entirely or is it set to a zero length password. In addition to this, from the couple of implementations that I have looked at the entire packet is not passed out of the base server code for authentication purposes. This might need to be taken into account in terms of what is used for the body and how it is constructed. (As a side note, the implementations that I have looked at so far also think that the password is a text string rather than a binary value which is going to be a short term issue as well.) 4. I must admit that I am disappointed that there is no challenge response mechanism in the MQTT specifications. I don't know that anything can be done at this point about it but there are some security issues that need to be highlighted because of this in the security considerations section. Only the v3 seems to have this problem. Also doing the channel binding would deal with this problem as well. Might just need some general discussions around the channel binding text. 5. Is there an intention to provide a "standard" format for the scope field or just to leave it as ad hoc? 6. It might be reasonable in section 2.1.3 to note that even if a result is cached, that cached check should be limited for a specific amount of time to recheck if the token is still active. More of an issue in terms of how long to cache for introspection. 7. In section 2.1.4 - I would presume that the last paragraph should be extended to say that the token is stored only for the length of the connection. That is the token always needs to be supplied every time a connect message is sent. Jim
- [Ace] Comments on draft-ietf-ace-mqtt-tls-profile Jim Schaad
- Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-pro… Ludwig Seitz
- Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-pro… Cigdem Sengul
- Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-pro… Jim Schaad
- Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-pro… Cigdem Sengul
- Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-pro… Daniel Migault
- Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-pro… Cigdem Sengul
- Re: [Ace] Comments on draft-ietf-ace-mqtt-tls-pro… Daniel Migault