Re: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21

Jim Schaad <ietf@augustcellars.com> Tue, 19 February 2019 22:46 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 16731131021 for <ace@ietfa.amsl.com>; Tue, 19 Feb 2019 14:46:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 3oxwBqG7Dxcz for <ace@ietfa.amsl.com>; Tue, 19 Feb 2019 14:46:46 -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 311EE13101E for <ace@ietf.org>; Tue, 19 Feb 2019 14:46:46 -0800 (PST)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 19 Feb 2019 14:46:39 -0800
From: Jim Schaad <ietf@augustcellars.com>
To: 'Sebastian Echeverria' <secheverria@sei.cmu.edu>, <ace@ietf.org>
References: <CAE70DDC-17CA-4B68-A43A-280DB9A20328@sei.cmu.edu>
In-Reply-To: <CAE70DDC-17CA-4B68-A43A-280DB9A20328@sei.cmu.edu>
Date: Tue, 19 Feb 2019 14:46:39 -0800
Message-ID: <024d01d4c8a4$fb6fd8f0$f24f8ad0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_024E_01D4C861.ED4D3530"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQKgRX/vwyo9Ywgt25E13rJGKlzXuqRQvikQ
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/tx0CaCU74XhqBMTlgYjS8nNI99E>
Subject: Re: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21
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: Tue, 19 Feb 2019 22:46:49 -0000

Sebastian,

 

The 4.01 is not restricted to just the DTLS case.  One could get this error from just trying to get the resource on the schema coap rather than coaps.  However, this could occur even in the DTLS profile case.  Consider the situation of the following:

 

I have a token which allows me to do a get on a resource

I setup the DTLS session with that token and preform the get

I then attempt to do a PUT on that same resource.

 

This would then return a 4.01 (Unauthorized) because I don’t have a valid access token for the purpose of doing the action.  The same thing would be true if I attempted to do a GET on a different resource.

 

Jim

 

 

From: Ace <ace-bounces@ietf.org> On Behalf Of Sebastian Echeverria
Sent: Monday, February 18, 2019 6:59 AM
To: ace@ietf.org
Subject: [Ace] Comment about error responses in draft-ietf-ace-oauth-authz-21

 

Hello,

 

I have a short comment about error responses from an RS in draft-ietf-ace-oauth-authz-21. More specifically, my question is about section 5.8.2. In the second paragraph, it states “The response code MUST be 4.01 (Unauthorized) in case the client has not performed the proof-of-possession, or if RS has no valid access token for the client.” I am assuming this means that if the client is trying to access a resource and sending a pop key id that is not known by the RS, either because the RS has never seen it or because it is associated to a token that has already been removed from the RS, then this is how the RS should reply. 

 

If this is the case, I am a bit confused on how to implement this when using the DTLS profile. When using this profile, a client will first try to establish a DTLS session with the RS when accessing a resource. Once the session is established, it will actually try to access the resource over that DTLS connection. The pop key id to be used is sent when establishing the DTLS connection in the DTLS handshake messages, but if the RS does not have a key+token associated to that id for whatever reason, then it will cancel the DTLS handshake. If the DTLS handshake is never completed, then the RS can’t really send a reply at all, much less a 4.01 reply.

 

Thanks,

 

Sebastian Echeverria