Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: enforcing mutual_tls_sender_constrained_access_tokens

Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 29 August 2017 06:53 UTC

Return-Path: <vladimir@connect2id.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0205132705 for <oauth@ietfa.amsl.com>; Mon, 28 Aug 2017 23:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 GNVJUMMpyPQS for <oauth@ietfa.amsl.com>; Mon, 28 Aug 2017 23:53:34 -0700 (PDT)
Received: from p3plsmtpa12-04.prod.phx3.secureserver.net (p3plsmtpa12-04.prod.phx3.secureserver.net [68.178.252.233]) (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 46717132386 for <oauth@ietf.org>; Mon, 28 Aug 2017 23:53:34 -0700 (PDT)
Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id maOTdTDMqjvvYmaOUd4NmJ; Mon, 28 Aug 2017 23:53:02 -0700
References: <50944e7c-a958-1d59-c68d-77f1c68db05c@connect2id.com> <CA+k3eCRYUoPWSzZMtSngv90kiw8UGedY5mN2S1ozLED=V-NfGg@mail.gmail.com>
To: IETF oauth WG <oauth@ietf.org>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <fb419508-c88d-bcfe-ccd9-dc51822ddb8d@connect2id.com>
Date: Tue, 29 Aug 2017 09:53:01 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <CA+k3eCRYUoPWSzZMtSngv90kiw8UGedY5mN2S1ozLED=V-NfGg@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms000003010509090908090102"
X-CMAE-Envelope: MS4wfNlKWmlm+nYl5XVzf5J0vHcvIV/XApVz7CVIZR1CrzobADSi0KYq2kwGyaoJuy6GmywqzZPCQCb7wi1j7eLUgewQhpWSq6+X6xN8xBvH6k2/Ydqr242i T+O3TNSwilMttKbACXne20+iUZFmWkNxT5hGrZPD0mZpyuAgyiMxP72w
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/zKV1ZmTQKJ8b9nYIfslzRg0tNgY>
Subject: Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: enforcing mutual_tls_sender_constrained_access_tokens
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Aug 2017 06:53:36 -0000

On 28/08/17 18:53, Brian Campbell wrote:
> "invalid_client" is the appropriate error, if the client is
> configured/registered for MTLS authentication, because it's effectively
> failed client authentication.
>
> I would say that "invalid_request" is probably the appropriate error for a
> public client with mutual_tls_sender_constrained_access_tokens=true that
> doesn't provide the TLS client certificate with the token request. There is
> effectively a missing required parameter in the context of the request.
Thanks, "invalid_request" does indeed look like the best fit to signal
the request is incomplete (missing TLS client cert).

Vladimir

> On Sun, Aug 27, 2017 at 1:46 AM, Vladimir Dzhuvinov <vladimir@connect2id.com
>> wrote:
>> Let's suppose that an OAuth 2.0 client is registered for
>>
>> mutual_tls_sender_constrained_access_tokens=true
>>
>>
>> Is it correct that in the presence of this parameter, and regardless of
>> how "token_endpoint_auth_method" is set, the AS must require a client X.509
>> cert to be passed to the token endpoint? If yes, then what error should the
>> AS return if no client cert is passed with the token request?
>>
>> https://tools.ietf.org/html/rfc6749#section-5.2
>>
>> Thanks,
>>
>> Vladimir
>>
>> PS: Noticed a typo - "manor" in #section-4.3
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>>

-- 
Vladimir Dzhuvinov :: vladimir@connect2id.com