| Internet-Draft | auth URI | June 2024 |
| Lasso | Expires 30 December 2024 | [Page] |
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.¶
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 (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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
The auth URI is intended to turn deceptive URIs, like the one shown in Section 7.6 of [RFC3986]:¶
ftp://cnn.example.com&[email protected]/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/¶
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., [email protected]¶
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¶
Method Name: info¶
Borrowing from Section 2.4 of [RFC2718], the 'auth' URI must consider the following:¶
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].¶
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.¶
[genuinely unsure what to put here... it's not entirely uncommon to find binary data encoded in an userinfo?]¶
Many of the ABNF rules in this document were adapted from [RFC7512]. Some of the structure of this text was adapted from [RFC7565].¶