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

Cigdem Sengul <cigdem.sengul@gmail.com> Sun, 20 September 2020 21:18 UTC

Return-Path: <cigdem.sengul@gmail.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 346D63A0E9B for <ace@ietfa.amsl.com>; Sun, 20 Sep 2020 14:18:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 g697hsXV9ro8 for <ace@ietfa.amsl.com>; Sun, 20 Sep 2020 14:18:32 -0700 (PDT)
Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B0BE3A0E94 for <ace@ietf.org>; Sun, 20 Sep 2020 14:18:32 -0700 (PDT)
Received: by mail-vk1-xa2d.google.com with SMTP id a16so2712533vke.3 for <ace@ietf.org>; Sun, 20 Sep 2020 14:18:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eE62GtF3fPZzXRI7AjKNUKOkvAkDiIT7wpbRbD6x1QE=; b=AH+VOMf/5IkZIlywEDrk5mbyH2GCrzF+aO9rzqJS0gMdxPy93MDmylPwjtDUSjl6H6 HWAR/cURaaagHXDuXDLdbW/mlpIMmN8H1fXq3YWEIFXjqOU9zQVJYN/pIwkWlM7zT8g0 jZwvWcB/y8dIBZSNjLrzSBsC6CSI4+dRNznqRfvml9SgLFwUezwVeKuz7wWA/RUVMUNO sjkRQ1RK0I6ijsRPQBkEhPQZePnrOSXIT+U6emqCcIa1NfMbso3JoP83ImCXlXU9zvGS yyhVFCh6Nk61GCvQX9NiYxeZcAN+Xpo9S/RqzkJ0z122kARHuGKp05HMtGB+TXADAux2 dfFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eE62GtF3fPZzXRI7AjKNUKOkvAkDiIT7wpbRbD6x1QE=; b=ZMN2vzCV/+hJ5LqFzVHca3BgRnuO2CBv/3Ws05F8cSPk6krUjqGjnascitNbrNdCX1 1YGbK8QKuQAAT0AKuuvP9zBdvK6MdF8V5ZNWwnZaVN0zEEdIXtnL+mdTaol4TATHGiqi tXRA+2iaTzMWyht6cgy+RWLGDObCpI9l2a6vftDynsfmtdD0VOtpklz9bQijZIeK78h+ Gt5twjJBnhjTYvOZlqTtVeuI0APU904LaT/HM0BHRQYWufcC9sk0aerF8GZ90ADDDpvC Hq85QSVrWnf4vRO3A9xtPMdGF8x0H+zghnvQVc3miarEcftsXhCbO3nizp/EmrJHn/d1 AvKA==
X-Gm-Message-State: AOAM5300U49nUPvnx4H8rcvle5R8ieyoS4WbLjizefH46sJgqIg7ihHI w9eCs/AZhqgDtJZprNoFSowdgljxhw7VCxE5qFmq5ZWChIg5Jg==
X-Google-Smtp-Source: ABdhPJyyOqt/Da3dGcebBT1jfLZABN24haSLyeTC254B5nP7VKTJ+EFwrlcLyS0f2JMOVgTCv82JANXwtqNJHpMQvCU=
X-Received: by 2002:a1f:ed86:: with SMTP id l128mr16758917vkh.16.1600636711599; Sun, 20 Sep 2020 14:18:31 -0700 (PDT)
MIME-Version: 1.0
References: <CADZyTkmMd7iO3jo359QSS+y1LoSKvoDw+vJonD8VUfheEgXLTA@mail.gmail.com> <41fa81ca-fd99-8a04-03c0-e33007bca78b@ri.se> <CAA7SwCObG4KS_mDCLOmPe2B7Y1sVYXCR1tSdHrPKMbJR3=Ua-g@mail.gmail.com> <d0931b48-0eb5-2c08-a22d-f881024c9e8d@ri.se>
In-Reply-To: <d0931b48-0eb5-2c08-a22d-f881024c9e8d@ri.se>
From: Cigdem Sengul <cigdem.sengul@gmail.com>
Date: Sun, 20 Sep 2020 22:18:22 +0100
Message-ID: <CAA7SwCMYWGUVdo2ri-tLa3DXU71C4tff3mqwYtnXcHouQsT5vA@mail.gmail.com>
To: Marco Tiloca <marco.tiloca@ri.se>
Cc: Ace Wg <ace@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009c02b205afc5463a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/vjvqqxGYh6_8hdIyNE7JNYxFK9s>
Subject: Re: [Ace] WGLC 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: Sun, 20 Sep 2020 21:18:34 -0000

Hello Marco,
Responses inline.

>
> [CS: This is because the Authentication Data explained under 2.2.4  is
> binary data.  The
>    binary data in MQTT is represented by a two-byte integer length, which
> indicates the number of data bytes, followed by that number of
>    bytes.
> So, we have the total length of the entire Authentication Data,
> Token length + token  + (total length - token length) of MAC data.
> I hope this is more clear.
>
> Do you think I should repeat what binary data is at the subsections rather
> than explaining in 2.2.4?
> ]
>
>
> ==>MT
> So the Authentication Data includes some <Length ; Content> binary data,
> possibly followed by some extra data (here a MAC/Signature). Correct?
>
I think it's worth clarifying this when introducing the Authentication
> Data, and say what is part of the binary data here in Section 2.2.4.1.
> <==
>
>
[CS:  I think I may introduce ASCII art to explain this.
The content of Authentication Data for 2.2.4.1 is: Token length (2B)
+token+Mac computed over the content from the TLS exporter.
i.e, it is inclusive of the MAC. T

Actually, Authentication Data is defined before the subsections 2.2.4.1 and
2.2.4.2, under 2.2.4, because it is common to both subsections, just its
content varies. The text says:
"The Authentication Method is followed by the Authentication Data,
   which has a property identifier 22 (0x16) and is binary data.  The
   binary data in MQTT is represented by a two-byte integer length,
   which indicates the number of data bytes, followed by that number of
   bytes."

Then, the subsection explains what is in the Authentication Data content
(ie. binary data part) and may include additional length fields.
I think this is where the confusion stems from - the multiple length
fields.
]

>
>
>> [Section 2.2.4.2]
>>
>> * Shouldn't the Authentication Data in the AUTH message from the server
>> start with a 2-byte server nonce length?
>>
> [CS: the client is calculating a MAC over its nonce and server nonce and
> sending it back, with the information of its nonce.
> I assumed the RS would remember its nonce length]
>
>
> ==>MT
> I was referring to the AUTH packet from the server, including its RS
> challenge.
>
> The message is still including Authentication Data, and in any other case
> this seems to start with a 2-byte length field, as also described in
> Section 2.2.4.
>
> If that length field is actually optional, I can see it might be omitted
> here, since the client is supposed to get always an 8-byte nonce from the
> server.
> <==
>
> [CS: That was the reason - the spec defined the nonce as 8-byte. And as it
did not make its size optional, the Authentication Data does not include
the nonce size.
]


>
> [CS: Has my previous explanation clarified this?
>
> client_nonce length + nonce
> (the size of AUTH DATA - client_nonce_length)  of MAC  of
> (client_nonce+server nonce)
>
>
> ==>MT
> Yes, I think similar clarifications would help here in Section 2.2.4.2.
> <==
>