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

John Bradley <ve7jtb@ve7jtb.com> Mon, 07 August 2017 15:53 UTC

Return-Path: <ve7jtb@ve7jtb.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 00F0613226B for <oauth@ietfa.amsl.com>; Mon, 7 Aug 2017 08:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com
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 q5EbwG9SFbLK for <oauth@ietfa.amsl.com>; Mon, 7 Aug 2017 08:53:41 -0700 (PDT)
Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2625413239C for <oauth@ietf.org>; Mon, 7 Aug 2017 08:53:41 -0700 (PDT)
Received: by mail-qk0-x233.google.com with SMTP id d136so4952480qkg.3 for <oauth@ietf.org>; Mon, 07 Aug 2017 08:53:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bjnZyW7D5niifHQRSLVB0JfAAj2tGIo2WPawjqlI7kE=; b=O8KMq+RgxD/OWA1bY1kQ2m2GxvJwXkZzYZePkszz3AFZ3EXLNrGZNpVwRRhK2/o9Sd /jMcW9YKMxI4cD2Y+mYuPKuaMrxqLPKAxvxwdOJFNFewuRjpWfvhtGS3tMy75zUEbYcn 1Pe8hgUO3kpTkDc3T6z+Kl0udHcxBug4qwWguGLkj1+Y/lUy5jIPsJmJUp6VBUKURdt9 We/DVG0Nb1lagLNjKTquao2RVU8rBKzaKE6yAdsVzP8bToAzSIEZdooJmHSvzoq/0T2I 9Jhl6A1Wm14IoS+mP/eErdTrwMueNPfIeEJgI9cNZGAvmtqlMrAdjddk20cL2WeFLaoR K+Xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bjnZyW7D5niifHQRSLVB0JfAAj2tGIo2WPawjqlI7kE=; b=NdEqabkGQt+38YZPgwhjbnykKDrBCWljuXrGaskZa+LVpsGnbCaCZtBkQp/E+koP5W w9alH96+fB9N+Dv2EKC2FQsUt/3D3u3RoPprjd96wdvxdnXt+bCNkgyjZFQHUKBnOtXl TjcUETF2jPbe6nfaNf+AeR25gtLZwlnlCXgaL/PO/y12SIk1nM0KFQkFW/SJwE+PkSMc S5smGaEzLL2K2lYxRek1E76EbZDUk3uuBQRhYXMeYhl8uO0K9GOGwBJjKVILN+4+fAks tXhNcUFHRndu2BNoEd8cC7fUCvnHgKTYDVaDKRQbnPhpU9VuYtXQvpGV9Lgo/W0Jgkxn DV0A==
X-Gm-Message-State: AHYfb5jodfDmVfYcnyfqTQHocfBkcameewFlIr3VhjZwMn1fqwMV0Fnu Al8hyang841p9jzA
X-Received: by 10.55.20.150 with SMTP id 22mr1304128qku.319.1502121218604; Mon, 07 Aug 2017 08:53:38 -0700 (PDT)
Received: from johns-mbp.lan ([191.115.204.25]) by smtp.gmail.com with ESMTPSA id b71sm5502967qkj.8.2017.08.07.08.53.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Aug 2017 08:53:37 -0700 (PDT)
From: John Bradley <ve7jtb@ve7jtb.com>
Message-Id: <FD048FB2-65CA-4BF2-B821-F6FA9341BB97@ve7jtb.com>
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 07 Aug 2017 11:53:32 -0400
In-Reply-To: <6d150831-ab97-09eb-199c-65eb9e0457c7@connect2id.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>, oauth <oauth@ietf.org>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
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> <44d04086-4817-a96b-c060-fb0011dc4ad9@connect2id.com> <7EBDF15A-E2A7-4409-B2E8-01AF37D1C274@ve7jtb.com> <6d150831-ab97-09eb-199c-65eb9e0457c7@connect2id.com>
X-Mailer: Apple Mail (2.3273)
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="001a1145e77ac011f105562bd925"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/xPRPyiF-H64ZWYr1fEzC0skYqyM>
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: Mon, 07 Aug 2017 15:53:46 -0000

The AS always gets the client cert from the TLS stack.   Validating the certificate cain is something people get wrong all the time.   However that is what the DN names are for.  Using those requires validating the certs.

If you use the x5c from the JWKS is is a simple compare of the two certs.  In principal the app doesn't need to validate the cert using PKIX.   The security is provided by checking the server cert protecting the JWKS endpoint and is dealt with in TLS one hopes.

John B.

> On Aug 7, 2017, at 11:38 AM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
> 
> A while ago, if I'm not mistaken, I glimpsed some report of
> vulnerabilities caused by incorrect public key comparison.
> 
> It looks like key comparison merits a section on its own.
> 
> How about giving the AS the option to check the signature of the
> submitted client cert, which is better supported? (but will be much more
> expensive in terms of CPU time than comparison)
> 
> If an AS registers an x5c with the JWK, is the AS supposed to validate
> the x5c signature using the JWK public parameter? Any other checks?
> 
> Thanks,
> 
> Vladimir
> 
> On 04/08/17 23:16, John Bradley wrote:
>> Having the whole certificate to compare may be easier in some environments that trying to directly compare the public keys.
>> 
>> I believe most environments make the cert from TLS available to the app comparing that to the one retrieved from the x5c element is relatively strait forward.
>> 
>> When comparing keys I worry that that may not be that easy to get from the TLS/HTTP stack.  
>> Some environments will provide SPKI and others like java have methods to directly manipulate the keys.
>> 
>> We should also check on any issues with representation of EC public keys.  
>> While JWA docent allow compressed points RFC 5480 allows them in SPKI.
>> 
>> Of the top of my head I don’t know if anyone issues certs in that format, but they could.  
>> 
>> If the client receives compressed points from SPKI and uncompressed from JWK it is possible to compare them but I have a bad feeling people will get it wrong.   
>> 
>> There is also a issue with leading zeros that must be present in the JWK but are not in the SPKI.
>> 
>> For the most part comparing the raw keys will work with the three currently supported named curves. 
>> New curves may also introduce new wrinkles.
>> 
>> If we were only talking RSA I would definitely ditch x5c.
>> 
>> However given that a certificate of some sort must exist to make MTLS work putting it in the x5c is not asking the world.
>> 
>> Getting a app to string compare two blobs seems less likely to go wrong in deployment than asking apps to do atleast format normalization of the public keys to compare them.
>> 
>> I wish it could be simpler.
>> 
>> John B.
>> 
>> 
>>> On Aug 4, 2017, at 3:17 PM, Vladimir Dzhuvinov <vladimir@connect2id.com> wrote:
>>> 
>>> 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 <https://datatracker.ietf.org/doc/html/rfc7517><https://datatracker.ietf.org/doc/html/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- <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- <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> <https://datatracker.ietf.org/doc/html/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 <https://datatracker.ietf.org/doc/html/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 <mailto:internet-drafts@ietf.org> <mailto:internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>> <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org> <mailto:internet-drafts@ietf.org <mailto: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 <mailto:i-d-announce@ietf.org> <mailto:i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>>
>>>>>> Cc: oauth@ietf.org <mailto:oauth@ietf.org> <mailto:oauth@ietf.org <mailto: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/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/> <https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ <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 <https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03><https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 <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 <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03> <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03 <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 <http://tools.ietf.org/> <http://tools.ietf.org/ <http://tools.ietf.org/>>.
>>>>>> 
>>>>>> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/> <ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>>
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OAuth mailing listOAuth@ietf.orghttps <mailto:listOAuth@ietf.orghttps> <mailto:listOAuth@ietf.orghttps <mailto:listOAuth@ietf.orghttps>>://www.ietf.org/mailman/listinfo/oauth <http://www.ietf.org/mailman/listinfo/oauth>
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> OAuth mailing list
>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>
>>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>>
>>>>>> 
>>>>>> 
>>> 
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <mailto:OAuth@ietf.org> <mailto:OAuth@ietf.org <mailto:OAuth@ietf.org>>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>>