[ietf-nntp] authinfo-02 changes
Ken Murchison
ken at oceana.com
Tue Jul 6 08:51:11 PDT 2004
Attached are the changes I just made to the AUTHINFO draft based on
comments from the list and those I received privately. I did a diff
against the nroff rather than the generated text, since the nroff isn't
subject to changes in page breaks. Please review and let me know if
I've missed anything.
--
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
-------------- next part --------------
Index: nntpauth.ms
===================================================================
RCS file: /home/jeff/cvsroot/nntpauth/nntpauth.ms,v
retrieving revision 1.38
diff -u -r1.38 nntpauth.ms
--- nntpauth.ms 17 Jun 2004 09:47:34 -0000 1.38
+++ nntpauth.ms 6 Jul 2004 15:47:10 -0000
@@ -32,7 +32,7 @@
.br
.tl 'Network Working Group''J. Vinocur'
.tl 'Internet Draft''Cornell University'
-.tl 'Document: draft-ietf-nntpext-authinfo-01.txt''C. Newman'
+.tl 'Document: draft-ietf-nntpext-authinfo-02.txt''C. Newman'
.tl '''Sun Microsystems'
.tl '''K. Murchison'
.tl '''Oceana Matrix Ltd.'
@@ -98,14 +98,15 @@
5. Authentication Tracking/Logging .......................... 15
6. Security Considerations .................................. 16
7. IANA Considerations ...................................... 16
- 7.1. IANA Considerations for SASL/GSSAPI services ........ 17
- 7.2. IANA Considerations for NNTP extensions ............. 17
-8. Normative References ..................................... 18
-9. Informative References ................................... 19
-10. Authors' Addresses ...................................... 19
-11. Acknowledgments ......................................... 19
-12. Intellectual Property Rights ............................ 20
-13. Copyright ............................................... 20
+ 7.1. IANA Considerations for SASL/GSSAPI services ........ 16
+ 7.2. IANA Considerations for NNTP extensions ............. 16
+8. References ............................................... 18
+ 8.1. Normative References ................................ 18
+ 8.2. Informative References .............................. 18
+9. Authors' Addresses ....................................... 19
+10. Acknowledgments ......................................... 19
+11. Intellectual Property Rights ............................ 19
+12. Copyright ............................................... 20
.fi
.LP
1. Introduction
@@ -172,8 +173,8 @@
The "USER" argument indicates that AUTHINFO USER/PASS is supported as
defined by Section 2.1 of this document. The "USER" argument MUST NOT
be advertised, and the AUTHINFO USER/PASS commands SHOULD NOT be provided,
-unless a strong encryption layer (e.g. TLS [NNTP-TLS])
-is in use or backward compatibility dictates otherwise.
+unless a strong encryption layer (e.g. TLS [NNTP-TLS]) is in use or
+backward compatibility dictates otherwise.
The "SASL:" argument indicates that AUTHINFO SASL is supported as
defined by Section 2.2 of this document. The "SASL:" argument is
@@ -291,7 +292,10 @@
482 Authentication commands issued out of sequence
.fi
.IP
-[1] Only valid for AUTHINFO USER.
+[1] Only valid for AUTHINFO USER. Note that unlike traditional 3xx
+codes which indicate that the client may continue the current command,
+the legacy 381 code means that the AUTHINFO PASS command must be used
+to complete the authentication exchange.
.IP
Parameters
.in 8
@@ -338,8 +342,7 @@
The AUTHINFO PASS command permits the client to use a clear-text
password to authenticate. A compliant implementation MUST NOT
implement this mechanism without also implementing support for TLS
-[NNTP-TLS] or the DIGEST-MD5 SASL [DIGEST-MD5] authentication
-mechanism. Use of this mechanism without an active strong encryption
+[NNTP-TLS]. Use of this mechanism without an active strong encryption
layer is deprecated as it exposes the user's password to all parties
on the network between the client and the server. Any implementation
of this mechanism SHOULD be configurable to disable it unless a strong
@@ -351,12 +354,13 @@
Usernames and passwords MUST use the UTF-8 [UTF-8] character set and
client MUST convert any user input to UTF-8 if necessary.
-Note that usernames and passwords containing whitespace are quite likely
-not to work as desired, due to the command argument syntax [NNTP]. (A
-client may wish to scan the username and password for whitespace, and
-if detected, warn the user of the likelihood of problems.) The SASL
-PLAIN [PLAIN] mechanism is recommended as an alternative, as it is
-more robust with regard to character set.
+Note that usernames and passwords containing whitespace are allowed,
+but may not work correctly with servers which blindly split command
+arguments at whitespace. A client may wish to scan the username and
+password for whitespace, and if detected, warn the user of the
+likelihood of problems. The SASL PLAIN [PLAIN] mechanism is
+recommended as an alternative, as it is more robust with regard to
+character set.
.LP
.ne 3
2.1.3. Examples
@@ -415,17 +419,17 @@
Syntax
.in 8
.nf
-AUTHINFO SASL sasl-mech-name [sasl-init-resp]
+AUTHINFO SASL mechanism [initial-response]
.fi
.IP
Responses
.in 8
.nf
-281 Authentication accepted
-283 sasl-server-chal Authentication accepted (with success data) [1]
-383 sasl-server-chal Continue with SASL exchange [1]
-481 Authentication failed/rejected
-482 SASL protocol error
+281 Authentication accepted
+283 challenge Authentication accepted (with success data) [1]
+383 challenge Continue with SASL exchange [1]
+481 Authentication failed/rejected
+482 SASL protocol error
.fi
.IP
[1] These responses MAY exceed 512 octets. The maximum length of
@@ -436,12 +440,13 @@
Parameters
.in 8
.nf
-sasl-mech-name = String identifying a [SASL] authentication mechanism
-sasl-init-resp = Optional initial client response. If present, the
- response MUST be encoded as specified in Section 3
- of [BASE64].
-sasl-server-chal = Server challenge. The challenge MUST be encoded as
- specified in Section 3 of [BASE64].
+mechanism = String identifying a [SASL] authentication
+ mechanism.
+initial-response = Optional initial client response. If present,
+ the response MUST be encoded as specified in
+ Section 3 of [BASE64].
+challenge = Server challenge. The challenge MUST be
+ encoded as specified in Section 3 of [BASE64].
.fi
.LP
.ne 3
@@ -473,14 +478,15 @@
A server challenge is sent as a 383 reply with a single argument
containing the [BASE64] encoded string supplied by the SASL
mechanism. If the server challenge has zero length, it MUST instead
-be sent as a single equals sign ("="), making the complete response
-"383 =".
+be sent as a single equals sign ("="), to indicate its presence and
+separate it from any trailing text.
A client response consists of a line containing a [BASE64] encoded
-string. If the client wishes to cancel the authentication exchange,
-it issues a line with a single "*". If the server receives such a
-response, it MUST reject the AUTHINFO SASL command by sending a 481
-reply.
+string. If the client response has zero length, it MUST instead be
+sent as a single equals sign ("="). If the client wishes to cancel
+the authentication exchange, it issues a line with a single "*". If
+the server receives such a response, it MUST reject the AUTHINFO SASL
+command by sending a 481 reply.
Note that these [BASE64] strings can be much longer than normal NNTP
responses. Clients and servers MUST be able to handle the maximum
@@ -513,7 +519,7 @@
reply.
If the server cannot [BASE64] decode any client response, it MUST
-reject the AUTHINFO SASL command with a 482 reply. If the client
+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
@@ -560,11 +566,11 @@
After a security layer is established, the server MUST continue to
advertise the AUTHINFO capability and "SASL:" argument (with the same
mechanism list as before authentication) and SHOULD NOT advertise the
-STARTTLS [NNTP-TLS] capability.
+STARTTLS [NNTP-TLS] capability (as STARTTLS is not allowed after
+authentication).
-When both [TLS] and SASL security layers are in effect, the TLS
-encoding MUST be applied after the SASL encoding, regardless of the
-order in which the layers were negotiated.
+When both TLS [NNTP-TLS] and SASL security layers are in effect, the
+TLS encoding MUST be applied after the SASL encoding.
To ensure interoperability, client and server implementations of this
extension MUST implement the [DIGEST-MD5] SASL mechanism.
@@ -670,7 +676,7 @@
[C] AUTHINFO SASL GSSAPI
[S] 383 =
[C] *
-[S] 481 Sequence successfully aborted
+[S] 481 Authentication aborted as requested
.fi
.IP
Example of attempting to use a mechanism that is not supported by the
@@ -718,12 +724,12 @@
authinfo-user-command = "AUTHINFO" WS "USER" WS username
authinfo-pass-command = "AUTHINFO" WS "PASS" WS password
-authinfo-sasl-command = "AUTHINFO" WS "SASL" WS sasl-mech-name
- [WS sasl-init-resp]
+authinfo-sasl-command = "AUTHINFO" WS "SASL" WS mechanism
+ [WS initial-response]
-username = 1*P-CHAR
-password = 1*P-CHAR
-sasl-init-resp = "=" / base64
+username = 1*(P-CHAR / SP / TAB)
+password = 1*(P-CHAR / SP / TAB)
+initial-response = base64-opt
.fi
.LP
3.2. Command Continuation
@@ -734,10 +740,9 @@
.IP
.nf
command-continuation /= authinfo-sasl-continuation
-authinfo-sasl-continuation = *([sasl-client-resp] CRLF)
- ; client waits for a "383" response from the server before
- ; sending each line
-sasl-client-resp = "*" / base64
+authinfo-sasl-continuation = ("*" / base64-opt) CRLF
+ ; client must send a continuation following each
+ ; "383" response from the server
.fi
.LP
3.3. Responses
@@ -746,9 +751,8 @@
various commands in this specification.
.IP
.nf
-simple-response-content /= response-x83-content
-response-x83-content = ("283" / "383") SP sasl-server-chal
-sasl-server-chal = "=" / base64
+simple-response-content /= response-sasl-content
+response-sasl-content = "283" SP base64 / "383" SP base64-opt
.fi
.LP
3.4. LIST EXTENSIONS responses
@@ -761,21 +765,18 @@
authinfo-extension = %x41.55.54.48.49.4E.46.4F ; "AUTHINFO"
*(SPA authinfo-extension-arg)
authinfo-extension-arg = "USER" /
- "SASL:" [sasl-mech-name *("," sasl-mech-name)]
+ "SASL:" [mechanism *("," mechanism)]
.fi
.LP
3.5. General non-terminals
.IP
.nf
-sasl-mech-name = 1*20sasl-mech-char
-sasl-mech-char = %x41-5A / DIGIT / "-" / "_"
+mechanism = 1*20mech-char
+mech-char = UPPER / DIGIT / "-" / "_"
; mechanism names restricted to uppercase letters,
; digits, "-" and "_"
-base64 = *(4base64-char) [base64-terminal]
-base64-terminal = 2base64-char "==" / 3base64-char "="
-base64-char = UPPER / LOWER / DIGIT / "+" / "/"
-LOWER = %x61-7A
+base64-opt = "=" / base64
.fi
.LP
4. Summary of Response Codes
@@ -795,7 +796,7 @@
.in 8
.nf
Generated by: AUTHINFO SASL
-1 argument: sasl-server-chal
+1 argument: challenge
Meaning: authentication accepted (with success data)
.fi
.IP
@@ -803,14 +804,16 @@
.in 8
.nf
Generated by: AUTHINFO USER
-Meaning: password required
+Meaning: password required via AUTHINFO PASS command. Note that this
+code is used for backwards compatibility and does not conform to the
+traditional use of 3xx codes.
.fi
.IP
Response code 383
.in 8
.nf
Generated by: AUTHINFO SASL
-1 argument: sasl-server-chal
+1 argument: challenge
Meaning: continue with SASL exchange
.fi
.IP
@@ -831,30 +834,12 @@
.LP
5. Authentication Tracking/Logging
.IP
-This section contains implementation suggestions and
-notes of best current practice, and does not specify further network
-protocol requirements.
-
-When authentication succeeds, the server will create an "identity" (the
-syntax resembles that of an email address) for the client using a
-technique such as the following (note that when using SASL, "username"
-corresponds to the authorization identity), for example:
+This section contains implementation suggestions and notes of best
+current practice, and does not specify further network protocol
+requirements.
-.in 9
-.ti 5
-(1) Lookup the supplied username in an implementation-specific database
-or directory to determine the primary email address for that user.
-.ti 5
-(2) Use the username directly as the email address if it is fully
-qualified (i.e., includes "@hostname"), otherwise append a configured
-"default domain" based on the IP address the client connected to.
-.ti 5
-(3) Use the username followed by "@" and then the result of a reverse
-DNS lookup on the client's IP address. If the reverse lookup fails, the
-domain literal syntax defined in SMTP [SMTP] is appropriate.
-.IP
Once authenticated, the server SHOULD be configurable to generate an
-audit trail associating the authentication identity with any articles
+audit trail associating the authorization identity with any articles
supplied during a POST operation, and this configuration SHOULD be the
default. This may be accomplished, for example, by inserting headers in
the posted articles, or by a server logging mechanism. The server MAY
@@ -885,7 +870,7 @@
When multiple authentication mechanisms are permitted by both client and
server, an active attacker can cause a down-negotiation to the weakest
mechanism. For this reason, both clients and servers SHOULD be
-configurable to forbid use of weaker mechanisms.
+configurable to forbid use of weak mechanisms.
.LP
7. IANA Considerations
.LP
@@ -963,8 +948,10 @@
o The AUTHINFO commands can be used before or after the MODE READER
command, with the same semantics.
.LP
+8. References
+.LP
.ne 4
-8. Normative References
+8.1. Normative References
.IP
.nf
.ne 2
@@ -1007,14 +994,10 @@
[StringPrep] Hoffman, P. and Blanchet, M., "Preparation of
Internationalized Strings ("stringprep")",
draft-hoffman-rfc3454bis-*.txt, Work in Progress.
-
-.ne 2
-[UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", RFC
-2279, Alis Technologies, January 1998.
.fi
.LP
.ne 4
-9. Informative References
+8.2. Informative References
.IP
.ne 2
[CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism",
@@ -1032,13 +1015,17 @@
[PLAIN] Zeilenga, K., "The Plain SASL Mechanism",
draft-ietf-sasl-plain-*.txt, Work in Progress.
-.ne 1
+.ne 2
[SMTP] Klensin, J., "Simple Mail Transport Protocol", RFC 2821, AT&T
Laboratories, April 2001.
+
+.ne 2
+[UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646", RFC
+3629, Alis Technologies, Novermber 2003.
.fi
.LP
.ne 3
-10. Authors' Addresses
+9. Authors' Addresses
.IP
.nf
Jeffrey M. Vinocur
@@ -1067,7 +1054,7 @@
.fi
.LP
.ne 4
-11. Acknowledgments
+10. Acknowledgments
.IP
A significant amount of the authentication text was originally from the
NNTP revision or common authentication specs written by Stan Barber. A
@@ -1080,7 +1067,7 @@
continual (yet sporadic) insight in discussion.
.LP
.ne 4
-12. Intellectual Property Rights
+11. Intellectual Property Rights
.IP
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
@@ -1103,7 +1090,7 @@
Director.
.LP
.ne 4
-13. Copyright
+12. Copyright
.IP
Copyright (C) The Internet Society (2004). All Rights Reserved.
More information about the ietf-nntp
mailing list