Re: [OAUTH-WG] New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

[Brian Campbell <[e-mail]>]

Whoops, "about" at the end of the 1st paragraph should be "abort".

On Nov 16, 2016 8:08 AM, "Brian Campbell" <[e-mail]>
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 <[e-mail]>
> 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 <[e-mail]> 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 <[e-mail]>
>>> 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 <
>>> [e-mail]> 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 <
>>>> [e-mail]> 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 <
>>>> <[e-mail]>[e-mail]> 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: * <[e-mail]>[e-mail]
>>>> *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" < <[e-mail]>
>>>> [e-mail]>, "John Bradley" < <[e-mail]>
>>>> [e-mail]>
>>>>
>>>>
>>>> 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 [e-mail]://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>