ietf-nntp Minutes from the WG (these have been submitted to IETF)
Chris Newman
Chris.Newman at INNOSOFT.COM
Fri Dec 19 18:44:49 PST 1997
On Fri, 19 Dec 1997, Chris Lewis wrote:
> >There was a suggestion to provide a mechanism for getting the various
> >AUTHINFO GENERIC mechanisms supported. Chris Lewis was not at the meeting,
> >but his input will be solicited. Such information could be returned
> >as part of a LIST EXTENSIONS response or another command or as a response
> >to AUTHINFO GENERIC without any arguments.
>
> I was anticipating do this via "AUTHINFO GENERIC LIST", and have LIST
> be a authentication scheme that provides the list of authentications
> available, then "nests" to a selected one. The advantage to this is
> that NNTP doesn't need to define how this is done. The disadvantage
> is that I may have to get around to doing some sort of AUTHINFO GENERIC
> subprotocol spec/BCP a bit sooner than I thought.
Actually, I think the listing should be done as part of the extensions
list to save a round trip. In addition, you don't have to write the
AUTHINFO GENERIC subprotocol spec as RFC 2222 already has everything
necessary. We can simply copy the way mechanism listing will be done in
SMTP (see draft-myers-smtp-auth-09.txt). I'm including context diffs to
the current version of the spec to do this, and when ABNF (RFC 2234) is
added for all the commands the formal grammar can be largely copied from
the smtp-auth spec. Since most NNTP clients also support SMTP, this will
minimize the extra code they need.
I'm also proposing CRAM-MD5 (RFC 2195) as the mandatory to implement
non-plaintext mechanism necessary to pass IESG muster. It's simple to
implement on the client, and I've included notes about how to transition
to it on the server side.
> The return codes have been changed on me so many times, I have to read
> the spec again.
I've proposed a bunch more, I'd be interested in what people think.
> The intent here is that the server can use this to provide or check
> a "Sender:" or "NNTP-Posting-User" or such like header. Doesn't need to
> be the email address of the originator or even mailable at all - merely
> needs to be a RFC822-formatted address that allows the site admin to
> identify the user, or generate X-trace headers or whatever.
Actually, "Sender" has to be a deliverable address. Otherwise something
like Originator-Info (draft-newman-msgheader-originfo-03.txt) would be
more suitable. I'm including my proposed wording.
- Chris
----
*** 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