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] > 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 > <mailto: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 > <mailto: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 > <mailto: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 > <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 > > <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 > <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 > <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 > <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 > <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 > > <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 > <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 > <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 > <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 > <mailto: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 > <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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <https://www.ietf.org/mailman/listinfo/oauth> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <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
