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

From: John Bradley <[email-masked]>
Date: Mon, 10 Oct 2016 17:59:49 -0300

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: [email-masked]
> 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" <[email-masked]>, "John Bradley" <[email-masked]>
> 
> 
> 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
>

---

From: "Preibisch, Sascha H" <[email-masked]>
Date: Tue, 11 Oct 2016 02:58:53 +0000

+1

From: Openid-specs-fapi <[email-masked]<mailto:[email-masked]>> on behalf of John Bradley via Openid-specs-fapi <[email-masked]<mailto:[email-masked]>>
Reply-To: John Bradley <[email-masked]<mailto:[email-masked]>>, Financial API Working Group List <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 10, 2016 at 1:59 PM
To: OAuth WG <[email-masked]<mailto:[email-masked]>>
Cc: Nat Sakimura via Openid-specs-fapi <[email-masked]<mailto:[email-masked]>>
Subject: [Openid-specs-fapi] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

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.

Regards
John B.

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
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" <[email-masked]<mailto:[email-masked]>>, "John Bradley" <[email-masked]<mailto:[email-masked]>>

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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_internet-2Ddrafts_draft-2Dcampbell-2Doauth-2Dtls-2Dclient-2Dauth-2D00.txt&d=DQMFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=y0V-Som1RDD_XSON16geiVwizJHHdigmrpofDystITA&s=260YDXh2PcZARRiXTxOl8pc5v0ziWSLzLiG9CI0OOlI&e=>
Status:         https://datatracker.ietf.org/doc/draft-campbell-oauth-tls-client-auth/<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dcampbell-2Doauth-2Dtls-2Dclient-2Dauth_&d=DQMFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=y0V-Som1RDD_XSON16geiVwizJHHdigmrpofDystITA&s=NOkb8avw2ZN74wW-gLDbuZfXskqV9xRqyYvV5Fg18_Y&e=>
Htmlized:       https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dcampbell-2Doauth-2Dtls-2Dclient-2Dauth-2D00&d=DQMFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=y0V-Som1RDD_XSON16geiVwizJHHdigmrpofDystITA&s=9z770xRpUnNkMOo9UDUj5gYGUZXwQljipKvN0VfMC74&e=>

Abstract:

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org&d=DQMFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BjnOFeRZMwPBZLm00SguJm4i4lt0O13oAeF-9EZheL8&m=y0V-Som1RDD_XSON16geiVwizJHHdigmrpofDystITA&s=kqP8TZStoJyWhk2OJiXgoNTWIsNvNH5qgGX7QBWBHWA&e=>.

The IETF Secretariat

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 17 Oct 2016 11:47:45 +0300

Superb, I welcome that!

Regarding
https://tools.ietf.org/html/draft-campbell-oauth-tls-client-auth-00#section-5.2
:

My concern is that the choice of how to bind the client identity is left
to implementers, and that may eventually become an interop problem.

Have you considered some kind of an open ended enumeration of the
possible binding methods, and giving them some identifiers or names, so
that AS / OPs can advertise them in their metadata, and clients register
accordingly?

For example:

"tls_client_auth_bind_methods_supported" : [ "subject_alt_name_match",
"subject_public_key_info_match" ]

Cheers,

Vladimir

On 10/10/16 23:59, John Bradley wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Fri, 21 Oct 2016 16:51:23 -0600

I did consider something like that but stopped short of putting it in the
-00 document. I'm not convinced that some metadata around it would really
contribute to interop one way or the other. I also wanted to get the basic
concept written down before going too far into the weeds. But I'd be open
to adding something along those lines in future revisions, if there's some
consensus that it'd be useful.

On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <[email-masked]
> wrote:

> Superb, I welcome that!
>
> Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls-
> client-auth-00#section-5.2 :
>
> Have you considered some kind of an open ended enumeration of the possible
> binding methods, and giving them some identifiers or names, so that AS /
> OPs can advertise them in their metadata, and clients register accordingly?
>
> For example:
>
> To: "Brian Campbell" <[email-masked]> <[email-masked]>, "John Bradley" <[email-masked]> <[email-masked]>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 27 Oct 2016 05:42:57 +0300

I see. Do you reckon the AS could simply probe the likely cert places
for containing the client_id? My reasoning is that there aren't that
many places where you could stick the client_id (let me know if I'm
wrong). If the AS is in doubt it will respond with invalid_client. I'm
starting to think this can work quite well. No extra meta param will be
needed (of which we have enough already).

---

From: Samuel Erdtman <[email-masked]>
Date: Thu, 27 Oct 2016 08:00:38 +0200

I think it is awesome that this document has been written since this is one
of the solutions that exists in the wild.

However I think that the connection to client (client_id) and certificate
could be more clearly specified, at the moment it is exemplified under
security considerations. I think there should be text saying that there
MUST be a binding and provide the default solution e.g. client_id as
subject common name.

Further I would prefer if it was not a MUST to include the client_id in the
HTTP request since I think there MUST exist a client binding in the
certificate. I think there is no need to have it explicitly in the HTTP
request. This might not be a problem for Classic OAuth but when adopted for
ACE framework (https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-03)
we would like to lessen the duplicated information as much as possible.

//Samuel

On Thu, Oct 27, 2016 at 4:42 AM, Vladimir Dzhuvinov <[email-masked]

> possible
> >> 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 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.
> >>
> >> To: "Brian Campbell" <[email-masked]> <
> [email-masked]>, "John Bradley" <[email-masked]> <
> [email-masked]>
> >>
> >>
> >> 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/

---

From: Brian Campbell <[email-masked]>
Date: Fri, 28 Oct 2016 14:31:20 -0600

Not wanting to add more meta parameters was a motivation. Also not being
sure of how to enumerate the possible approaches. My thinking was also that
there are a lot of factors involved and that it'd probably be better left
to service documentation to describe things like what authorities are
trusted and what the client to cert binding is. Like I said, we can look at
adding more metadata, if there's some consensus to do so. But I worry that
it'll just be bloat that doesn't really add value.

I also think that, in many situations, it's unlikely that a cert will
contain a client id anywhere as subject information. A client id is scoped
to a particular authorization server and it's hard to imagine a CA issuing
a cert with an identifier that's only meaningful in the context of some
other entity like that. Maybe in a more closed system where the AS and an
organizational CA are both in the same management/administrative domain but
not in the more general case.

On Wed, Oct 26, 2016 at 8:42 PM, Vladimir Dzhuvinov <[email-masked]

---

From: Brian Campbell <[email-masked]>
Date: Fri, 28 Oct 2016 14:56:21 -0600

On Thu, Oct 27, 2016 at 12:00 AM, Samuel Erdtman <[email-masked]> wrote:

> I think it is awesome that this document has been written since this is
> one of the solutions that exists in the wild.
>
>
Thanks. To some extent I was working to codify those existing solutions,
which is one of the reasons why the specific binding between client and
certificate is left open ended.

> MUST be a binding and provide the default solution e.g. client_id as

I sort of thought the need for connection between client and certificate
was implicit in the text that is in section 2. But I can work to make the
language more explicit. As I mentioned in my recent reply to Vladimir, I
expect client_id as subject common name to be more the exception rather
than the common case so don't feel it'd be appropriate as a default.

>
> Further I would prefer if it was not a MUST to include the client_id in
> the HTTP request since I think there MUST exist a client binding in the

There needs to be a binding between the client and certificate but that
doesn't mean the client id will be in the certificate. Having the client id
explicitly available in the HTTP request allows the AS to easily identify
the client independently and consistently from the content of the
certificate or key and allows the AS to not have to index its client
storage by some other value. It may lead to a small amount of duplicate
info in some cases but I believe the consistency is worth it.

//Samuel
>
>
> On Thu, Oct 27, 2016 at 4:42 AM, Vladimir Dzhuvinov <
> [email-masked]> wrote:
>

---

From: Samuel Erdtman <[email-masked]>
Date: Sun, 30 Oct 2016 16:27:56 +0100

Thanks for the reply Brian,

See inline

On Fri, Oct 28, 2016 at 10:56 PM, Brian Campbell <[email-masked]

> than the common case so don't feel it'd be appropriate as a default.

I agree it is written so that the connection to the certificate is
implicitly required but I think it would be better if it was explicit
written since the lack of a connection would result in a potential security
hole.

When it comes to the client_id I think subject common name or maybe subject
serial numbers will be the common location, and I think an example would be
valuable.

> info in some cases but I believe the consistency is worth it.

I´m not saying it is a bad Idea just that I would prefer if it was not a
MUST.
With very limited addition of code it is just as easy to get the
certificate attribute for client id as it is to get it from the HTTP
request data (at least in java). I also think that with the requirement to
match the incoming certificate in some way one has to read out the
certificate that was used to establish the connection to do some kind of
matching.

>>> >> At the request of the OpenID Foundation Financial Services API
>>> Working group, Brian Campbell and I have documented
>>> >> The Banks want to use it for some server to server API use cases
>>> being driven by new open banking regulation.
>>> >>