Re: [Ace] WGLC for draft-ietf-ace-oscore-profile

Jim Schaad <> Mon, 22 October 2018 19:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE06A1277C8; Mon, 22 Oct 2018 12:09:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NSwBoUHDdNiv; Mon, 22 Oct 2018 12:09:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA4341294D7; Mon, 22 Oct 2018 12:09:21 -0700 (PDT)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 22 Oct 2018 12:04:13 -0700
From: Jim Schaad <>
To: <>
CC: <>
References: <065a01d45f4e$b738ae60$25aa0b20$>
In-Reply-To: <065a01d45f4e$b738ae60$25aa0b20$>
Date: Mon, 22 Oct 2018 12:08:53 -0700
Message-ID: <028c01d46a3a$ae1b9e40$0a52dac0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIoMJGW0ffnzj4eMWBhJ41cSURLyKSBBagw
Content-Language: en-us
X-Originating-IP: []
Archived-At: <>
Subject: Re: [Ace] WGLC for draft-ietf-ace-oscore-profile
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Oct 2018 19:09:25 -0000

* Section 1 - I understand the reasoning behind having the server send back
a nonce, although it would be good to have a description someplace about why
this is being done.  (I would also make it optional as not all RS need to do
this.)  I do not understand the reasoning behind having the client send a
nonce to the server.

* Section 3.1 - This is more general than the section, but you should not
use the URI path in the text, instead you should be using the name that is
in the authz document.

* Section 3.2 - Does it really make sense to use 'COSE_Key' to transport the
key data?  Would a different field name be better?

* Section 3.2 - Please provide a justification for the requirement that the
ids must be unique over the set of all clients and RS.   I can see that the
client ids need to be unique on a single RS and RS ids need to be unique for
any given client but not the broader statement.

* Please add an explicit section on when a RS and a client should discard
the security context.

* Section 6 - Ok I'll bite  - how does not echoing the nonce allow for a
man-in-the-middle attack given that the salt and shared secret are still
going to be known only to the C and RS and not to the MITM.  I can see a DOS
attack being made, but that can be done even without this just by causing
the response to never be delivered.

* Appendix - I am not sure that I think that the EDHOC profile should be in
this document as oppose to being in it's own document.  The fact that we
have not even tried to get this to work in any of the interop tests means
that I am less sure that it is well baked.


> -----Original Message-----
> From: Ace <> On Behalf Of Jim Schaad
> Sent: Monday, October 8, 2018 2:35 PM
> To:
> Subject: [Ace] WGLC for draft-ietf-ace-oscore-profile
> The chairs believe that the set of documents dealing with the OAuth
> framework for constrained environments is nearing the point that we should
> be able to advance it to the IESG for publication.   We therefore want to
> have a full list of issues that need to be dealt with at the Bangkok
> meeting.
> This starts a 2 week WGLC for draft-ietf-ace-oscore-profile
> We know that the following issues are outstanding:
> draft-ietf-ace-oscore-profile:
> *  No current known issues
> Jim & Roman
> _______________________________________________
> Ace mailing list