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

Benjamin Kaduk <kaduk@mit.edu> Wed, 14 April 2021 02:11 UTC

Return-Path: <kaduk@mit.edu>
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 BAA9B3A1415 for <ace@ietfa.amsl.com>; Tue, 13 Apr 2021 19:11:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 YveZ-xQgO_NG for <ace@ietfa.amsl.com>; Tue, 13 Apr 2021 19:11:55 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA763A1418 for <ace@ietf.org>; Tue, 13 Apr 2021 19:11:55 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 13E2Bk7M019515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Apr 2021 22:11:51 -0400
Date: Tue, 13 Apr 2021 19:11:45 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Daniel Migault <mglt.ietf@gmail.com>
Cc: Cigdem Sengul <cigdem.sengul@gmail.com>, "ace@ietf.org" <ace@ietf.org>, Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>
Message-ID: <20210414021145.GQ79563@kduck.mit.edu>
References: <DM6PR15MB237941DDA59DF2A67A2F52B7E3969@DM6PR15MB2379.namprd15.prod.outlook.com> <CAA7SwCNmxax3F222eeYyQ1rEOq+cOZzZwT1Y4+CPBrJB+8XtXw@mail.gmail.com> <CADZyTkk4j0TJMFFPZ0j4zXo1miRBdG4A=jQUJQdiePdsiiMkVA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CADZyTkk4j0TJMFFPZ0j4zXo1miRBdG4A=jQUJQdiePdsiiMkVA@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/Rl1O4J8V_Olq34F7NUcpI3gTe1k>
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 02:11:57 -0000

Cigdem and Daniel,

Thanks for working to get this resolved.  It will be one less thing for me
to comment on :)

-Ben

On Tue, Apr 13, 2021 at 08:57:53AM -0400, Daniel Migault 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

> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace