[NNTP] Proposed changes to AUTHINFO-09
Ken Murchison
ken at oceana.com
Tue Aug 2 09:40:20 PDT 2005
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 <iesg at ietf.org>.
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: 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