Section 12. Security Considerations

This section is meant to inform application developers, information
   providers, and users of the security limitations in NNTP as described
   by this document.  The discussion does not include definitive
   solutions to the problems revealed, though it does make some
   suggestions for reducing security risks.
12.1.  Personal and Proprietary Information
   NNTP, because it was created to distribute network news articles,
   will forward whatever information is stored in those articles.
   Specification of that information is outside this scope of this
   document, but it is likely that some personal and/or proprietary
   information is available in some of those articles.  It is very
   important that designers and implementers provide informative
   warnings to users so that personal and/or proprietary information in
   material that is added automatically to articles (e.g., in headers)
   is not disclosed inadvertently.  Additionally, effective and easily
   understood mechanisms to manage the distribution of news articles
   SHOULD be provided to NNTP Server administrators, so that they are
   able to report with confidence the likely spread of any particular
   set of news articles.
12.2.  Abuse of Server Log Information
   A server is in the position to save session data about a user's
   requests that might identify their reading patterns or subjects of
   interest.  This information is clearly confidential in nature, and
   its handling can be constrained by law in certain countries.  People
   using this protocol to provide data are responsible for ensuring that
   such material is not distributed without the permission of any
   individuals that are identifiable by the published results.
12.3.  Weak Authentication and Access Control
   There is no user-based or token-based authentication in the basic
   NNTP specification.  Access is normally controlled by server
   configuration files.  Those files specify access by using domain
   names or IP addresses.  However, this specification does permit the
   creation of extensions to NNTP for such purposes; one such extension
   is [NNTP-AUTH].  While including such mechanisms is optional, doing
   so is strongly encouraged.
   Other mechanisms are also available.  For example, a proxy server
   could be put in place that requires authentication before connecting
   via the proxy to the NNTP server.
12.4.  DNS Spoofing
   Many existing NNTP implementations authorize incoming connections by
   checking the IP address of that connection against the IP addresses
   obtained via DNS lookups of lists of domain names given in local
   configuration files.  Servers that use this type of authentication
   and clients that find a server by doing a DNS lookup of the server
   name rely very heavily on the Domain Name Service, and are thus
   generally prone to security attacks based on the deliberate
   misassociation of IP addresses and DNS names.  Clients and servers
   need to be cautious in assuming the continuing validity of an IP
   number/DNS name association.
   In particular, NNTP clients and servers SHOULD rely on their name
   resolver for confirmation of an IP number/DNS name association,
   rather than cache the result of previous host name lookups.  Many
   platforms already can cache host name lookups locally when
   appropriate, and they SHOULD be configured to do so.  It is proper
   for these lookups to be cached, however, only when the TTL (Time To
   Live) information reported by the name server makes it likely that
   the cached information will remain useful.
   If NNTP clients or servers cache the results of host name lookups in
   order to achieve a performance improvement, they MUST observe the TTL
   information reported by DNS.  If NNTP clients or servers do not
   observe this rule, they could be spoofed when a previously accessed
   server's IP address changes.  As network renumbering is expected to
   become increasingly common, the possibility of this form of attack
   will increase.  Observing this requirement thus reduces this
   potential security vulnerability.
   This requirement also improves the load-balancing behaviour of
   clients for replicated servers using the same DNS name and reduces
   the likelihood of a user's experiencing failure in accessing sites
   that use that strategy.
12.5.  UTF-8 Issues
   UTF-8 [RFC3629] permits only certain sequences of octets and
   designates others as either malformed or "illegal".  The Unicode
   standard identifies a number of security issues related to illegal
   sequences and forbids their generation by conforming implementations.
   Implementations of this specification MUST NOT generate malformed or
   illegal sequences and SHOULD detect them and take some appropriate
   action.  This could include the following:
   o  Generating a 501 response code.
   o  Replacing such sequences by the sequence %xEF.BF.BD, which encodes
      the "replacement character" U+FFFD.
   o  Closing the connection.
   o  Replacing such sequences by a "guessed" valid sequence (based on
      properties of the UTF-8 encoding).
   In the last case, the implementation MUST ensure that any replacement
   cannot be used to bypass validity or security checks.  For example,
   the illegal sequence %xC0.A0 is an over-long encoding for space
   (%x20).  If it is replaced by the correct encoding in a command line,
   this needs to happen before the command line is parsed into
   individual arguments.  If the replacement came after parsing, it
   would be possible to generate an argument with an embedded space,
   which is forbidden.  Use of the "replacement character" does not have
   this problem, since it is permitted wherever non-US-ASCII characters
   are.  Implementations SHOULD use one of the first two solutions where
   the general structure of the NNTP stream remains intact and SHOULD
   close the connection if it is no longer possible to parse it
   sensibly.
12.6.  Caching of Capability Lists
   The CAPABILITIES command provides a capability list, which is
   information about the current capabilities of the server.  Whenever
   there is a relevant change to the server state, the results of this
   command are required to change accordingly.
   In most situations, the capabilities list in a given server state
   will not change from session to session; for example, a given
   extension will be installed permanently on a server.  Some clients
   may therefore wish to remember which extensions a server supports to
   avoid the delay of an additional command and response, particularly
   if they open multiple connections in the same session.
   However, information about extensions related to security and privacy
   MUST NOT be cached, since this could allow a variety of attacks.
   For example, consider a server that permits the use of cleartext
   passwords on links that are encrypted but not otherwise:
      [Initial connection set-up completed.]
      [S] 200 NNTP Service Ready, posting permitted
      [C] CAPABILITIES
      [S] 101 Capability list:
      [S] VERSION 2
      [S] READER
      [S] NEWNEWS
      [S] POST
      [S] XENCRYPT
      [S] LIST ACTIVE NEWSGROUPS
      [S] .
      [C] XENCRYPT
      [Client and server negotiate encryption on the link]
      [S] 283 Encrypted link established
      [C] CAPABILITIES
      [S] 101 Capability list:
      [S] VERSION 2
      [S] READER
      [S] NEWNEWS
      [S] POST
      [S] XSECRET
      [S] LIST ACTIVE NEWSGROUPS
      [S] .
      [C] XSECRET fred flintstone
      [S] 290 Password for fred accepted
   If the client caches the last capabilities list, then on the next
   session it will attempt to use XSECRET on an unencrypted link:
      [Initial connection set-up completed.]
      [S] 200 NNTP Service Ready, posting permitted
      [C] XSECRET fred flintstone
      [S] 483 Only permitted on secure links
   This exposes the password to any eavesdropper.  While the primary
   cause of this is passing a secret without first checking the security
   of the link, caching of capability lists can increase the risk.
   Any security extension should include requirements to check the
   security state of the link in a manner appropriate to that extension.
   Caching should normally only be considered for anonymous clients that
   do not use any security or privacy extensions and for which the time
   required for an additional command and response is a noticeable
   issue.