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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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.