Internet Engineering Task Force S. Lasso Internet-Draft 28 June 2024 Intended status: Standards Track Expires: 30 December 2024 The auth URI scheme draft-soni-auth-uri-01 Abstract This document describes an URI scheme capable of susbtituting userinfo in traditional URIs, in machine-to-machine contexts, allowing for the deprecation and, in some applications, complete elimination of userinfo from URIs. In particular, the nature of the proposed URI scheme makes it unsuitable for use in semantic attacks, without compromising legitimate use-cases. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 30 December 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Lasso Expires 30 December 2024 [Page 1] Internet-Draft auth URI June 2024 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Background: Considerations for a new way of encoding authentication . . . . . . . . . . . . . . . . . . . . . 3 3. The auth URI: syntax and semantics . . . . . . . . . . . . . 3 3.1. Fragment Handling . . . . . . . . . . . . . . . . . . . . 4 4. The "info" method . . . . . . . . . . . . . . . . . . . . . . 4 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6.1. Initial assignments . . . . . . . . . . . . . . . . . . . 5 6.1.1. The 'info' method . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 8. Interoperability Considerations . . . . . . . . . . . . . . . 6 9. Encoding considerations . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Userinfo in URIs has been around since the introduction of URIs, but this is widely considered a historical mistake, as, due to the way userinfo is constructed, it enables some semantic attacks on URIs [RFC3986] (Section 7.6). Unfortunately, in machine-to-machine contexts, the ability to shove an userinfo-shaped peg into just about any URI-shaped hole turned out to be highly useful. The auth URI builds on this context and enables the complete removal of the userinfo syntax in at least some applications. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Lasso Expires 30 December 2024 [Page 2] Internet-Draft auth URI June 2024 2. Background: Considerations for a new way of encoding authentication The primary goal of a replacement for the userinfo syntax should be mitigating and/or eliminating the userinfo-related semantic attacks currently applicable to URIs. However, this does not preclude secondary goals such as improved support for secret storage (password managers). Making it an URI enables the following features in alignment with the primary goal: The auth URI generally prohibits operating system-level handling. When one program attempts to open an auth URI, the operating system MUST NOT open another program to handle the auth URI. Like userinfo, the auth URI shows up first/early in the URI, but unlike userinfo, it is not recognizable as a website or web address. This makes the auth URI easier to identify as an auth URI or at least "not a normal web address" than the equivalent userinfo. The auth URI explicitly uses syntax that is not usually detected by existing link recognition/extraction systems or "linkifiers". While this doesn't really add anything beyond the previously mentioned mitigations, it does help to reiterate that these URIs, while valid URIs, are not hyperlinks. Additionally, and in alignment with secondary goals, the auth URI can support "advanced" auth methods, including secret storage integration. 3. The auth URI: syntax and semantics The auth URI is a meta-URI, in that it carries an URI within itself. The auth URI syntax is defined here in Augmented BNF [RFC5234], borrrowing the terms 'URI', 'unreserved', and 'pct-encoded' from [RFC3986]. authURI = "auth" ":" auth-method "?" auth-query "&&" URI auth-query = [ auth-qattr *("&" auth-qattr) ] auth-q-res-avail = ":" / "[" / "]" / "@" / "!" / "$" / "'" / "(" / ")" / "*" / "+" / "," / "=" auth-qchar = unreserved / auth-q-res-avail / pct-encoded auth-attr-name-char = ALPHA / DIGIT / "-" / "_" auth-method-nm-char = ALPHA / DIGIT / "-" / "_" auth-qattr = 1*auth-attr-name-char "=" *auth-qchar auth-method = 1*auth-method-nm-char As an additional requirement, the embedded URI MUST NOT contain userinfo. Lasso Expires 30 December 2024 [Page 3] Internet-Draft auth URI June 2024 Semantically, the auth URI attaches auth details (not necessarily credentials themselves, but possibly how to locate the credentials) to the embedded URI. This embedded URI MAY itself be another auth URI, and an implementation MAY retry auth with the inner details, but SHOULD limit the maximum number of retries. An implementation MUST be able to parse at least 3 auth URIs before an embedded URI. 3.1. Fragment Handling Section 3.5 of [RFC3986] specifies how fragments should be handled, and said specification is reiterated by Section 2.5 of [RFC8820]. For the sake of clarification, the auth URI does not affect fragment resolution. However, care must be taken when parsing auth URIs with RFC3986 libraries: the fragment identifier will be extracted with the full URI and any "%23" in the embedded URI MUST NOT be unescaped before further parsing. 4. The "info" method The "info" method is a direct replacement for traditional userinfo. As such, it takes two attributes: "name" and "ad" (short for "auth data"). As with traditional userinfo, only the "name" attribute is required. As with traditional userinfo, applications are encouraged to not render in cleartext the value of the "ad" attribute. 5. Examples The auth URI is intended to turn deceptive URIs, like the one shown in Section 7.6 of [RFC3986]: ftp://cnn.example.com&story=breaking_news@10.0.0.1/top_story.htm Into something a little more ominous: auth:info?name=cnn.example.com%26story =breaking_news&&ftp://10.0.0.1/top_story.htm Making auth URIs unusable for the purposes of deception. Additionally, an example of regular usage of auth URIs might be to set an ssh username: auth:info?name=user&&ssh://server.example/ Lasso Expires 30 December 2024 [Page 4] Internet-Draft auth URI June 2024 6. IANA Considerations In accordance with the guidelines and registration procedures for new URI schemes [RFC7595], this section provides the information needed to register the 'auth' URI scheme. Scheme name: auth Status: Permanent Applications/Protocols that use this scheme name: At the time of writing, no applications use this scheme name. The intent is for this scheme to gradually replace userinfo in applications that currently make use of userinfo. Contact: Soni L., fakedme@gmail.com Change controller: [Note to RFC Editor: Replace with standard IETF language] References: RFC XXXXX [Note to RFC Editor: Replace with final RFC number] Additionally, in accordance IANA Considerations [RFC8126], the IANA is asked to create a registry for auth URI methods. Registry Name: 'auth' URI Methods Registry Group: Uniform Resource Identifiers (URI) Schemes Registry Information: Method Name, References Assignment Policy: IETF review 6.1. Initial assignments 6.1.1. The 'info' method Method Name: info References: This document, Section 4. 7. Security Considerations Borrowing from Section 2.4 of [RFC2718], the 'auth' URI must consider the following: Lasso Expires 30 December 2024 [Page 5] Internet-Draft auth URI June 2024 Does the user need to be warned that such a thing is happening without an explicit request? This will generally depend on the auth method used, but in particular the "info" method does not require it. Is it possible to fake URLs of this type in a dangerous way? No. In fact, the primary purpose of the auth URI is to forbid this. Are there mechanisms for identifying the requester? None that are known. Does the mechanism contains passwords or other security information that are passed inside the referring document in the clear? Yes, but no more than existing mechanisms, and only for compatibility purposes. This last point should sufficiently meet the requirements of [RFC3552]. 8. Interoperability Considerations The 'auth' URI explicitly breaks interoperability with existing userinfo-based systems, possibly necessitating conversions between them. Also, as described in Section 3.1, care must be taken when parsing the embedded URI. 9. Encoding considerations [genuinely unsure what to put here... it's not entirely uncommon to find binary data encoded in an userinfo?] 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, . Lasso Expires 30 December 2024 [Page 6] Internet-Draft auth URI June 2024 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC8820] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 8820, DOI 10.17487/RFC8820, June 2020, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . 10.2. Informative References [RFC7512] Pechanec, J. and D. Moffat, "The PKCS #11 URI Scheme", RFC 7512, DOI 10.17487/RFC7512, April 2015, . [RFC7565] Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565, DOI 10.17487/RFC7565, May 2015, . [RFC2718] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, "Guidelines for new URL Schemes", RFC 2718, DOI 10.17487/RFC2718, November 1999, . Acknowledgements Many of the ABNF rules in this document were adapted from [RFC7512]. Some of the structure of this text was adapted from [RFC7565]. Author's Address Soni Lasso Terense Email: fakedme@gmail.com Lasso Expires 30 December 2024 [Page 7] Internet-Draft auth URI June 2024 URI: https://soniex2.autistic.space/ Lasso Expires 30 December 2024 [Page 8]