Re: [Ace] Shepard comments on draft-ietf-ace-oscore-profile

Jim Schaad <ietf@augustcellars.com> Mon, 18 February 2019 21:54 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 ABECF1274D0; Mon, 18 Feb 2019 13:54:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 WZXfbIQSXslg; Mon, 18 Feb 2019 13:54:21 -0800 (PST)
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 DD712126C7E; Mon, 18 Feb 2019 13:54:20 -0800 (PST)
Received: from Jude (50.252.25.182) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 18 Feb 2019 13:54:13 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Francesca Palombini' <francesca.palombini@ericsson.com>, <draft-ietf-ace-oscore-profile@ietf.org>
CC: <ace@ietf.org>
References: <023901d4b8fc$b72658c0$25730a40$@augustcellars.com> <B145CB00-EF21-408F-8D71-7B872BBEA02D@ericsson.com> <026c01d4b984$6d36b330$47a41990$@augustcellars.com> <5D9AA2B5-FF39-4DE6-AA1A-6CF10684D33B@ericsson.com>
In-Reply-To: <5D9AA2B5-FF39-4DE6-AA1A-6CF10684D33B@ericsson.com>
Date: Mon, 18 Feb 2019 13:54:12 -0800
Message-ID: <01ce01d4c7d4$7dc16ed0$79444c70$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQFnk/fkaIwMlY1BYB1b9/Cas2b5AwIqf1tZAd6jmREBxv9qWqaR/57w
Content-Language: en-us
X-Originating-IP: [50.252.25.182]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/tPKAZAzGijpYHC2jl5vTJqMzyl0>
Subject: Re: [Ace] Shepard comments on draft-ietf-ace-oscore-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: Mon, 18 Feb 2019 21:54:24 -0000

Looks fine.

Jim


> -----Original Message-----
> From: Francesca Palombini <francesca.palombini@ericsson.com>
> Sent: Monday, February 18, 2019 4:55 AM
> To: Jim Schaad <ietf@augustcellars.com>om>; draft-ietf-ace-oscore-
> profile@ietf.org
> Cc: ace@ietf.org
> Subject: Re: Shepard comments on draft-ietf-ace-oscore-profile
> 
> Hi Jim,
> 
> Here is the update including your comments. It also includes minor
> comments from Marco (thanks!) that we had missed before.
> 
> https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-ace-
> oscore-profile.txt&url2=https://ace-wg.github.io/ace-oscore-profile/draft-
> ietf-ace-oscore-profile.txt
> 
> Concerning the error caused by unrecognized fields in the
> OSCORE_Security_Context, I only defined that for the RS: in fact, the client
> does not validate the token, so stopping the processing because of an
> unrecognized field would open up for easy DoS attacks by intermediaries. If
> the AS actually sends unrecognized fields, the RS will anyway stop the
> process itself when receiving the token.
> 
> This was the last change, so if you are ok with this, I will go ahead and submit
> a new version.
> 
> Francesca
> 
> On 31/01/2019, 17:46, "Jim Schaad" <ietf@augustcellars.com> wrote:
> 
> 
> 
>     > -----Original Message-----
>     > From: Francesca Palombini <francesca.palombini@ericsson.com>
>     > Sent: Thursday, January 31, 2019 6:26 AM
>     > To: Jim Schaad <ietf@augustcellars.com>om>; draft-ietf-ace-oscore-
>     > profile@ietf.org
>     > Cc: ace@ietf.org
>     > Subject: Re: Shepard comments on draft-ietf-ace-oscore-profile
>     >
>     > Hi Jim,
>     >
>     > Inline.
>     >
>     > Thanks,
>     > Francesca
>     >
>     > On 31/01/2019, 01:34, "Jim Schaad" <ietf@augustcellars.com> wrote:
>     >
>     >
>     >     1.  Please update the text for MUST/SHOULD/MAY to include the
> language
>     > from
>     >     RFC 8174.
>     >
>     > FP: Right, thanks. Updated now in the github.
>     >
>     >     2.  Section 3.2.1 - What to do is clear if a field is not missing.  What is
>     >     the correct behavior if a field is present that the client and/or resource
>     >     server does not recognize.  Is this a fatal error or is it sufficient that
>     >     they may not behave the same?
>     >
>     > FP: Assuming you are referring to fields missing in the
>     > OSCORE_Security_Context, (please correct me otherwise) this is a good
>     > point. We currently do not define what happens if the security context
> has
>     > unrecognized parameters. We don't foresee this happening, as the AS
>     > should know what the client and RS implement. However, to cover this
> case
>     > (bad implementation or something went wrong), to be on the safe side,
> we
>     > propose that there is a fatal error in that case. In fact, we don't know
> what
>     > additional parameters might be registered in the
> OSCORE_Security_Context,
>     > and although they could be "risk-free" (as in optional additional
> information
>     > non-necessary for the security context derivation), they could also be
> input
>     > to the key derivation for example, in which case the endpoint non-
>     > recognizing them would end up storing a "wrong" security context. What
> do
>     > you think?
> 
>     Sounds good.  I had a vague thought that perhaps some of the group items
> might be added in the future but no hard items to add.
> 
>     Jim
> 
>     >
>     >     Jim
>     >
>     >
>     >
> 
> 
>