Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt

Vladimir Dzhuvinov <vladimir@connect2id.com> Wed, 02 August 2017 07:54 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 D44D4131C04 for <oauth@ietfa.amsl.com>; Wed, 2 Aug 2017 00:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 suUIgl_pkaR8 for <oauth@ietfa.amsl.com>; Wed, 2 Aug 2017 00:54:12 -0700 (PDT)
Received: from p3plsmtpa06-01.prod.phx3.secureserver.net (p3plsmtpa06-01.prod.phx3.secureserver.net [173.201.192.102]) (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 5A83A128D86 for <oauth@ietf.org>; Wed, 2 Aug 2017 00:54:12 -0700 (PDT)
Received: from [192.168.0.101] ([78.130.190.73]) by :SMTPAUTH: with SMTP id coTLdTb64RabxcoTMd5EuK; Wed, 02 Aug 2017 00:53:41 -0700
To: oauth@ietf.org
References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> <CA+k3eCThoxNM394K=it4vCL2k-BW68Lg73eTN=4Z3LrupbXtVw@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <b3b27355-11fc-21c9-cfad-f6fb0571ed02@connect2id.com>
Date: Wed, 2 Aug 2017 10:53:39 +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+k3eCThoxNM394K=it4vCL2k-BW68Lg73eTN=4Z3LrupbXtVw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------D8EFDAEBBB0C9D847B45EB9B"
Content-Language: en-US
X-CMAE-Envelope: MS4wfEtjai5g15jk+qdZPP4HyLo1Sy2PBUFxtIYQAwTGrYJI5UjPktD+kXwUHShNx7cAIyZ1YpjpxNTiy8kilDqeWEzlr6huKSr5eljP7JlDi+zSxzH/0hAA VG366TDymC3BSsNdhdmDeEd4WNxcSVza9ZE1JEzDPv/UEihPajnO+u0M
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/khNIrWdrltHlKL1BhwEwVvMUVgM>
Subject: Re: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-mtls-03.txt
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: Wed, 02 Aug 2017 07:54:15 -0000

Thanks everyone for the update! Having a clear distinction between the
PKIX vs public key bound methods will help interop, implementers' job,
and it also appears good for security.

Questions:

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03#section-2.3

> where the X.509 certificates are represented using the "x5c" parameter from [RFC7517 <https://datatracker.ietf.org/doc/html/rfc7517>]

For the public key method, is it really necessary for the client to
include its certificate in the JWK x5c parameter? This will make
implementation harder for developers, and I'm not sure it adds anything
in terms of security. Registering the public key parameters seems
sufficient to me.


https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03#section-2.1

> When used in conjunction with a trusted X.509 certificate source, it also allows the client to rotate its X.509 certificates without the need to change its respective authentication data at the authorization server.
I don't understand this - "in conjunction with a trusted X.509
certificate source"


Thanks,

Vladimir

On 28/07/17 21:33, Brian Campbell wrote:
> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published with
> the changes listed below based on comments and dissuasion in Prague.
>
>    draft-ietf-oauth-mtls-03
> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>
>
>    o  Introduced metadata and client registration parameter to publish
>       and request support for mutual TLS sender constrained access
>       tokens
>    o  Added description of two methods of binding the cert and client,
>       PKI and Public Key.
>    o  Indicated that the "tls_client_auth" authentication method is for
>       the PKI method and introduced "pub_key_tls_client_auth" for the
>       Public Key method
>    o  Added implementation considerations, mainly regarding TLS stack
>       configuration and trust chain validation, as well as how to to do
>       binding of access tokens to a TLS client certificate for public
>       clients, and considerations around certificate bound access tokens
>    o  Added new section to security considerations on cert spoofing
>    o  Add text suggesting that a new cnf member be defined in the
>       future, if hash function(s) other than SHA-256 need to be used for
>       certificate thumbprints
>
>
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: Fri, Jul 28, 2017 at 12:25 PM
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
> To: i-d-announce@ietf.org
> Cc: oauth@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
>         Title           : Mutual TLS Profile for OAuth 2.0
>         Authors         : Brian Campbell
>                           John Bradley
>                           Nat Sakimura
>                           Torsten Lodderstedt
>         Filename        : draft-ietf-oauth-mtls-03.txt
>         Pages           : 17
>         Date            : 2017-07-28
>
> Abstract:
>    This document describes Transport Layer Security (TLS) mutual
>    authentication using X.509 certificates as a mechanism for OAuth
>    client authentication to the token endpoint as well as for
>    certificate bound sender constrained access tokens.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-03
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>