Whoops, "about" at the end of the 1st paragraph should be "abort".
On Nov 16, 2016 8: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>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>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> >>>> brian.d.campb...@gmail.com>, "John Bradley" < <ve7...@ve7jtb.com> >>>> 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> >>>> https://www.ietf.org/internet-drafts/draft-campbe >>>> ll-oauth-tls-client-auth-00.txt >>>> Status: >>>> <https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/> >>>> https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/ >>>> Htmlized: >>>> <https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00> >>>> 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 listOAuth@ietf.orghttps://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
