+1 On Wed, Apr 4, 2018, 5:42 PM Brian Campbell <bcampb...@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 <jric...@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.bis...@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:ve7...@ve7jtb.com <ve7...@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.mad...@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 <ve7...@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.mad...@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.i...@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 <oa...@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
