Subject: [NNTP] AUTHINFO diffs

From: Ken Murchison <[email-masked]>
Date: Wed, 08 Jun 2005 13:09:37 -0400

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: [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: Wed, 08 Jun 2005 12:32:26 -0700

> *believe* is addresses all issues.  Please review.

Are we really okay with going back to the old DIGEST-MD5?  I thought the
SASL working group didn't really like that idea and would rather that we
wait up for the new revision.

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

---

From: Ken Murchison <[email-masked]>
Date: Wed, 08 Jun 2005 15:42:22 -0400

> wait up for the new revision.

Right, the suggestions are to wait for the updated DIGEST-MD5 or go with 
  TLS+PLAIN.  We just need to select at least one mandatory to implement 
(not necessarily mandatory to use) mechanism, so that two conforming 
implementations can always be configured to interoperate.

IMO, PLAIN is the simplest to implement, but this is going to then 
mandate that every implementation also supports TLS.  The only mechanism 
other than PLAIN or DIGEST-MD5 which we could mandate would probably be 
GSSAPI.

---

From: Russ Allbery <[email-masked]>
Date: Wed, 08 Jun 2005 13:13:55 -0700

> other than PLAIN or DIGEST-MD5 which we could mandate would probably be

I would rather not require TLS.  Adding SASL support is significantly
easier than adding TLS support.  Requiring GSSAPI feels like a non-starter
to me as well; some Cyrus SASL builds don't even include GSSAPI with the
default module set due to the other library dependencies.

This makes me think that we should probably wait for DIGEST-MD5, as much
as I dislike that.  :/  Do we have any feel for how long that delay is
going to be?

---

From: Ned Freed <[email-masked]>
Date: Wed, 08 Jun 2005 13:27:43 -0700 (PDT)

> I would rather not require TLS.

Agreed.

> Adding SASL support is significantly
> easier than adding TLS support.

Agreed as well. There are libraries available for both, but generally speaking
adding TLS  is a trickier proposition.

> Requiring GSSAPI feels like a non-starter

I'm not an NNTP implementor so I hesitate to call this a total nonstarter, but
GSSAPI certainly has proved to be a nonstarter for many implementations of
other protocols. (Poor library quality is part of this, but not all. GSSAPI is
simply too complex.)

> as I dislike that.  :/  Do we have any feel for how long that delay is

Well, there's already a draft (draft-ietf-sasl-rfc2831bis-05.txt, right?), so
don't have to wait to cite it. Unless the IESG has created even more procedural
folderol I'm unaware of, there should be no problem last-calling a document
with a normative reference to such a draft. Actual publication as an RFC would
have to wait for that reference to resolve, but having a draft that's in the
RFC Editor queue is where this WG's responsibility ends. If it makes sense for
a document to sit in that state for a while, so be it.

IMO only, of course.

				Ned

---

From: Ken Murchison <[email-masked]>
Date: Wed, 08 Jun 2005 16:41:22 -0400

> as I dislike that.  :/  Do we have any feel for how long that delay is

Not really, but I think it shouldn't drag on much past the next IETF.

I don't recall, will the base document block on AUTHINFO?  If not, then 
I'd say lets wait for DIGEST-MD5 and move base, TLS and STREAMING forward.

---

From: Russ Allbery <[email-masked]>
Date: Wed, 08 Jun 2005 13:42:42 -0700

> I'd say lets wait for DIGEST-MD5 and move base, TLS and STREAMING

The base document won't inherently; however, I don't really want to get
into the position that implementors add CAPABILITIES without adding
AUTHINFO.  But maybe implementors will be smart enough to figure that out.

---

From: "Jeffrey M. Vinocur" <[email-masked]>
Date: Wed, 8 Jun 2005 19:40:15 -0400

> +     0. Meta-information on this draft ...........................  2

What happens when section 0 is removed?  Does the RFC editor take 
responsibility for repaginating the text and updating the table of 
contents?

> +     Unrecognized arguments MUST be ignored by the client.

(We're talking here about the AUTHINFO capabilities line.)

I'm not sure I agree with this change.  Perhaps the user would like to 
be notified of new AUTHINFO methods.  Regardless, this is a user 
interface issue and not a protocol issue, so I'm skeptical of the 
appropriateness of dictating it.

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: Russ Allbery <[email-masked]>
Date: Wed, 08 Jun 2005 17:17:33 -0700

> I'm not sure I agree with this change.  Perhaps the user would like to be
> notified of new AUTHINFO methods.  Regardless, this is a user interface
> issue and not a protocol issue, so I'm skeptical of the appropriateness of
> dictating it.

Isn't bringing something to the attention of the user still allowed under
the conventional interpretation of "ignored by the client"?  I would tend
to read that as "ignored for protocol purposes," not implying that the
client can't take informational notice of them.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 08 Jun 2005 21:16:23 -0400

> responsibility for repaginating the text and updating the table of 

Either that, or the editor asks me to send a new version without sections 0.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 08 Jun 2005 21:17:18 -0400

> client can't take informational notice of them.

Is this a vote for leaving the change above as-is?

---

From: Russ Allbery <[email-masked]>
Date: Wed, 08 Jun 2005 18:19:05 -0700

>> Isn't bringing something to the attention of the user still allowed
>> under the conventional interpretation of "ignored by the client"?  I
>> would tend to read that as "ignored for protocol purposes," not
>> implying that the client can't take informational notice of them.

> Is this a vote for leaving the change above as-is?

Yes, I liked the change.  It seems cleaner to me this way.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 08 Jun 2005 21:27:17 -0400

> a document to sit in that state for a while, so be it.

Ned, thanks for the input.

This sounds like the most logical patch to take.  Unless I get off my 
ass and rewrite a PASSDSS-type SASL mechanism that we can try to fasttrack.

Just out of curiosity, what happens to the NNTP base doc, which has an 
informative reference to AUTHINFO, if AUTHINFO is sitting in the queue 
waiting for DIGEST-MD5 to resolve?

---

From: Ken Murchison <[email-masked]>
Date: Wed, 08 Jun 2005 21:39:30 -0400

> Either that, or the editor asks me to send a new version without 

Actually, maybe I'll just pull the note to the editor up before the TOC 
and remove sections 0 completely.

---

From: Ned Freed <[email-masked]>
Date: Wed, 08 Jun 2005 18:55:30 -0700 (PDT)

> waiting for DIGEST-MD5 to resolve?

Informative references don't need to resolve prior to publication. Normative
ones do. IMO this is the really important difference between the two, and the
one that needs to be taken into account when boundary cases arise.

				Ned

---

From: "Jeffrey M. Vinocur" <[email-masked]>
Date: Thu, 9 Jun 2005 06:12:32 -0400

On Jun 8, 2005, at 8:17 PM, Russ Allbery wrote:

> under
> the conventional interpretation of "ignored by the client"?

I...dunno.  Do we use "ignored" in this fashion elsewhere?  It doesn't 
seem intuitive to me.

> I would tend

Hrm.  Can the client use that information to trigger an automatic check 
for a new release and present that information to the user?  Can the 
client refuse to authenticate until the user acknowledges the notice?  
I see no reason we should prohibit either of these behaviors, but I'm 
hesitant to say they qualify as "ignoring" anything.

So, then, what's the actual meaning of the "Unrecognized..." sentence?  
Is there any protocol problem we're at risk here?  The "Future 
extensions..." sentence is useful, but what does the second sentence 
add?

-- 
Jeffrey M. Vinocur
[email-masked]

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Thu, 9 Jun 2005 11:39:11 +0100

Ken Murchison said:
> I don't recall, will the base document block on AUTHINFO?

I don't believe so; it's an informative reference, not a normative one.

> If not, then 

I'd like to see everything out at once, but I'd rather we didn't hold up
anything else over this.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Ken Murchison <[email-masked]>
Date: Thu, 09 Jun 2005 10:17:38 -0400

Jeffrey M. Vinocur wrote:

> extensions..." sentence is useful, but what does the second sentence add?

The second sentence is just telling the client that it shouldn't 
choke/crash/format-hard-drive if its sees an AUTHINFO option that it 
doesn't know about.  It should continue using those that it does know 
about, hence the "MUST ignore".

As far as reporting unrecognized options to the user, we're not 
preventing this at all.  All we're discussing in our document is the 
protocol, not user interaction.