Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication

Cigdem Sengul <cigdem.sengul@gmail.com> Wed, 14 April 2021 13:01 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 3B3CB3A0E54 for <ace@ietfa.amsl.com>; Wed, 14 Apr 2021 06:01:55 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1CKf7mIgs7yw for <ace@ietfa.amsl.com>; Wed, 14 Apr 2021 06:01:50 -0700 (PDT)
Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 73ADA3A0E52 for <ace@ietf.org>; Wed, 14 Apr 2021 06:01:50 -0700 (PDT)
Received: by mail-vs1-xe30.google.com with SMTP id e16so9721443vsu.0 for <ace@ietf.org>; Wed, 14 Apr 2021 06:01:50 -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=r1Ao6IX4dN63MidT+AFcQw95gL71b4NJkueHgYrbFnU=; b=ALCFM877cE5igQK2QZeyM68+reMGdMkZrZtN1O2vhhUNZUt1j0BXUWnjiAqDqwgs/R 1liSVseQzK9PsWHCY/xgHx2lhOIvFOdcyKdEXcvBQ2rUXfcY4BPu4YRRvmUwsxWfVEPx TfL5PQRKdkgB8vBwO3ty8++VvjYR/4VCzcolIPBnk8lTLY8wrUoVHrmgDEzzfkQxqE0c 8oIY6ceN5wvYi74T6flzTxx4e9USBOTz0hEIhXB4oyD93RnwNd+WFxbM4J0lsBpmiCQD DCdj3jjjt2hqTQNlV6NEsk/CV9E5TsKrz1f126S/kbQGaxBdMaMBJdgudKclC9GPGobK Hk8g==
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=r1Ao6IX4dN63MidT+AFcQw95gL71b4NJkueHgYrbFnU=; b=h+WulKUlzmxB2/k+wVmBfNmah/jlrU5f6JKlp62uh2VD+BN/ynPzHjul958kWNKhCz LigewWOjKIrAhWUIfNeuNjygIxC12QwU1H5ErRn0mKb+Wgaac9jzMmlBx7NKOjARV5Ou gKTuql1O+Yx4p1DiDecYAjgjb+QzCC8O2RNbOzPkWTCEwBlco/zEj6LKTue8AX4rjPSb JNATYvLoYIgZQ+bulFx0OVLxZahRzLpwvavOb0xPVP6VCBKNgOfdfPzgiHFs7rDi+pky Du/za2JEdoUvDAIiDFpL+eCCFgoojTdYTWh+8ltPmf5VHOP+HnYGH++z/R40U+PR63hT DhrQ==
X-Gm-Message-State: AOAM533zlT8OqSSWjq30O9tbwUctZJIMv1rGDnKJRdAB+zHMRZYoda8o Rk2PDdWUdtHcl64a+ONZQ4LsLASl47mgBMEXlUg=
X-Google-Smtp-Source: ABdhPJz0fISOeZ+K/KHasrqU5WJ5U+iiMcTvCls8dd/ss0ns2c4W3CXzuQjAeMS8+9H4Bbz90yBBsP9WirpOGZ0Xgrk=
X-Received: by 2002:a67:f3d9:: with SMTP id j25mr16317744vsn.22.1618405308620; Wed, 14 Apr 2021 06:01:48 -0700 (PDT)
MIME-Version: 1.0
References: <DM6PR15MB237941DDA59DF2A67A2F52B7E3969@DM6PR15MB2379.namprd15.prod.outlook.com> <CAA7SwCNmxax3F222eeYyQ1rEOq+cOZzZwT1Y4+CPBrJB+8XtXw@mail.gmail.com> <CADZyTkk4j0TJMFFPZ0j4zXo1miRBdG4A=jQUJQdiePdsiiMkVA@mail.gmail.com> <CAA7SwCNJ6wkzz=JS4s4xUgZ-rZTf5XFBuHMNe04ijRU1Z9ppmg@mail.gmail.com> <DM6PR15MB2379A0F88237CF5F7B8DD619E34E9@DM6PR15MB2379.namprd15.prod.outlook.com>
In-Reply-To: <DM6PR15MB2379A0F88237CF5F7B8DD619E34E9@DM6PR15MB2379.namprd15.prod.outlook.com>
From: Cigdem Sengul <cigdem.sengul@gmail.com>
Date: Wed, 14 Apr 2021 14:01:36 +0100
Message-ID: <CAA7SwCO=gXCa1kCmxacQTW4+vGaAaE7xWSYrwF3Smr90q8g0Lg@mail.gmail.com>
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: Daniel Migault <mglt.ietf@gmail.com>, Ace Wg <ace@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000085e22105bfee59ad"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/iquA4TQyzJEQh_7k6rM-LvMuaLU>
Subject: Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS - AS communication
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, 14 Apr 2021 13:01:55 -0000

Hello Daniel,
I should clarify: I did not mean it was not compliant - it was more asking
whether anybody objects to registering ace+json when the framework talks
about a different method.
Kind regards,
--Cigdem

On Wed, Apr 14, 2021 at 1:50 PM Daniel Migault <daniel.migault@ericsson.com>
wrote:

> Hi,
>
> I am certainly missing something, but it is unclear to me why
> "application/ace+json" does not comply to "application/x-www-form-urlencoded".
> In other words, what would the update of the mqtt draft consist of to be
> aligned with the framework. I also have the impression that the use of
> "application/x-www-form-urlencoded" is a MAY and that the framework does
> not specify MUST. In general I am tempted to think it is better to be
> aligned with but It would probably need to understand better the issue and
> I am encouraging the WG to state rapidly their thoughts so we can move the
> draft forward.
>
> Regarding the second point, yes, the draft that introduces ace+json should
> register it.
>
> Yours,
> Daniel
> ------------------------------
> *From:* Ace <ace-bounces@ietf.org> on behalf of Cigdem Sengul <
> cigdem.sengul@gmail.com>
> *Sent:* Wednesday, April 14, 2021 4:58 AM
> *To:* Daniel Migault <mglt.ietf@gmail.com>om>; Ace Wg <ace@ietf.org>
> *Subject:* Re: [Ace] MQTT, OSCORE, DTLS profiles - recommendation on RS -
> AS communication
>
> Hello Daniel,
>
> One thing I didn't have a chance to ask yesterday in the interim was about
> the registration of the 'ace+json' application type.
> Francesca brought this up as the MQTT profile describes the HTTPS
> interactions differently than the core draft  which says " When HTTP is
> used as a transport then the client makes a request to the token endpoint
> by sending the parameters using the "application/
> x-www-form-urlencoded" format with a character encoding of UTF-8 in the
> HTTP request entity-body, as defined in section 3.2 of [RFC6749]."
>
> As I discussed with Francesca, we had discussions on the mailing list with
> Jim using ace+json as well. I recalled the view that the draft that
> introduces it should register it - I want to check if this is the general
> agreement, or you (or the group) has a different view
>     - (1) registering this new type, or (2) MQTT draft is modified to
> comply with framework description
>     - do we still agree that (1) it should be the  MQTT profile
> registering it or (2) it should be done elsewhere?
>
> Kind regards,
> --Cigdem
>
> On Tue, Apr 13, 2021 at 1:58 PM Daniel Migault <mglt.ietf@gmail.com>
> wrote:
>
> Thanks for the update, that works for me.
>
> Yours,
> Daniel
>
> On Tue, Apr 13, 2021 at 8:44 AM Cigdem Sengul <cigdem.sengul@gmail.com>
> wrote:
>
> Hello Daniel,
> I propose the following change to clarify the TLS use - if you are happy
> with it, I will update the document:
>
> To provide communication confidentiality and RS authentication to MQTT
> clients, TLS
>
>    is used, and TLS 1.3 [RFC8446] is RECOMMENDED.  This document makes
>
>    the same assumptions as Section 4 of the ACE framework
>
>    [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with
>
>    the AS and setting up keying material.  While the Client-Broker
>
>    exchanges are only over MQTT, the required Client-AS and RS-AS
>
>    interactions are described for HTTPS-based communication [RFC7230],
>
>    using 'application/ace+json' content type, and unless otherwise
>
>    specified, using JSON encoding. The Client-AS and RS-AS MAY also use
>    protocols other than HTTP, e.g.  Constrained Application Protocol
>    (CoAP) [RFC7252] or MQTT; it is recommended
>     that TLS is used to secure the communication channels between
> Client-AS and RS-AS."
>
> Since it is in this paragraph, one thing that Francesca brought up to do
> is to register the 'application/ace+json' content type.
> Kind regards,
> --Cigdem
>
> On Fri, Mar 5, 2021 at 9:11 PM Daniel Migault <daniel.migault=
> 40ericsson.com@dmarc.ietf.org> wrote:
>
> Hi,
>
>
>
> Now that the authz document is being consolidated, I do have some minor
> concerns regarding the recommendations mentioned in the profile documents,
> that might require an additional update.
>
> The update to the authz document indicates more more clearly than before
> that profiles need to provide some recommendations for the RS – AS
> communication.
>
>
>
> “””
>
> Profiles MUST  specify for introspection a communication security protocol
> RECOMMENDED to be used between RS and AS that provides the features
> required above. “””
>
>
>
> It seems to me the MQTT profile text makes it pretty clear that TLS is
> recommended for all communications but I am wondering if additional
> clarification would be beneficial – see below. That said I agree this is a
> very minor point in this case that could be handled by the RFC editor.
>
> For the OSCORE or DTLS profiles, unless I am missing the RS – AS
> recommendations in the documents , it seems to me it has been omitted and
> needs to be added -- see below.
>
>
>
>
>
> Yours,
>
> Daniel
>
>
>
> ## MQTT - draft-ietf-ace-mqtt-tls-profile-10
>
>
>
> “””
>
>    To provide communication confidentiality and RS authentication, TLS
>
>    is used, and TLS 1.3 [RFC8446] is RECOMMENDED.  This document makes
>
>    the same assumptions as Section 4 of the ACE framework
>
>    [I-D.ietf-ace-oauth-authz] regarding Client and RS registration with
>
>    the AS and setting up keying material.  While the Client-Broker
>
>    exchanges are only over MQTT, the required Client-AS and RS-AS
>
>    interactions are described for HTTPS-based communication [RFC7230],
>
>    using 'application/ace+json' content type, and unless otherwise
>
>    specified, using JSON encoding.
>
> “””
>
>
>
> I am wondering if that would not be more appropriated to specify in the
> first line RS and AS authentication or simply authentication.
>
>
>
>
>
>
>
>
>
>    - OSCORE draft-ietf-ace-oscore-profile-16
>
> “””
>
> This
>
>    profile RECOMMENDS the use of OSCORE between client and AS, to reduce
>
>    the number of libraries the client has to support, but other
>
>    protocols fulfilling the security requirements defined in section 5
>
>    of [I-D.ietf-ace-oauth-authz] (such as TLS or DTLS) MAY be used as
>
>    well.
>
> “””
>
>
>
>
>    - DTLS draft-ietf-ace-dtls-authorize-15
>
>
>
> “””
>
> It is RECOMMENDED that the client
>
>    uses DTLS with the same keying material to secure the communication
>
>    with the authorization server, proving possession of the key as part
>
>    of the token request.  Other mechanisms for proving possession of the
>
>    key may be defined in the future.
>
> “””
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
>
>
> --
> Daniel Migault
> Ericsson
>
>