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

+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
>