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

[Brian Campbell <[e-mail]>]

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

On Mon, Aug 19, 2019 at 4:15 PM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-oauth-mtls-16: Discuss
>
> ----------------------------------------------------------------------
> 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.
>

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.

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

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.



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

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.



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

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?



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

Will remove.


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

ok


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

ok


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

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
>
> 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" :)
>

ok


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

 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.



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

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.



> Section 2.1.2
>
> 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.



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

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.



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

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


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

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?


>
>    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?
>

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



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

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


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

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


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

same same


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

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


>
> Section 3.4
>
> Similarly, we could reference RFC 7591 here.
>

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



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

Shoot, okay. Will do.


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

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.



> 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?
>

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.


>
> 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?
>

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.


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

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
>
>    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?
>

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

okay


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

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


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

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?


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

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.


>
> Section 9.2
>
>    This specification requests registration of the following value in
>
> nit: "values" plural
>

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


>
> Section 10.2
>
> I think that RFC 7517 needs to be normative, since we use the jwks
> 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
> with RFC 2119.
>

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