[NNTP] AUTHINFO diffs

Ken Murchison ken at oceana.com
Wed Jun 8 10:09:37 PDT 2005


Here's the diffs between AUTHINFO-08 and what I currently have.  I 
*believe* is addresses all issues.  Please review.


--- authinfo-8.txt	2005-06-08 13:06:50.000000000 -0400
+++ authinfo-9.txt	2005-06-08 13:05:17.000000000 -0400
@@ -6,7 +6,7 @@

  NNTP Extensions Working Group                                 J. Vinocur
  Internet Draft                                        Cornell University
-Updates: 2970 (if approved)                                 K. Murchison
+Updates: 2980 (if approved)                                 K. Murchison
  Expires: December 2005                                Oceana Matrix Ltd.
                                                                 C. Newman
                                                          Sun Microsystems
@@ -14,7 +14,7 @@


                     NNTP Extension for Authentication
-                     draft-ietf-nntpext-authinfo-08
+                     draft-ietf-nntpext-authinfo-09


  Status of this memo
@@ -48,67 +48,86 @@
  Abstract

       This document defines an extension the Network News Transport
-     Protocol [NNTP] which allows a client to indicate an authentication
+     Protocol (NNTP) which allows a client to indicate an authentication
       mechanism to the server, perform an authentication protocol
       exchange, and optionally negotiate a security layer for subsequent
       protocol interactions during the remainder of an NNTP session.

-     Section 3.1 of [NNTP-COMMON] summarizes some ad-hoc authentication
-     methods currently used in the NNTP protocol.  This document updates
-     and formalizes the AUTHINFO USER/PASS authentication method and
-     deprecates the AUTHINFO SIMPLE and AUTHINFO GENERIC authentication
-     methods.  Additionally, this document defines a profile of the
-     Simple Authentication and Security Layer [SASL] for NNTP.
+     This document updates and formalizes the AUTHINFO USER/PASS
+     authentication method specified in RFC 2980 and deprecates the
+     AUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods.
+     Additionally, this document defines a profile of the Simple
+     Authentication and Security Layer (SASL) for NNTP.

  Table of Contents

-     0. Changes from Previous Version ............................  2
+     0. Meta-information on this draft ...........................  2
+        0.1. Changes from Previous Version .......................  3
+        0.2. Note to the RFC Editor ..............................  3
       1. Introduction .............................................  3
-        1.1. Conventions Used in this Document ...................  3
+        1.1. Conventions Used in this Document ...................  4
       2. The AUTHINFO Extension ...................................  4
          2.1. Advertising the AUTHINFO Extension ..................  4
-        2.2. Authenticating with the AUTHINFO Extension ..........  5
-        2.3. AUTHINFO USER/PASS Command ..........................  6
+        2.2. Authenticating with the AUTHINFO Extension ..........  6
+        2.3. AUTHINFO USER/PASS Command ..........................  7
             2.3.1. Usage ..........................................  7
-           2.3.2. Description ....................................  7
-           2.3.3. Examples .......................................  8
-        2.4. AUTHINFO SASL Command ...............................  9
-           2.4.1. Usage ..........................................  9
-           2.4.2. Description .................................... 10
-           2.4.3. Examples ....................................... 13
+           2.3.2. Description ....................................  8
+           2.3.3. Examples .......................................  9
+        2.4. AUTHINFO SASL Command ............................... 10
+           2.4.1. Usage .......................................... 10
+           2.4.2. Description .................................... 11
+           2.4.3. Examples ....................................... 14
       3. Augmented BNF Syntax for the AUTHINFO Extension .......... 16
          3.1. Commands ............................................ 16
-        3.2. Command Continuation ................................ 16
+        3.2. Command Continuation ................................ 17
          3.3. Responses ........................................... 17
          3.4. Capability entries .................................. 17
-        3.5. General non-terminals ............................... 17
-     4. Summary of Response Codes ................................ 17
-     5. Authentication Tracking/Logging .......................... 18
-     6. Security Considerations .................................. 18
-     7. IANA Considerations ...................................... 19
-        7.1. IANA Considerations for SASL/GSSAPI services ........ 19
-        7.2. IANA Considerations for NNTP extensions ............. 19
+        3.5. General non-terminals ............................... 18
+     4. Summary of Response Codes ................................ 18
+     5. Authentication Tracking/Logging .......................... 19
+     6. Security Considerations .................................. 19
+     7. IANA Considerations ...................................... 20
+        7.1. IANA Considerations for SASL/GSSAPI services ........ 20
+        7.2. IANA Considerations for NNTP extensions ............. 20
       8. References ............................................... 21
          8.1. Normative References ................................ 21
-        8.2. Informative References .............................. 21
+        8.2. Informative References .............................. 22
       9. Authors' Addresses ....................................... 22
-     10. Acknowledgments ......................................... 22
+     10. Acknowledgments ......................................... 23
       11. Intellectual Property Rights ............................ 23
-     12. Copyright ............................................... 23
+     12. Copyright ............................................... 24

-0. Changes from Previous Version
+0. Meta-information on this draft
+
+0.1. Changes from Previous Version

       Changed:
-     o  Updated to RFC 3978/3979 boilerplate.
-     o  Uses new ABNF tokens from [NNTP].
-     o  Fixed a typo in note regarding AUTHINFO SASL and 480 response.
-     o  Section 6: Sync'd language with [NNTP-TLS].
+     o  Removed references from Abstract.
+     o  Replaced I-Ds in References with RFCs.
+     o  Made [UTF-8] normative instead of informative.

       Clarified:
-     o  Section 3: This document extends the ABNF in [NNTP], and the
-        [NNTP] ABNF must be imported first before validating the
-        AUTHINFO ABNF (based on recommendations of AD regarding
-        IMAPEXT I-Ds).
+     o  Added paragraph to 2.3.2 (copied from section 2.4.2) describing
+        success and failure response for AUTHINFO USER/PASS.
+     o  Referenced [NNTP] for 483, 502 and 504 response codes.
+
+     Other:
+     o  Added note to RFC Editor regarding References.
+     o  Miscellaneous editorial changes.
+
+0.2. Note to the RFC Editor
+
+     The normative references to RFC 2234, RFC 2831, RFC 2222, and RFC 3454
+     and the informative references to RFC 2195, RFC 2222, and RFC 2595 
may be
+     replaced by draft-crocker-abnf-rfc2234bis, draft-ietf-sasl-rfc2831bis,
+     draft-ietf-sasl-rfc2222bis, draft-hoffman-rfc3454bis,
+     draft-ietf-sasl-crammd5, draft-ietf-sasl-gssapi, draft-ietf-sasl-plain
+     respectively should any or all of those documents reach RFC status
+     before this one.
+
+     The normative references to [NNTP] and [NNTP-TLS] are documents which
+     are expected to be published simultaneously with this one and so can
+     be replaced by references to the resulting RFCs.

  1. Introduction

@@ -196,7 +215,7 @@
       capability is followed by a whitespace-separated list of available
       SASL mechanism names.

-     The server may list the AUTHINFO capability with no arguments,
+     The server MAY list the AUTHINFO capability with no arguments,
       which indicates that it complies with this specification and does
       not permit any authentication commands in its current state.  In
       this case, the client MUST NOT attempt to utilize any AUTHINFO
@@ -205,12 +224,12 @@
       specification).

       Future extensions may add additional arguments to this capability.
-     Unrecognized arguments SHOULD be ignored or brought to the
-     attention of the user.
+     Unrecognized arguments MUST be ignored by the client.

       As the AUTHINFO command is related to security, cached results of
       CAPABILITIES from a previous session MUST NOT be relied on, as per
-     section 12.6 of [NNTP].
+     section 12.6 of [NNTP].  However, a client MAY use such cached
+     results in order to detect active down-negotiation attacks.

       Example (here, the STARTTLS extension [NNTP-TLS] is also in use):

@@ -356,6 +375,14 @@
       on the username.  Thus the same server can respond with both 381
       and other response codes to AUTHINFO USER.

+     Should the client successfully present proper credentials, the
+     server issues a 281 reply.  If the server is unable to authenticate
+     the client, it MUST reject the AUTHINFO USER/PASS command with a
+     481 reply.  If an AUTHINFO USER/PASS command fails, the client MAY
+     proceed without authentication.  Alternatively, the client MAY try
+     another authentication mechanism, or present different credentials
+     by issuing another AUTHINFO command.
+
       The AUTHINFO PASS command permits the client to use a clear-text
       password to authenticate.  A compliant implementation MUST NOT
       implement this command without also implementing support for TLS
@@ -367,7 +394,7 @@
       by [NNTP-TLS] is not active, and this configuration SHOULD be the
       default.  The server will use the 483 response code to indicate
       that the datastream is insufficiently secure for the command being
-     attempted.
+     attempted (see section 3.2.1 of [NNTP]).

       Usernames and passwords MUST use the UTF-8 [UTF-8] character set
       and a client MUST convert any user input to UTF-8 if necessary.
@@ -478,9 +505,11 @@
       Optionally, it also negotiates a security layer for subsequent
       protocol interactions during this session.  If the requested
       authentication mechanism is invalid (e.g. is not supported), the
-     server rejects the AUTHINFO SASL command with a 503 reply.  If the
-     requested authentication mechanism requires an encryption layer,
-     the server rejects the AUTHINFO SASL command with a 483 reply.
+     server rejects the AUTHINFO SASL command with a 503 reply (see
+     section 3.2.1 of [NNTP]).  If the requested authentication
+     mechanism requires an encryption layer, the server rejects the
+     AUTHINFO SASL command with a 483 reply (see section 3.2.1 of
+     [NNTP]).

       The service name specified by this protocol's profile of SASL is
       "nntp".
@@ -545,14 +574,14 @@
       with a 482 reply.

       If the server cannot [BASE64] decode any client response, it MUST
-     reject the AUTHINFO SASL command with a 504 reply.  If the client
-     cannot BASE64 decode any of the server's challenges, it MUST cancel
-     the authentication using the "*" response.  In particular, servers
-     and clients MUST reject (and not ignore) any character not
-     explicitly allowed by the BASE64 alphabet, and MUST reject any
-     sequence of BASE64 characters that contains the pad character ('=')
-     anywhere other than the end of the string (e.g. "=AAA" and
-     "AAA=BBB" are not allowed).
+     reject the AUTHINFO SASL command with a 504 reply (see section
+     3.2.1 of [NNTP]).  If the client cannot BASE64 decode any of the
+     server's challenges, it MUST cancel the authentication using the
+     "*" response.  In particular, servers and clients MUST reject (and
+     not ignore) any character not explicitly allowed by the BASE64
+     alphabet, and MUST reject any sequence of BASE64 characters that
+     contains the pad character ('=') anywhere other than the end of the
+     string (e.g. "=AAA" and "AAA=BBB" are not allowed).

       The authorization identity generated by this [SASL] exchange is a
       simple username, and both client and server MUST use the [SASLprep]
@@ -984,9 +1013,9 @@
       [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
       Encodings", RFC 3548, July 2003.

-     [DIGEST-MD5] Leach, P., Newman, C., Melnikov, A.,
+     [DIGEST-MD5] Leach, P., Newman, C.,
       "Using Digest Authentication as a SASL Mechanism",
-     draft-ietf-sasl-rfc2831bis-*.txt, Work in Progress.
+     RFC 2831, May 2000.

       [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
       Requirement Levels", BCP 14, RFC 2119, March 1997.
@@ -998,36 +1027,37 @@
       "Using TLS with NNTP", draft-ietf-nntpext-tls-nntp-*.txt,
       Work in Progress.

-     [SASL] Melnikov, A., "Simple Authentication and Security Layer
-     (SASL)", draft-ietf-sasl-rfc2222bis-*.txt, Work in Progress.
+     [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)",
+     RFC 2222, October 1997.

       [SASLprep] Zeilega, K., "SASLprep: Stringprep Profile for
       User Names and Passwords", RFC 4013, February 2005.

       [StringPrep] Hoffman, P. and Blanchet, M., "Preparation of
       Internationalized Strings ("stringprep")",
-     draft-hoffman-rfc3454bis-*.txt, Work in Progress.
+     RFC 3454, December 2002.
+
+     [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", RFC
+     3629, November 2003.

  8.2. Informative References

-     [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism",
-     draft-ietf-sasl-crammd5-*.txt, Work in Progress.
+     [CRAM-MD5] Klensin, J., Catoe, R., Krumviede, P., "IMAP/POP
+     AUTHorize Extension for Simple Challenge/Response", RFC 2195,
+     September 1997.

-     [GSSAPI] Melnikov, A., "SASL GSSAPI Mechanisms",
-     draft-ietf-sasl-gssapi-*.txt, Work in Progress.
+     [GSSAPI] Myers, J., "Simple Authentication and Security Layer
+     (SASL)", RFC 2222, October 1997.

       [NNTP-COMMON] Barber, S., "Common NNTP Extensions", RFC 2980,
       October 2000.

-     [PLAIN] Zeilenga, K., "The Plain SASL Mechanism",
-     draft-ietf-sasl-plain-*.txt, Work in Progress.
+     [PLAIN] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
+     June 1999.

       [SMTP] Klensin, J., "Simple Mail Transport Protocol", RFC 2821,
       April 2001.

-     [UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646",
-     RFC 3629, November 2003.
-
  9. Authors' Addresses

       Jeffrey M. Vinocur
@@ -1052,7 +1082,7 @@
       1050 Lakes Drive, Suite 250
       West Covina, CA 91790 USA

-     Email: cnewman at iplanet.com
+     Email: Chris.Newman at sun.com

  10. Acknowledgments


-- 
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