IMAP Extension for Simple Authentication and Security Layer (SASL) Initial Client Response
Extracted elements (13)
The extension was designed to eliminate at least one complete round trip at the beginning of an IMAP session, which is particularly undesirable when round-trip costs are high. Prior to this extension, the IMAP SASL profile always required at least one complete round trip because it did not support an initial client response argument.
If either the client or the server do not support the SASL-IR capability, a mechanism which uses an initial client response is negotiated using the challenge/response exchange described in RFC 3501, with an initial zero-length server challenge.
Clients that implement this extension MUST NOT send an initial client response to servers that do not advertise the SASL-IR capability; in such a situation, clients MUST fall back to IMAP-compatible mode.
If the client uses an initial response with a SASL mechanism that does not support an initial response, the server MUST reject the command with a tagged BAD response.
Servers that implement this extension MUST support clients that omit the initial client response.
The initial client response MUST be encoded as BASE64 as defined in RFC 4648, and MUST be transmitted outside of a quoted string or literal.
To send a zero-length initial response, the client MUST send a single pad character ('='). This indicates the response is present but is a zero-length string.
When decoding BASE64 data in the initial client response, decoding errors MUST be treated as IMAP would handle them in any normal SASL client response. The server should check for characters not in the BASE64 alphabet and pad characters not at the end of the string.
The SASL-IR extension is present in any IMAP server that returns 'SASL-IR' as one of the supported capabilities in its CAPABILITY response. Servers supporting this extension accept an optional initial client response with the AUTHENTICATE command for SASL mechanisms that support it.
IANA has added 'SASL-IR' to the IMAP4 Capabilities Registry.
Server implementations MUST treat the omission of an initial client response from the AUTHENTICATE command as defined by RFC 3501, as if this extension did not exist.
Server implementations that enforce line length limits MUST be aware that the addition of the initial response parameter to AUTHENTICATE may increase the maximum line length that IMAP parsers may expect to support. Server implementations MUST be able to receive the largest possible initial client response that their supported mechanisms might receive.
The AUTHENTICATE command is redefined as: 'AUTHENTICATE' SP auth-type [SP (base64 / '=')], followed by *(CRLF base64). The optional second argument carries the initial client response encoded as BASE64, or '=' to indicate a zero-length initial response.