Re: [Ace] draft-ietf-ace-dtls-authorize

Benjamin Kaduk <kaduk@mit.edu> Sun, 31 January 2021 21:26 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 AF1B13A126E for <ace@ietfa.amsl.com>; Sun, 31 Jan 2021 13:26:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-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 Sv0sg6Mp9W1u for <ace@ietfa.amsl.com>; Sun, 31 Jan 2021 13:25:59 -0800 (PST)
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 3196B3A1270 for <ace@ietf.org>; Sun, 31 Jan 2021 13:25:59 -0800 (PST)
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 10VLPmf9026059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 31 Jan 2021 16:25:53 -0500
Date: Sun, 31 Jan 2021 13:25:48 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Francesca Palombini <francesca.palombini@ericsson.com>
Cc: Olaf Bergmann <bergmann@tzi.org>, Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org>, "ace@ietf.org" <ace@ietf.org>
Message-ID: <20210131212548.GR21@kduck.mit.edu>
References: <DM6PR15MB237928B2B84B18E9AE050EC3E3BA9@DM6PR15MB2379.namprd15.prod.outlook.com> <8735ylc7hi.fsf@wangari> <3148902D-F91E-40E1-AC9B-2110DB46CCD5@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3148902D-F91E-40E1-AC9B-2110DB46CCD5@ericsson.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/WvIaFuFtQc2UI4EYM2ZWWNpzbEU>
Subject: Re: [Ace] draft-ietf-ace-dtls-authorize
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, 31 Jan 2021 21:26:01 -0000

I agree with Francesca that we should only RECOMMEND CoAP+DTLS for "both
legs" of communication with the AS -- the intent of the framework is that
we can decouple the protocol used in the different interactions if needed.

-Ben

P.S. The sentence prior to the quoted ones refers to Sections 5.6 and 5.6
of the framework for the token and introspection endpoint descriptions;
these seem to be 5.8 and 5.9, respectively, in
draft-ietf-ace-oauth-authz-36.


On Fri, Jan 29, 2021 at 01:15:14PM +0000, Francesca Palombini wrote:
> Hi Olaf,
> 
> When I read the draft I don't see how the change is reflected in your summary, actually your summary shows no difference between OSCORE and DTLS profile, while actually there is one. This is the difference we are discussing in the DTLS profile, about secure communication between Client and Authorization Server:
> 
> 1. DTLS OLD:
>    The use of CoAP
>    and DTLS for this communication is RECOMMENDED in this profile, other
>    protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) MAY be
>    used instead.
> 
> 2. DTLS CURRENT:
>   The use of CoAP
>    and DTLS for this communication is REQUIRED in this profile.  Other
>    protocols (such as HTTP and TLS, or CoAP and OSCORE [RFC8613]) will
>    require specification of additional profile(s).
> 
> 3. OSCORE CURRENT:
>     The
>    use of CoAP and OSCORE ([RFC8613]) for this communication is
>    RECOMMENDED in this profile; other protocols fulfilling the security
>    requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] (such
>    as HTTP and DTLS or TLS) MAY be used instead.
> 
> 3. allows for applications to use this OSCORE profile "coap_oscore" and OSCORE between C and AS, but also if they prefer, DTLS between C and AS, or other security protocols that fulfil the security requirements of the framework.
> 1. also allows for the same for the DTLS profile (although it might be good to clarify that other protocols are only allowed if they fulfil the sec requirements).
> 2. does NOT allow for "coap_dtls" to use anything else than DTLS between C and AS. If C and AS want to use e.g. TLS, a new profile needs to be defined. This doesn't seem like a good idea.
> 
> About the "need to look somewhere else" : the only thing we say in the profiles is that C and AS have to have set up a secure communication channel. That is not really protocol specific, how that is established is out of scope of the profiles.
> 
> The question is: do we really need to specify one different profile for each security protocol used between C and AS? I hope not.
> 
> So my preference would update the text in the DTLS profile:
> 
> NEW:
>    The use of CoAP
>    and DTLS for this communication is RECOMMENDED in this profile, other
>    protocols fulfilling the security
>    requirements defined in section 5 of [I-D.ietf-ace-oauth-authz] MAY be
>    used instead.
> 
> Francesca
> 
> On 28/01/2021, 18:11, "Ace on behalf of Olaf Bergmann" <ace-bounces@ietf.org on behalf of bergmann@tzi.org> wrote:
> 
>     Hi Daniel,
> 
>     On 2021-01-28, Daniel Migault <daniel.migault=40ericsson.com@dmarc.ietf.org> wrote:
> 
>     > Apparently, the change on the DTLS profile has not been noticed by
>     > everyone in the WG, so I am bringing the discussion here.
>     >
>     > The change has been made as a response to a comment from the security
>     > directorate. Please provide your feed backs by Feb 4 (but preferably
>     > before)- and potentially propose the text you would like to see if you
>     > disagree with the change.
> 
>     I agree with the change (although I do not care very much but the new
>     text makes more sense than the old) because the change suggested in the
>     secdir review is not about mandating one protocol or the other. It is
>     about which protocol you need to implement if you want to use that
>     protocol between C and AS. In short:
> 
>     * the OSCORE profile mandates that "if you want to use CoAP over OSCORE
>       between the C and the AS, you need to follow the steps in the
>       OSCORE specification and look somewhere else if you want to use
>       another protocol", and
>     * the DTLS profile mandates that "if you want to use CoAP over DTLS
>       between the C and the AS, you need to follow the steps in the
>       DTLS specification  and look somewhere else if you want to use
>       another protocol"
> 
>     Grüße
>     Olaf
> 
>     _______________________________________________
>     Ace mailing list
>     Ace@ietf.org
>     https://www.ietf.org/mailman/listinfo/ace
>