[NNTP] STARTTLS diffs
Ken Murchison
ken at oceana.com
Fri Jun 10 09:39:16 PDT 2005
Here's my rewrite of STARTTLS which hopefully addresses (or at least
begins to address) all issues brought up during last call (especially
those raised by Eric). The most significant rewrites are in the
Introduction (1), STARTTLS description (2.2.2) and Security
Considerations (5). Section 2.2.2.1 is been almost entirely removed
because the client/server shouldn't be offering options that it isn't
willing to accept, so checking them after the fact is really pointless.
Section 2.2.2.2 has been merged into 2.2.2. I also added mandatory
to implement cipher for interoperability (using the same one as RFC
3501), and rewrote the text concerning verifying the hostname in the
server's certificate.
If its too difficult to read the diffs, I have posted the entire
document here:
ftp://ftp.oceana.com/pub/drafts/draft-ietf-nntpext-tls-nntp-07pre1.txt
--- starttls-6.txt 2005-06-10 12:06:40.000000000 -0400
+++ starttls-7.txt 2005-06-10 12:34:59.000000000 -0400
@@ -14,7 +14,7 @@
Using TLS with NNTP
- draft-ietf-nntpext-tls-nntp-06
+ draft-ietf-nntpext-tls-nntp-07
Status of this memo
@@ -48,29 +48,39 @@
Abstract
This memo defines an extension to the Network News Transport
- Protocol [NNTP] to provide connection-based security (via Transport
- Layer Security [TLS]). The primary goal is to provide encryption
+ Protocol (NNTP) to allow an NNTP client and server to use Transport
+ Layer Security (TLS). The primary goal is to provide encryption
for single-link confidentiality purposes, but data integrity,
(optional) certificate-based peer entity authentication, and
(optional) data compression are also possible.
+Note to the RFC Editor
+
+ The normative references to RFC 2234, RFC 2246, and RFC 3546 may
+ be replaced by draft-crocker-abnf-rfc2234bis,
+ draft-ietf-tls-rfc2246-bis, and draft-ietf-tls-rfc3526bis
+ respectively should any or all of those documents reach RFC status
+ before this one.
+
+ The normative reference to [NNTP] and the informative reference to
+ [NNTP-AUTH] are documents which are expected to be published
+ simultaneously with this one and so can be replaced by references
+ to the resulting RFCs.
+
Table of Contents
- 0. Changes from Previous Version ............................ 2
- 1. Introduction ............................................. 3
+ 1. Introduction ............................................. 2
1.1. Conventions Used in this Document ................... 3
2. The STARTTLS Extension ................................... 3
2.1. Advertising the STARTTLS Extension .................. 3
2.2. STARTTLS Command .................................... 4
2.2.1. Usage .......................................... 4
2.2.2. Description .................................... 4
- 2.2.2.1. Processing After the STARTTLS Command ..... 5
- 2.2.2.2. Result of the STARTTLS Command ............ 6
- 2.2.3. Examples ....................................... 7
+ 2.2.3. Examples ....................................... 6
3. Augmented BNF Syntax for the STARTTLS Extension .......... 8
3.1. Commands ............................................ 8
- 3.2. Capability entries .................................. 9
- 4. Summary of Response Codes ................................ 9
+ 3.2. Capability entries .................................. 8
+ 4. Summary of Response Codes ................................ 8
5. Security Considerations .................................. 9
6. IANA Considerations ...................................... 11
7. References ............................................... 12
@@ -79,40 +89,34 @@
8. Authors' Addresses ....................................... 12
9. Acknowledgments .......................................... 13
10. Intellectual Property Rights ............................ 13
- 11. Copyright ............................................... 14
-
-0. Changes from Previous Version
-
- Changed:
- o Made Ken the primary author.
- o Updated to RFC 3978/3979 boilerplate.
- o Fixed CAPABILITIES responses (specifically LIST arguments) in
- examples.
- o Section 5: Consolidated two paragraphs to coincide with language
- in [NNTP-AUTH].
-
- Clarified:
- o Section 2.1: STARTTLS MUST NOT be advertised once a TLS layer
- is active or after successful authentication.
- o Section 3: This document extends the ABNF in [NNTP], and the
- [NNTP] ABNF must be imported first before validating the
- STARTTLS ABNF (based on recommendations of AD regarding
- IMAPEXT I-Ds).
+ 11. Copyright ............................................... 13
1. Introduction
Historically, unencrypted NNTP [NNTP] connections were satisfactory
for most purposes. However, sending passwords unencrypted over the
- network is no longer appropriate, and sometimes strong encryption
- is desired for the entire connection.
+ network is no longer appropriate, and sometimes integrity and/or
+ confidentiality protection is desired for the entire connection.
- The STARTTLS extension provides a way to use the popular TLS [TLS]
- service with the existing NNTP protocol. The current
- (unstandardized) use of TLS for NNTP is most commonly on a
- dedicated TCP port; this practice is discouraged for the reasons
- documented in section 7 of "Using TLS with IMAP, POP3 and ACAP"
- [TLS-IMAPPOP]. Therefore, this specification formalizes the
- STARTTLS command already in occasional use by the installed base.
+ The TLS protocol (formerly known as SSL) provides a way to secure
+ an application protocol from tampering and eavesdropping. Although
+ advanced SASL authentication mechanisms [NNTP-AUTH] can provide a
+ lightweight version of this service, TLS is complimentary to simple
+ authentication-only SASL mechanisms or deployed clear-text password
+ login commands.
+
+ In some existing implementations, TCP port 563 has been dedicated
+ to NNTP over TLS. These implementations begin the TLS negotiation
+ immediately upon connection, and then continue with the initial
+ steps of an NNTP session. This use of TLS on a separate port is
+ discouraged for the reasons documented in section 7 of "Using TLS
+ with IMAP, POP3 and ACAP" [TLS-IMAPPOP].
+
+ This specification formalizes the STARTTLS command already in
+ occasional use by the installed base. The STARTTLS command
+ rectifies a number of the problems with using a separate port for a
+ "secure" protocol variant, and is the preferred way of using TLS
+ with NNTP.
1.1. Conventions Used in this Document
@@ -183,8 +187,8 @@
A client issues the STARTTLS command to request negotiation of TLS.
The STARTTLS command is usually used to initiate session security,
- although it can be used for client certificate authentication
- and/or data compression.
+ although it can also be used for client and/or server certificate
+ authentication and/or data compression.
An NNTP server returns the 483 response to indicate that a secure
or encrypted connection is required for the command sent by the
@@ -204,17 +208,7 @@
begins. A server MUST NOT under any circumstances reply to a
STARTTLS command with either a 480 or 483 response.
- If the client receives a failure response to STARTTLS, the client
- must decide whether or not to continue the NNTP session. Such a
- decision is based on local policy. For instance, if TLS was being
- used for client authentication, the client might try to continue
- the session in case the server allows it to do so even with no
- authentication. However, if TLS was being negotiated for
- encryption, a client that gets a failure response needs to decide
- whether to continue without TLS encryption, to wait and try again
- later, or to give up and notify the user of the error.
-
- After receiving a 382 response to a STARTTLS command, the client
+ Upon receiving a 382 response to a STARTTLS command, the client
MUST start the TLS negotiation before giving any other NNTP
commands. The TLS negotiation begins for both the client and
server with the first octet following the CRLF of the 382 response.
@@ -233,56 +227,34 @@
(otherwise it is not possible for a server with several hostnames
to present the correct certificate to the client).
- Although current use of TLS most often involves the dedication of
- port 563 for NNTP over TLS, the continued use of TLS on a separate
- port is discouraged for the reasons documented in section 7 of
- "Using TLS with IMAP, POP3 and ACAP" [TLS-IMAPPOP].
-
-2.2.2.1. Processing After the STARTTLS Command
-
- After the TLS handshake has been completed, both parties MUST
- immediately decide whether or not to continue based on the
- authentication and privacy achieved (if any). The NNTP client and
- server may decide to move ahead even if the TLS negotiation ended
- without authentication and/or without privacy because NNTP services
- are often performed without authentication or privacy, but some
- NNTP clients or servers may want to continue only if a particular
- level of authentication and/or privacy was achieved.
-
- If the NNTP client decides that the level of authentication or
- privacy is not high enough for it to continue, it SHOULD issue a
- QUIT command immediately after the TLS negotiation is complete. If
- the NNTP server decides that the level of authentication or privacy
- is not high enough for it to continue, it SHOULD either reject
- subsequent restricted NNTP commands from the client with a 483
- response code (possibly with a text string such as "Command refused
- due to lack of security"), or reject a command with a 400 response
- code (possibly with a text string such as "Connection closing due
- to lack of security") and close the connection.
-
- The decision of whether or not to believe the authenticity of the
- other party in a TLS negotiation is a local matter. However, some
- general rules for the decisions are:
-
- o The client MAY check that the identity presented in the server's
- certificate matches the intended server hostname or domain.
- This check is not required (and may fail in the absence of the
- TLS "server_name" extension [TLS-EXT], as described above), but
- if it is implemented and the match fails, the client SHOULD
- either request explicit user confirmation, or terminate the
- connection but allow the user to disable the check in the
- future.
- o Generally an NNTP server would want to accept any verifiable
- certificate from a client, however authentication can be done
- using the client certificate (perhaps in combination with the
- SASL EXTERNAL mechanism [NNTP-AUTH], although an implementation
- supporting STARTTLS is not required to support SASL in general
- or that mechanism in particular). The server MAY use
- information about the client certificate for identification of
- connections or posted articles (either in its logs or directly
- in posted articles).
-
-2.2.2.2. Result of the STARTTLS Command
+ Generally an NNTP server would want to accept any verifiable
+ certificate from a client, however authentication can be done using
+ the client certificate (perhaps in combination with the SASL
+ EXTERNAL mechanism [NNTP-AUTH], although an implementation
+ supporting STARTTLS is not required to support SASL in general or
+ that mechanism in particular). The server MAY use information
+ about the client certificate for identification of connections or
+ posted articles (either in its logs or directly in posted
+ articles).
+
+ If the client receives a failure response to STARTTLS or if the TLS
+ negotiation fails, the client must decide whether or not to
+ continue the NNTP session. Such a decision is based on local
+ policy. For instance, if TLS was being used for client
+ authentication, the client might try to continue the session in
+ case the server allows it to do so even with no authentication.
+ However, if TLS was being negotiated for encryption, a client that
+ gets a failure response needs to decide whether to continue without
+ TLS encryption, to wait and try again later, or to give up and
+ notify the user of the error.
+
+ If the server is unable to initiate the TLS negotiation or if the
+ TLS negotiation fails, the server SHOULD either reject subsequent
+ restricted NNTP commands from the client with a 483 response code
+ (possibly with a text string such as "Command refused due to lack
+ of security"), or reject a command with a 400 response code
+ (possibly with a text string such as "Connection closing due to
+ lack of security") and close the connection.
Upon successful completion of the TLS handshake, the NNTP protocol
is reset to the state immediately after the initial greeting
@@ -308,11 +280,11 @@
MUST NOT advertise the MODE-READER capability.
The capability list returned in response to a CAPABILITIES command
- received after the TLS handshake MAY be different than the list
- returned before the TLS handshake. For example, an NNTP server
- supporting SASL [NNTP-AUTH] might not want to advertise support for
- a particular mechanism unless a client has sent an appropriate
- client certificate during a TLS handshake.
+ received after a successful TLS handshake MAY be different than the
+ list returned before the TLS handshake. For example, an NNTP
+ server supporting SASL [NNTP-AUTH] might not want to advertise
+ support for a particular mechanism unless a client has sent an
+ appropriate client certificate during a TLS handshake.
2.2.3. Examples
@@ -428,6 +400,13 @@
described in section 12 of [NNTP]; those considerations remain
relevant to any NNTP implementation.
+ NNTP client and server implementations MUST implement the
+ TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement
+ the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is
+ important as it assures that any two compliant implementations can
+ be configured to interoperate. All other cipher suites are
+ OPTIONAL.
+
Before the TLS handshake has begun, any protocol interactions are
performed in the clear and may be modified by an active attacker.
For this reason, clients and servers MUST discard any sensitive
@@ -437,39 +416,48 @@
layer, and other protocol state SHOULD be re-negotiated as well.
It should be noted that NNTP is not an end-to-end mechanism. Thus,
- if an NNTP client/server pair decide to add TLS privacy, they are
- securing the transport only for that link. Similarly, because
- delivery of a single piece of news may go between more than two
- NNTP servers, adding TLS privacy to one pair of servers does not
- mean that the entire NNTP chain has been made private.
+ if an NNTP client/server pair decide to add TLS confidentiality,
+ they are securing the transport only for that link. Similarly,
+ because delivery of a single piece of news may go between more than
+ two NNTP servers, adding TLS confidentiality to one pair of servers
+ does not mean that the entire NNTP chain has been made private.
Furthermore, just because an NNTP server can authenticate an NNTP
client, it does not mean that the articles from the NNTP client
were authenticated by the NNTP client when the client received
them.
- Both the NNTP client and server must check the result of the TLS
- negotiation to see whether an acceptable degree of authentication
- and privacy was achieved. Ignoring this step completely
- invalidates using TLS for security. The decision about whether
- acceptable authentication or privacy was achieved is made locally,
- is implementation-dependent, and is beyond the scope of this
- document.
-
- The NNTP client and server should note carefully the result of the
- TLS negotiation. If the negotiation results in no privacy, or if
- it results in privacy using algorithms or key lengths that are
- deemed not strong enough, or if the authentication is not good
- enough for either party, the client may choose to end the NNTP
- session with an immediate QUIT command, or the server may choose
- not to accept any more NNTP commands.
-
- The client and server should also be aware that the TLS protocol
- permits privacy and security capabilities to be renegotiated mid-
- connection (see section 7.4.1 of [TLS]). For example, one of the
- parties may desire minimal encryption after any authentication
- steps have been performed. This underscores the fact that security
- is not present simply because TLS has been negotiated; the nature
- of the established security layer must be considered.
+ During the TLS negotiation, the client MUST check its understanding
+ of the server hostname against the server's identity as presented
+ in the server Certificate message, in order to prevent man-in-the-
+ middle attacks. Matching is performed according to these rules:
+
+ - The client MUST use the server hostname it used to open the
+ connection (or the hostname specified in TLS "server_name"
+ extension [TLS-EXT]) as the value to compare against the server
+ name as expressed in the server certificate. The client MUST
+ NOT use any form of the server hostname derived from an insecure
+ remote source (e.g., insecure DNS lookup). CNAME
+ canonicalization is not done.
+
+ - If a subjectAltName extension of type dNSName is present in the
+ certificate, it SHOULD be used as the source of the server's
+ identity.
+
+ - Matching is case-insensitive.
+
+ - A "*" wildcard character MAY be used as the left-most name
+ component in the certificate. For example, *.example.com would
+ match a.example.com, foo.example.com, etc. but would not match
+ example.com.
+
+ - If the certificate contains multiple names (e.g. more than one
+ dNSName field), then a match with any one of the fields is
+ considered acceptable.
+
+
+ If the match fails, the client SHOULD either ask for explicit user
+ confirmation, or terminate the connection with a QUIT command and
+ indicate the server's identity is suspect.
A man-in-the-middle attack can be launched by deleting the STARTTLS
capability label in the CAPABILITIES response from the server.
@@ -483,12 +471,12 @@
later session (of course, the STARTTLS capability would not be
listed after a security layer is in place).
- If the TLS negotiation fails or if the client receives a 483
+ If the TLS negotiation fails or if the client receives a 483 or 580
response, the client has to decide what to do next. The client has
to choose among three main options: to go ahead with the rest of
- the NNTP session, to retry TLS later in the session, or to give up
- and postpone newsreading/transport activity. If a failure or error
- occurs, the client can assume that the server may be able to
+ the NNTP session, to (re)try TLS later in the session, or to give
+ up and postpone newsreading/transport activity. If a failure or
+ error occurs, the client can assume that the server may be able to
negotiate TLS in the future, and should try to negotiate TLS in a
later session. However, if the client and server were only using
TLS for authentication and no previous 480 response was received,
@@ -556,12 +544,12 @@
[NNTP] Feather, C., "Network News Transport Protocol",
draft-ietf-nntpext-base-*.txt, Work in Progress.
- [TLS] Dierks, T., Rescorla, E., "The TLS Protocol Version 1.1",
- draft-ietf-tls-rfc2246-bis-*.txt, Work in Progress.
+ [TLS] Dierks, T., Allen, C., "The TLS Protocol Version 1.0",
+ RFC 2246, January 1999.
[TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D.,
Mikkelsen, J., Wright, T., "Transport Layer Security (TLS)
- Extensions", draft-ietf-tls-rfc3546bis-*.txt, Work in Progress.
+ Extensions", RFC 3546, June 2003.
7.2. Informative References
@@ -596,12 +584,12 @@
1050 Lakes Drive, Suite 250
West Covina, CA 91790
- EMail: cnewman at iplanet.com
+ EMail: Chris.Newman at sun.com
9. Acknowledgments
- A significant amount of the STARTTLS text was lifted from RFC 3207
- by Paul Hoffman.
+ A significant amount of the text in this document was lifted from
+ RFC 2595 by Chris Newman and RFC 3207 by Paul Hoffman.
Special acknowledgment goes also to the people who commented
privately on intermediate revisions of this document, as well as
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
More information about the ietf-nntp
mailing list