Dude. You're freaking awesome. Thanks for this insight. -- Jim Manico @Manicode Secure Coding Education +1 (808) 652-3805
> On Nov 24, 2016, at 7:48 AM, Samuel Erdtman <sam...@erdtman.se> wrote: > > +1 on providing guidance. > > >> On Wed, Nov 16, 2016 at 12:08 AM, Brian Campbell >> <bcampb...@pingidentity.com> wrote: >> Yes, I believe you are correct. Client certificates are provided in the >> handshake (initial or renegotiated) at the request of the server. If the >> server asks and the client doesn't provide a cert, it's up to the server >> whether to continue or about the handshake. >> >> There seem to be a number of different ways of trying to deal with this (not >> strictly for this OAuth case but similar situations). >> >> The AS could always request client certs but allow connections to proceed >> regardless. Then check for certs for appropriate clients while processing >> token requests. I guess there's a little overhead in the handshake with >> this for all the connections that won't present a cert. But not a ton. The >> main drawback is that some/many browsers have UI that will prompt users to >> choose a cert even when they don't have any. And the user experience can be >> very bad or confusing as a result. >> >> The token endpoint could be on a different host or port which always >> requests client certs. Still allow connections to proceed regardless and >> check the client credentials at the OAuth layer. Pretty similar to the above >> but avoids the usability issues with end users because it's only at the >> token endpoint. >> >> Trying renegotiation after the application sees that it's a token request or >> that it's a token request from a client id that's configured for mutual TLS >> is another approach. In my own limited experience with this kind of thing, >> however, this approach can be kind of flaky. And your point about the >> initial data not being trustworthy is legitimate. I'm not sure if it really >> matters in this case. I don't know. And signaling to resubmit is another >> issue all together. >> >> There are probably other approaches too but those are the things I've seen >> or can imagine. In all (or nearly all) the deployments of our stuff that I >> know about that deal with mutual TLS, some variation of the second option is >> used. >> >> All this seem like implementation/deployment details though and I'm hesitant >> to try and define how to do it in this doc. Maybe providing some guidance. >> I'm not exactly sure how to do that though. >> >> >> >>> On Tue, Nov 15, 2016 at 10:14 AM, Samuel Erdtman <sam...@erdtman.se> wrote: >>> Torstens questions triggers another question from me. >>> >>> If we have an AS that can handle both certificate client auth and client >>> secret, how does the AS know that it should ask for client certificate on >>> the TLS layer. >>> >>> It was a while since I last read the TLS specification and it might have >>> changed but if i remember correctly client certificates are provided in >>> initial handshake or in re-negotiate and it is only provided on request by >>> the server. >>> >>> If this is still true the AS would need to first get the token request, see >>> that this is a client that authenticates with certificate and request a TLS >>> re-negotiate to get the certificate authentication and a re-submission of >>> the token request since we cannot trust the data first submitted. >>> >>> Are I missing something obvious, or is this something that needs to be >>> defined? >>> >>> //Samuel >>> >>> >>> >>> >>> >>> >>> >>>> On Mon, Nov 14, 2016 at 1:26 AM, Justin Richer <jric...@mit.edu> wrote: >>>> Right — this is a fine way to put it. RFC7591 defines a client model where >>>> RFC6749 didn’t. Ideally all that metadata would’ve been in the original >>>> spec, but it’s not. It doesn’t matter whether the client was registered >>>> dynamically or statically, it just matters that the AS knows what to >>>> expect from a given client. >>>> >>>> — Justin >>>> >>>>> On Nov 14, 2016, at 6:21 AM, Brian Campbell <bcampb...@pingidentity.com> >>>>> wrote: >>>>> >>>>> Yes, the intend is that the authentication method is determined by client >>>>> policy regardless of whether the client was dynamically registered or >>>>> statically configured or whatever. I can make that point more explicit in >>>>> future revisions of the draft. >>>>> >>>>>> On Sat, Nov 12, 2016 at 10:59 PM, Torsten Lodderstedt >>>>>> <tors...@lodderstedt.net> wrote: >>>>>> I understand. My point is different: the text seems to assume everybody >>>>>> is using client registration, but that's not the case. I would like to >>>>>> point out it makes sense to explicitely state the assumption that it is >>>>>> determined by client policy (indepedent of the way this policy is >>>>>> established). >>>>>> >>>>>> >>>>>>> Am 13.11.2016 um 14:24 schrieb Justin Richer: >>>>>>> As part of the client’s registered data model. At least, based on how >>>>>>> our own implementation works (where we support client_secret_basic, >>>>>>> private_key_jwt, etc), that’s where we’d check to see if the client was >>>>>>> supposed to be using TLS auth or not. >>>>>>> >>>>>>> We don’t let clients switch away from their registered auth mechanism. >>>>>>> >>>>>>> — Justin >>>>>>> >>>>>>>> On Nov 13, 2016, at 2:21 PM, Torsten Lodderstedt >>>>>>>> <tors...@lodderstedt.net> wrote: >>>>>>>> >>>>>>>> Justin, >>>>>>>> >>>>>>>>> Am 13.11.2016 um 13:39 schrieb Justin Richer: >>>>>>>>> Torsten, I believe this is intended to be triggered by the >>>>>>>>> tls_client_auth value specified in §3. >>>>>>>> >>>>>>>> in the token request? >>>>>>>> >>>>>>>>> >>>>>>>>> Nit on that section, the field name for the client metadata in >>>>>>>>> RFC7591 is token_endpoint_auth_method, the _supported version is from >>>>>>>>> the corresponding discovery document. >>>>>>>>> >>>>>>>>> — Justin >>>>>>>>> >>>>>>>> Torsten. >>>>>>>>>> On Nov 13, 2016, at 12:31 PM, Torsten Lodderstedt >>>>>>>>>> <tors...@lodderstedt.net> wrote: >>>>>>>>>> >>>>>>>>>> Hi John and Brian, >>>>>>>>>> >>>>>>>>>> thanks for writting this draft. >>>>>>>>>> >>>>>>>>>> One question: how does the AS determine the authentication method is >>>>>>>>>> TLS authentication? I think you assume this is defined by the >>>>>>>>>> client-specific policy, independent of whether the client is >>>>>>>>>> registered automatically or manually. Would you mind to explicitely >>>>>>>>>> state this in the draft? >>>>>>>>>> >>>>>>>>>> best regards, >>>>>>>>>> Torsten. >>>>>>>>>> >>>>>>>>>>> Am 11.10.2016 um 05:59 schrieb John Bradley: >>>>>>>>>>> At the request of the OpenID Foundation Financial Services API >>>>>>>>>>> Working group, Brian Campbell and I have documented >>>>>>>>>>> mutual TLS client authentication. This is something that lots of >>>>>>>>>>> people do in practice though we have never had a spec for it. >>>>>>>>>>> >>>>>>>>>>> The Banks want to use it for some server to server API use cases >>>>>>>>>>> being driven by new open banking regulation. >>>>>>>>>>> >>>>>>>>>>> The largest thing in the draft is the IANA registration of >>>>>>>>>>> “tls_client_auth” Token Endpoint authentication method for use in >>>>>>>>>>> Registration and discovery. >>>>>>>>>>> >>>>>>>>>>> The trust model is intentionally left open so that you could use a >>>>>>>>>>> “common name” and a restricted list of CA or a direct lookup of the >>>>>>>>>>> subject public key against a reregistered value, or something in >>>>>>>>>>> between. >>>>>>>>>>> >>>>>>>>>>> I hope that this is non controversial and the WG can adopt it >>>>>>>>>>> quickly. >>>>>>>>>>> >>>>>>>>>>> Regards >>>>>>>>>>> John B. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>> >>>>>>>>>>>> From: internet-dra...@ietf.org >>>>>>>>>>>> Subject: New Version Notification for >>>>>>>>>>>> draft-campbell-oauth-tls-client-auth-00.txt >>>>>>>>>>>> Date: October 10, 2016 at 5:44:39 PM GMT-3 >>>>>>>>>>>> To: "Brian Campbell" <brian.d.campb...@gmail.com>, "John Bradley" >>>>>>>>>>>> <ve7...@ve7jtb.com> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> A new version of I-D, draft-campbell-oauth-tls-client-auth-00.txt >>>>>>>>>>>> has been successfully submitted by John Bradley and posted to the >>>>>>>>>>>> IETF repository. >>>>>>>>>>>> >>>>>>>>>>>> Name: draft-campbell-oauth-tls-client-auth >>>>>>>>>>>> Revision: 00 >>>>>>>>>>>> Title: Mutual X.509 Transport Layer Security (TLS) >>>>>>>>>>>> Authentication for OAuth Clients >>>>>>>>>>>> Document date: 2016-10-10 >>>>>>>>>>>> Group: Individual Submission >>>>>>>>>>>> Pages: 5 >>>>>>>>>>>> URL: >>>>>>>>>>>> https://www.ietf.org/internet-drafts/draft-campbell-oauth-tls-client-auth-00.txt >>>>>>>>>>>> Status: >>>>>>>>>>>> https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ >>>>>>>>>>>> Htmlized: >>>>>>>>>>>> https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Abstract: >>>>>>>>>>>> This document describes X.509 certificates as OAuth client >>>>>>>>>>>> credentials using Transport Layer Security (TLS) mutual >>>>>>>>>>>> authentication as a mechanism for client authentication to the >>>>>>>>>>>> authorization server's token endpoint. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>>>>>>> submission >>>>>>>>>>>> until the htmlized version and diff are available at >>>>>>>>>>>> tools.ietf.org. >>>>>>>>>>>> >>>>>>>>>>>> The IETF Secretariat >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
