draft-ietf-nntpext-base-03.txt some comments
Chris Newman
Chris.Newman at INNOSOFT.COM
Fri Jan 16 15:26:58 PST 1998
On Thu, 15 Jan 1998, Nat Ballou (Exchange) wrote:
> One of the things discussed in DC was how a client could
> get a list of authenticators from the server. Current
> practice with shipping NNTP servers is to allow an
> 'AUTHINFO GENERIC' command (no arguments) and have the
> server return a CR/LF separated list of authentication
> packages, terminated with CRLF.CRLF.
>
> Comments?
Not a great idea, IMHO -- that's likely to add an extra round trip to the
usual startup procedure:
S: greeting
C: ask for capabilities
S: return capabilities
C: ask for authentication mechanisms
S: return authentication mechanisms
C: begin authentication
S: ...
I think it's much better to fold the authentication list into the general
capabilities list as is proposed for SMTP:
draft-myers-smtp-auth-09.txt
I'm attaching my proposed changes to this message.
- Chris
-------------- next part --------------
*** draft-ietf-nntpext-base-02.txt Fri Dec 5 09:25:20 1997
--- nntpsasl.txt Fri Dec 19 18:23:56 1997
***************
*** 580,585 ****
--- 580,593 ----
402.
+ 8.1.6 List of SASL mechanisms
+
+ Servers MUST list the available SASL mechanisms [8] suitable
+ for use in AUTHINFO GENERIC. This is represented as a
+ "SASL=" capability followed by a space separated list of
+ SASL authentication mechanisms.
+
+
9. The AUTHENTICATION Step
9.1 AUTHINFO
***************
*** 590,596 ****
required to accept authentication information that is
volunteered by the client. Clients MUST accommodate servers
that reject any authentication information volunteered by the
! client.
--- 598,608 ----
required to accept authentication information that is
volunteered by the client. Clients MUST accommodate servers
that reject any authentication information volunteered by the
! client. When a server requires authentication it MUST
! send a 450 response to any command except the AUTHINFO
! command. A client MUST respond to this with an AUTHINFO
! GENERIC response. If the AUTHINFO GENERIC response fails,
! then the client MAY fall back to using AUTHINFO USER.
***************
*** 600,610 ****
AUTHINFO PASS password
! When authorization is required, the server MUST send a 450
! response requesting authorization from the client. The client
! MUST enter AUTHINFO USER username in order to make use of the
! AUTHINFO authentication step. If the server will accept this
! form of authentication and a password is required to complete
the authentication step, the server MUST respond with a 350
response. The client MUST then send AUTHINFO PASS followed by
one or more space characters followed by the password. If the
--- 612,627 ----
AUTHINFO PASS password
! Support for AUTHINFO USER and AUTHINFO PASS is optional
! for both client and server implementations. Due to the
! danger of plaintext passwords, servers which implement
! this SHOULD be configurable to disable its use and MAY
! include the ability to automatically transition users to
! the CRAM-MD5 mechanism [9] when they first use AUTHINFO
! PASS.
!
! If the server will accept AUTHINFO USER authentication and
! a password is required to complete
the authentication step, the server MUST respond with a 350
response. The client MUST then send AUTHINFO PASS followed by
one or more space characters followed by the password. If the
***************
*** 645,685 ****
9.1.2 AUTHINFO GENERIC
! AUTHINFO GENERIC authenticator arguments...
! AUTHINFO GENERIC is used to identify a specific entity to the
! server using arbitrary authentication or identification
! protocols. The desired protocol is indicated by the
! authenticator parameter, and any number of parameters can be
! passed to the authenticator.
! When authorization is required, the server will send a 350
! response requesting authorization from the client.
! The client should enter AUTHINFO GENERIC followed by the
! authenticator name and the arguments if any. The
! authenticator and arguments must not contain the sequence
! "..".
! The server will attempt to engage the server end
! authenticator; similarly, the client should engage the client
! end authenticator. The server end authenticator will then
! initiate authentication using the NNTP sockets (if appropriate
! for that authentication protocol), using the protocol
! specified by the authenticator name. These authentication
! protocols are not included in this document, but are similar
! in structure to those referenced in RFC 1731[5] for the IMAP-4
! protocol.
! If the server returns 501, this means that the authenticator
! invocation was syntactically incorrect, or that AUTHINFO
! GENERIC is not supported. The client should retry using the
! regular AUTHINFO command.
Barber [Page 11]
--- 662,741 ----
9.1.2 AUTHINFO GENERIC
! AUTHINFO GENERIC <mechanism> [initial-response]
! This begins a SASL [8] authentication exchange for the
! specified SASL mechanism. The client and server exchange
! base64 encoded strings until the authentication is
! complete. The service name for this profile of SASL is
! "nntp". If the SASL mechanism specifies an authorization
! identity in addition to an authentication identity, the
! server first verifies that authentication identity has
! permission to login as that authorization identity, then
! will use the authorization identity to select permission.
! This allows a proxy server architecture.
! Support for the CRAM-MD5 [9] mechanism is MANDATORY for
! all client implementations. Server implementations which
! support the AUTHINFO command MUST also support the
! CRAM-MD5 [9] mechanism. However, a server MAY permit
! only unrestricted access in which case that server is not
! required to support the AUTHINFO command.
! If the server returns a 350 response with a base64 encoded
! server challenge, then the client continues with the next
! step for the specified authentication mechanism, by
! sending a single line containing either the next base64
! encoded client response followed by a CRLF, or a single
! "*" followed by a CRLF to cancel the authentication
! exchange.
! The server can return any of the following status codes at
! completion. This is not an exhaustive list as additional
! codes may be added later. In case of a failure, the
! client MAY attempt a different mechanism.
! 250 indicates a successful termination.
+ 251 indicates successful termination with a final server
+ challenge base64 encoded as the text of this code.
+ 501 indicates that the mechanism exchange was
+ syntactically incorrect or the client terminated the
+ exchange with a "*".
+ 503 indicates the authentication mechanism is not
+ supported.
+ 550 indicates the authentication was rejected. This is
+ also used if the user does not exist in order to prevent
+ probing for users.
+ 551 indicates the user's password or public key
+ certificate has expired and the user will have to use a
+ password change or certificate update mechanism
+ appropriate for the authentication mechanism.
+
+ 552 indicates that the mechanism the user requested
+ requires an external encryption layer before use. The
+ client MAY attempt to use a stronger mechanism or
+ negotiate on a strong encryption mechanism prior to
+ authentication.
+
+ 553 indicates that the mechanism the user requested is too
+ weak for local security policy for that user. The client
+ MAY attempt to use a stronger mechanism.
+
+ 554 indicates that the user does not have a password entry
+ for the requested mechanism, but that the user MAY use
+ AUTHINFO USER and AUTHINFO PASS to authentication against
+ a legacy authentication database and to initialize the
+ authentication database for the requested mechanism so it
+ may be used in the future.
+
+
+
+
Barber [Page 11]
***************
*** 686,713 ****
INTERNET DRAFT September 1997
- If the requested authenticator capability is not found or
- there is some other unspecified server program error, the
- server returns the 503 response code.
-
The authenticators converse using their protocol until
complete. If the authentication succeeds, the server
authenticator will terminate with a 250, and the client can
continue by reissuing the command that prompted the 350. If
! the authentication fails, the server will respond with a 452.
! The client must provide authentication when requested by the
! server. The server may request authentication at any time.
! Servers may request authentication more than once during a
single session.
! When the server authenticator completes, it provides to the
! server (by a mechanism herein undefined) the email address of
the user, and potentially what the user is allowed to access.
! Once authenticated, the server shall generate a Sender: line
using the email address provided by the authenticator if it
does not match the user-supplied From: line. Additionally, the
! server should log the event, including the user's
authenticated email address (if available). This will provide
a means by which subsequent statistics generation can
associate news group references with unique entities - not
--- 742,767 ----
INTERNET DRAFT September 1997
The authenticators converse using their protocol until
complete. If the authentication succeeds, the server
authenticator will terminate with a 250, and the client can
continue by reissuing the command that prompted the 350. If
! the authorization was not sufficient for the re-issued
! command, the server will respond with a 452.
! The client MUST provide authentication when requested by the
! server. The server MAY request authentication at any time.
! Servers MAY request authentication more than once during a
single session.
! When the authentication exchange completes, the server
! SHOULD have access (by a mechanism herein undefined) to the
! primary email address of
the user, and potentially what the user is allowed to access.
! Once authenticated, the server SHOULD generate a Sender: line
using the email address provided by the authenticator if it
does not match the user-supplied From: line. Additionally, the
! server SHOULD log the event, including the user's
authenticated email address (if available). This will provide
a means by which subsequent statistics generation can
associate news group references with unique entities - not
***************
*** 718,727 ****
9.1.2.1 Responses
250 Authorization accepted
350 Continue with authorization sequence
- 450 Authorization required for this command
- 452 Authorization rejected
501 Command not supported or Command Syntax Error
! 502 Program error, function not performed
nnn authenticator-specific protocol.
9.1.3 Transition Issues
--- 772,784 ----
9.1.2.1 Responses
250 Authorization accepted
350 Continue with authorization sequence
501 Command not supported or Command Syntax Error
! 503 Program error, function not performed
! 550 Authentication/Authorization Failed
! 551 Password/certificate expired
! 552 Encryption required
! 553 Mechanism too weak for user
! 554 Transition needed
nnn authenticator-specific protocol.
9.1.3 Transition Issues
***************
*** 1945,1950 ****
--- 2002,2014 ----
Specification,Implementation and Analysis", RFC-1305,
University of Delaware, March 1992.
+ [8] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, Netscape Communications, October 1997.
+
+ [9] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
+ for Simple Challenge/Response", RFC 2195, MCI, September
+ 1997.
+
15.1 Notes
More information about the ietf-nntp
mailing list