[NNTP] Proposed changes to STARTTLS-07
Ken Murchison
ken at oceana.com
Tue Aug 2 08:30:13 PDT 2005
Based on comments from the list and Russ' suggestion, here is my current
diff for STARTTLS. Note that a lot of this is just moving text around
(back to -06 placement). It feels like we need more text describing
*why* the connection should be closed after a failed TLS (session in
indeterminate state, interop problems, etc), but I couldn't come up with
anything that I like. Suggested text is welcome.
--- starttls-07.txt 2005-08-02 10:12:03.000000000 -0400
+++ starttls-08.txt 2005-08-02 11:21:43.000000000 -0400
@@ -14,7 +14,7 @@
Using TLS with NNTP
- draft-ietf-nntpext-tls-nntp-07
+ draft-ietf-nntpext-tls-nntp-08
Status of this memo
@@ -56,11 +56,10 @@
Note to the RFC Editor
- The normative references to RFC 2234, RFC 2246, and RFC 3546, and the
- informative reference to RFC 2222 may
- be replaced by draft-crocker-abnf-rfc2234bis,
- draft-ietf-tls-rfc2246-bis draft-ietf-tls-rfc3526bis, and
- draft-ietf-sasl-rfc2222bis
+ The normative references to RFC 2234, RFC 2246, and RFC 3546,
+ and the informative reference to RFC 2222 may be replaced by
+ draft-crocker-abnf-rfc2234bis, draft-ietf-tls-rfc2246-bis
+ draft-ietf-tls-rfc3526bis, and draft-ietf-sasl-rfc2222bis
respectively should any or all of those documents reach RFC status
before this one.
@@ -205,10 +204,26 @@
If the server is unable to initiate the TLS negotiation for any
reason (e.g. a server configuration or resource problem), the
- server MUST reject the STARTTLS command with a 580 response.
- Otherwise, the server issues a 382 response and TLS negotiation
- begins. A server MUST NOT under any circumstances reply to a
- STARTTLS command with either a 480 or 483 response.
+ server MUST reject the STARTTLS command with a 580 response, and
+ 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
+ subsequent restricted command with a 400 response code (possibly
+ with a text string such as "Connection closing due to lack of
+ security") and close the connection. Otherwise, the server issues
+ a 382 response and TLS negotiation 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.
Upon receiving a 382 response to a STARTTLS command, the client
MUST start the TLS negotiation before giving any other NNTP
@@ -229,34 +244,8 @@
(otherwise it is not possible for a server with several hostnames
to present the correct certificate to the client).
- The server remains in the non-authenticated state, even if client
- credentials are supplied during the TLS negotiation. The AUTHINFO
- SASL command [NNTP-AUTH] with the EXTERNAL mechanism [SASL] MAY be
- used to authenticate once TLS client credentials are successfully
- exchanged, but servers supporting the STARTTLS command are not
- required to support AUTHINFO in general or that mechanism in
- particular. The server MAY use information from 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.
+ If the TLS negotiation fails, both client and server SHOULD
+ immediately close the connection.
Upon successful completion of the TLS handshake, the NNTP protocol
is reset to the state immediately after the initial greeting
@@ -271,6 +260,16 @@
capability list, which was not obtained from the TLS negotiation
itself.
+ The server remains in the non-authenticated state, even if client
+ credentials are supplied during the TLS negotiation. The AUTHINFO
+ SASL command [NNTP-AUTH] with the EXTERNAL mechanism [SASL] MAY be
+ used to authenticate once TLS client credentials are successfully
+ exchanged, but servers supporting the STARTTLS command are not
+ required to support AUTHINFO in general or that mechanism in
+ particular. The server MAY use information from the client
+ certificate for identification of connections or posted articles
+ (either in its logs or directly in posted articles).
+
Both the client and the server MUST know if there is a TLS session
active. A client MUST NOT attempt to start a TLS session if a TLS
session is already active. A server MUST NOT return the STARTTLS
@@ -425,8 +424,8 @@
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.
+ were authenticated by the NNTP client when the client itself
+ received them (prior to forwarding them to the server).
During the TLS negotiation, the client MUST check its understanding
of the server hostname against the server's identity as presented
@@ -530,8 +529,9 @@
o Published Specification: This document.
- o Author, Change Controller, and Contact for Further Information:
- Author of this document.
+ o Contact for Further Information: Authors of this document.
+
+ o Change Controller: IESG <iesg at ietf.org>.
7. References
@@ -544,7 +544,7 @@
Requirement Levels", BCP 14, RFC 2119, March 1997.
[NNTP] Feather, C., "Network News Transport Protocol",
- draft-ietf-nntpext-base-*.txt, Work in Progress.
+ draft-ietf-nntpext-base-*, Work in Progress.
[TLS] Dierks, T., Allen, C., "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
@@ -556,7 +556,7 @@
7.2. Informative References
[NNTP-AUTH] Vinocur, J., Murchison, K., Newman, C., "NNTP Extension
- for Authentication", draft-ietf-nntpext-auth-*.txt, Work in
+ for Authentication", draft-ietf-nntpext-authinfo-*, Work in
Progress.
[SASL] Myers, J., "Simple Authentication and Security Layer
@@ -569,8 +569,8 @@
Kenneth Murchison
Oceana Matrix Ltd.
- 21 Princeton Place
- Orchard Park, NY 14127 USA
+ 2495 Main St, Suite 401
+ Buffalo, NY 14214
Email: ken at oceana.com
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 2495 Main St. - Suite 401
716-604-0088 x26 Buffalo, NY 14214
--PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
More information about the ietf-nntp
mailing list