Network News Transfer Protocol (NNTP) Extension for Authentication
updates
- rfc-2980 — Common NNTP Extensions
Extracted elements (28)
AUTHINFO GENERIC is deprecated in favor of AUTHINFO SASL so that NNTP can benefit from authentication mechanisms developed for other SASL-enabled protocols (SMTP, POP, IMAP, LDAP, BEEP), rather than maintaining an NNTP-specific equivalent.
SASL PLAIN is recommended when both AUTHINFO USER/PASS and AUTHINFO SASL are implemented because DIGEST-MD5 is insufficient for some environments (e.g., where the server needs to pass plaintext passwords to an external authentication service), and PLAIN eliminates white-space limitations of AUTHINFO USER/PASS.
Servers MAY use SASLprep to canonicalize usernames for AUTHINFO USER/PASS comparison, but doing so may cause interoperability problems with legacy implementations that do not canonicalize.
This document supersedes the AUTHINFO USER and AUTHINFO PASS definitions from RFC 2980 Section 3.1.1, and deprecates AUTHINFO SIMPLE and AUTHINFO GENERIC. Servers SHOULD NOT advertise AUTHINFO GENERIC in capabilities.
A client SHOULD scan the username and password for white space and warn the user if any is detected, as servers may not preserve exact white space sequences. SASL PLAIN is recommended as an alternative that does not suffer from these issues.
A compliant implementation MUST NOT implement AUTHINFO PASS without also implementing support for TLS. Use of AUTHINFO PASS without an active strong encryption layer is deprecated. Any implementation SHOULD be configurable to disable it when TLS is not active, and this SHOULD be the default.
A server MUST implement at least one of AUTHINFO USER or AUTHINFO SASL commands in order to advertise the AUTHINFO capability label. The AUTHINFO capability MUST NOT be advertised after successful authentication.
A server MUST NOT under any circumstances reply to an AUTHINFO command with a 480 response. A client MUST NOT continue authentication beyond the first step unless the server responds with a 38x response code.
After successful authentication, the client MUST NOT issue a MODE READER command, and the server MUST NOT advertise the MODE-READER capability. The server MUST continue to advertise the SASL capability with the same list of mechanisms as before authentication.
Cached results of CAPABILITIES from a previous session MUST NOT be relied on for AUTHINFO, as the extension is security-related. A client MAY use cached results to detect active down-negotiation attacks.
Clients and servers MUST be able to handle the maximum encoded size of challenges and responses generated by their supported SASL mechanisms, independent of any line length limitations elsewhere in the protocol implementation.
If the server advertises the SASL argument in the AUTHINFO capability, it MUST also advertise the SASL capability in response to the CAPABILITIES command, followed by a whitespace-separated list of available SASL mechanism names.
Servers and clients MUST reject (and not ignore) any character not explicitly allowed by the Base64 alphabet, and MUST reject any Base64 sequence containing the pad character ('=') anywhere other than the end of the string.
The authorization identity generated by the SASL exchange is a simple username, and both client and server MUST use the SASLprep profile of the StringPrep algorithm to prepare these names for transmission or comparison. If preparation fails or results in an empty string, the server MUST fail authentication with 481.
The USER argument MUST NOT be advertised, and AUTHINFO USER/PASS commands SHOULD NOT be provided, unless a strong encryption layer (e.g., TLS) is in use or backward compatibility dictates otherwise.
To ensure interoperability, client and server implementations of the AUTHINFO extension MUST implement the DIGEST-MD5 SASL mechanism.
When a security layer is negotiated via SASL, it takes effect for the client immediately after the CRLF of its last response, and for the server immediately after the CRLF of its success reply. The server MUST discard prior session knowledge such as current newsgroup and article number.
When both TLS and SASL security layers are in effect, TLS encoding MUST be applied after SASL encoding (cleartext is SASL-encoded first, then TLS-encoded).
AUTHINFO SASL initiates a SASL exchange. The command syntax is: AUTHINFO SASL mechanism [initial-response], where the initial-response MUST be Base64-encoded. The command MUST NOT be pipelined and may exceed 512 octets.
AUTHINFO USER and AUTHINFO PASS commands present clear-text credentials to the server. AUTHINFO USER supplies the username; AUTHINFO PASS supplies the password. These commands MUST NOT be pipelined.
The AUTHINFO extension provides three new commands: AUTHINFO USER, AUTHINFO PASS, and AUTHINFO SASL. The capability label for this extension is AUTHINFO, advertised in response to the CAPABILITIES command.
IANA registered the SASL/GSSAPI service name 'nntp', referring to authenticated use of Usenet news service via the NNTP protocol. The NNTP Extensions registry is updated with the AUTHINFO extension definition.
Clients and servers MUST discard any sensitive knowledge obtained prior to the start of SASL negotiation upon establishment of a security layer. The CAPABILITIES command SHOULD be re-issued and protocol state SHOULD be re-negotiated after a security layer is established.
Implementations MUST support a configuration where authentication mechanisms vulnerable to passive eavesdropping (such as AUTHINFO USER/PASS and SASL PLAIN) are not advertised or used without an external security layer such as TLS, and this SHOULD be the default configuration.
Servers MAY drop the connection after a number of failed authentication attempts, but SHOULD NOT do so until at least 3 attempts have failed.
When multiple authentication mechanisms are permitted by both parties, an active attacker can cause down-negotiation to the weakest mechanism. Both clients and servers SHOULD be configurable to forbid use of weak mechanisms.
For AUTHINFO USER/PASS with both username and password required: server MUST return 381 to AUTHINFO USER; MUST return 482 to AUTHINFO PASS if no cached username; MUST use the most recent AUTHINFO USER argument; MUST NOT return 381 to AUTHINFO PASS. On success, server returns 281; on failure, 481.
SASL server challenges are sent as 383 responses with a single Base64-encoded argument. A zero-length challenge MUST be sent as a single equals sign ('='). Client responses are Base64-encoded lines; zero-length responses MUST also be sent as '='. Client cancellation is sent as a single '*'.