Subject: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-mtls-16: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 19 Aug 2019 15:15:19 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-oauth-mtls-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(1) I think that we need some text that covers how the resource server
will know to use mtls (and thus, to send a CertificateRequest to the
client during the TLS handshake).  The authorization server and client
can indicate their capabilities/preference via the RFC 8414 and RFC 7591
discovery and registration procedures, but I didn't see any discussion
of how an AS might know a RS's capabilities, or how an RS might develop
expectations of the capabilities of the clients accessing it.  A naive
conclusion might be that any given RS (hostname+port) would have to
either always or never use mtls, given the misordering between TLS
handshake completion and delivery of TLS application data (i.e.,
including the oauth token), though there may be refinements available in
the form of the unpopular TLS 1.2 renegotiation or TLS 1.3
post-handshake authentication (or exported authenticators).  Doing
either of those in an environment with TLS Termination per Section 6.5
may entail additional complications.

(We may also want some additional text discussing error handling for the
client/AS interaction, e.g., if a request shows up from a client-id that
should be using mtls but did not provide a certificate in the TLS
handshake, but that is only debatably something that rises to
Discuss-level; or if a client that advertised an intent to use MTLS used
the regular token endpoint and not the mtls endpoint alias (if they
differ).)

(2) I can't validate the examples in Appendix A.

Specifically, my reading of the text would put the "x5t#S256" value as
needing 86 characters, but only 43 are provided.  The ones there also do
not seem to be a prefix of the result that I get from taking the PEM
certificate contents and running them through the pipeline:

base64 -di | sha256sum |awk '{print $1}'|tr -d '\n'|base64

(Noting, of course, that 'base64' will be producing the non-URL-safe
variant, but expecting it to remain "pretty close".)

I also had some trouble comparing the "y" coordinate from the JWK to the
certificate contents, but that may just be user error.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 1

nit: in Figure 1, the (C) label is applied to both an arrow and a box
(the other two boxes are not labelled).

   (C)  The protected resource validates the access token in order to
        authorize the request.  In some cases, such as when the token is
        self-contained and cryptographically secured, the validation can
        be done locally by the protected resource.  While other cases
        require that the protected resource call out to the
        authorization server to determine the state of the token and
        obtain meta-information about it.

nit: "While" is a conjunction but this last sentence only has one
clause.

   Layering on the abstract flow above, this document standardizes
   enhanced security options for OAuth 2.0 utilizing client certificate
   based mutual TLS.  Section 2 provides options for authenticating the

nit: "client-certificate-based" is hyphenated.

   request in step (A).  While step (C) is supported with semantics to
   express the binding of the token to the client certificate for both
   local and remote processing in Section 3.1 and Section 3.2
   respectively.  This ensures that, as described in Section 3,

nit: same thing about "while".

   protected resource access in step (B) is only possible by the
   legitimate client bearing the access token and holding the private
   key corresponding to the certificate.

nit: I guess it is only protected resource access "using this tokwn"
that is only possible as specified.

Section 1.2

We probably want to say something like "in addition to the normal TLS
server authentication with a certificate" -- we need both for it to
properly be "mutual" :)

Section 2.1

   The PKI (public key infrastructure) method of mutual TLS OAuth client
   authentication adheres to the way in which X.509 certificates are
   traditionally used for authentication.  It relies on a validated
   certificate chain [RFC5280] and a single subject distinguished name
   (DN) or a single subject alternative name (SAN) to authenticate the
   client.  Only one subject name value of any type is used for each

I think we might be able to refer to RFC 6125 and call these the "CN-ID"
and "DNS-ID".  That might also let us get out of doing quite as much
referencing to RFC 4514 and specifying string representations "by hand"...

I'm surprised to not see any discussion of trust anchor management or
how to indicate (or decide) which CAs are to be trusted for this
purpose, even if that's just to acknowledge that it must be done but
leave it up to deployments.

Section 2.1.2

Similarly the tls_client_auth_san_uri could be a URI-ID.

   tls_client_auth_san_ip
      A string representation of an IP address in either dotted decimal
      notation (for IPv4) or colon-delimited hexadecimal (for IPv6, as
      defined in [RFC4291] section 2.2) that is expected to be present
      as an iPAddress SAN entry in the certificate, which the OAuth
      client will use in mutual TLS authentication.

Do we want to note that this string representation differs from the
actual iPAddress encoding?  I guess by the time you go to actually
implement it, it's probably pretty obvious, though...

Section 2.2.2

   For the Self-Signed Certificate method of binding a certificate with
   a client using mutual TLS client authentication, the existing
   "jwks_uri" or "jwks" metadata parameters from [RFC7591] are used to
   convey the client's certificates via JSON Web Key (JWK) in a JWK Set
   (JWKS) [RFC7517].  The "jwks" metadata parameter is a JWK Set
   containing the client's public keys as an array of JWKs while the
   "jwks_uri" parameter is a URL that references a client's JWK Set.  A
   certificate is represented with the "x5c" parameter of an individual
   JWK within the set.  Note that the members of the JWK representing

nit: "containing the client's public keys" is a bit of a juxtaposition
with "represented with the "x5c" parameter" (which is certificates).
True, the certificate does contain the public key, so it's not exactly
wrong, but since we focus elsewhere on the certificate, it may not make
sense to focus on the public key here.

Section 3

                 Binding the access token to the client certificate in
   that fashion has the benefit of decoupling that binding from the
   client's authentication with the authorization server, which enables
   mutual TLS during protected resource access to serve purely as a
   proof-of-possession mechanism.  Other methods of associating a

I don't think I understand what's meant about "decoupling that binding
from the client's authentication with the authorization server" -- it
seems like the authorization server shouldn't issue a bound token
without some proof of possession, which the client's authentication
thereto performs.

   The protected resource MUST obtain, from its TLS implementation
   layer, the client certificate used for mutual TLS and MUST verify
   that the certificate matches the certificate associated with the
   access token.  If they do not match, the resource access attempt MUST

How does the resource server know it needs to do this?  Is this just
configured as part of the ability to do mutual TLS, or indiated by a
token type, or something else?

Section 3.1

Per BCP 201, we may want to say something about this recommendation
changing over time as cryptographic algorithm preferences change.  RFC
7525 has a decent note to this effect:

   Community knowledge about the strength of various algorithms and
   feasible attacks can change quickly, and experience shows that a Best
   Current Practice (BCP) document about security is a point-in-time
   statement.  Readers are advised to seek out any errata or updates
   that apply to this document.

(obviously the "BCP" part doesn't apply to this document, but most of
the rest should.)  This could of course be coordinated between here and
Section 7.2.

There's only 43 characters of base64 in the "x5t#S256" example; for
SHA-256 output shouldn't there be 86?

Section 3.2

(Same comment about the length of base64 in the example, in Figure 3.)

Section 3.3

We should probably reference RFC 8414 (at least) the first time we talk
about authorizaiton server metadata parameters.

Section 3.4

Similarly, we could reference RFC 7591 here.

Section 5

                                                                 Note
   that the endpoints in "mtls_endpoint_aliases" use a different host
   than their conventional counterparts, which allows the authorization
   server (via SNI or actual distinct hosts) to differentiate its TLS
   behavior as appropriate.

nit: Sadly, "SNI" does not appear in
https://www.rfc-editor.org/materials/abbrev.expansion.txt as a
"well-known" abbreviation, so we probably have to say 'TLS "server_name"
extension [RFC 6066]' or similar.

Section 6.1

   In order to support the Self-Signed Certificate method, the
   authorization server would configure the TLS stack in such a way that
   it does not verify whether the certificate presented by the client
   during the handshake is signed by a trusted CA certificate.

This statement doesn't quite follow -- *support*ing self-signed
certificates only requires that you configure TLS to not require a valid
client cert+chain for the handshake to succeed, but it can still try to
validate such a chain.  This would be useful if, for example, you
intended to support both self-signed and CA-signed certificates.
We may also want a specific note to implementors to check validation
results for certificates intended to be CA-signed, if we're going to
include a note about disabling validation for self-signed cert usage.

Section 6.2

Would there be any scenario in which "additional security" might be
gained from having the RS check that the client-presented cert does
chain to a trusted CA?

Section 6.3

Isn't this ignoring the elephant in the room about what to do when the
refresh token is also bound to the (expiring) client certificate?

Section 6.5

There are a couple of active proposals for new, secure, protocols from
load balancer to backend server, but probably not anything quite mature
enough to be worth referencing from here.
(e.g., draft-schwartz-tls-lb and another one that I think was presented
in QUIC but I can't find right now)

Section 7

We could potentially also talk about how the use of jwks_uri requires
a fairly strong level of trust in the service at the target of the URI:
the client has to trust it to faithfully provide the certification
information, and the RS has to trust it to provide valid data for the
client in question, as well as the usual trust in the TLS connection
that identifies it, etc.

Section 7.1

   The OAuth 2.0 Authorization Framework [RFC6749] requires that an
   authorization server bind refresh tokens to the client to which they
   were issued and that confidential clients (those having established
   authentication credentials with the authorization server)
   authenticate to the AS when presenting a refresh token.  As a result,
   refresh tokens are indirectly certificate-bound when issued to
   clients utilizing the "tls_client_auth" or
   "self_signed_tls_client_auth" methods of client authentication.

nit(?): is this "indirectly" or "implicitly" bound?

Section 7.2

I'm not sure why we mention both (first) preimage and second-preimage
resistance, as they're pretty different properties.  I suppose there
could be some registration scenarios where only the thumbprint is
provided and thus an attacker with a DB dump would not have the first
preimage in the form of the actual intended certificate, but even if
they could reconstruct that "real" preimage from the thumbprint they
wouldn't have the corresponding private key.  So second-preimage
probably covers what we need, and we can assume that the "first"
preimage (certificate) is always available to the attacker.

Section 7.4

Maybe we should say "agree out of band" on the set of trust anchors.

Section 7.5

   o  handling of null-terminator bytes and non-canonical string
      representations in subject names;

ASN.1 encodings are going to be using counted strings, so any
NUL terminators will be in implementation languages.  I think we might
want to reword this to indicate that ASN.1 strings cannot be directly
interpreted as native language strings in languages that use NUL
terminators.

   o  handling of wildcard patterns in subject names;

Interestingly, RFC 5280 punts on the semantics of wildcard characters in
SANs, though I think many applications will insist on only a single
wildcard and the leftmost label being just the single wildcard
character.

Section 8

There's perhaps some additional considerations if a client uses the same
certificate across multiple RSes, in that the client certificate
provides an additional mechanism for collaborating RSes to correlate a
single client, in ways that just the access token would not.  This is
not a terribly common threat model in a highly centralized deployment
where all RSes are fairly well trusted, of course, but there can be some
environments where it is relevant, so it probably merits discussion.

Section 9.2

   This specification requests registration of the following value in

nit: "values" plural

Section 10.2

I think that RFC 7517 needs to be normative, since we use the jwks
containers for conveying certificate information.

It also seems like RFCs 7591 and 8414 should probably be normative.

Traditionally we keep RFC 8174 as normative, as part of BCP 14 along
with RFC 2119.

---

From: Brian Campbell <[email-masked]>
Date: Wed, 21 Aug 2019 15:21:23 -0600

Thanks Ben, I attempt (over the course of many hours) to respond to your
comments and discuss your discuss inline below.

> draft-ietf-oauth-mtls-16: Discuss

Is there some text that you can propose?

Whether or not to ask for or require MTLS and how to determine when is
going to be a deployment decision of the RS. I don't think what you
describe as the naive conclusion is all that naive at all. But maybe that
just makes me naive:) In implementations/deployments that I've seen thus
far, a particular RS decides (or is dictated by some policy) that its stuff
is high value enough that it needs cert-bound access tokens so it always
sends a CertificateRequest to the client during the TLS handshake. Such an
RS that also wants to allow access via non cert-bound access tokens might
just let the TLS connection proceed even if the client doesn't offer a
certificate or it might offer its stuff on a different host and/or port
that is just regular TLS. I don't want to preclude the use of renegotiation
or post-handshake authentication but (other than some past pain with
renegotiation) I'm not really qualified to discuss or make recommendations
about using them.

Note also there is not something like RFC 8414 and RFC 7591 for RSs and
(for good reasons I think) the WG has balked at working on something like
that. So the requirements/capabilities/preferences of an RS will need to be
communicated or configured out-of-band. And that's the case in general for
RSs independent of this document.

> the regular token endpoint and not the mtls endpoint alias (if they

The end of sec 2
https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-2
 says what to do in the case of a certificate mismatch in client auth:
   "If the presented certificate doesn't match that
   which is expected for the given "client_id", the authorization server
   returns a normal OAuth 2.0 error response per Section 5.2 of RFC6749
   [RFC6749] with the "invalid_client" error code to indicate failed
   client authentication."

And my intent and assumption was that a mismatch covered the case where no
certificate was presented (i.e. null cert doesn't match expected cert just
as different cert doesn't match). But perhaps that particular case should
be made more explicit?  The second to last paragraph of sec 3
https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 has similar
guidance for error handing in the case of mismatch during resource access.

The case of a so called public client that has
tls_client_certificate_bound_access_tokens metadata of true that shows up
at the token endpoint without having done MTLS is a bit more nuanced and I
think it's untimely a policy decision for the AS at that point as to
whether to error or issue an unbound token.

> variant, but expecting it to remain "pretty close".)

Here's a quick back of the napkin calculation that gives 43 characters: SHA
256 produces a 256 bit output, which is 32 bytes. Base64url encoding 32
bytes gives 43 bytes/characters of output (the ratio of output bytes to
input bytes is 4:3 with base64 encoding).

I am not *nix skilled enough to troubleshoot that command pipeline but I
suspect that the sha256sum output is in hex which represents each byte of
the hash output with two charterers and thus double the resultant size.

I don't believe this particular example has been validated by other folks
but it was produced using code that has produced consistent results with
other implementers. Also it's code from an existing JOSE/JWT library (
https://bitbucket.org/b_c/jose4j/wiki/Home) that's using long existing
support for the x5t / x5t#S256 parameters in JWS and JWK.

That was intentional and meant to show that access token validation can
happen locally (in the box) or by introspection call-out to the AS (the
arrow). Maybe this could be done a bit differently, with I dunno sub items
of C1 and C2 or something, that would be more clear?

> nit: "While" is a conjunction but this last sentence only has one

Will remove.

> nit: "client-certificate-based" is hyphenated.

ok

> nit: same thing about "while".

ok

> that is only possible as specified.

I kinda felt like that was implied at this point. But I can add "using this
token" there, if you think it's needed or helpful?

> server authentication with a certificate" -- we need both for it to

ok

> referencing to RFC 4514 and specifying string representations "by hand"...

 RFC 6125 "Representation and Verification of Domain-Based Application
Service
 Identity within Internet Public Key Infrastructure Using X.509 (PKIX)
     Certificates in the Context of Transport Layer Security (TLS)" came up
at one point but given that certificate usage in this draft aren't about
Domain-Based Application Services I was unable to see the applicable or how
using it might help.

> leave it up to deployments.

It's gotta be done (unless using the self-singed method) and it is
definitely up to deployments as I wouldn't even pretend to know where to
begin on providing general guidance nor would I think it appropriate.

I felt like this was pretty well implied and touched on in security
considerations too. But please suggest some specific text, if you think
it's needed or would be useful.

> Similarly the tls_client_auth_san_uri could be a URI-ID.

Similar to the above I'm really not seeing how or why this would be done or
useful.

> implement it, it's probably pretty obvious, though...

I don't know, to be honest. The text in question came as a suggestion from
someone on the WG list and it seemed good enough to me.  I sort of thought
it would probably be pretty obvious too. However the other IESG ballot
positions have also had similar(ish) comments (see
https://mailarchive.ietf.org/arch/msg/oauth/PbpygP8an-e80dDolo97Q5cBdd4 and
https://mailarchive.ietf.org/arch/msg/oauth/IsoOa0jvabolUSzjzWHjk8b0aVY) so
it seems something more or different is needed with respect to this
tls_client_auth_san_ip thing. The suggestion from Suresh around RFC 5952
seems promising but I need to look further into it than just reading the
title. Which I'll do. But also trying to be somewhat timely in responding
to these reviews.

I've also never been able to think of a case where tls_client_auth_san_ip
is actually needed so maybe removing it all together is an option as well.

> sense to focus on the public key here.

That juxtaposition arises out of the way JWK is primarily about bare public
keys and certificates are an optional additional JSON member.

> without some proof of possession, which the client's authentication

What it is trying to say is that the AS does what the AS does in terms of
client auth including dealing with trust anchors and what type of subject
name or allowing for self singed auth matching against explicitly
configured certs. But, because the token is bound to the hash of the cert,
the RS need not concern itself with any of that and can treat the client
TLS certificate as only a proof-of-possession mechanism for using the
access token. Does that help your understanding or just confuse things
further?

> token type, or something else?

Configured and/or based on the presence of the cnf claim with x5t#S256
method in the access token.

> the rest should.)  This could of course be coordinated between here and

Makes sense. I'll incorporate some text borrowed from 7525 in 3.1 and/or
7.2.

> SHA-256 output shouldn't there be 86?

see previous explanation of why 43 seems right based on my math and code

> (Same comment about the length of base64 in the example, in Figure 3.)

same same

> about authorizaiton server metadata parameters.

Yeah, that's an oversight on my part. Will fix.

> Similarly, we could reference RFC 7591 here.

RFC 7591 has been referenced several times already at this point.

> extension [RFC 6066]' or similar.

Shoot, okay. Will do.

> include a note about disabling validation for self-signed cert usage.

I take your point but the text (which I did not write FWIW) was meant to be
practical guidance based on an understanding of how the most common web
servers work (problem in chain validation terminates the handshake) and the
options they provide (can turn off cert chain validating) and what they
surface about the handshake results (AFAIK not the kind of info that would
allow the distinction you mention so the whole process of chain validation
would maybe have to be deferred to the application layer). I can try and
add or amend some text along the lines of your comment. But I worry I'd do
more harm than good in doing so.

> gained from having the RS check that the client-presented cert does

I'm sure there is some such scenario out there. But this is meant as
implementation considerations or guidance for the general or common cases.

> refresh token is also bound to the (expiring) client certificate?

The only time a refresh token is bound directly to the client certificate
is for public clients (
https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-4 and
https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-7.1) and
public clients can only use self signed certificates for which the
expiration isn't all that meaningful and can be made to be far enough in
the future.

> client in question, as well as the usual trust in the TLS connection

I understand what you are saying but don't know what I would actually write
and kinda think that anything along those lines should have been in RFC
7591 anyway because it's applicable there and not just in the context of
this narrow document.

> nit(?): is this "indirectly" or "implicitly" bound?

I guess it's both? But "indirectly" seemed right to me. The word "implicit"
also has some meaning and connotations in the general word of OAuth, which
are unrelated but I was trying to avoid it just the same.

> Maybe we should say "agree out of band" on the set of trust anchors.

okay

> interpreted as native language strings in languages that use NUL

I am not equipped with the knowledge to do that rewording. Please suggest
some specific text, if you'd like to have it reworded.

> wildcard and the leftmost label being just the single wildcard

Also there is no allowance anywhere in this draft for using wildcards in
subject names for the client certificate. This whole section came as a
suggestion doing WGLC that was taken to get through WGLC. But it's not
entirely contextually relevant. This bullet in particular. Maybe it'd be
better to remove it?

> environments where it is relevant, so it probably merits discussion.

I have balked at adding any such discussion and will continue to do so
because there is likely so much correlateble info in an access token
already that the client has no control over and might well not even know
about. I don't know how to write what you're suggesting in a meaningful way
and without giving the impression that using a different certificate
provides privacy benefits that are not really there.

>    This specification requests registration of the following value in

Will fix and also found and will fix the same thing in 9.3

> containers for conveying certificate information.

okay

> It also seems like RFCs 7591 and 8414 should probably be normative.

I was on the fence with these two as i didn't think they are strictly
necessary but am happy to move them to normative. 7519 and 7662 probably
too.

> Traditionally we keep RFC 8174 as normative, as part of BCP 14 along

I think I knew that but somehow got it wrong here. Will fix.

-- 
_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: Brian Campbell <[email-masked]>
Date: Wed, 21 Aug 2019 21:18:35 -0600

I missed responding to this one part below about sec 7.2 and yet somehow
remembered that I'd missed it. Anyway, I feel like I had some seemingly
legitimate reason for mentioning (first) preimage when I wrote that text
but I cannot recall what that was and, on reading the text again with the
benefit of your comment, I think you are right. Second-preimage resistance
is what we care about in this context. I'll drop mention of regular
preimage.

> preimage (certificate) is always available to the attacker.

On Wed, Aug 21, 2019 at 3:21 PM Brian Campbell <[email-masked]>
wrote:

> https://tools.ietf.org/html/draft-ietf-oauth-mtls-16#section-3 has
> similar guidance for error handing in the case of mismatch during resource
> access.
>
> Here's a quick back of the napkin calculation that gives 43 characters:
> SHA 256 produces a 256 bit output, which is 32 bytes. Base64url encoding 32
> I kinda felt like that was implied at this point. But I can add "using
> this token" there, if you think it's needed or helpful?
>
>
>>
>> Section 1.2
>>
>      Certificates in the Context of Transport Layer Security (TLS)" came
> up at one point but given that certificate usage in this draft aren't about
> Similar to the above I'm really not seeing how or why this would be done
> or useful.
>
>
>
>>
>>    tls_client_auth_san_ip
> https://mailarchive.ietf.org/arch/msg/oauth/IsoOa0jvabolUSzjzWHjk8b0aVY)
> so it seems something more or different is needed with respect to this
> That juxtaposition arises out of the way JWK is primarily about bare
> public keys and certificates are an optional additional JSON member.
>
>
>>
>> Section 3
>>
> I take your point but the text (which I did not write FWIW) was meant to
> be practical guidance based on an understanding of how the most common web
> I understand what you are saying but don't know what I would actually
> write and kinda think that anything along those lines should have been in
> RFC 7591 anyway because it's applicable there and not just in the context
> of this narrow document.
>
>
>>
>> Section 7.1
>>
> I guess it's both? But "indirectly" seemed right to me. The word
> "implicit" also has some meaning and connotations in the general word of
> OAuth, which are unrelated but I was trying to avoid it just the same.
>
>
>>
>> Section 7.2
>>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 22 Aug 2019 18:16:55 -0500

> describe as the naive conclusion is all that naive at all. But maybe that

Well, I think it was naive when I wrote it, because I didn't think very
hard.  But it's possible to be naive and be correct at the same time...

> RSs independent of this document.

Sure, and I don't really see that changing anytime soon.

In terms of proposed text, it looks like after the first paragraph of
Section 3 would be a reasonable place, perhaps:

In order for a resource server to use certificate-bound access tokens, it
must have advance knowledge that mtls is to be used for some or all
resource accesses.  In particular, the client ID or access token itself
cannot be used as input to the decision of whether or not to use mtls,
since from the TLS perspective those are "Application Data", only exchanged
after the TLS handshake has been completed, and the initial
CertificateRequest occurs during the handshake, before the Application Data
is available.  Although subsequent opportunities for a TLS client to
present a certificate may be available, e.g., via TLS 1.2 renegotiation
[RFC5246] or TLS 1.3 post-handshake authentication [RFC8446], this document
makes no provision for their usage.  It is expected to be common that a
mtls-using resource server will require mtls for all resources hosted
thereupon, or will serve mtls-protected and regular resources on separate
hostname+port combinations, though other workflows are possible.  How
resource server policy is synchronized with the AS is out of scope for this
document.

And then the following paragraph could start "Within the scope of an
mtls-protected resource-access flow,"

> be made more explicit?  The second to last paragraph of sec 3

It probably should; "if the presented certificate" as a predicate could
fairly be easily read as to ignore the case where no certificate is
presented.

> whether to error or issue an unbound token.

Do you have any feelings about whether or not you want to mention that case
explicitly as being up to local policy at the AS (vs. leaving it implicit
as is presently being done)?

> the hash output with two charterers and thus double the resultant size.

Please excuse me while I wipe the egg off my face.
Yes, that sha256sum output is in hex, and I should have counted the bits
directly.  I hope you did not waste too much time on this (and now I can
get the thumbprint to agree).

> support for the x5t / x5t#S256 parameters in JWS and JWK.

Thanks for the heads-up about how the example was generated; it's
reassuring.

> of C1 and C2 or something, that would be more clear?

Hmm.  With the explanation, it makes sense.  It's possible that C1/C2 might
be more clear, though, but don't  feel obligated to do that.

> token" there, if you think it's needed or helpful?

Or perhaps "using a certificate-bound token".  I think it's just barely
worth adding, since this section is largely reiterating the general OAuth
flow, and this helps emphasize that the "and holding the private key" is
the important/new part.

> Domain-Based Application Services I was unable to see the applicable or how

Okay, if it was already considered and rejected I don't want to rehash old
ground.

> it's needed or would be useful.

Maybe a couple lines at the end of Section 7.3, "TLS certificate validation
(for both client and server certificates) requires a local database of
trusted certificate authorities (CAs).  Decisions about what CAs to trust
and how to make such a determination of trust are out of scope for this
document, but such policy must be consistent between AS and RS for reliable
operation."?

> is actually needed so maybe removing it all together is an option as well.

That all sounds reasonable to me; I'm happy to leave this topic to the
other ballot threads (or remove the option entirely).

> access token. Does that help your understanding or just confuse things

I think it helps my understanding, thanks.
Perhaps it is the RS's verification of proof-of-possession that is
decoupled from the client's authentication to the AS, then?

> method in the access token.

Okay.
(I think this may have been the part of my notes that was a precursor to
the Discuss point; sorry if it was underdeveloped or unclear.)

> RFC 7591 has been referenced several times already at this point.

Okay.

> > extension [RFC 6066]' or similar.

Thanks.  Though I do wonder whether "we" should ask to have it added ... I
wonder how well-known it is outside the security area.

> more harm than good in doing so.

I sympathize with your concern; please don't feel obligated to take any
action here on this non-blocking comment.

> implementation considerations or guidance for the general or common cases.

Okay; we definitely don't have to cover such things in this document.

> expiration isn't all that meaningful and can be made to be far enough in

Oh, I think I was misunderstanding what the "indirectly certificate-bound"
meant in 7.1.  Okay, this seems less worrisome now.

> 7591 anyway because it's applicable there and not just in the context of

I guess in some sense this is already done in RFC 3986 (Section 7.1), too,
which 7591 unfortunately does not cite directly.

> are unrelated but I was trying to avoid it just the same.

Per your clarification above, I think I misunderstood the meaning here.
My new suggestion would be "indirectly certificate-bound by way of the
clientID and the associated requirement for (certificate-based)
authentication to the AS", if that's not too unwieldly.

> some specific text, if you'd like to have it reworded.

How about:

o handling of embedded NUL bytes in ASN.1 counted-length strings, and
non-canonical or non-normalized string representations in subject names

> entirely contextually relevant. This bullet in particular. Maybe it'd be

I'd leave it in.  I don't think I had any specific change in mind here, and
was just making an observation.

> provides privacy benefits that are not really there.

Okay.  You're much closer to what access tokens look like in practice than
I am, and this is a fairly theoretical scenario anyway.

> I think I knew that but somehow got it wrong here. Will fix.

Thanks for all the updates!

-Ben

---

From: Brian Campbell <[email-masked]>
Date: Fri, 23 Aug 2019 15:07:43 -0600

Thanks for the responses Ben. More inline below with stuff that warrants no
further discussion snipped out.

On Thu, Aug 22, 2019 at 5:17 PM Benjamin Kaduk <[email-masked]> wrote:

>
>   But it's possible to be naive and be correct at the same time...
>

I rather like that and suspect I might have to use it in the future :)

> mtls-protected resource-access flow,"

Thank you for that. Super helpful. I'll incorporate.

> fairly be easily read as to ignore the case where no certificate is

Fair enough. Maybe, "If no certificate is presented or that which is
presented doesn't match" would suffice to avoid that reading?

> as is presently being done)?

I don't really *want* to add anything but it's probably better to be
explicit about it. I'll look for a place to work it in.

> get the thumbprint to agree).

No worries. I only spent enough time second guessing everything so as to
try and avoid getting egg on my own face.

> this

Works for me.

> document, but such policy must be consistent between AS and RS for reliable

The very last part isn't exactly true as this document recommends or at
least discusses the possibility that an RS run in a "trust em all" mode wrt
client certs and use the client cert only for private-key PoP of the bound
access tokens. As such, I'm inclined to take your text but end it with
"scope for this document."

> other ballot threads (or remove the option entirely).

I think the other thread(s) got it to an actionable way forward
https://mailarchive.ietf.org/arch/msg/oauth/KUb3G-Rr_7KsAWVCNsvwS9AgFSI

> decoupled from the client's authentication to the AS, then?

Yeah, I think so. I guess I sometimes conflate the binding in the token and
the verification of the binding by the RS. I'll work on the wording a bit.

> authentication to the AS", if that's not too unwieldly.

It's possible to be unwieldy and be correct at the same time:) I'm inclined
to use it.

> non-canonical or non-normalized string representations in subject names

Sure.

> Thanks for all the updates!

Likewise, thanks for the review. Yours can be long and painful at times but
are quite useful.

---

From: Brian Campbell <[email-masked]>
Date: Fri, 23 Aug 2019 16:32:35 -0600

I went ahead and pushed a -17, which I think addresses everything discussed
in this thread.

https://tools.ietf.org/html/draft-ietf-oauth-mtls-17

Thanks again for the review and suggestions.

On Fri, Aug 23, 2019 at 3:07 PM Brian Campbell <[email-masked]>
wrote:

> Thanks for the responses Ben. More inline below with stuff that warrants
> no further discussion snipped out.
>
>> similar
> Yeah, I think so. I guess I sometimes conflate the binding in the token
> and the verification of the binding by the RS. I'll work on the wording a
> bit.
>
>
> It's possible to be unwieldy and be correct at the same time:) I'm
> inclined to use it.
>
>
>>
>> > > Section 7.5
>> > >
> Likewise, thanks for the review. Yours can be long and painful at times
> but are quite useful.
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 23 Aug 2019 17:34:07 -0500

> presented doesn't match" would suffice to avoid that reading?

I think so :)

> explicit about it. I'll look for a place to work it in.

Okay, thanks.

> "scope for this document."

Good point; works for me.

> It's possible to be unwieldy and be correct at the same time:) I'm inclined

:)

> Likewise, thanks for the review. Yours can be long and painful at times but

Let me know when that stops being the case!  I mean, just the last
part ;)

-Ben