Subject: ietf-nntp Separate AUTHINFO spec

From: Chris Newman <[email-masked]>
Date: Wed, 13 May 1998 17:18:28 -0700 (PDT)

I got some cycles in a waiting room to finish a prerelease draft this
morning.  I took the text from the last NNTP spec as a starting point, and
added a bit more. 

Open issues:
* Should this go back in the base spec?
* Should we co-opt AUTHINFO GENERIC for use by SASL only as Microsoft's
  implementation has done.  If so, should we include both the capability
  listing and the "AUTHINFO GENERIC" with no arguments listing of
  mechanisms?  This would probably be incompatible with non-SASL use of
  AUTHINFO GENERIC, but that may not be a problem given there is no 
  specification for any AUTHINFO GENERIC mechanisms.
* What SASL mechanism should be mandatory-to-implement according to the
  requirements described in draft-newman-auth-mandatory-00.txt.
* Needs more examples.
* Needs ABNF grammar.

Comments would be welcome.

		- Chris
---
Network Working Group                                          C. Newman
Internet Draft                                                  Innosoft
Document: draft-ietf-nntpext-auth-00pre1.txt                    May 1998
                                                   Expires in six months

                          NNTP Authentication

Status of this memo

     This document is an Internet-Draft.  Internet-Drafts are working
     documents of the Internet Engineering Task Force (IETF), its areas,
     and its working groups.  Note that other groups may also distribute
     working documents as Internet-Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time.  It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."

     To view the entire list of current Internet-Drafts, please check
     the "1id-abstracts.txt" listing contained in the Internet-Drafts
     Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
     (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
     (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
     West Coast).

Abstract

     Although NNTP [NNTP] has historically provided public access to
     newsgroups, it is often useful to use authentication to control
     resource consumption.  The NNTP AUTHINFO command described here
     provides a way to do this.

1. How to Read This Document

     The key words "MUST", "MUST NOT", "MANDATORY", "SHOULD", "SHOULD
     NOT", "RECOMMENDED" and "MAY" in this document are to be
     interpreted as defined in "Key words for use in RFCs to Indicate
     Requirement Levels" [KEYWORDS].

     This document assumes you are familiar with NNTP [NNTP] and SASL
     [SASL].

Newman                                                          [Page 1]

Internet Draft            NNTP Authentication                   May 1998

2. AUTHINFO and SASL Capabilities

     A server supporting the AUTHINFO command as defined in this
     specification will advertise the "AUTHINFO" capability in response
     to the "LIST EXTENSIONS" command.  The AUTHINFO capability has one
     OPTIONAL argument "USER" which indicates that AUTHINFO USER and
     AUTHINFO PASS are supported.

     A server supporting one or more SASL mechanisms will advertise the
     "SASL" capability in response to the "LIST EXTENSIONS" command.
     The SASL capability is followed by a space-separated list of SASL
     mechanism names.

     Example:
          [C] LIST EXTENSIONS
          [S] 202-Extensions supported:
          [S]  OVER
          [S]  PAT
          [S]  LISTGROUP
          [S]  AUTHINFO USER
          [S]  SASL CRAM-MD5 GSSAPI
          [S] .

3. Authentication Response Codes

     An NNTP server MAY respond to any client command other than QUIT or
     AUTHINFO with a 450 failure response.  This indicates the client
     MUST authenticate in order to use that command or access that
     resource.

     If a client has previously authenticated, but is not authorized to
     access a given resource, the server MAY respond with a 452 failure
     response.

4. AUTHINFO

     AUTHINFO is used to authenticate a user.  In all cases, clients
     MUST provide this information when requested by the server.
     Servers are not required to accept authentication information that
     is volunteered by the client.  Clients MUST accommodate servers
     that reject any authentication information volunteered by the
     client.

Newman                                                          [Page 2]

Internet Draft            NNTP Authentication                   May 1998

4.1. AUTHINFO USER/PASS

     AUTHINFO USER username

     AUTHINFO PASS password

     These commands permit the client to use a plain-text password to
     authenticate.  A compliant implementation MUST NOT implement this
     mechanism without also implementing support for a strong encryption
     layer or a stronger authentication mechanism.  Use of this
     mechanism is deprecated as it exposes the user's password to all
     parties on the network between the client and the server.

     The client begins by issuing the AUTHINFO USER username command.
     If the server is willing to accept this form of authentication and
     a password is required, the server responds with a 350 response.
     The client continues by sending the AUTHINFO PASS password command.
     If the username/password combination is valid or no password is
     required, the server responds with a 250 response and the client
     MAY then retry the command which resulted in a 450 response.

     If the server returns 501, this means that the authenticator
     invocation was syntactically incorrect, or that this form of
     AUTHINFO is not supported.

     If the requested authenticator capability is not found or there is
     some other unspecified server program error, the server MUST return
     the 503 response code.

4.1.2. 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
     503 Program error, function not performed

4.2. AUTHINFO GENERIC

     AUTHINFO GENERIC authenticator arguments...

     The AUTHINFO GENERIC command MAY be used by private agreement to
     authenticate a client.  Definition of new AUTHINFO GENERIC
     mechanisms is discouraged in favor of SASL mechanisms which are not
     NNTP-specific.

Newman                                                          [Page 3]

Internet Draft            NNTP Authentication                   May 1998

     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 arguments can be passed to the authenticator.

     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 socket (if appropriate for that authentication
     protocol), using the protocol specified by the authenticator name.
     These authentication protocols are not included in this document.

     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 SASL
     command or the AUTHINFO USER command.

     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 450. 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.

4.2.1 Responses

     250 Authorization accepted
     450 Authorization required for this command
     452 Authorization rejected
     501 Command not supported or Command Syntax Error
     503 Program error, function not performed
     nnn authenticator-specific protocol.

Newman                                                          [Page 4]

Internet Draft            NNTP Authentication                   May 1998

4.3. AUTHINFO SASL

     AUTHINFO SASL mechanism [initial-response]

     The AUTHINFO SASL command permits NNTP clients to authenticate
     using SASL [SASL] mechanisms such as CRAM-MD5 [CRAM-MD5],
     KERBEROS_V4, GSSAPI or EXTERNAL.  This profile of SASL uses the
     service name "news" for Kerberos and GSSAPI mechanisms.

     The optional initial-response argument is a base64-encoded string
     of the initial client response for SASL mechanisms with no initial
     server challenge.

     The server MAY continue the authentication with a 351 response
     containing a base64-encoded server-challenge.  The client replies
     with a line containing a base64-encoded client-response followed by
     CRLF, or with a "*" followed by CRLF to cancel the exchange.  The
     server responds to "*" with a 501 response.

     The server indicates successful completion with either a 250
     success response, or a 251 success response which contains a
     base64-encoded token with final server challenge data.  The server
     indicates failure with a 452, 501, 503 error or other 45x code as
     defined by future IESG-approved amendments to this specification.

     If a security layer is negotiated, the server begins with the octet
     immediately after the CRLF at the end of a 250 or 251 success
     response, and the client begins with the octet immediately after
     the CRLF of the last client-response in the SASL exchange.  In
     addition, after a security layer is negotiated, the client SHOULD
     re-issue the LIST EXTENSIONS command to reduce the impact of active
     attacks prior to authentication.

4.3.1 Responses

     250 Authorization accepted
     251 final-server-challenge-data (client authorization accepted)
     351 server-challenge-data
     450 Authorization required for this command
     452 Authorization rejected
     501 Command not supported or Command Syntax Error
     503 Program error, function not performed
     45x Treat unknown 45x codes as equivalent to 452

Newman                                                          [Page 5]

Internet Draft            NNTP Authentication                   May 1998

4.4. Transition Issues

     The implementations of AUTHINFO commonly in use prior to the
     release of this memo have a different response code set. The code
     281 was used in place of 250, 381 and 480 were used in place of 450
     and 482 and 502 were used in place of 452. Clients compliant with
     this spec MAY also want to be able to accommodate the older codes
     to lessen the impact of the transition to this specification.

     Some implementations have treated AUTHINFO GENERIC as equivalent to
     the new AUTHINFO SASL command, but with different response codes
     and without a response code equivalent to 251.  Other
     implementations have used AUTHINFO GENERIC in incompatible ways.
     Some implementations have used AUTHINFO GENERIC with no arguments
     as a request to list available SASL or non-SASL mechanisms.  As a
     result, this specification has deprecated AUTHINFO GENERIC in favor
     of an interoperable option.

5. Security Considerations

     The AUTHINFO USER and AUTHINFO PASS commands are subject to passive
     attacks and replay attacks and are therefore not safe for most
     real-world use.

     The AUTHINFO GENERIC and AUTHINFO SASL commands inherit the
     security considerations of the underlying mechanism choosen.

     When multiple authentication mechanisms are permitted by both
     client and server, then 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.

     A SASL integrity protection layer can not protect protocol
     exchanges conducted prior to authentication.  For this reason, the
     LIST EXTENSIONS command should be re-issued after successful
     negotiation of integrity protection, and other protocol state
     SHOULD be re-negotiated as well.

     An IP level integrity protection layer [IPAUTH, IPESP] can provide
     better protection from some denial of service attacks than a SASL
     integrity layer can provide, and is thus preferred when available.

6. Acknowledgements

     A significant amount of this text was originally from the NNTP

Newman                                                          [Page 6]

Internet Draft            NNTP Authentication                   May 1998

     revision spec written by Stan Barber.

7. References

     [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
     for Simple Challenge/Response", RFC 2195, MCI, September 1997.

     [IPAUTH] Atkinson, "IP Authentication Header", RFC 1826, Naval
     Research Laboratory, August 1995.

     [IPESP] Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 1827,
     Naval Research Laboratory, August 1995.

     [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement
     Levels", RFC 2119, Harvard University, March 1997.

     [NNTP] Barber, S., "Network News Transport Protocol", Work in
     Progress.

     [SASL] Myers, "Simple Authentication and Security Layer (SASL)", RFC
     2222, Netscape Communications, October 1997.

8. Authors' Addresses

     Chris Newman
     Innosoft International, Inc.
     1050 Lakes Drive
     West Covina, CA 91790 USA

     Email: [email-masked]

Newman                                                          [Page 7]