Subject: [NNTP] AUTHINFO diffs (take 2)

From: Ken Murchison <[email-masked]>
Date: Thu, 09 Jun 2005 11:13:40 -0400

Here are updated diffs.  I've removed sections 0, and moved the note to 
the RFC editor up above the TOC.  I've also gone back to using 
draft-ietf-sasl-rfc2831bis as normative.

As soon as I get a thumbs up from Russ, I'll submit it.

--- authinfo-8.txt	2005-06-08 13:06:50.000000000 -0400
+++ authinfo-9.txt	2005-06-09 10:56:03.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,28 +48,40 @@
  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.
+
+Note to the RFC Editor
+
+     The normative references to RFC 2234, 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-rfc2222bis, draft-hoffman-rfc3454bis,
+     draft-ietf-sasl-crammd5, draft-ietf-sasl-gssapi, and
+     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.

  Table of Contents

-     0. Changes from Previous Version ............................  2
       1. Introduction .............................................  3
          1.1. Conventions Used in this Document ...................  3
       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.3.1. Usage ..........................................  7
+           2.3.1. Usage ..........................................  6
             2.3.2. Description ....................................  7
             2.3.3. Examples .......................................  8
          2.4. AUTHINFO SASL Command ...............................  9
@@ -78,7 +90,7 @@
             2.4.3. Examples ....................................... 13
       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
@@ -87,29 +99,15 @@
       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
+        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

-0. 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].
-
-     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).
-
  1. Introduction

       Although NNTP [NNTP] has traditionally been used to provide public
@@ -196,7 +194,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 +203,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 +354,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 +373,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 +484,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 +553,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]
@@ -998,36 +1006,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 +1061,7 @@
       1050 Lakes Drive, Suite 250
       West Covina, CA 91790 USA

-     Email: [email-masked]
+     Email: [email-masked]

  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

---

From: Russ Allbery <[email-masked]>
Date: Thu, 09 Jun 2005 10:20:27 -0700

> As soon as I get a thumbs up from Russ, I'll submit it.

The only remaining concern that I have is that recent IETF traffic and
comments from Sam Hartman lead me to wonder if CRAM-MD5 is something that
we shouldn't be mentioning.  Apparently, it's vulnerable to MITM attacks
and doesn't really make the security community happy.

Our only references to it are as an example of another auth mechanism, as
near as I can tell.  Maybe we should use GSSAPI for that example instead
of CRAM-MD5?

It's not a big deal since it's just an example and an informative
reference, but I don't know if it might be better to be safe.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Ken Murchison <[email-masked]>
Date: Thu, 09 Jun 2005 14:20:26 -0400

> reference, but I don't know if it might be better to be safe.

The only problem is that CRAM-MD5 is the only mainstream SASL mechanism 
which doesn't support an initial response, so unless I make something 
up, we're stuck with it.  We're not endorsing or recommending its use, 
so I think we're safe.

---

From: Russ Allbery <[email-masked]>
Date: Thu, 09 Jun 2005 11:25:51 -0700

> up, we're stuck with it.  We're not endorsing or recommending its use,

Okay, that works.  Go ahead and submit.  Thanks!

---

From: Ken Murchison <[email-masked]>
Date: Thu, 09 Jun 2005 14:34:14 -0400

> Okay, that works.  Go ahead and submit.  Thanks!

Done.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 09 Jun 2005 14:35:19 -0400

>  > Okay, that works.  Go ahead and submit.  Thanks!

Clicked too early.  Here is a link to the doc:

ftp://ftp.oceana.com/pub/drafts/draft-ietf-nntpext-authinfo-09.txt