IETF Logo Mail Archive

Re: [GNAP] Authentication mechanisms discovery

Benjamin Kaduk <kaduk@mit.edu> Tue, 01 September 2020 03:13 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 019E33A091F for <txauth@ietfa.amsl.com>; Mon, 31 Aug 2020 20:13:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 fp5EALwtl6pK for <txauth@ietfa.amsl.com>; Mon, 31 Aug 2020 20:13:31 -0700 (PDT)
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 9CDD03A0921 for <txauth@ietf.org>; Mon, 31 Aug 2020 20:13:31 -0700 (PDT)
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 0813DP4Y014794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 31 Aug 2020 23:13:27 -0400
Date: Mon, 31 Aug 2020 20:13:24 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Denis <denis.ietf@free.fr>
Cc: "txauth@ietf.org" <txauth@ietf.org>
Message-ID: <20200901031324.GR16914@kduck.mit.edu>
References: <fdf69c9e-6950-b2d2-f889-dd4219fec6f1@free.fr> <CAD9ie-tRG5F=z_Py3RVFOjELPYcGxQPJxepzO_rFQg=XSG+Yaw@mail.gmail.com> <CAD9ie-t=qFWT=0vezac8dUV7e2TxfswNkr3Qz9TB4XnCmHjSzQ@mail.gmail.com> <320d584f-ce34-5230-66d5-d7dc6cdceb69@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <320d584f-ce34-5230-66d5-d7dc6cdceb69@free.fr>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/VPN3gb6ziI_W7dTnoNQkDcPXmco>
Subject: Re: [GNAP] Authentication mechanisms discovery
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Sep 2020 03:13:33 -0000

On Tue, Aug 25, 2020 at 11:37:45AM +0200, Denis wrote:
> Hi Dick,
> 
> A few arguments:
> 
>   * The 401 (Unauthorized) status code indicates that the request has
>     not  been applied because it lacks valid authentication credentials
>     for the target resource.
>     Information about how to authenticate is NOT in the HTTP
>     Authorization header. So it is not a discovery mechanism but, at
>     best, a trial and error mechanism.

I'm not sure that I'm understanding you, here.  Yes, the 401 HTTP status
code does not convey information about how to authenticate, but per
https://tools.ietf.org/html/rfc7235#section-3.1 the WWW-Authenticate header
field MUST be included in the response, and that header field does contain
one or more challeng that shows how to authenticate, potentially along with
parameters for each method.  So are you also trying to say that the
combination of HTTP 401 and WWW-Authenticate is also "not a discovery
mechanism"?

Thanks,

Ben

v2.23.0 | Report a Bug | By Email