Network Working Group C. Newman Internet Draft Innosoft Document: draft-newman-nntpext-auth-00.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. 0. Open Issues Discussion is on the NNTPEXT WG mailing list . Should this be merged into the NNTP base spec? If so, what is the mandatory-to-implement mechanism? If not, is a mandatory-to-implement mechanism necessary? Newman [Page 1] Internet Draft NNTP Authentication May 1998 Do we want to co-opt all use of AUTHINFO GENERIC for use by SASL and not have a separate command? Needs examples and ABNF. 1. How to Read This Document The key words "MUST", "MUST NOT", "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]. 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. Newman [Page 2] Internet Draft NNTP Authentication May 1998 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. 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 Newman [Page 3] Internet Draft NNTP Authentication May 1998 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. 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 Newman [Page 4] Internet Draft NNTP Authentication May 1998 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. 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. Newman [Page 5] Internet Draft NNTP Authentication May 1998 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 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 Newman [Page 6] Internet Draft NNTP Authentication May 1998 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 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: chris.newman@innosoft.com Newman [Page 7]