Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)
updated by
Extracted elements (20)
Use of TCP port 563 for NNTP-over-TLS (where TLS negotiation begins immediately upon connection) is discouraged in favor of STARTTLS on the standard NNTP port, for the reasons documented in RFC 2595 Section 7 regarding dedicated 'secure' ports.
If TLS negotiation fails, both client and server SHOULD immediately close the connection, as a failed negotiation often leaves the session in an indeterminate state where interoperability cannot be guaranteed.
A client MUST NOT attempt to start a TLS session if one is already active. A server MUST NOT return the STARTTLS capability after TLS handshake completion and MUST respond with 502 if STARTTLS is received while TLS is already active. The client MUST NOT issue MODE READER while a TLS session is active.
If the server is unable to initiate TLS negotiation, it MUST reject the STARTTLS command with a 580 response. It SHOULD then either reject subsequent restricted commands with 483 or close the connection with 400.
Servers MUST be able to understand backwards-compatible TLS Client Hello messages (where client_version is TLS 1.0 or later). The TLS SNI extension 'server_name' SHOULD be implemented by all clients and by any server implementing STARTTLS known by multiple names.
The server remains in the non-authenticated state even if client credentials are supplied during TLS negotiation. The AUTHINFO SASL command with the EXTERNAL mechanism MAY be used to authenticate after TLS client credentials are exchanged.
The STARTTLS capability MUST NOT be advertised once a TLS layer is active or after successful authentication. Cached CAPABILITIES results from a previous session MUST NOT be relied upon.
The STARTTLS command MUST NOT be pipelined.
Upon receiving a 382 response to STARTTLS, the client MUST start the TLS negotiation before issuing any other NNTP commands. TLS negotiation begins with the first octet following the CRLF of the 382 response.
The STARTTLS command defines three response codes: 382 (continue with TLS negotiation), 502 (command unavailable, e.g., TLS already active or authentication has occurred), and 580 (cannot initiate TLS negotiation). The server MUST NOT return 480 or 483 in response to STARTTLS.
The STARTTLS extension adds a STARTTLS command and advertises the capability label 'STARTTLS' in response to the CAPABILITIES command. It provides connection-based security via TLS, enabling encryption, data integrity, optional certificate-based authentication, and optional data compression.
This document registers the STARTTLS extension in the IANA NNTP extension registry. The capability label is 'STARTTLS' with no arguments, defining one new command (STARTTLS) that cannot be pipelined and that removes the STARTTLS and MODE-READER capabilities from the list after successful negotiation.
A man-in-the-middle attack can be launched by deleting the STARTTLS capability label from the CAPABILITIES response, preventing TLS negotiation. Clients can partially protect against this by recording that a server offers TLS and generating an alarm if it does not appear in subsequent sessions.
Before the TLS handshake, protocol interactions are in the clear and may be modified by an active attacker. Clients and servers MUST discard sensitive knowledge obtained prior to TLS establishment upon the establishment of a security layer, and SHOULD re-issue CAPABILITIES afterward.
Certificate matching rules: if a subjectAltName of type dNSName is present it SHOULD be used; matching is case-insensitive; a '*' wildcard MAY be used as the leftmost component; multiple names in the certificate are acceptable if any one matches. If matching fails, the client SHOULD ask for user confirmation or terminate with QUIT.
Clients MUST verify the binding between server identity and public keys presented. Clients SHOULD implement the certificate validation algorithm in RFC 3280 Section 6, but MAY supplement with other equivalent methods such as comparing against a local store of already-verified certificates.
During TLS negotiation, the client MUST check its understanding of the server hostname against the server's identity in the Certificate message to prevent man-in-the-middle attacks. The client MUST use the hostname used to open the connection and MUST NOT use hostnames derived from insecure remote sources such as insecure DNS lookups.
NNTP implementations MUST implement the TLS_RSA_WITH_RC4_128_MD5 cipher suite and SHOULD implement TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA to assure interoperability between compliant implementations. All other cipher suites are OPTIONAL.
NNTP is not an end-to-end mechanism. TLS confidentiality on one NNTP link does not secure the full Netnews article delivery chain, which may traverse multiple servers. Client authentication of an article's origin at a server does not imply the client authenticated the article when it first received it.
Upon successful TLS handshake completion, the NNTP protocol resets to the state immediately after the initial greeting response (except MODE READER effects are preserved). The server MUST discard client knowledge not obtained from TLS negotiation; the client SHOULD discard and MUST NOT rely on server knowledge not from TLS negotiation.