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

Vladimir Dzhuvinov <vladimir@connect2id.com> Fri, 04 August 2017 19:18 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 BC0CB132012 for <oauth@ietfa.amsl.com>; Fri, 4 Aug 2017 12:18:09 -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 AIsAfgq2nCRg for <oauth@ietfa.amsl.com>; Fri, 4 Aug 2017 12:18:07 -0700 (PDT)
Received: from p3plsmtpa06-03.prod.phx3.secureserver.net (p3plsmtpa06-03.prod.phx3.secureserver.net [173.201.192.104]) (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 5B44A131FFA for <oauth@ietf.org>; Fri, 4 Aug 2017 12:18:07 -0700 (PDT)
Received: from [192.168.0.101] ([78.130.190.73]) by :SMTPAUTH: with SMTP id di6Idb2Y2PMtZdi6JdStmj; Fri, 04 Aug 2017 12:17:35 -0700
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: oauth <oauth@ietf.org>
References: <150126635076.25225.3854025136006448469@ietfa.amsl.com> <CA+k3eCThoxNM394K=it4vCL2k-BW68Lg73eTN=4Z3LrupbXtVw@mail.gmail.com> <b3b27355-11fc-21c9-cfad-f6fb0571ed02@connect2id.com> <CA+k3eCR+YuVivqkUkdc+n4PFfQXPGwztC3PNSZnEe7Tds77xqQ@mail.gmail.com> <CA+k3eCRE9B8M4bAX0m5hY1t9Uvvz292Q5WYmSZjF7h_FkCJTKw@mail.gmail.com>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <44d04086-4817-a96b-c060-fb0011dc4ad9@connect2id.com>
Date: Fri, 4 Aug 2017 22:17:34 +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+k3eCRE9B8M4bAX0m5hY1t9Uvvz292Q5WYmSZjF7h_FkCJTKw@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060608040006060505070809"
X-CMAE-Envelope: MS4wfDlyAD+BscWT4XIhnEjj/4AGCjWGrDqGoyMiFZOefa0L84iFtWZSyycK5tkIteqQ8hj28n9CxA4H39KTQAL4SGvurFUtRmkkYCN6dXkJahjCajcfIDtw YUzCgnoKVLIQPaSsei3wGjmtI5OBiD9zZ5fuMPDCxGWbZ4WyR8j+9o02omom7Ung4F/7XWl3em6p41/I2/e3BLLyMExJj6D1TRE=
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/slPfmW0f5AZRusFlBE8_NxJVlYI>
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: Fri, 04 Aug 2017 19:18:10 -0000

What are the potential uses of the x5c parameter?

Vladimir


On 04/08/17 21:13, Brian Campbell wrote:
> Just wanted to note that, in an off-list exchange, John has pushed back on
> the idea to potentially drop mention of using x5c.
>
> On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell <bcampbell@pingidentity.com>;
> wrote:
>
>> Thanks for the review, Vladimir.
>>
>> The text about which you have questions was written by Torsten (credit or
>> blame where it's due!) but I believe he's out of the office for a bit so
>> I'll try and answer.
>>
>> Your 1st question:
>> I've had the same thought regarding the public key method and using the
>> JWK x5c parameter. A JWK already has the public key, which is sufficient
>> for comparison in the public key method. So x5c is just superfluous here. I
>> believe that's a change that the next revision should have and will look to
>> make it unless someone wants to make a strong case for needing x5c.
>>
>> Your 2nd question:
>> I also found the sentence, "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." somewhat difficult to understand when I first
>> read it. The intended meaning relies on content earlier in the same
>> paragraph that says, "As pre-requisite, the client registers a X.509
>> certificate or *a trusted source for its X.509 certificates (jwks uri as
>> defined in [RFC7591])* with the authorization server."  Basically what
>> it's trying to say is that when a client is registered or configured with a
>> jwks_uri, then client key rotation can be done without needing to
>> explicitly update the client config/registration with the AS. Does that
>> explain it? I believe the text could be more straightforward and will
>> endeavor to make it more clear in the next draft update.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov <
>> vladimir@connect2id.com>; wrote:
>>
>>> 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> <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>; <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-03https://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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>