OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
draft-ietf-oauth-mtls-17
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-02-28
|
17 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-01-28
|
17 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-01-27
|
17 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-11-04
|
17 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-09-16
|
17 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2019-09-16
|
17 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2019-09-16
|
17 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2019-09-13
|
17 | (System) | IANA Action state changed to Waiting on Authors |
2019-09-11
|
17 | (System) | RFC Editor state changed to EDIT |
2019-09-11
|
17 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-09-11
|
17 | (System) | Announcement was received by RFC Editor |
2019-09-11
|
17 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-09-11
|
17 | Amy Vezza | IESG has approved the document |
2019-09-11
|
17 | Amy Vezza | Closed "Approve" ballot |
2019-09-11
|
17 | Amy Vezza | Ballot approval text was generated |
2019-09-11
|
17 | Roman Danyliw | IESG state changed to Approved-announcement to be sent from IESG Evaluation |
2019-09-11
|
17 | Roman Danyliw | IESG state changed to IESG Evaluation from IESG Evaluation::AD Followup |
2019-08-26
|
17 | Gunter Van de Velde | Assignment of request for Last Call review by OPSDIR to Susan Hares was marked no-response |
2019-08-23
|
17 | Benjamin Kaduk | [Ballot comment] Thank you for addressing my Discuss (and Comment!) points! |
2019-08-23
|
17 | Benjamin Kaduk | [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss |
2019-08-23
|
17 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-08-23
|
17 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2019-08-23
|
17 | Brian Campbell | New version available: draft-ietf-oauth-mtls-17.txt |
2019-08-23
|
17 | (System) | New version approved |
2019-08-23
|
17 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2019-08-23
|
17 | Brian Campbell | Uploaded new revision |
2019-08-22
|
16 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-08-22
|
16 | Éric Vyncke | [Ballot comment] Thank you for the hard work put into this extensive document. I second Suresh's COMMENT about IPv6 address representation. Regards, -éric |
2019-08-22
|
16 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-08-22
|
16 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-08-21
|
16 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-08-21
|
16 | Warren Kumari | [Ballot comment] Thank you for a very readable document -- I'd put off reading this because I'd assumed it was going to be really hard … [Ballot comment] 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. |
2019-08-21
|
16 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-08-21
|
16 | Alissa Cooper | [Ballot comment] I did not review this document myself but I'm ballot based on the Gen-ART review. |
2019-08-21
|
16 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-08-21
|
16 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2019-08-20
|
16 | (System) | IANA Review state changed to IANA - Not OK from Version Changed - Review Needed |
2019-08-20
|
16 | Suresh Krishnan | [Ballot comment] * 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. … [Ballot comment] * 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. |
2019-08-20
|
16 | Suresh Krishnan | Ballot comment text updated for Suresh Krishnan |
2019-08-20
|
16 | Suresh Krishnan | [Ballot comment] * Section 2.1.2. Suggest using the IPv6 Address Text Representation described in RFC5952 instead of using the representations described in [RFC4291] … [Ballot comment] * 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. |
2019-08-20
|
16 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-08-19
|
16 | Adam Roach | [Ballot comment] Thanks for the work that everyone did on this document. I have one suggestion for clarification, followed by a handful of editorial nits. … [Ballot comment] 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). |
2019-08-19
|
16 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-08-19
|
16 | Benjamin Kaduk | [Ballot discuss] (1) I think that we need some text that covers how the resource server will know to use mtls (and thus, to send … [Ballot 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. |
2019-08-19
|
16 | Benjamin Kaduk | [Ballot comment] Section 1 nit: in Figure 1, the (C) label is applied to both an arrow and a box (the other two boxes are … [Ballot 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. |
2019-08-19
|
16 | Benjamin Kaduk | [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk |
2019-08-19
|
16 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-08-19
|
16 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-08-19
|
16 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-08-19
|
16 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-08-13
|
16 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2019-08-13
|
16 | Brian Campbell | New version available: draft-ietf-oauth-mtls-16.txt |
2019-08-13
|
16 | (System) | New version approved |
2019-08-13
|
16 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2019-08-13
|
16 | Brian Campbell | Uploaded new revision |
2019-08-12
|
15 | Roman Danyliw | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-08-12
|
15 | Cindy Morgan | Placed on agenda for telechat - 2019-08-22 |
2019-08-12
|
15 | Roman Danyliw | Ballot has been issued |
2019-08-12
|
15 | Roman Danyliw | [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw |
2019-08-12
|
15 | Roman Danyliw | Created "Approve" ballot |
2019-08-12
|
15 | Roman Danyliw | Ballot writeup was changed |
2019-08-12
|
15 | Roman Danyliw | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The request is for a Proposed Standard type for the draft-ietf-oauth-mtls-10 document since the document defines new mechanisms to enhance the security of the OAuth protocol that has normative extensions to the interaction between the OAuth Client and OAuth Authorization Server. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes OAuth client authentication and certificate bound access tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization sever using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. Working Group Summary: This work was motivated by a request from OpenBanking UK to allow the OAuth Client and OAuth Authorization Server establish a mutually authenticated channel. Document Quality: A number of people reviewed the document over several rounds of reviews and provided feedback during meetings and on the mailing list, with no blocking comments. Implementations: Ping Identity has implemented one of the two methods, PKI-based method. Ping Identity also supports the certificate bound access token. Authlete has an implementation of this document. https://www.authlete.com/ ConnectId has an implementation. https://connect2id.com/blog/connect2id-server-6.13 oidc-provider: https://github.com/panva/node-oidc-provider References: OpenBanking UK reference this document https://openbanking.atlassian.net/wiki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2 OpenID WG reference https://bitbucket.org/openid/mobile/src/default/draft-mobile-client-initiated-backchannel-authentication.xml?fileviewer=file-view-default OpenID Foundation FAPI WG ref to MTLS https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md?fileviewer=file-view-default Berlin Group‘s Nextgen PSD2 Spec: https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf Personnel: The document shepherd is Rifaat Shekh-Yusef. The responsible Area Director is Roman Danyliw. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed this document and feels the document is ready. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document shepherd has no concerns with the level of reviews, as the document was discussed and reviewed by many participants. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Security review is always appreciated. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The document shepherd has no such concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. Brian: https://www.ietf.org/mail-archive/web/oauth/current/msg18200.html John: https://www.ietf.org/mail-archive/web/oauth/current/msg18264.html Nat: https://www.ietf.org/mail-archive/web/oauth/current/msg18199.html Torsten: https://www.ietf.org/mail-archive/web/oauth/current/msg18201.html (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No such IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There was a solid WG consensus that included feedback and support from multiple parties and individuals. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No such threat or discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Id nits returns that the RFC5246 is obsoleted by RFC 8446. However, including references to RFC5246 and RFC8446 is intentional. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such reviews are necessary. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document registers new values with existing registries. The document does not introduce any new registry. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document contains JSON-based examples, and these were validated using JSONLint. |
2019-08-12
|
15 | Roman Danyliw | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The request is for a Proposed Standard type for the draft-ietf-oauth-mtls-10 document since the document defines new mechanisms to enhance the security of the OAuth protocol that has normative extensions to the interaction between the OAuth Client and OAuth Authorization Server. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes OAuth client authentication and certificate bound access tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization sever using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. Working Group Summary: This work was motivated by a request from OpenBanking UK to allow the OAuth Client and OAuth Authorization Server establish a mutually authenticated channel. Document Quality: A number of people reviewed the document over several rounds of reviews and provided feedback during meetings and on the mailing list, with no blocking comments. Implementations: Ping Identity has implemented one of the two methods, PKI-based method. Ping Identity also supports the certificate bound access token. Authlete has an implementation of this document. https://www.authlete.com/ ConnectId has an implementation. https://connect2id.com/blog/connect2id-server-6.13 oidc-provider: https://github.com/panva/node-oidc-provider References: OpenBanking UK reference this document https://openbanking.atlassian.net/wiki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2 OpenID WG reference https://bitbucket.org/openid/mobile/src/default/draft-mobile-client-initiated-backchannel-authentication.xml?fileviewer=file-view-default OpenID Foundation FAPI WG ref to MTLS https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md?fileviewer=file-view-default Berlin Group‘s Nextgen PSD2 Spec: https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf Personnel: The document shepherd is Rifaat Shekh-Yusef. The responsible Area Director is Eric Rescorla. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed this document and feels the document is ready. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document shepherd has no concerns with the level of reviews, as the document was discussed and reviewed by many participants. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Security review is always appreciated. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The document shepherd has no such concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. Brian: https://www.ietf.org/mail-archive/web/oauth/current/msg18200.html John: https://www.ietf.org/mail-archive/web/oauth/current/msg18264.html Nat: https://www.ietf.org/mail-archive/web/oauth/current/msg18199.html Torsten: https://www.ietf.org/mail-archive/web/oauth/current/msg18201.html (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No such IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There was a solid WG consensus that included feedback and support from multiple parties and individuals. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No such threat or discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Id nits returns that the RFC5246 is obsoleted by RFC 8446. However, including references to RFC5246 and RFC8446 is intentional. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such reviews are necessary. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document registers new values with existing registries. The document does not introduce any new registry. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document contains JSON-based examples, and these were validated using JSONLint. |
2019-08-08
|
15 | Jean Mahoney | Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour. |
2019-08-01
|
15 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2019-08-01
|
15 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-oauth-mtls-15. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-oauth-mtls-15. If any part of this review is inaccurate, please let us know. The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete. First, in the JWT Confirmation Methods registry on the JSON Web Token (JWT) registry page located at: https://www.iana.org/assignments/jwt/ a single, new registration will be made as follows: Confirmation Method Value: x5t#S256 Confirmation Method Description: X.509 Certificate SHA-256 Thumbprint Change Controller: IESG Reference: [ RFC-to-be; Section 3.1 ] As this document requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the JWT Confirmation Methods have asked that you send a review request to the mailing list jwt-reg-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC. Second, in the OAuth Authorization Server Metadata registry on the OAuth Parameters registry page located at: https://www.iana.org/assignments/oauth-parameters/ two, new registrations are to be made as follows: Metadata Name: tls_client_certificate_bound_access_tokens Metadata Description: Indicates authorization server support for mutual TLS client certificate-bound access tokens. Change Controller: IESG Reference: [ RFC-to-be; Section 3.3 ] Metadata Name: mtls_endpoint_aliases Metadata Description: JSON object containing alternative authorization server endpoints, which a client intending to do mutual TLS will use in preference to the conventional endpoints. Change Controller: IESG Reference: [ RFC-to-be; Section 5 ] As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated experts for the OAuth Authorization Server Metadata have asked that you send a review request to the mailing list oauth-ext-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC. Third, in the OAuth Token Endpoint Authentication Methods registry also on the OAuth Parameters registry page located at: https://www.iana.org/assignments/oauth-parameters/ two, new registrations are to be made as follows: Token Endpoint Authentication Method Name: tls_client_auth Change Controller: IESG Reference: [ RFC-to-be; Section 2.2.1 ] Token Endpoint Authentication Method Name: self_signed_tls_client_auth Change Controller: IESG Reference: [ RFC-to-be; Section 2.2.1 ] As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated expert for the OAuth Authorization Server Metadata has asked that you send a review request to the mailing list oauth-ext-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC. Fourth, in the OAuth Token Introspection Respons registry also on the OAuth Parameters registry page located at: https://www.iana.org/assignments/oauth-parameters/ a single, new registration is to be made as follows: Name: cnf Description: Confirmation Change Controller: IESG Reference: [RFC7800][ RFC-to-be ] As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated expert for the OAuth Authorization Server Metadata has asked that you send a review request to the mailing list oauth-ext-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC. Fifth, in the OAuth Dynamic Client Registration Metadata registry also on the OAuth Parameters registry page located at: https://www.iana.org/assignments/oauth-parameters/ six, new registrations are to be made as follows: Client Metadata Name: tls_client_certificate_bound_access_tokens Client Metadata Description: Indicates the client's intention to use mutual TLS client certificate-bound access tokens. Change Controller: IESG Reference: [ RFC-to-be; Section 3.4 ] Client Metadata Name: tls_client_auth_subject_dn Client Metadata Description: String value specifying the expected subject DN of the client certificate. Change Controller: IESG Reference: [ RFC-to-be; Section 2.1.2 ] Client Metadata Name: tls_client_auth_san_dns Client Metadata Description: String value specifying the expected dNSName SAN entry in the client certificate. Change Controller: IESG Reference: [ RFC-to-be; Section 2.1.2 ] Client Metadata Name: tls_client_auth_san_uri Client Metadata Description: String value specifying the expected uniformResourceIdentifier SAN entry in the client certificate. Change Controller: IESG Reference: [ RFC-to-be; Section 2.1.2 ] Client Metadata Name: tls_client_auth_san_ip Client Metadata Description: String value specifying the expected iPAddress SAN entry in the client certificate. Change Controller: IESG Reference: [ RFC-to-be; Section 2.1.2 ] Client Metadata Name: tls_client_auth_san_email Client Metadata Description: String value specifying the expected rfc822Name SAN entry in the client certificate. Change Controller: IESG Reference: [ RFC-to-be; Section 2.1.2 ] As this also requests registrations in a Specification Required (see RFC 8126) registry, the IESG-designated expert for the OAuth Authorization Server Metadata has asked that you send a review request to the mailing list oauth-ext-review@ietf.org. Expert review will need to be completed before your document can be approved for publication as an RFC. The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2019-08-01
|
15 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-07-25
|
15 | Vincent Roca | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Vincent Roca. Sent review to list. |
2019-07-18
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2019-07-18
|
15 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2019-07-15
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Vincent Roca |
2019-07-15
|
15 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Vincent Roca |
2019-07-15
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2019-07-15
|
15 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2019-07-11
|
15 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2019-07-11
|
15 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-08-01): From: The IESG To: IETF-Announce CC: rdd@cert.org, draft-ietf-oauth-mtls@ietf.org, Rifaat Shekh-Yusef , rifaat.ietf@gmail.com, … The following Last Call announcement was sent out (ends 2019-08-01): From: The IESG To: IETF-Announce CC: rdd@cert.org, draft-ietf-oauth-mtls@ietf.org, Rifaat Shekh-Yusef , rifaat.ietf@gmail.com, oauth@ietf.org, oauth-chairs@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: (OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens) to Proposed Standard The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'OAuth 2.0 Mutual TLS Client Authentication and Certificate-Bound Access Tokens' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-08-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes OAuth client authentication and certificate- bound access and refresh tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization server using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-mtls/ballot/ No IPR declarations have been submitted directly on this I-D. |
2019-07-11
|
15 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2019-07-11
|
15 | Cindy Morgan | Last call announcement was changed |
2019-07-11
|
15 | Roman Danyliw | Last call was requested |
2019-07-11
|
15 | Roman Danyliw | Last call announcement was generated |
2019-07-11
|
15 | Roman Danyliw | Ballot approval text was generated |
2019-07-11
|
15 | Roman Danyliw | Ballot writeup was generated |
2019-07-11
|
15 | Roman Danyliw | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-07-03
|
15 | Brian Campbell | New version available: draft-ietf-oauth-mtls-15.txt |
2019-07-03
|
15 | (System) | New version approved |
2019-07-03
|
15 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2019-07-03
|
15 | Brian Campbell | Uploaded new revision |
2019-06-22
|
14 | Roman Danyliw | Second AD Review: https://mailarchive.ietf.org/arch/msg/oauth/pvUVPea35ML77sWxIkDDG1llMs4 |
2019-04-11
|
14 | Brian Campbell | New version available: draft-ietf-oauth-mtls-14.txt |
2019-04-11
|
14 | (System) | New version approved |
2019-04-11
|
14 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2019-04-11
|
14 | Brian Campbell | Uploaded new revision |
2019-03-27
|
13 | Cindy Morgan | Shepherding AD changed to Roman Danyliw |
2019-02-25
|
13 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-02-25
|
13 | Brian Campbell | New version available: draft-ietf-oauth-mtls-13.txt |
2019-02-25
|
13 | (System) | New version approved |
2019-02-25
|
13 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2019-02-25
|
13 | Brian Campbell | Uploaded new revision |
2019-01-28
|
13 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2019-01-28
|
13 | Brian Campbell | Uploaded new revision |
2018-12-21
|
12 | Eric Rescorla | Waiting for a new I-D from Brian. |
2018-11-04
|
12 | Eric Rescorla | https://mozphab-ietf.devsvcdev.mozaws.net/D3657 |
2018-11-04
|
12 | Eric Rescorla | IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested |
2018-10-18
|
12 | Brian Campbell | New version available: draft-ietf-oauth-mtls-12.txt |
2018-10-18
|
12 | (System) | New version approved |
2018-10-18
|
12 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2018-10-18
|
12 | Brian Campbell | Uploaded new revision |
2018-10-10
|
11 | Rifaat Shekh-Yusef | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The request is for a Proposed Standard type for the draft-ietf-oauth-mtls-10 document since the document defines new mechanisms to enhance the security of the OAuth protocol that has normative extensions to the interaction between the OAuth Client and OAuth Authorization Server. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes OAuth client authentication and certificate bound access tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization sever using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. Working Group Summary: This work was motivated by a request from OpenBanking UK to allow the OAuth Client and OAuth Authorization Server establish a mutually authenticated channel. Document Quality: A number of people reviewed the document over several rounds of reviews and provided feedback during meetings and on the mailing list, with no blocking comments. Implementations: Ping Identity has implemented one of the two methods, PKI-based method. Ping Identity also supports the certificate bound access token. Authlete has an implementation of this document. https://www.authlete.com/ ConnectId has an implementation. https://connect2id.com/blog/connect2id-server-6.13 oidc-provider: https://github.com/panva/node-oidc-provider References: OpenBanking UK reference this document https://openbanking.atlassian.net/wiki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2 OpenID WG reference https://bitbucket.org/openid/mobile/src/default/draft-mobile-client-initiated-backchannel-authentication.xml?fileviewer=file-view-default OpenID Foundation FAPI WG ref to MTLS https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md?fileviewer=file-view-default Berlin Group‘s Nextgen PSD2 Spec: https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf Personnel: The document shepherd is Rifaat Shekh-Yusef. The responsible Area Director is Eric Rescorla. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed this document and feels the document is ready. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document shepherd has no concerns with the level of reviews, as the document was discussed and reviewed by many participants. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Security review is always appreciated. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The document shepherd has no such concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. Brian: https://www.ietf.org/mail-archive/web/oauth/current/msg18200.html John: https://www.ietf.org/mail-archive/web/oauth/current/msg18264.html Nat: https://www.ietf.org/mail-archive/web/oauth/current/msg18199.html Torsten: https://www.ietf.org/mail-archive/web/oauth/current/msg18201.html (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No such IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There was a solid WG consensus that included feedback and support from multiple parties and individuals. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No such threat or discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no nits with this document. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such reviews are necessary. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document registers new values with existing registries. The document does not introduce any new registry. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document contains JSON-based examples, and these were validated using JSONLint. |
2018-08-30
|
11 | Brian Campbell | New version available: draft-ietf-oauth-mtls-11.txt |
2018-08-30
|
11 | (System) | New version approved |
2018-08-30
|
11 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2018-08-30
|
11 | Brian Campbell | Uploaded new revision |
2018-08-25
|
10 | Rifaat Shekh-Yusef | (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? … (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? The request is for a Proposed Standard type for the draft-ietf-oauth-mtls-10 document since the document defines new mechanisms to enhance the security of the OAuth protocol that has normative extensions to the interaction between the OAuth Client and OAuth Authorization Server. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: This document describes OAuth client authentication and certificate bound access tokens using mutual Transport Layer Security (TLS) authentication with X.509 certificates. OAuth clients are provided a mechanism for authentication to the authorization sever using mutual TLS, based on either self-signed certificates or public key infrastructure (PKI). OAuth authorization servers are provided a mechanism for binding access tokens to a client's mutual TLS certificate, and OAuth protected resources are provided a method for ensuring that such an access token presented to it was issued to the client presenting the token. Working Group Summary: This work was motivated by a request from OpenBanking UK to allow the OAuth Client and OAuth Authorization Server establish a mutually authenticated channel. Document Quality: A number of people reviewed the document over several rounds of reviews and provided feedback during meetings and on the mailing list, with no blocking comments. Implementations: Ping Identity has implemented one of the two methods, PKI-based method. Ping Identity also supports the certificate bound access token. Authlete has an implementation of this document. https://www.authlete.com/ ConnectId has an implementation. https://connect2id.com/blog/connect2id-server-6.13 References: OpenBanking UK reference this document https://openbanking.atlassian.net/wiki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2 OpenID WG reference https://bitbucket.org/openid/mobile/src/default/draft-mobile-client-initiated-backchannel-authentication.xml?fileviewer=file-view-default OpenID Foundation FAPI WG ref to MTLS https://bitbucket.org/openid/fapi/src/master/Financial_API_WD_002.md?fileviewer=file-view-default Berlin Group‘s Nextgen PSD2 Spec: https://docs.wixstatic.com/ugd/c2914b_5351b289bf844c6881e46ee3561d95bb.pdf Personnel: The document shepherd is Rifaat Shekh-Yusef. The responsible Area Director is Eric Rescorla. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The document shepherd has reviewed this document and feels the document is ready. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document shepherd has no concerns with the level of reviews, as the document was discussed and reviewed by many participants. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. Security review is always appreciated. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. The document shepherd has no such concerns. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. Brian: https://www.ietf.org/mail-archive/web/oauth/current/msg18200.html John: https://www.ietf.org/mail-archive/web/oauth/current/msg18264.html Nat: https://www.ietf.org/mail-archive/web/oauth/current/msg18199.html Torsten: https://www.ietf.org/mail-archive/web/oauth/current/msg18201.html (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No such IPR disclosures. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There was a solid WG consensus that included feedback and support from multiple parties and individuals. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No such threat or discontent. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. There are no nits with this document. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No such reviews are necessary. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). The document registers new values with existing registries. The document does not introduce any new registry. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document contains JSON-based examples, and these were validated using JSONLint. |
2018-08-25
|
10 | Rifaat Shekh-Yusef | Responsible AD changed to Eric Rescorla |
2018-08-25
|
10 | Rifaat Shekh-Yusef | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-08-25
|
10 | Rifaat Shekh-Yusef | IESG state changed to Publication Requested |
2018-08-25
|
10 | Rifaat Shekh-Yusef | IESG process started in state Publication Requested |
2018-08-25
|
10 | Rifaat Shekh-Yusef | Changed consensus to Yes from Unknown |
2018-08-25
|
10 | Rifaat Shekh-Yusef | Intended Status changed to Proposed Standard from None |
2018-07-22
|
10 | Rifaat Shekh-Yusef | Changed document writeup |
2018-07-21
|
10 | Rifaat Shekh-Yusef | Changed document writeup |
2018-07-21
|
10 | Rifaat Shekh-Yusef | Changed document writeup |
2018-07-17
|
10 | Brian Campbell | New version available: draft-ietf-oauth-mtls-10.txt |
2018-07-17
|
10 | (System) | New version approved |
2018-07-17
|
10 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2018-07-17
|
10 | Brian Campbell | Uploaded new revision |
2018-07-17
|
09 | Rifaat Shekh-Yusef | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2018-07-17
|
09 | Rifaat Shekh-Yusef | Notification list changed to Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> |
2018-07-17
|
09 | Rifaat Shekh-Yusef | Document shepherd changed to Rifaat Shekh-Yusef |
2018-06-04
|
09 | Brian Campbell | New version available: draft-ietf-oauth-mtls-09.txt |
2018-06-04
|
09 | (System) | New version approved |
2018-06-04
|
09 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2018-06-04
|
09 | Brian Campbell | Uploaded new revision |
2018-05-07
|
08 | Brian Campbell | New version available: draft-ietf-oauth-mtls-08.txt |
2018-05-07
|
08 | (System) | New version approved |
2018-05-07
|
08 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2018-05-07
|
08 | Brian Campbell | Uploaded new revision |
2018-01-30
|
07 | Brian Campbell | New version available: draft-ietf-oauth-mtls-07.txt |
2018-01-30
|
07 | (System) | New version approved |
2018-01-30
|
07 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2018-01-30
|
07 | Brian Campbell | Uploaded new revision |
2018-01-15
|
06 | Brian Campbell | New version available: draft-ietf-oauth-mtls-06.txt |
2018-01-15
|
06 | (System) | New version approved |
2018-01-15
|
06 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2018-01-15
|
06 | Brian Campbell | Uploaded new revision |
2017-11-12
|
05 | Brian Campbell | New version available: draft-ietf-oauth-mtls-05.txt |
2017-11-12
|
05 | (System) | New version approved |
2017-11-12
|
05 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2017-11-12
|
05 | Brian Campbell | Uploaded new revision |
2017-10-12
|
04 | Brian Campbell | New version available: draft-ietf-oauth-mtls-04.txt |
2017-10-12
|
04 | (System) | New version approved |
2017-10-12
|
04 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2017-10-12
|
04 | Brian Campbell | Uploaded new revision |
2017-07-28
|
03 | Brian Campbell | New version available: draft-ietf-oauth-mtls-03.txt |
2017-07-28
|
03 | (System) | New version approved |
2017-07-28
|
03 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2017-07-28
|
03 | Brian Campbell | Uploaded new revision |
2017-06-29
|
02 | Brian Campbell | New version available: draft-ietf-oauth-mtls-02.txt |
2017-06-29
|
02 | (System) | New version approved |
2017-06-29
|
02 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2017-06-29
|
02 | Brian Campbell | Uploaded new revision |
2017-05-26
|
01 | Brian Campbell | New version available: draft-ietf-oauth-mtls-01.txt |
2017-05-26
|
01 | (System) | New version approved |
2017-05-26
|
01 | (System) | Request for posting confirmation emailed to previous authors: Brian Campbell , Nat Sakimura , Torsten Lodderstedt , John Bradley |
2017-05-26
|
01 | Brian Campbell | Uploaded new revision |
2017-05-09
|
00 | Rifaat Shekh-Yusef | This document now replaces draft-campbell-oauth-mtls instead of None |
2017-05-09
|
00 | Brian Campbell | New version available: draft-ietf-oauth-mtls-00.txt |
2017-05-09
|
00 | (System) | WG -00 approved |
2017-05-09
|
00 | Brian Campbell | Set submitter to "Brian Campbell ", replaces to draft-campbell-oauth-mtls and sent approval email to group chairs: oauth-chairs@ietf.org |
2017-05-09
|
00 | Brian Campbell | Uploaded new revision |