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

Sebastian Echeverria <secheverria@sei.cmu.edu> Mon, 18 February 2019 14:59 UTC

Return-Path: <secheverria@sei.cmu.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 54CCF12941A for <ace@ietfa.amsl.com>; Mon, 18 Feb 2019 06:59:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sei.cmu.edu
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 Y4Fk6WBsGARZ for <ace@ietfa.amsl.com>; Mon, 18 Feb 2019 06:59:23 -0800 (PST)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 2E4EC1293B1 for <ace@ietf.org>; Mon, 18 Feb 2019 06:59:22 -0800 (PST)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x1IExLM6014189 for <ace@ietf.org>; Mon, 18 Feb 2019 09:59:21 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x1IExLM6014189
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sei.cmu.edu; s=t52kn2igOmwp; t=1550501961; bh=9vIJtn32PF5/xfT6GHN2ROcWjNr0VH/ljWk4sTBNupM=; h=From:To:Subject:Date:From; b=BkQWNc3sAxH6xXhvujEHD/TJ37EiyPPC8Jq4BCEtV+zq9ommlNS9OJ6zVT1oEy4nV UtHOv2c5gsi4U4ZkvbzppJsDRBE3ANdlmruURQv/Dyfmc994pmTg0xP/npC5aH8fR8 8+AXwPDesTaYuKS3E5IIFJ9rphvedS52zaFURHgE=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x1IExJL6007383 for <ace@ietf.org>; Mon, 18 Feb 2019 09:59:19 -0500
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0435.000; Mon, 18 Feb 2019 09:59:19 -0500
From: Sebastian Echeverria <secheverria@sei.cmu.edu>
To: "ace@ietf.org" <ace@ietf.org>
Thread-Topic: Comment about error responses in draft-ietf-ace-oauth-authz-21
Thread-Index: AQHUx5qFGyefWPMegEiYHRQaj1z5gA==
Date: Mon, 18 Feb 2019 14:59:18 +0000
Message-ID: <CAE70DDC-17CA-4B68-A43A-280DB9A20328@sei.cmu.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.201.81]
Content-Type: multipart/alternative; boundary="_000_CAE70DDC17CA4B68A43A280DB9A20328seicmuedu_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/EgtYJVQOl3VuSlI3MAIbP0BvoSM>
Subject: [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: Mon, 18 Feb 2019 14:59:25 -0000

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