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

Brian Campbell <bcampbell@pingidentity.com> Fri, 04 August 2017 19:32 UTC

Return-Path: <bcampbell@pingidentity.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 F2166131FFA for <oauth@ietfa.amsl.com>; Fri, 4 Aug 2017 12:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.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 ku6C0gKGTB4D for <oauth@ietfa.amsl.com>; Fri, 4 Aug 2017 12:32:53 -0700 (PDT)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 6A442131EB1 for <oauth@ietf.org>; Fri, 4 Aug 2017 12:32:53 -0700 (PDT)
Received: by mail-pg0-x22f.google.com with SMTP id u5so11555730pgn.0 for <oauth@ietf.org>; Fri, 04 Aug 2017 12:32:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EtRL81mNY77KwAwK4Y5iFsyDaZHIOtw+9nb+CcMKFYI=; b=PNUgqd00aZsLWDAjPqEKSmcjM+TiscRrXKdZBWPcCGowlxy1rIIkyrMTe38gKyDof6 qR0OKK5LqcXvgpRiIhVD2UJjsh8Io6ERoLkir8VdPUPptwExpofdnyO9whCit+XaV8RG QGhmjvCNn3jXzA15lz5mraQRJS2R/vC9h9MpQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EtRL81mNY77KwAwK4Y5iFsyDaZHIOtw+9nb+CcMKFYI=; b=HBjIY1haWaSOms9KoXZaDbklqnNethtGYpTuLtQaolbZWQCgdW8fa7BKLWZhzT5eQe UxeYwPMB7faU7JdUtuUeHNOQhnC3FShZaY6vh9QHULOQlzO667jv+Fqex+2Ed6lcs5WW aHqlAiyzcK++vhRA++EShabo1lIQX3ecPu0axnNkeEZn4bJhudu8lSzH5stoinYt1q5z JmPlUyv572mBZE0BbfptWGHDAL0+I4PjMNmEdOKKWAliHHf/BVEmFNRKArwXd7OzvDbO nsjphkUSM96QWDRuF+12j5biDACHRq7juBpBdAqfvaHTCzQWhrzBSRlNpfRY3tSrQo0E /g+Q==
X-Gm-Message-State: AIVw111IhopQu9eL5FAGjcVj2pLh816UrIVo+A6jgDZMMuH9bYpo7DY2 Ui+eJqlyAAC22QdkJqxR0hMFG+iKlLDYKWSNP0Cde1Eby4Dfa5YPQZLEVIlP0IF9zsgDu7p2D8e VdDoQzig=
X-Received: by 10.84.210.203 with SMTP id a69mr4013164pli.395.1501875172919; Fri, 04 Aug 2017 12:32:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.182.230 with HTTP; Fri, 4 Aug 2017 12:32:22 -0700 (PDT)
In-Reply-To: <44d04086-4817-a96b-c060-fb0011dc4ad9@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>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Fri, 4 Aug 2017 13:32:22 -0600
Message-ID: <CA+k3eCQ_T==NMXHBuAs4a1WYJOR_V4EGQMbR9+HBBiU01Mj2yg@mail.gmail.com>
To: Vladimir Dzhuvinov <vladimir@connect2id.com>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c09614c2de59c0555f29091"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/uCJ2uip-EdmBL6Tdxbm9xz8v6dY>
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:32:57 -0000

His argument (best I can articulate anyway) is that there may be
difficulties or gotchas in some cases in doing a comparison of the public
key from the client cert to the public key from a JWK. Where the comparison
or the client cert directly to the cert from x5c in a JWK would be more
straightforward and/or less error prone. I don't necessarily agree but
wanted to bring the discussion back to the list.

On Fri, Aug 4, 2017 at 1: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>]
> >>>
> >>> 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
> >>>
> >>>
>
>
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*