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

[Jim Manico <[e-mail]>]

Dude. You're freaking awesome. Thanks for this insight.

--
Jim Manico
@Manicode
Secure Coding Education
[phone]

> On Nov 24, 2016, at 7:48 AM, Samuel Erdtman <[e-mail]> wrote:
> 
> +1 on providing guidance.
> 
> 
>> On Wed, Nov 16, 2016 at 12: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]> 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]
>>>>>>>>>>>> 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]>, "John Bradley" <[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
>>>>>>>>>>>> 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
>>>>>>>>>>> [e-mail]
>>>>>>>>>>> https://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
>>>> 
>>> 
>> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth