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. _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth