Subject: [NNTP] Proposed changes to AUTHINFO-09

From: Ken Murchison <[email-masked]>
Date: Tue, 02 Aug 2005 12:40:20 -0400

Based on comments from the list and Russ' suggestions, here is my 
current diff for AUTHINFO.

--- nntpauth-09.txt	2005-08-02 12:36:43.000000000 -0400
+++ nntpauth-10.txt	2005-08-02 12:36:50.000000000 -0400
@@ -14,7 +14,7 @@

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

  Status of this memo
@@ -47,7 +47,7 @@

  Abstract

-     This document defines an extension the Network News Transport
+     This document defines an extension to the Network News Transport
       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
@@ -61,12 +61,9 @@

  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
+     The normative references to RFC 2234 and RFC 3454 may
+     be replaced by draft-crocker-abnf-rfc2234bis and
+     draft-hoffman-rfc3454bis respectively should one or both of those
       documents reach RFC status before this one.

       The normative references to [NNTP] and [NNTP-TLS] are documents
@@ -90,7 +87,7 @@
             2.4.3. Examples ....................................... 13
       3. Augmented BNF Syntax for the AUTHINFO Extension .......... 16
          3.1. Commands ............................................ 16
-        3.2. Command Continuation ................................ 17
+        3.2. Command Continuation ................................ 16
          3.3. Responses ........................................... 17
          3.4. Capability entries .................................. 17
          3.5. General non-terminals ............................... 17
@@ -99,12 +96,12 @@
       6. Security Considerations .................................. 18
       7. IANA Considerations ...................................... 19
          7.1. IANA Considerations for SASL/GSSAPI services ........ 19
-        7.2. IANA Considerations for NNTP extensions ............. 20
+        7.2. IANA Considerations for NNTP extensions ............. 19
       8. References ............................................... 21
          8.1. Normative References ................................ 21
          8.2. Informative References .............................. 22
       9. Authors' Addresses ....................................... 22
-     10. Acknowledgments ......................................... 23
+     10. Acknowledgments ......................................... 22
       11. Intellectual Property Rights ............................ 23
       12. Copyright ............................................... 23

@@ -319,8 +316,8 @@
       return 480 in response to AUTHINFO USER/PASS.

       Parameters
-        username = UTF-8 string identifying the user/client
-        password = UTF-8 string representing the user's password
+        username = octet string identifying the user/client
+        password = octet string representing the user's password

  2.3.2. Description

@@ -375,9 +372,6 @@
       that the datastream is insufficiently secure for the command being
       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.
-
       Note that a server MAY, but is not required to, allow white space
       characters in usernames and passwords.  A server implementation MAY
       blindly split command arguments at white space and therefore not
@@ -388,6 +382,13 @@
       recommended as an alternative, as it does not suffer from these
       issues.

+     Also note that historically the username is not canonicalized in
+     any way.  Clients and servers MAY use the [SASLprep] profile of the
+     [StringPrep] algorithm to prepare usernames for transmission or
+     comparison, but doing so may cause interoperability problems with
+     legacy implementations.  If canonicalization is desired, the SASL
+     PLAIN [PLAIN] mechanism is recommended as an alternative.
+
  2.3.3. Examples

       Example of successful AUTHINFO USER:
@@ -759,7 +760,7 @@
       initial-response = base64-opt
       username = 1*user-pass-char
       password = 1*user-pass-char
-     user-pass-char = P-CHAR
+     user-pass-char = B-CHAR

       NOTE: A server implementation MAY parse AUTHINFO USER and AUTHINFO
@@ -914,8 +915,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 <[email-masked]>.

  7.2. IANA Considerations for NNTP extensions

@@ -994,20 +996,21 @@

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

       [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
       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.

       [NNTP-TLS] Murchison, K., Vinocur, J., Newman, C.,
-     "Using TLS with NNTP", draft-ietf-nntpext-tls-nntp-*.txt,
+     "Using TLS with NNTP", draft-ietf-nntpext-tls-nntp-*,
       Work in Progress.

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

       [SASLprep] Zeilega, K., "SASLprep: Stringprep Profile for
       User Names and Passwords", RFC 4013, February 2005.
@@ -1016,23 +1019,19 @@
       Internationalized Strings ("stringprep")",
       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] Klensin, J., Catoe, R., Krumviede, P., "IMAP/POP
-     AUTHorize Extension for Simple Challenge/Response", RFC 2195,
-     September 1997.
+     [CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", draft-
+     ietf-sasl-crammd5-*, Work in Progress.

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

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

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

       [SMTP] Klensin, J., "Simple Mail Transport Protocol", RFC 2821,
       April 2001.
@@ -1050,8 +1049,8 @@

       Kenneth Murchison
       Oceana Matrix Ltd.
-     21 Princeton Place
-     Orchard Park, NY 14127 USA
+     2495 Main St, Suite 401
+     Buffalo, NY  14214 USA

       Email: [email-masked]

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

---

From: Ken Murchison <[email-masked]>
Date: Mon, 08 Aug 2005 13:14:02 -0400

Does "octet string" sound right, or should I change this to "string of 
octets", or simply "string"?

---

From: Russ Allbery <[email-masked]>
Date: Mon, 08 Aug 2005 10:26:40 -0700

> octets", or simply "string"?

It sounds fine to me.

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