ietf-nntp RFC977bis w.r.t. authentication

[Larry Osterman (Exchange)]

Here's a first try (based on the definition in RFC1734).  Please see the
****NOTE**** comments within.

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 450 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 SHOULD NOT contain the sequence "..".
	The authenticator MUST be either be the name of a SASL [RFC2222]
authentication package, or have the form X-<authenticator> for experimental
authentication mechanisms.

	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 AUTHINFO USER/AUTHINFO
PASS commands. 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 client should then retry with another authenticator,
or fall back to AUTHINFO USER/AUTHINFO PASS.

	The authentication protocol exchange consists of a series of server
challenges and client answers that are specific to the authenticator.  A
server challenge, is a line consisting of a 381*****NOTE**** response code
followed by a space and a BASE64 encoded string.  The client answer consists
of a line containing a BASE64 encode string.  If a client wishes to cancel
an authentication exchange, it SHOULD issue a line with a single "*".  If
the server receives such an answer, it MUST reject the AUTHINFO command with
an error.  If the protocol exchange is initiated by the client, the client
MAY present it's initial answer as a BASE64 encoded string in the arguments
to the AUTHINFO command.

	If the authentication succeeds, the server authenticator will
terminate with a 250, and the client can continue by reissuing the command
that prompted the 450*****NOTE****. 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.

	Please note: This SASL profile does NOT support a SASL protection
mechanism.

***************
Note:  The original text uses 450 in the second paragraph and 350 in the
last.  From the later comments, I assume that the last was supposed to be
450 and have taken the liberty of correcting it.

Also I was unsure of what response to use to indicate the interim response
from the server.  I chose 381, since that is what the Exchange and MCIS
servers use, however arguably 450 may be more appropriate.

Larry Osterman
Sent from larryo-laptop.dns.microsoft.com running NT5 and Outlook 98 and
Exchange Server 5.5.  Please notify the sender of any difficulties


-----Original Message-----
From: sob at academ.com [mailto:sob at academ.com]
Sent: Tuesday, May 05, 1998 4:40 PM
To: Larry Osterman (Exchange); Chris Lewis; ietf-nntp at academ.com
Subject: RE: ietf-nntp RFC977bis w.r.t. authentication


> As I posted earlier, I doubt it's 8bit enough.  Can it handle arbitrary
CRLF
> sequences in protocol elements?  Can it handle NULs in protocol elements?

Good point. Propose some text to address the issue and then the rest of us
can review it. If you want to see this fixed, you have to contribute to the
process of fixing it.

> The point is that authentication protocols have a nasty tendency of
> generating a LOT of variible length binary data.  So you HAVE to define
how
> the SASL data is wrapped.  I know of 2 ways of doing this used by other
> protocols.  LDAP BER encodes the binary data and transfers it that way
> (which is reasonable since it's an ASN.1 protocol).  The other way is to
> base64 the data and send the binary blobs as CRLF delimited strings (POP,
> IMAP, and SMTP-AUTH) do this.
> 
> Since NNTP is a text protocol I'd STRONGLY suggest the latter.

See above. Send proposed text for the draft.

-- 
Stan   | Academ Consulting Services        |internet: sob at academ.com
Olan   | For more info on academ, see this |uucp: mcsun!academ!sob
Barber | URL- http://www.academ.com/academ |Opinions expressed are only
mine.