Hi Karl, > On 7. May 2019, at 22:42, Karl McGuinness <kmcguinn...@okta.com> wrote: > > 1) You often need to deploy your cloud edge load balancer in TCP mode and > handle your own TLS termination if you want client authentication.
I like that option since it gives end2end transport security for your application. Unfortunately, that’s not supported by all cloud platforms. > 2) There are often many intermediates between your edge where client TLS is > terminated and your actual service. You need to forward cert context from > the edge as protected headers to your AS. That’s certainly true. The mTLS implementations I know all support passing the certificate from the TLS handshake via header parameter. Brian Campbell wrote a draft about this topic for token binding (https://tools.ietf.org/html/draft-ietf-tokbind-ttrp), but conceptually the same holds true for mTLS. Clearly, authenticity and integrity of the request between proxy and consuming service must be ensured, TLS in conjunction with shared secrets or TLS Client authentication could be used for that purpose or even network mechanisms. > 3) It's not easy to use different trust roots per tenant for client > authentication. That’s required if you use the PKI mode. I would recommend to use the self-signed mode (in combination with the optional_no_ca setting at your TLS terminating proxy), which does not require any trust root. Given you consider using DPoP, which uses raw keys, self-signed should be fine for you as well. > SNI is not supported as a selector via off the shelf solutions and requires a > software defined network (SDN) solution. > > On the FaaS side client complexity is there especially with OpenSSL bindings > > 1) > https://medium.com/@vaneek/using-mutual-tls-authentication-in-a-serverless-world-3afd19a6fe70 As far as I understand this article, it’s mainly about PKI. So again, use mTLS in conjunction with self-signed certs and optional_no_ca. kind regards, Torsten. > > -Karl > >> On May 7, 2019, at 11:17 AM, Torsten Lodderstedt <tors...@lodderstedt.net> >> wrote: >> >> >> >>> Am 07.05.2019 um 20:09 schrieb Karl McGuinness <kmcguinn...@okta.com>: >>> >>> mTLS has significant challenges at scale in a multi-tenant SaaS deployment >>> on public clouds using modern edge technologies/services. Applications are >>> increasingly being built using Function-as-a-Service/ephemeral workloads as >>> well. Additional complexity increases if you also want to support "bring >>> your own CA”.. >> >> Can you please share the details of those challenges with us? >> >>> >>> DPoP enables application level deployment model independent of how one’s >>> edge or runtime is deployed/managed. This is very valuable for SaaS >>> providers. We expect to eventually deploy a DPoP like solution for all >>> client models and not just SPA. >>> >>> -Karl >>> >>>> On May 7, 2019, at 10:43 AM, Torsten Lodderstedt <tors...@lodderstedt.net> >>>> wrote: >>>> >>>> Hi, >>>> >>>> mTLS is dead simple to use, secure, is used and can be used on a broad >>>> basis (in contrast to the token binding stuff). I also like the fact it >>>> provides both client authentication and sender-constraining. >>>> >>>> We started the work on DPoP for the simple reason that SPAs don’t work >>>> well with mTLS and we want to provide a solution with somehow limited >>>> capabilities, e.g. regarding replay protection (see DPoP introduction). >>>> >>>> If someone asks me for the default solution, it’s simple: use mTLS. And if >>>> you build a SPA and want to do really security sensitive things, implement >>>> your OAuth stuff and the RS interactions in the backend of your >>>> application. >>>> >>>> DPoP is in a really early stage, let’s see where it will go. >>>> >>>> best regards, >>>> Torsten. >>>> >>>>> On 7. May 2019, at 10:25, Hannes Tschofenig <hannes.tschofe...@arm.com> >>>>> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> In the OAuth conference call today Vittorio mentioned that some folks are >>>>> wondering whether DPOP is essentially a superset of MTLS and whether it >>>>> makes sense to only proceed with one solution rather potentially two. >>>>> >>>>> I was wondering whether others in the group have a few about this aspect? >>>>> >>>>> Ciao >>>>> Hannes >>>>> >>>>> IMPORTANT NOTICE: The contents of this email and any attachments are >>>>> confidential and may also be privileged. If you are not the intended >>>>> recipient, please notify the sender immediately and do not disclose the >>>>> contents to any other person, use it for any purpose, or store or copy >>>>> the information in any medium. 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 >>> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
