Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt

From: Brian Campbell <[email-masked]>
Date: Tue, 1 Aug 2017 13:57:10 -0600

Thanks Justin.

In my original announcement email, I should have given credit to Torsten as
he made many of the updates in -03. So complements on improvements as well
as blame for issues can be pointed to him as well!

Your point about document structure is taken and we will look to make the
separation of the client authentication and resource access more clear in
future revisions. The document was aiming for something conceptually along
those same lines already. But it could be made more clear.

This could define a new “token_type” but other than having different token
type names in messages, I don't know that a new token_type or HTTP auth
scheme that would probably have to come along with it adds value to the use
cases here. However, they would very likely make deployment of this stuff
much more cumbersome and take longer.  Whereas many systems can likely plug
in mutual TLS on top of the existing token_type and HTTP auth scheme
without major changes. I'm strongly inclined to not introduce a new
token_type and more inclined to not do a new HTTP auth scheme.

Fair point about breaking out all the registered parameters into their own
hanging list items. It is somewhat inconsistent in that regard now. Will
look to address that in a future revision.

Using just a certificate hash for mTLS sender constrained access tokens was
intentional to allow mTLS at the resource to be used as a
proof-of-possession method only. It's part of the authorization check at
resource access and deliberately not about authentication with the RS.
Using the hash simplifies the check at the RS to one consistent way of
doing things while allowing for different modes of doing client
authentication at the AS. So the lack of parallelism with the client
authentication at the token endpoint was very much intentional. Following
from that, the need to do mTLS at the token endpoint in order to get
mTLS-bound access tokens for an RS was also kind of intentional. Though, as
§4.3 <https://tools.ietf.org/html/draft-ietf-oauth-mtls-03#section-4.3>
attempts to describe, a public client could do mTLS at the token endpoint
with a generated self-singed cert to have an access token bound but not
actually authenticate to the token endpoint. You are certainly right that
there are other ways an AS could decide on the certificate to bind the
access token to. And other ways a cnf claim member could provide for such a
binding. But we were aiming to not provide too many options in the doc. So
my thinking here was that this draft is about mTLS and so saying how to use
mTLS for the AS to do the access token binding seemed like the most
appropriate and straightforward approach. It's not so much that mTLS
authentication is needed for the client at the token endpoint to allow for
bound access tokens. But rather that having mTLS at the token endpoint
provides a strong signal of the certificate to which to bind the issued
access token.

On Mon, Jul 31, 2017 at 2:18 PM, Justin Richer <[email-masked]> wrote:

> Brian, thanks for the update. This is really coming along!
>
> I think the spec would benefit from a more clear separation of the client
> authentication and resource access sections. They’re really almost two
> different but related specs, but there’s enough overlap that I think that
> keeping them in the same document is fine with some structural changes
> applied. I think the content is by and large all here, it’s just jumbled
> together.
>
> To that end, I think there might be three major sections to this document
> (not counting the IANA, security, privacy, and other boilerplate bits). A
> suggested breakdown:
>
> 1) Types of mTLS client auth under consideration. This is where the
> definition of public key vs. pki comes in, and where the two authentication
> methods are defined for both registration and discovery. Some implementor’s
> notes on what kinds of things you need to store here, including the
> tls_client_auth_ client metadata extensions. For better or worse, 7591
> defines OAuth’s client model, and not just for dynamic registration.
>
> 2) How to use mTLS to authenticate a client. This can be a relatively
> short section that says use (1) in the context of getting an access token
> at the token endpoint. Here is where you point out that you still need to
> send client_id and that the association with the cert’s DN and the
> client_id is done at the AS (there’s existing text for this).
>
> 3) How to use mTLS to bind an access token. This is a bit more complicated
> because it’s the RS that needs to know the binding between the token and
> the cert’s DN, so that’s where you’d define the “cnf” stuff. An unfortunate
> side effect of spec history means that the “cnf” claim for 7662 also gets
> defined here. This is also where you’d put the bits about
> mutual_tls_sender_constrained_access_tokens for discovery and
> registration. Should this be a new “token_type”?
>
>
> A few more comments:
>
> §2.3 really should break out all registered parameters into their own
> hanging list items (even if you break them up into different sections like
> suggested above)
>
> §3 seems to say that you can only do mTLS-bound access tokens at an RS if
> you do mTLS authentication at the token endpoint. Is that an intentional
> restriction? To me these two functions seem to be more orthogonal than the
> spec is hinting at. Like, I could use private_key_jwt or PKCE or magic to
> authenticate at the RS but use mTLS at the RS, for whatever esoteric
> reason, like the AS and RS being in different security domains. Still,
> functionally, if the client’s registered parameters are enough to trust for
> token issuance, they should be enough to trust for token usage. In other
> words, have the RS depend on tls_client_auth_subject_dn etc. instead of
> "the same certificate that was used for mutual TLS at the token endpoint".
>
> Along those lines, §3 also depends entirely on matching a specific
> certificate hash instead of validating a certificate (and possibly it’s
> chain) and associated DN. This isn’t in parallel with the client
> authentication at the token endpoint, and I’d like to see these come
> together. Should we have a third certificate validation method in §2 for
> “certificate hash”? Or maybe we should have a separate list for
> “resource_server_auth_method” for the client?
>
> In any event, it still feels like there are two things that are fighting
> for attention in this spec: cert-based authentication of the client at the
> token endpoint, and cert-based PoP of the token at the resource.
>
>  — Justin
>
> On Jul 28, 2017, at 2:33 PM, Brian Campbell <[email-masked]>
> wrote:
>
> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published with
> the changes listed below based on comments and dissuasion in Prague.
>
>    draft-ietf-oauth-mtls-03 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>
>
>    o  Introduced metadata and client registration parameter to publish
>       and request support for mutual TLS sender constrained access
>       tokens
>    o  Added description of two methods of binding the cert and client,
>       PKI and Public Key.
>    o  Indicated that the "tls_client_auth" authentication method is for
>       the PKI method and introduced "pub_key_tls_client_auth" for the
>       Public Key method
>    o  Added implementation considerations, mainly regarding TLS stack
>       configuration and trust chain validation, as well as how to to do
>       binding of access tokens to a TLS client certificate for public
>       clients, and considerations around certificate bound access tokens
>    o  Added new section to security considerations on cert spoofing
>    o  Add text suggesting that a new cnf member be defined in the
>       future, if hash function(s) other than SHA-256 need to be used for
>       certificate thumbprints
>
>
>
> ---------- Forwarded message ----------
> From: <[email-masked]>
> Date: Fri, Jul 28, 2017 at 12:25 PM
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-mtls-03.txt
> To: [email-masked]
> Cc: [email-masked]
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>
>         Title           : Mutual TLS Profile for OAuth 2.0
>         Authors         : Brian Campbell
>                           John Bradley
>                           Nat Sakimura
>                           Torsten Lodderstedt
>         Filename        : draft-ietf-oauth-mtls-03.txt
>         Pages           : 17
>         Date            : 2017-07-28
>
> Abstract:
>    This document describes Transport Layer Security (TLS) mutual
>    authentication using X.509 certificates as a mechanism for OAuth
>    client authentication to the token endpoint as well as for
>    certificate bound sender constrained access tokens.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-oauth-mtls-03
> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03
>
>
> 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.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> *CONFIDENTIALITY NOTICE: This email may contain confidential and
> privileged material for the sole use of the intended recipient(s). Any
> review, use, distribution or disclosure by others is strictly prohibited.
> If you have received this communication in error, please notify the sender
> immediately by e-mail and delete the message and any file attachments from
> your computer. Thank you.*_______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>

-- 
*CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you.*

---

From: John Bradley <[email-masked]>
Date: Tue, 1 Aug 2017 17:45:40 -0400

I agree with Brian on the points about the difference between validating the certificate at the AS for client authentication and the RS.  This was defiantly intentional.   

Lets face it people do a crap job of validating certificates in general.  While browsers validating TLS certificates is not bad for the most part, asking developers to do PKIX validation is almost always going to go wrong in deployment some significant percentage of the time.

The idea is to have the AS do all the heavy lifting and allow the RS to be as dumb as possible.  It should not need to check certificate expiry or other validity.  It should do a simple compare and be done with it.   If people want something else fine but we should not add extra options for edge cases that are likely to go wrong.

In the SAML R&E community using bear keys in meta-data rather than CA certificates is the preferred option to avoid runtime certificate issues and only validate certificates for meta-data.

I personally would be happiest if the AS also just compared a thumbprint of the cert based on a registered HTTPS JWKS_URI and validate any cert at that level where things are better understood and OCSP pinning etc is available.

Cutting out the AS validating the cert via PKIX was a bridge to far for banking due to perceived EU digital signature regulations.  However it is fragile and will cause issues.

We struck a balance.

The same is true about requiring mutual TLS at the AS.  Yes you could do it other ways, however that requires more complexity passing the cert to the AS.   This is simple and harder to mess up.

This is the striped down 80% spec without the chrome hood ornament.    The feeding is that if you want mutual TLS then doing it on all the legs is not a huge burden.

Mobile clients can use it via dynamic registration if there is a real use case.

In general the authors still think that token binding will be the more mass market consumer option. 

This is intended to fill the need for people that are forced to use MTLS by regulation or can’t wait to deploy.

It is always tempting to add features,  I am perhaps one of worst perpetrators of that.   

This we wanted to be simple enough to cover the EU banking use case and get implemented and deployed in a reasonable amount of time.

John B.
> On Aug 1, 2017, at 3:57 PM, Brian Campbell <[email-masked]> wrote:
> 
> Thanks Justin. 
> 
> In my original announcement email, I should have given credit to Torsten as he made many of the updates in -03. So complements on improvements as well as blame for issues can be pointed to him as well!
> 
> Your point about document structure is taken and we will look to make the separation of the client authentication and resource access more clear in future revisions. The document was aiming for something conceptually along those same lines already. But it could be made more clear.
> 
> This could define a new “token_type” but other than having different token type names in messages, I don't know that a new token_type or HTTP auth scheme that would probably have to come along with it adds value to the use cases here. However, they would very likely make deployment of this stuff much more cumbersome and take longer.  Whereas many systems can likely plug in mutual TLS on top of the existing token_type and HTTP auth scheme without major changes. I'm strongly inclined to not introduce a new token_type and more inclined to not do a new HTTP auth scheme. 
> 
> Fair point about breaking out all the registered parameters into their own hanging list items. It is somewhat inconsistent in that regard now. Will look to address that in a future revision.
> 
> Using just a certificate hash for mTLS sender constrained access tokens was intentional to allow mTLS at the resource to be used as a proof-of-possession method only. It's part of the authorization check at resource access and deliberately not about authentication with the RS. Using the hash simplifies the check at the RS to one consistent way of doing things while allowing for different modes of doing client authentication at the AS. So the lack of parallelism with the client authentication at the token endpoint was very much intentional. Following from that, the need to do mTLS at the token endpoint in order to get mTLS-bound access tokens for an RS was also kind of intentional. Though, as §4.3 <https://tools.ietf.org/html/draft-ietf-oauth-mtls-03#section-4.3> attempts to describe, a public client could do mTLS at the token endpoint with a generated self-singed cert to have an access token bound but not actually authenticate to the token endpoint. You are certainly right that there are other ways an AS could decide on the certificate to bind the access token to. And other ways a cnf claim member could provide for such a binding. But we were aiming to not provide too many options in the doc. So my thinking here was that this draft is about mTLS and so saying how to use mTLS for the AS to do the access token binding seemed like the most appropriate and straightforward approach. It's not so much that mTLS authentication is needed for the client at the token endpoint to allow for bound access tokens. But rather that having mTLS at the token endpoint provides a strong signal of the certificate to which to bind the issued access token. 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Jul 31, 2017 at 2:18 PM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> I think the spec would benefit from a more clear separation of the client authentication and resource access sections. They’re really almost two different but related specs, but there’s enough overlap that I think that keeping them in the same document is fine with some structural changes applied. I think the content is by and large all here, it’s just jumbled together.
> 
> To that end, I think there might be three major sections to this document (not counting the IANA, security, privacy, and other boilerplate bits). A suggested breakdown:
> 
> 1) Types of mTLS client auth under consideration. This is where the definition of public key vs. pki comes in, and where the two authentication methods are defined for both registration and discovery. Some implementor’s notes on what kinds of things you need to store here, including the tls_client_auth_ client metadata extensions. For better or worse, 7591 defines OAuth’s client model, and not just for dynamic registration.
> 
> 2) How to use mTLS to authenticate a client. This can be a relatively short section that says use (1) in the context of getting an access token at the token endpoint. Here is where you point out that you still need to send client_id and that the association with the cert’s DN and the client_id is done at the AS (there’s existing text for this).
> 
> 3) How to use mTLS to bind an access token. This is a bit more complicated because it’s the RS that needs to know the binding between the token and the cert’s DN, so that’s where you’d define the “cnf” stuff. An unfortunate side effect of spec history means that the “cnf” claim for 7662 also gets defined here. This is also where you’d put the bits about mutual_tls_sender_constrained_access_tokens for discovery and registration. Should this be a new “token_type”?
>  
> 
> A few more comments:
> 
> §2.3 really should break out all registered parameters into their own hanging list items (even if you break them up into different sections like suggested above)
> 
> §3 seems to say that you can only do mTLS-bound access tokens at an RS if you do mTLS authentication at the token endpoint. Is that an intentional restriction? To me these two functions seem to be more orthogonal than the spec is hinting at. Like, I could use private_key_jwt or PKCE or magic to authenticate at the RS but use mTLS at the RS, for whatever esoteric reason, like the AS and RS being in different security domains. Still, functionally, if the client’s registered parameters are enough to trust for token issuance, they should be enough to trust for token usage. In other words, have the RS depend on tls_client_auth_subject_dn etc. instead of "the same certificate that was used for mutual TLS at the token endpoint". 
> 
> Along those lines, §3 also depends entirely on matching a specific certificate hash instead of validating a certificate (and possibly it’s chain) and associated DN. This isn’t in parallel with the client authentication at the token endpoint, and I’d like to see these come together. Should we have a third certificate validation method in §2 for “certificate hash”? Or maybe we should have a separate list for “resource_server_auth_method” for the client?
> 
> In any event, it still feels like there are two things that are fighting for attention in this spec: cert-based authentication of the client at the token endpoint, and cert-based PoP of the token at the resource.
> 
>  — Justin
> 
>> On Jul 28, 2017, at 2:33 PM, Brian Campbell <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> A new draft of "Mutual TLS Profile for OAuth 2.0" has been published with the changes listed below based on comments and dissuasion in Prague. 
>> 
>> From: <[email-masked] <mailto:[email-masked]>>
>> To: [email-masked] <mailto:[email-masked]>
>> Cc: [email-masked] <mailto:[email-masked]>
>> 
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/>
>> 
>> https://tools.ietf.org/html/draft-ietf-oauth-mtls-03 <https://tools.ietf.org/html/draft-ietf-oauth-mtls-03>
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>
>> 
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03 <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03>
>> 
>> 
>> 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 <http://tools.ietf.org/>.
>> 
>> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>> 
>> 
>> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
>> OAuth mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> 
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._______________________________________________
> OAuth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 2 Aug 2017 10:53:39 +0300

Thanks everyone for the update! Having a clear distinction between the
PKIX vs public key bound methods will help interop, implementers' job,
and it also appears good for security.

Questions:

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03#section-2.3

> where the X.509 certificates are represented using the "x5c" parameter from [RFC7517 <https://datatracker.ietf.org/doc/html/rfc7517>]

For the public key method, is it really necessary for the client to
include its certificate in the JWK x5c parameter? This will make
implementation harder for developers, and I'm not sure it adds anything
in terms of security. Registering the public key parameters seems
sufficient to me.

https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03#section-2.1

> When used in conjunction with a trusted X.509 certificate source, it also allows the client to rotate its X.509 certificates without the need to change its respective authentication data at the authorization server.
I don't understand this - "in conjunction with a trusted X.509
certificate source"

Thanks,

Vladimir

On 28/07/17 21:33, Brian Campbell wrote:
>    draft-ietf-oauth-mtls-03
> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 2 Aug 2017 11:02:37 +0300

In terms of structure, I would like to suggest giving PKI bound auth and
pub key bound mTLS auth their own sections, instead of having them in
one section (2.1 as it is now).

The two methods are distinctive enough, and implementers should easily
recognise they can implement just one of them.

Vladimir

---

From: Brian Campbell <[email-masked]>
Date: Wed, 2 Aug 2017 09:29:54 -0600

Thanks for the review, Vladimir.

The text about which you have questions was written by Torsten (credit or
blame where it's due!) but I believe he's out of the office for a bit so
I'll try and answer.

Your 1st question:
I've had the same thought regarding the public key method and using the JWK
x5c parameter. A JWK already has the public key, which is sufficient for
comparison in the public key method. So x5c is just superfluous here. I
believe that's a change that the next revision should have and will look to
make it unless someone wants to make a strong case for needing x5c.

Your 2nd question:
I also found the sentence, "When used in conjunction with a trusted X.509
certificate source, it also allows the client to rotate its X.509
certificates without the need to change its respective authentication data
at the authorization server." somewhat difficult to understand when I first
read it. The intended meaning relies on content earlier in the same
paragraph that says, "As pre-requisite, the client registers a X.509
certificate or *a trusted source for its X.509 certificates (jwks uri as
defined in [RFC7591])* with the authorization server."  Basically what it's
trying to say is that when a client is registered or configured with a
jwks_uri, then client key rotation can be done without needing to
explicitly update the client config/registration with the AS. Does that
explain it? I believe the text could be more straightforward and will
endeavor to make it more clear in the next draft update.

On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov <[email-masked]>
wrote:

> PKIX vs public key bound methods will help interop, implementers' job, and
> it also appears good for security.
>
> Questions:
>
> implementation harder for developers, and I'm not sure it adds anything in
> terms of security. Registering the public key parameters seems sufficient
> to me.
>
>
> I don't understand this - "in conjunction with a trusted X.509 certificate
> source"
>
>
> Thanks,
>
> Vladimir
>
>    draft-ietf-oauth-mtls-03<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>
>
>
> From: <[email-masked]> <[email-masked]>
> The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/
>
> There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03
>
> A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03
>
>
> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 2 Aug 2017 09:41:58 -0600

A fair suggestion and we'll see what can be done to make the distinction
more clear.

On Wed, Aug 2, 2017 at 2:02 AM, Vladimir Dzhuvinov <[email-masked]>
wrote:

> >> On Jul 28, 2017, at 2:33 PM, Brian Campbell <[email-masked]
> >
> >> wrote:
> >>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 3 Aug 2017 12:48:58 +0200

Hi Justin,

thanks for reviewing the draft. 

> Am 01.08.2017 um 21:57 schrieb Brian Campbell <[email-masked]>:
> 
> Thanks Justin. 
> 

I agree. Although on a conceptual level the sender restricted access tokens as described in this draft are different, there is no difference in the HTTP payload. The difference lays completely in the way the TLS connection is established (which somehow makes the beauty of the concept). I therefore think introducing a new token type is inappropriate. But still, the clients needs to treat requests to a RS using sender constraint access tokens different than requests to a RS utilizing bearer tokens. I could image the RS may announce its mTLS support via another metadata parameter „mutual_tls_sender_constrained_access_tokens“ in the 401 response. 

best regards,
Torsten.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 4 Aug 2017 12:13:06 -0600

Just wanted to note that, in an off-list exchange, John has pushed back on
the idea to potentially drop mention of using x5c.

On Wed, Aug 2, 2017 at 9:29 AM, Brian Campbell <[email-masked]>
wrote:

> I've had the same thought regarding the public key method and using the
> JWK x5c parameter. A JWK already has the public key, which is sufficient
> for comparison in the public key method. So x5c is just superfluous here. I
> defined in [RFC7591])* with the authorization server."  Basically what
> it's trying to say is that when a client is registered or configured with a
> On Wed, Aug 2, 2017 at 1:53 AM, Vladimir Dzhuvinov <
> [email-masked]> wrote:
>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 4 Aug 2017 22:17:34 +0300

What are the potential uses of the x5c parameter?

Vladimir

---

From: Brian Campbell <[email-masked]>
Date: Fri, 4 Aug 2017 13:32:22 -0600

His argument (best I can articulate anyway) is that there may be
difficulties or gotchas in some cases in doing a comparison of the public
key from the client cert to the public key from a JWK. Where the comparison
or the client cert directly to the cert from x5c in a JWK would be more
straightforward and/or less error prone. I don't necessarily agree but
wanted to bring the discussion back to the list.

On Fri, Aug 4, 2017 at 1:17 PM, Vladimir Dzhuvinov <[email-masked]>
wrote:

> >>> where the X.509 certificates are represented using the "x5c" parameter
> from [RFC7517 <https://datatracker.ietf.org/doc/html/rfc7517>]
> >>>
> >>> When used in conjunction with a trusted X.509 certificate source, it
> also allows the client to rotate its X.509 certificates without the need to
> change its respective authentication data at the authorization server.
> >>>
> >>>    draft-ietf-oauth-mtls-03<https://datatracker.ietf.org/doc/
> html/draft-ietf-oauth-mtls-03> <https://datatracker.ietf.org/
> doc/html/draft-ietf-oauth-mtls-03>
> >>>
> >>>
> >>> There are also htmlized versions available at:https://tools.ietf.org/
> html/draft-ietf-oauth-mtls-03https://datatracker.ietf.
> org/doc/html/draft-ietf-oauth-mtls-03
> >>>

---

From: John Bradley <[email-masked]>
Date: Fri, 4 Aug 2017 16:16:24 -0400

Having the whole certificate to compare may be easier in some environments that trying to directly compare the public keys.

I believe most environments make the cert from TLS available to the app comparing that to the one retrieved from the x5c element is relatively strait forward.

When comparing keys I worry that that may not be that easy to get from the TLS/HTTP stack.  
Some environments will provide SPKI and others like java have methods to directly manipulate the keys.

We should also check on any issues with representation of EC public keys.  
While JWA docent allow compressed points RFC 5480 allows them in SPKI.

Of the top of my head I don’t know if anyone issues certs in that format, but they could.  

If the client receives compressed points from SPKI and uncompressed from JWK it is possible to compare them but I have a bad feeling people will get it wrong.   

There is also a issue with leading zeros that must be present in the JWK but are not in the SPKI.

For the most part comparing the raw keys will work with the three currently supported named curves. 
New curves may also introduce new wrinkles.

If we were only talking RSA I would definitely ditch x5c.

However given that a certificate of some sort must exist to make MTLS work putting it in the x5c is not asking the world.

Getting a app to string compare two blobs seems less likely to go wrong in deployment than asking apps to do atleast format normalization of the public keys to compare them.

I wish it could be simpler.

John B.

> On Aug 4, 2017, at 3:17 PM, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
>>>> where the X.509 certificates are represented using the "x5c" parameter from [RFC7517 <https://datatracker.ietf.org/doc/html/rfc7517 <https://datatracker.ietf.org/doc/html/rfc7517>>]
>>>> 
>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls->
>>>> 03#section-2.1
>>>> 
>>>>   draft-ietf-oauth-mtls-03<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>>
>>>> 
>>>> 
>>>> From: <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
>>>> The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/>
>>>> 
>>>> There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 <https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>
>>>> 
>>>> A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03 <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03>
>>>> 
>>>> 
>>>> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>>>> 
>>>> OAuth mailing [email-masked] <mailto:[email-masked]>://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>>

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Mon, 7 Aug 2017 18:38:57 +0300

A while ago, if I'm not mistaken, I glimpsed some report of
vulnerabilities caused by incorrect public key comparison.

It looks like key comparison merits a section on its own.

How about giving the AS the option to check the signature of the
submitted client cert, which is better supported? (but will be much more
expensive in terms of CPU time than comparison)

If an AS registers an x5c with the JWK, is the AS supposed to validate
the x5c signature using the JWK public parameter? Any other checks?

Thanks,

Vladimir

---

From: John Bradley <[email-masked]>
Date: Mon, 7 Aug 2017 11:53:32 -0400

The AS always gets the client cert from the TLS stack.   Validating the certificate cain is something people get wrong all the time.   However that is what the DN names are for.  Using those requires validating the certs.

If you use the x5c from the JWKS is is a simple compare of the two certs.  In principal the app doesn't need to validate the cert using PKIX.   The security is provided by checking the server cert protecting the JWKS endpoint and is dealt with in TLS one hopes.

John B.

> On Aug 7, 2017, at 11:38 AM, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
>>>>>> where the X.509 certificates are represented using the "x5c" parameter from [RFC7517 <https://datatracker.ietf.org/doc/html/rfc7517 <https://datatracker.ietf.org/doc/html/rfc7517><https://datatracker.ietf.org/doc/html/rfc7517 <https://datatracker.ietf.org/doc/html/rfc7517>>>]
>>>>>> 
>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls- <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls->>
>>>>>> 03#section-2.1
>>>>>> 
>>>>>>  draft-ietf-oauth-mtls-03<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>>> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03> <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>>>
>>>>>> 
>>>>>> 
>>>>>> From: <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>>>>> To: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>>>> Cc: [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/> <https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/>>
>>>>>> 
>>>>>> There are also htmlized versions available at:https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 <https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03><https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03 <https://tools.ietf.org/html/draft-ietf-oauth-mtls-03https://datatracker.ietf.org/doc/html/draft-ietf-oauth-mtls-03>>
>>>>>> 
>>>>>> A diff from the previous version is available at:https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03 <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03> <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03 <https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-mtls-03>>
>>>>>> 
>>>>>> 
>>>>>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/> <http://tools.ietf.org/ <http://tools.ietf.org/>>.
>>>>>> 
>>>>>> Internet-Drafts are also available by anonymous FTP at:ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/> <ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>>
>>>>>> 
>>>>>> OAuth mailing [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>://www.ietf.org/mailman/listinfo/oauth <http://www.ietf.org/mailman/listinfo/oauth>
>>>>>> 
>>>>>> 
>>>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>>
>>>>>> 
>>>>>> 
>>> 
>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth> <https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Aug 2017 16:09:13 +0000

> A while ago, if I'm not mistaken, I glimpsed some report of vulnerabilities
> caused by incorrect public key comparison.

There was a recent issue raised by Hanno about incorrect public/private key matching leading to incorrect revocation of a certificate; was that what you were thinking of?

---

From: Justin Richer <[email-masked]>
Date: Mon, 7 Aug 2017 14:40:23 -0400

Thanks for the explanation, Brian. I think the draft’s current structure helped me to erroneously conflate the two aspects of the document — in that it sounded like mTLS client authentication was required for an mTLS-bound (or really, certificate-bound) token. I see now that this isn’t the case, and the hashing approach makes more sense to me. Having the text separate these more clearly and stating that you don’t need the one to do the other (but it helps) would be a good move. I could see that the document was already trying to separate the two aspects of the spec, but I think it’s not quite there yet.

 — Justin

> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.  If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 8 Aug 2017 22:42:10 +0300

> There was a recent issue raised by Hanno about incorrect public/private key matching leading to incorrect revocation of a certificate; was that what you were thinking of?
Thanks Rich, I was able to find it now. The issue apparently affects
public/private key matching, not public/public key matching, so it
shouldn't be a concern for mTLS:

https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html

Vladimir

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Tue, 8 Aug 2017 23:15:14 +0300

> The AS always gets the client cert from the TLS stack.   Validating the certificate cain is something people get wrong all the time.   However that is what the DN names are for.  Using those requir…
For the self-signed certs (pub_key_tls_client_auth) just the signature
needs to be checked, which, in Java at least, is well supported:

https://docs.oracle.com/javase/8/docs/api/java/security/cert/Certificate.html#verify-java.security.PublicKey-java.security.Provider-

I agree that with PKI certs (tls_client_auth) chain validation can be
tricky.

> If you use the x5c from the JWKS is is a simple compare of the two certs.  In principal the app doesn't need to validate the cert using PKIX.   The security is provided by checking the server cert…
My question was actually about client registration, if the AS should
perform validation of the x5c when the client JWK gets registered (for
pub_key_tls_client_auth). Things that come to mind: 1) that the x5c
length is one; 2) that the x5c matches the JWK public key (though for
cert string matching that doesn't seem to be necessary).

Thanks,

Vladimir