Ballot for draft-ietf-oauth-mtls
Yes
No Objection
Note: This ballot was opened for revision 15 and is now closed.
Thank you for a very readable document -- I'd put off reading this because I'd assumed it was going to be really hard to follow if you are not an expert in this art, but was pleasantly surprised at how approachable it is.
Thank you for the hard work put into this extensive document. I second Suresh's COMMENT about IPv6 address representation. Regards, -éric
Thanks for the work that everyone did on this document. I have one suggestion for clarification, followed by a handful of editorial nits. --------------------------------------------------------------------------- §2.1.2: > 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. This probably needs some text that clarifies expectations around comparison and/or normalization. For example, if the iPAddress value in the cert is "20 01 0d b8 00 00 00 00 00 00 00 00 c0 00 02 ca" (and a mask of all F's), one should presume that this would match both tls_client_auth_san_ip values "2001:db8:0:0:0:0:c000:2ca" and "2001:DB8::192.0.2.202", right? If no, then this document needs to talk about normalization of address representation. --------------------------------------------------------------------------- §1: > Layering on the abstract flow above, this document standardizes > enhanced security options for OAuth 2.0 utilizing client certificate > based mutual TLS. Nit: "client-certificate-based" > OAuth 2.0 defines a shared secret method of client authentication but Nit: "shared-secret" --------------------------------------------------------------------------- §1: > This document describes an additional > mechanism of client authentication utilizing mutual TLS certificate- > based authentication Nit: "mutual-TLS" > Mutual TLS certificate-bound access tokens ensure that only the party Nit: "Mutual-TLS" > Mutual TLS certificate-bound access tokens and mutual TLS client Nit: "Mutual-TLS... mutual-TLS" > Additional client metadata parameters are introduced by this document > in support of certificate-bound access tokens and mutual TLS client > authentication. Nit: "mutual-TLS" The remainder of the document has several other uses of the phrase "mutual TLS" as an adjective; they should be similarly hyphenated. I will not call them out individually. (Non-adjectival uses should not contain hyphens, so this isn't a simple find-and-replace operation.) --------------------------------------------------------------------------- §5: > Authorization servers supporting both clients using mutual TLS and > conventional clients MAY chose to isolate the server side mutual TLS > behaviour to only clients intending to do mutual TLS, thus avoiding Nit: "behavior" (or adjust other spellings in the document to be consistently British).
I did not review this document myself but I'm ballot based on the Gen-ART review.
Thank you for addressing my Discuss (and Comment!) points!
* Section 2.1.2. Suggest using the IPv6 Address Text Representation described in RFC5952 instead of using the representations described in RFC4291 section 2.2. The canonical representation described in RFC5952 makes it easier to compare two IPv6 address strings which is probably something you want to do while doing mutual authentication.