Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07

Brian Campbell <bcampbell@pingidentity.com> Thu, 12 April 2018 19:36 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 960651250B8 for <oauth@ietfa.amsl.com>; Thu, 12 Apr 2018 12:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 efMcdkn2ELHL for <oauth@ietfa.amsl.com>; Thu, 12 Apr 2018 12:36:52 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 CC07B129515 for <oauth@ietf.org>; Thu, 12 Apr 2018 12:36:51 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id h10so4495746iob.2 for <oauth@ietf.org>; Thu, 12 Apr 2018 12:36:51 -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=Wn9v5qWlM91gAYcqHEcqgPcCE0XcQJou9wTgwLyACbc=; b=nG/JzGgFNvMppXMsEujMW92aj8zvLM+4Z1kSurOEP0blmOOCQ1SLunhm6nEhtkcro4 XbDJfgERN8tBTf2bTL8WUvYO+PPNYd2M8BU/UU+feQIcjIYIeHnk8n5dNkuyvSr7ifR3 j5J7rQLFNOptCMVkz8QJCcevGEcrYFWyi/66s=
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=Wn9v5qWlM91gAYcqHEcqgPcCE0XcQJou9wTgwLyACbc=; b=gZ/M1tb++kMh7yGh63aETPE2d3Qc4j5nDZ7fDEW3j0DAHawq/4ujEOQZ3CBZmYj0d9 RGDVunAp8aikeDNLd3mRgvkfbozrGas5D11PgLCQOWHryPDGEEBbRHiGSuKlJN1F3lmR IR2mMQXfj+UH9fJHHULPHNGQxE+mhJKLSdMrOJ0cn6Ho7CRYMoxpzvbv1fTExqobyzrm 0M+atwJV7S/E3nTd2sye3D49Gp0g1oy1gig4ocBqQFi5rL1oSHncr/WY30xp1HzKmFH0 XCRXjC+IZvzwev1MV25ltybY6so3j4eOJuJJNokysjTEicol90Glwn5vDx5UIDNZWkqD lpJw==
X-Gm-Message-State: ALQs6tBCgOfL/MdYjrmEvf6lVtBmwQfvxwpHZQ3rhMoaqKP+YswMr8VA fl8Mb/IVD1Cft6IjbkToElDeBRdGyIifw8PboFfwcm6YTAPw8qLtSdd5+yoqbQ46bUy3hU5JxML x/BfZwft6yxFGoTMD
X-Google-Smtp-Source: AIpwx4+I5uPbEb84injPojxQm95GfS6lwxEKJ8Lv8QT8tfKUvoxB18IvKOij2mcSwEXjwr9egqQwp0YliU0OmOJ/kIs=
X-Received: by 10.107.28.15 with SMTP id c15mr10706062ioc.247.1523561810956; Thu, 12 Apr 2018 12:36:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.2.126.149 with HTTP; Thu, 12 Apr 2018 12:36:20 -0700 (PDT)
In-Reply-To: <41ae74de-4258-49ae-aa16-1fb24f19e3d8@Canary>
References: <CAGL6epK7X-jbO0c8GTxm2cAesYwU19R5_GsFY4tpUYxjW-MF_w@mail.gmail.com> <4D385B9E-AA8F-45B3-8C1D-C7B346FFA649@forgerock.com> <7E31B878-CE5E-459B-A083-7EA5D8532DC4@ve7jtb.com> <742bcf97-231d-4dba-b633-46c9ac2839b0@Canary> <806CDFE6-8E14-4126-B322-EEC7A932E548@ve7jtb.com> <d1428ddb-60c9-478a-9af8-c54d1f5d13f5@default> <B48FA5D7-EC84-4D51-8B81-3527EECC03D5@mit.edu> <CA+k3eCQQWKFpjDvTrxX=oTF3MpsLWjHZ-=Ts8guPTudqCEv=cA@mail.gmail.com> <CAANoGhLUhyPYW9sNJdx_gACYm6fDoUF9jCGX-PmwOwN0jT+JtQ@mail.gmail.com> <41ae74de-4258-49ae-aa16-1fb24f19e3d8@Canary>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Thu, 12 Apr 2018 13:36:20 -0600
Message-ID: <CA+k3eCSFiM+m100+QX3c8zV-f-WP6Z=VVtzrjEHmj9mF+7ZUAw@mail.gmail.com>
To: Neil Madden <neil.madden@forgerock.com>
Cc: John Bradley <ve7jtb@ve7jtb.com>, IETF oauth WG <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="001a114098128931e50569abe03f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Zp0L7ElATnCeLOIBoka1q7cHDtA>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07
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: Thu, 12 Apr 2018 19:36:57 -0000

Okay, that makes sense. I think something along those lines could fit into
the Implementation Considerations somewhere pretty well. I'll add that to
my list of updates for the next revision.

On Thu, Apr 12, 2018 at 4:11 AM, Neil Madden <neil.madden@forgerock.com>
wrote:

> I agree that this is beyond the scope of the spec. To be clear, our desire
> is that the mtls spec includes some wording along the following lines:
>
> “The AS MAY choose to terminate TLS connections at a load balancer,
> reverse proxy, or other network intermediary. How the client certificate
> metadata is securely communicated between the intermediary and the AS in
> this case is out of scope of this specification.”
>
> That makes it clear that it is a supported pattern without commiting to
> how it should be achieved.
>
> Regards,
>
> Neil
>
> --
>
> On Thursday, Apr 05, 2018 at 5:07 pm, John Bradley <ve7jtb@ve7jtb.com>
> wrote:
> +1
>
> On Wed, Apr 4, 2018, 5:42 PM Brian Campbell <bcampbell@pingidentity.com>
> wrote:
>
>> Strongly agree with Justin that any kind of TLS header forwarding
>> standards like that are well beyond the scope of this spec.
>>
>>
>> On Fri, Mar 30, 2018 at 10:02 PM, Justin Richer <jricher@mit.edu> wrote:
>>
>>> I don’t believe this is the spec to define TLS header forwarding
>>> standards in.
>>>
>>>  — Justin
>>>
>>>
>>> On Mar 30, 2018, at 2:03 PM, Vivek Biswas <vivek.biswas@oracle.com>
>>> wrote:
>>>
>>> There are additional challenges which we have faced.
>>>
>>> A.      Most of the Mutual SSL communication as mentioned below
>>> terminates at the LBR and the LBR needs to have client certificates to
>>> trust the client. But lot of times the connection from LBR to Authorization
>>> server may be non-SSL.
>>>
>>> The CN, SHA-256 thumprint and serial number of the Client Cert are sent
>>> as header to the AuthzServer/Backend Server. However, if the connection
>>> from LBR to AuthzServer/Backend Server is unencrypted it is prone to MIM
>>> attacks. Hence, it’s a MUST requirement to have one-way SSL from LBR to
>>> AuthzServer/Backend Server, so that the headers passed are not compromised.
>>>
>>> This is a MOST common scenario in a real world. And we don’t want
>>> everyone come up with their own names for the header. There should be some
>>> kind of standardization around the header names.
>>>
>>> Regards
>>> Vivek Biswas, CISSP
>>>
>>> *From:* John Bradley [mailto:ve7jtb@ve7jtb.com <ve7jtb@ve7jtb..com>]
>>> *Sent:* Thursday, March 29, 2018 11:57 AM
>>> *To:* Neil Madden
>>> *Cc:* oauth
>>> *Subject:* Re: [OAUTH-WG] WGLC on draft-ietf-oauth-mtls-07
>>>
>>> Yes that is quite a common deployment scenario.   I think that is the
>>> way most of the Open Banking implementations have deployed it currently.
>>>
>>> The intent is to support that.   One problem is that how the certificate
>>> is transmitted to the application tends to be load balancer/reverse proxy
>>> specific as no real standard exists.
>>>
>>> If you think that needs to be clarified text is welcome.
>>>
>>> John B.
>>>
>>>
>>>
>>>
>>> On Mar 29, 2018, at 2:54 PM, Neil Madden <neil.madden@forgerock.com>
>>> wrote:
>>>
>>> Thanks, and understood.
>>>
>>> The privacy concerns are mostly around correlating activity of
>>> *clients*, which may or may not reveal activity patterns of users using
>>> those clients. I don’t know how much of a concern that is in reality, but
>>> thought it should be mentioned.
>>>
>>> A colleague also made the following comment about the draft:
>>>
>>> “It is still quite common to terminate TLS in a load balancer or proxy,
>>> and to deploy authorization servers in a secure network zone behind an
>>> intermediate in a DMZ. In these cases, TLS would not be established between
>>> the client and authorization server as per §2, but information about the
>>> TLS handshake may be made available by other means (typically adding to a
>>> downstream header) allowing lookup and verification of the client
>>> certificate as otherwise described. Given the prevalence of this approach
>>> it would be good to know whether such a deployment would be compliant or
>>> not.”
>>>
>>> Kind regards,
>>> Neil
>>> --
>>>
>>>
>>> On Thursday, Mar 29, 2018 at 4:47 pm, John Bradley <ve7jtb@ve7jtb.com>
>>> wrote:
>>> Thanks for the feedback. We will review your comments and reply.
>>>
>>> One data point is that this will not be the only POP spec. The spec
>>> using token binding vs mtls has better privacy properties. It is UK Open
>>> banking that has pressed us to come up with a standard to help with
>>> interoperability.
>>>
>>> This spec has been simplified in some ways to facilitate the majority of
>>> likely deployments.
>>>
>>> I understand that in future certificates may have better than SHA256
>>> hashes.
>>>
>>> Regards
>>> John B.
>>>
>>>
>>>
>>> On Mar 29, 2018, at 12:18 PM, Neil Madden <neil.madden@forgerock.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I have reviewed this draft and have a number of comments, below.
>>> ForgeRock have not yet implemented this draft, but there is interest in
>>> implementing it at some point. (Disclaimer: We have no firm commitments on
>>> this at the moment, I do not speak for ForgeRock, etc).
>>>
>>> 1. https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-3.1 defines
>>> a new confirmation method “x5t#S256”. However, there is already a
>>> confirmation method “jwk” that can contain a JSON Web Key, which itself can
>>> contain a “x5t#S526” claim with exactly the same syntax and semantics. The
>>> draft proposes:
>>>
>>> { “cnf”: { “x5t#S256”: “…” } }
>>>
>>> but you can already do:
>>>
>>> { “cnf”: { “jwk”: { … , “x5t#S256”: “…” } } }
>>>
>>> If the intent is just to save some space and avoid the mandatory fields
>>> of the existing JWK types, maybe this would be better addressed by defining
>>> a new JWK type which only has a thumbprint? e.g., { “kty”: “x5t”,
>>> “x5t#S256”: “…” }.
>>>
>>> 2. I find the naming “mutual TLS” and “mTLS” a bit of a misnomer: it’s
>>> really only the client authentication that we are interested here, and the
>>> fact that the server also authenticates with a certificate is not hugely
>>> relevant to this particular spec (although it is to the overall security of
>>> OAuth). Also, TLS defines non-certificate based authentication mechanisms
>>> (e..g. TLS-SRP extension for password authenticated key exchange, PSK for
>>> pre-shared key authentication) and even non-X.509 certificate types (
>>> https://www.iana.org/assignments/tls-extensiontype-
>>> values/tls-extensiontype-values.xhtml#tls-extensiontype-values-3). I’d
>>> prefer that the draft explicitly referred to “X.509 Client Certificate
>>> Authentication” rather than mutual TLS, and changed identifiers like
>>> ‘tls_client_auth’ (https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#
>>> section-2.1.1) to something more explicit like
>>> ‘tls_x509_pki_client_auth’.
>>>
>>> This is especially confusing in section 3 on sender constrained access
>>> tokens, as there are two different servers involved: the AS and the
>>> protected resource server, but there is no “mutual” authentication between
>>> them, only between each of them and the client.
>>>
>>> 3. The draft links to the TLS 1.2 RFC, while the original OAuth 2.0 RFC
>>> only specifies TLS 1.0. Is the intention that TLS 1.2+ is required? The
>>> wording in Section 5.1 doesn’t seem clear if this could also be used with
>>> TLS 1.0 or 1.1, or whether it is only referring to future TLS versions.
>>>
>>> 4.. It might be useful to have a discussion for implementors of whether
>>> TLS session resumption (and PSK in TLS 1.3) and/or renegotiation impact the
>>> use of client certificates, if at all?
>>>
>>>
>>> 5. Section 3 defines sender-constrained access tokens in terms of the
>>> confirmation key claims (e.g., RFC 7800 for JWT).. However, the OAuth 2.0
>>> Pop Architecture draft defines sender constraint and key confirmation as
>>> different things (https://tools.ietf.org/html/draft-ietf-oauth-pop-
>>> architecture-08#section-6.2). The draft should decide which of those it
>>> is implementing and if sender constraint is intended, then reusing the
>>> confirmation key claims seems misleading. (I think this mTLS draft is doing
>>> key confirmation so should drop the language about sender constrained
>>> tokens).
>>>
>>> 6. The OAuth 2.0 PoP Architecture draft says (
>>> https://tools.ietf.org/html/draft-ietf-oauth-pop-
>>> architecture-08#section-5
>>> <https://tools..ietf.org/html/draft-ietf-oauth-pop-architecture-08#section-5>
>>> ):
>>>
>>> Strong, fresh session keys:
>>>
>>> Session keys MUST be strong and fresh.. Each session deserves an
>>> independent session key, i.e., one that is generated specifically
>>> for the intended use. In context of OAuth this means that keying
>>> material is created in such a way that can only be used by the
>>> combination of a client instance, protected resource, and
>>> authorization scope.
>>>
>>>
>>> However, the mTLS draft section 3 (https://tools.ietf.org/html/
>>> draft-ietf-oauth-mtls-07#section-3) says:
>>>
>>> The client makes protected resource requests as described in
>>> [RFC6750], however, those requests MUST be made over a mutually
>>> authenticated TLS connection using the same certificate that was used
>>> for mutual TLS at the token endpoint.
>>>
>>> These two statements are contradictory: the OAuth 2.0 PoP architecture
>>> effectively requires a fresh key-pair to be used for every access token
>>> request, whereas this draft proposes reusing the same long-lived client
>>> certificate for every single access token and every resource server.
>>>
>>> In the self-signed case (and even in the CA case, with a bit of work -
>>> e.g., https://www.vaultproject.io/docs/secrets/pki/index.html) it is
>>> perfectly possible for the client to generate a fresh key-pair for each
>>> access token and include the certificate on the token request (e.g., as per
>>>  https://tools.ietf.org/html/draft-ietf-oauth-pop-key-
>>> distribution-03#section-5.1 - in which case an appropriate “alg” value
>>> should probably be described). This should probably at least be an option.
>>>
>>>
>>> 7. The use of a single client certificate with every resource server
>>> (RS) should be called out in a Privacy Considerations section, as it allows
>>> correlation of activity.
>>>
>>> 8. This is maybe a more general point, but RFC 6750 defines the
>>> Authorization: Bearer scheme (https://tools.ietf.org/html/
>>> rfc6750#section-2) for a client to communicate it’s access token to the
>>> RS in a standard way. As sender-constrained access tokens are not strictly
>>> bearer tokens any more, should this draft also register a new scheme for
>>> that? Should there be a generic PoP scheme?
>>>
>>> 9. The Security Considerations should really make some mention of the
>>> long history of attacks against X.509 certificate chain validation, e.g.
>>> failure to check the “CA” bit in the basic constraints, errors in parsing
>>> DNs, etc. It should be strongly suggested to use an existing TLS library to
>>> perform these checks rather than implementing your own checks. This relates
>>> to Justin’s comments around DN parsing and normalisation.
>>>
>>> 10. The PKI client authentication method (https://tools.ietf.org/html/
>>> draft-ietf-oauth-mtls-07#section-2.1) makes no mention at all of
>>> certificate revocation and how to handle checking for that (CRLs, OCSP -
>>> with stapling?). Neither does the Security Considerations. If this is a
>>> detail to be agreed between then AS and the CA (or just left up to the AS
>>> TLS stack) then that should perhaps be made explicit. Again, there are
>>> privacy considerations with some of these mechanisms, as OCSP requests are
>>> typically sent in the clear (plain HTTP) and so allow an observer to see
>>> which clients are connecting to which AS.
>>>
>>> 11. The same comment applies to how the protected resource checks for
>>> revocation of the certificate presented during sender constrained access
>>> token usage. Should the RS make its own revocation checks based on the
>>> information in the certificate presented, or should it trust the
>>> certificate while the access token is still valid? If the latter case, is
>>> the AS responsible for revoking any access tokens whose certificate have
>>> been revoked (if so, should it be doing an OCSP call on every token
>>> introspection request, and should the RS be passing on the
>>> certificate/serial number on that request)? If the Client request uses OCSP
>>> Stapling (https://en.wikipedia.org/wiki/OCSP_stapling) how can the RS
>>> verify the signature on that if it does not have a separate trust
>>> relationship with the CA already?
>>>
>>> 12. The use of only SHA-256 fingerprints means that the security
>>> strength of the sender-constrained access tokens is limited by the
>>> collision resistance of SHA-256 - roughly “128-bit security" - without a
>>> new specification for a new thumbprint algorithm. An implication of this is
>>> that is is fairly pointless for the protected resource TLS stack to ever
>>> negotiate cipher suites/keys with a higher level of security. In more
>>> crystal ball territory, if a practical quantum computer becomes a
>>> possibility within the lifetime of this spec, then the expected collision
>>> resistance of SHA-256 would drop quadratically, allowing an attacker to
>>> find a colliding certificate in ~2^64 effort. If we are going to pick just
>>> one thumbprint hash algorithm, I would prefer we pick SHA-512.
>>>
>>> Cheers,
>>>
>>> Neil
>>>
>>>
>>>
>>> On 19 Mar 2018, at 22:34, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
>>> wrote:
>>>
>>> All,
>>>
>>> As discussed during the meeting today, we are starting a WGLC on the
>>> MTLS document:
>>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-07
>>>
>>> Please, review the document and provide feedback on any issues you see
>>> with the document.
>>>
>>> The WGLC will end in two weeks, on April 2, 2018.
>>>
>>> Regards,
>>> Rifaat and Hannes
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org <OAuth@ietf..org>
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://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.*__________________________
>> _____________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://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._