ietf-corpus

rfc-5593

Internet Message Access Protocol (IMAP) - URL Access Identifier Extension

N. Cook
date2009-06 streamIETF wgnon working group statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc5593 doi10.17487/RFC5593
The existing IMAP URL specification (RFC 5092) lists several <access> identifiers and <access> identifier prefixes that can be used to restrict access to URLAUTH-generated URLs. However, these identifiers do not provide facilities for new services such as streaming. This document proposes a set of new <access> identifiers as well as an IANA mechanism to register new <access> identifiers for future applications. This document updates RFC 5092. [STANDARDS-TRACK]

updates

Extracted elements (17)

design-rationale §3.3

An access identifier name can also be registered as an access identifier prefix, but this requires two separate IANA registrations because the two forms carry distinct authorization semantics.

email, registry

design-rationale §3.3

New access identifiers share the same authorization semantics as 'submit+' but require the IMAP server to provide an extensible mechanism for associating userids with named applications, enabling per-application access control and audit.

email

design-rationale §3.2

The 'submit+' prefix cannot serve as a general mechanism for external entities acting on behalf of users for three reasons: (1) extending its authorized entity list increases the attack surface; (2) server logs cannot distinguish intended application use; and (3) the IMAP server cannot prioritize resources per application without distinct identifiers.

email, security

interoperability-note §1

This document updates RFC 5092 and is authoritative over it; in the event of any differences or discrepancies between the two documents, RFC 5593 takes precedence. IANA definitions for all existing RFC 5092 access identifiers are re-registered here.

email

normative-requirement §6 MUST

Access identifiers and prefixes MUST be registered using the 'IETF Review' policy as specified in RFC 5226.

email, registry

normative-requirement §3.3 MUST

Additional access identifiers MUST take one of two forms: either a plain application name (e.g., 'exampleapp') or an application name followed by '+' and a userid (e.g., 'exampleapp3+testuser').

email

normative-requirement §3.3 MUST

For access identifier prefix forms, the IMAP server SHALL NOT validate the specified userid but MUST validate that the IMAP session has an authorization identity that is authorized as an application entity for the specified application.

email, security

normative-requirement §4 MUST

Implementations MUST accept access identifier token strings in a case-insensitive fashion, as the use of upper- or lower-case in the ABNF is for editorial clarity only.

email

protocol-element §3.1

The 'anonymous' access identifier indicates that use of the URL is not restricted by session authorization identity, permitting unauthenticated access.

email

protocol-element §3.1

The 'authuser' access identifier restricts use of a URLAUTH-generated URL to authenticated IMAP sessions logged in as any non-anonymous user of that IMAP server.

email

protocol-element §3.4

The 'stream' access identifier is a new identifier used by SIP Media Servers to retrieve IMAP URL attachments for streaming to email clients, as described in the STREAMING specification.

email, realtime

protocol-element §3.1

The 'submit+' access identifier prefix, followed by a userid, indicates that only a userid authorized as a message submission entity on behalf of the specified userid is permitted to use the URL.

email

protocol-element §3.1

The 'user+' access identifier prefix, followed by a userid, limits use of the URL to IMAP sessions logged in as that specific userid.

email

registry §6

IANA created a new registry for IMAP URLAUTH access identifiers and prefixes. Initial entries include 'stream' (identifier), 'submit' (prefix), 'user' (prefix), 'authuser' (identifier), and 'anonymous' (identifier).

email, registry

registry §6.1

The IANA registration template for new access identifiers requires: Type (identifier or prefix), Application name, Description, RFC Number, and Contact information. Registrations are subject to IETF Review.

email, registry

security-consideration §7

The extension mechanism defined in this document is itself a security measure: it prevents overloading the 'submit+' identifier as a generic entity-access mechanism. All other security implications are identical to those in Section 10.1 of RFC 5092.

email, security

wire-format §4

The ABNF for the updated access syntax is: 'application = 1*(ALPHA/DIGIT)' and 'access =/ application / (application "+" enc-user)', extending the RFC 5092 grammar to allow arbitrary application names as access identifiers or prefixes.

email