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

Discussion:

John Bradley

2016-10-10 20:59:49 UTC

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.

Preibisch, Sascha H

2016-10-11 02:58:53 UTC

Permalink

+1

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

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-***@ietf.org<mailto:internet-***@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" <***@gmail.com<mailto:***@gmail.com>>, "John Bradley" <***@ve7jtb.com<mailto:***@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://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:
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<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

Vladimir Dzhuvinov

2016-10-17 08:47:45 UTC

Permalink

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

Post by 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.

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Brian Campbell

2016-10-21 22:51:23 UTC

Permalink

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.

Post by Vladimir Dzhuvinov
Superb, I welcome that!
Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls-
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?
"tls_client_auth_bind_methods_supported" : [ "subject_alt_name_match",
"subject_public_key_info_match" ]
Cheers,
Vladimir
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.
Subject: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
Date: October 10, 2016 at 5:44:39 PM GMT-3
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
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
https://www.ietf.org/mailman/listinfo/oauth

Vladimir Dzhuvinov

2016-10-27 02:42:57 UTC

Permalink

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).

Post by Brian Campbell
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.

Samuel Erdtman

2016-10-27 06:00:38 UTC

Permalink

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

Post by Vladimir Dzhuvinov
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).

basic

Post by Brian Campbell
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

Post by Brian Campbell
consensus that it'd be useful.
On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <

possible

Post by Brian Campbell

Post by Vladimir Dzhuvinov
binding methods, and giving them some identifiers or names, so that AS /
OPs can advertise them in their metadata, and clients register

accordingly?

Post by Brian Campbell

Post by Vladimir Dzhuvinov
"tls_client_auth_bind_methods_supported" : [ "subject_alt_name_match",
"subject_public_key_info_match" ]
Cheers,
Vladimir
At the request of the OpenID Foundation Financial Services API Working

group, Brian Campbell and I have documented

Post by Brian Campbell

Post by Vladimir Dzhuvinov
mutual TLS client authentication. This is something that lots of

people do in practice though we have never had a spec for it.

Post by Brian Campbell

Post by Vladimir Dzhuvinov
The Banks want to use it for some server to server API use cases being

driven by new open banking regulation.

Post by Brian Campbell

Post by Vladimir Dzhuvinov
The largest thing in the draft is the IANA registration of

âtls_client_authâ Token Endpoint authentication method for use in
Registration and discovery.

Post by Brian Campbell

Post by Vladimir Dzhuvinov
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.

Post by Brian Campbell

Post by Vladimir Dzhuvinov
I hope that this is non controversial and the WG can adopt it quickly.
Regards
John B.
Subject: New Version Notification for draft-campbell-oauth-tls-

client-auth-00.txt

Post by Brian Campbell

Post by Vladimir Dzhuvinov
Date: October 10, 2016 at 5:44:39 PM GMT-3
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

Post by Brian Campbell

Post by Vladimir Dzhuvinov
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

Post by Brian Campbell

Post by Vladimir Dzhuvinov
Status: https://datatracker.ietf.org/

doc/draft-campbell-oauth-tls-client-auth/

Post by Brian Campbell

Post by Vladimir Dzhuvinov
Htmlized: https://tools.ietf.org/html/draft-campbell-oauth-tls-

client-auth-00

Post by Brian Campbell

Post by Vladimir Dzhuvinov
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

Post by Brian Campbell

Post by Vladimir Dzhuvinov
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
_______________________________________________

oauth

Post by Brian Campbell

Post by Vladimir Dzhuvinov
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Brian Campbell

2016-10-28 20:56:21 UTC

Permalink

Post by Samuel Erdtman
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.

Post by Samuel Erdtman
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.

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.

Post by Samuel Erdtman
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.

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

Post by Samuel Erdtman
On Thu, Oct 27, 2016 at 4:42 AM, Vladimir Dzhuvinov <

Post by Brian Campbell
I did consider something like that but stopped short of putting it in

the

Post by Brian Campbell
-00 document. I'm not convinced that some metadata around it would

really

Post by Brian Campbell
contribute to interop one way or the other. I also wanted to get the

basic

Post by Brian Campbell
concept written down before going too far into the weeds. But I'd be

open

Post by Brian Campbell
to adding something along those lines in future revisions, if there's

some

Post by Brian Campbell
consensus that it'd be useful.
On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <

Post by Vladimir Dzhuvinov
Superb, I welcome that!
Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls-
My concern is that the choice of how to bind the client identity is

left

Post by Brian Campbell

Post by Vladimir Dzhuvinov
to implementers, and that may eventually become an interop problem.
Have you considered some kind of an open ended enumeration of the

possible

Post by Brian Campbell

Post by Vladimir Dzhuvinov
binding methods, and giving them some identifiers or names, so that AS

Post by Brian Campbell

Post by Vladimir Dzhuvinov
OPs can advertise them in their metadata, and clients register

accordingly?

Post by Brian Campbell

group, Brian Campbell and I have documented

Post by Brian Campbell

Post by Vladimir Dzhuvinov
mutual TLS client authentication. This is something that lots of

people do in practice though we have never had a spec for it.

Post by Brian Campbell

Post by Vladimir Dzhuvinov
The Banks want to use it for some server to server API use cases being

driven by new open banking regulation.

Post by Brian Campbell

Post by Vladimir Dzhuvinov
The largest thing in the draft is the IANA registration of

âtls_client_authâ Token Endpoint authentication method for use in
Registration and discovery.

Post by Brian Campbell

Post by Vladimir Dzhuvinov
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.

Post by Brian Campbell

Post by Vladimir Dzhuvinov
I hope that this is non controversial and the WG can adopt it quickly.
Regards
John B.
Subject: New Version Notification for draft-campbell-oauth-tls-clien

t-auth-00.txt

Post by Brian Campbell

Authentication for OAuth Clients

Post by Brian Campbell

Post by Vladimir Dzhuvinov
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

Post by Brian Campbell

Post by Vladimir Dzhuvinov
Status: https://datatracker.ietf.org/

doc/draft-campbell-oauth-tls-client-auth/

Post by Brian Campbell

Post by Vladimir Dzhuvinov
Htmlized: https://tools.ietf.org/html/d

raft-campbell-oauth-tls-client-auth-00

Post by Brian Campbell

submission

Post by Brian Campbell

Post by Vladimir Dzhuvinov
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
_______________________________________________

ietf.org/mailman/listinfo/oauth

Post by Brian Campbell

Post by Vladimir Dzhuvinov
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Samuel Erdtman

2016-10-30 15:27:56 UTC

Permalink

Thanks for the reply Brian,

See inline

Post by Brian Campbell

Post by Samuel Erdtman
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.

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.

Post by Brian Campbell

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.

Post by Brian Campbell
//Samuel

Post by Samuel Erdtman
On Thu, Oct 27, 2016 at 4:42 AM, Vladimir Dzhuvinov <

Post by Brian Campbell
I did consider something like that but stopped short of putting it in

the

Post by Brian Campbell
-00 document. I'm not convinced that some metadata around it would

really

Post by Brian Campbell
contribute to interop one way or the other. I also wanted to get the

basic

Post by Brian Campbell
concept written down before going too far into the weeds. But I'd be

open

Post by Brian Campbell
to adding something along those lines in future revisions, if there's

some

Post by Brian Campbell
consensus that it'd be useful.
On Mon, Oct 17, 2016 at 2:47 AM, Vladimir Dzhuvinov <

Post by Vladimir Dzhuvinov
Superb, I welcome that!
Regarding https://tools.ietf.org/html/draft-campbell-oauth-tls-
My concern is that the choice of how to bind the client identity is

left

Post by Brian Campbell

Post by Vladimir Dzhuvinov
to implementers, and that may eventually become an interop problem.
Have you considered some kind of an open ended enumeration of the

possible

Post by Brian Campbell

Post by Vladimir Dzhuvinov
binding methods, and giving them some identifiers or names, so that

AS /

Post by Brian Campbell

Post by Vladimir Dzhuvinov
OPs can advertise them in their metadata, and clients register

accordingly?

Post by Brian Campbell

Post by Vladimir Dzhuvinov
"tls_client_auth_bind_methods_supported" : [

"subject_alt_name_match",

Post by Brian Campbell

Post by Vladimir Dzhuvinov
"subject_public_key_info_match" ]
Cheers,
Vladimir
At the request of the OpenID Foundation Financial Services API

Working group, Brian Campbell and I have documented

Post by Brian Campbell

Post by Vladimir Dzhuvinov
mutual TLS client authentication. This is something that lots of

people do in practice though we have never had a spec for it.

Post by Brian Campbell

Post by Vladimir Dzhuvinov
The Banks want to use it for some server to server API use cases

being driven by new open banking regulation.

Post by Brian Campbell

Post by Vladimir Dzhuvinov
The largest thing in the draft is the IANA registration of

âtls_client_authâ Token Endpoint authentication method for use in
Registration and discovery.

Post by Brian Campbell

Post by Vladimir Dzhuvinov
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.

Post by Brian Campbell

Post by Vladimir Dzhuvinov
I hope that this is non controversial and the WG can adopt it quickly.
Regards
John B.
Subject: New Version Notification for draft-campbell-oauth-tls-clien

t-auth-00.txt

Post by Brian Campbell

Authentication for OAuth Clients

Post by Brian Campbell

Post by Vladimir Dzhuvinov
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

Post by Brian Campbell

Post by Vladimir Dzhuvinov
Status: https://datatracker.ietf.org/

doc/draft-campbell-oauth-tls-client-auth/

Post by Brian Campbell

Post by Vladimir Dzhuvinov
Htmlized: https://tools.ietf.org/html/d

raft-campbell-oauth-tls-client-auth-00

Post by Brian Campbell

submission

Post by Brian Campbell

Post by Vladimir Dzhuvinov
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
_______________________________________________

ietf.org/mailman/listinfo/oauth

Post by Brian Campbell

Post by Vladimir Dzhuvinov
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Brian Campbell

2016-11-02 21:03:16 UTC

Permalink

That's fair. I agree it can be made more explicit and that it be good to do
so.

Post by Samuel Erdtman
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.

In my experience and the way we built support for mutual TLS OAuth client
auth the client_id value does not appear in the certificate anywhere. I'm
not saying it can't happen but don't think it's particularly common.

I can look at adding some examples, if there's some consensus that they'd
be useful and this document moves forward.

Post by Samuel Erdtman
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.

Justin Richer

2016-11-03 12:41:55 UTC

Permalink

I agree that the client_id is unlikely to be found inside the
certificate itself. The client_id is issued by the authorization server
for the client to use at that single AS. The certificate is issued by
the CA for the client to use on any connection. The AS and CA are not
likely to be the same system in most deployments. The client will use
the same cert across multiple connections, possibly multiple AS's, but
the same isn't true of the client_id.

Additionally, I think we want to allow for a binding of a self-signed
certificate using dynamic registration, much the way that we already
allow binding of a client-generated JWK today.

I do think that more examples and guidance are warranted, though, to
help AS developers.

-- Justin

Post by Samuel Erdtman
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.
That's fair. I agree it can be made more explicit and that it be good
to do so.
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.
In my experience and the way we built support for mutual TLS OAuth
client auth the client_id value does not appear in the certificate
anywhere. I'm not saying it can't happen but don't think it's
particularly common.
I can look at adding some examples, if there's some consensus that
they'd be useful and this document moves forward.
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.
Getting data out of the certificate isn't a concern. I just believe
that the constancy of having the client id parameter is worth the
potential small amount duplicate data in some cases. It's just a -00
draft though and if the WG wants to proceed with this document, we
seek further input and work towards some consensus.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Jim Manico

2016-11-03 12:48:41 UTC

Permalink

Just to be clear, the relationship should more like...

AS issues public key to clients, or client sends public key to AS. The authorities job is NOT to give the client the public key, but to sign the public key for authenticity. It's bad practice to accept the full cert (pub key+signature) from an authority. If an authority is creating your public key, they are also creating your private key.... bad.

The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id.

This seems like a bad idea. I suggest a separate key/signature for each service.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

I agree that the client_id is unlikely to be found inside the certificate itself. The client_id is issued by the authorization server for the client to use at that single AS. The certificate is issued by the CA for the client to use on any connection. The AS and CA are not likely to be the same system in most deployments. The client will use the same cert across multiple connections, possibly multiple AS's, but the same isn't true of the client_id.
Additionally, I think we want to allow for a binding of a self-signed certificate using dynamic registration, much the way that we already allow binding of a client-generated JWK today.
I do think that more examples and guidance are warranted, though, to help AS developers.
-- Justin

That's fair. I agree it can be made more explicit and that it be good to do so.

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.

In my experience and the way we built support for mutual TLS OAuth client auth the client_id value does not appear in the certificate anywhere. I'm not saying it can't happen but don't think it's particularly common.
I can look at adding some examples, if there's some consensus that they'd be useful and this document moves forward.

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.

Getting data out of the certificate isn't a concern. I just believe that the constancy of having the client id parameter is worth the potential small amount duplicate data in some cases. It's just a -00 draft though and if the WG wants to proceed with this document, we seek further input and work towards some consensus.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Justin Richer

2016-11-03 12:51:13 UTC

Permalink

Yes, I elided the certificate issuance process. The point remains the
same: you're not going to be submitting a CSR to the same party you're
getting your client_id from, usually. If the draft assumes that, then
it's incredibly limiting.

Do people really use separate TLS client certs for separate connections
in the wild? I've personally never seen that. What I've seen is that a
piece of software gets its certificate that it uses to make whatever
connections it needs to make.

-- Justin

Post by Jim Manico
Just to be clear, the relationship should more like...
AS issues public key to clients, or client sends public key to AS. The
authorities job is NOT to give the client the public key, but to sign
the public key for authenticity. It's bad practice to accept the full
cert (pub key+signature) from an authority. If an authority is
creating your public key, they are also creating your private key.... bad.

The client will use the same cert across multiple connections,

possibly multiple AS's, but the same isn't true of the client_id.
This seems like a bad idea. I suggest a separate key/signature for each service.
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

I agree that the client_id is unlikely to be found inside the
certificate itself. The client_id is issued by the authorization
server for the client to use at that single AS. The certificate is
issued by the CA for the client to use on any connection. The AS and
CA are not likely to be the same system in most deployments. The
client will use the same cert across multiple connections, possibly
multiple AS's, but the same isn't true of the client_id.
Additionally, I think we want to allow for a binding of a self-signed
certificate using dynamic registration, much the way that we already
allow binding of a client-generated JWK today.
I do think that more examples and guidance are warranted, though, to help AS developers.
-- Justin

Post by Samuel Erdtman
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.
That's fair. I agree it can be made more explicit and that it be good to do so.
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.
In my experience and the way we built support for mutual TLS OAuth
client auth the client_id value does not appear in the certificate
anywhere. I'm not saying it can't happen but don't think it's
particularly common.
I can look at adding some examples, if there's some consensus that
they'd be useful and this document moves forward.
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.
Getting data out of the certificate isn't a concern. I just believe
that the constancy of having the client id parameter is worth the
potential small amount duplicate data in some cases. It's just a -00
draft though and if the WG wants to proceed with this document, we
seek further input and work towards some consensus.
_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
https://www.ietf.org/mailman/listinfo/oauth

Jim Manico

2016-11-03 14:31:39 UTC

Permalink

Thanks Justin. I use several security intel services and they all have different cert delivery mechanisms for mutual TLS. It's â¢rareâ¢ for services to let clients choose certs, they are usually assigned to users by each service from my experience.

Aloha,
--
Jim Manico
@Manicode
Secure Coding Education
+1 (808) 652-3805

Yes, I elided the certificate issuance process. The point remains the same: you're not going to be submitting a CSR to the same party you're getting your client_id from, usually. If the draft assumes that, then it's incredibly limiting.
Do people really use separate TLS client certs for separate connections in the wild? I've personally never seen that. What I've seen is that a piece of software gets its certificate that it uses to make whatever connections it needs to make.
-- Justin

Post by Jim Manico
Just to be clear, the relationship should more like...
AS issues public key to clients, or client sends public key to AS. The authorities job is NOT to give the client the public key, but to sign the public key for authenticity. It's bad practice to accept the full cert (pub key+signature) from an authority. If an authority is creating your public key, they are also creating your private key.... bad.