From owner-ietf-nntp@academ.com Wed May 13 20:21:47 1998 Delivery-Date: Wed, 13 May 1998 20:21:47 -0400 Return-Path: owner-ietf-nntp@academ.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA25647 for ; Wed, 13 May 1998 20:21:46 -0400 (EDT) Received: from announcer.academ.com (majordomo@ANNOUNCER.ACADEM.COM [198.137.249.60]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id UAA15493 for ; Wed, 13 May 1998 20:24:10 -0400 (EDT) Received: (from majordomo@localhost) by announcer.academ.com (8.8.5/8.8.8) id TAA06908; Wed, 13 May 1998 19:18:13 -0500 (CDT) Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.5/8.8.8) with ESMTP id TAA06903 for ; Wed, 13 May 1998 19:18:12 -0500 (CDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by academ.com (8.8.8/8.8.8) with ESMTP id TAA18107 for ; Wed, 13 May 1998 19:18:06 -0500 (CDT) Received: from elwood.innosoft.com ("port 62297"@ELWOOD.INNOSOFT.COM) by INNOSOFT.COM (PMDF V5.1-10 #8694) with SMTP id <01IWZQU2SNW4985HVJ@INNOSOFT.COM> for ietf-nntp@academ.com; Wed, 13 May 1998 17:16:53 PDT Date: Wed, 13 May 1998 17:18:28 -0700 (PDT) From: Chris Newman Subject: ietf-nntp Separate AUTHINFO spec To: NNTPEXT WG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Originator-Info: login-id=chris; server=THOR.INNOSOFT.COM Sender: owner-ietf-nntp@academ.com Precedence: bulk Reply-To: ietf-nntp@academ.com 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: chris.newman@innosoft.com Newman [Page 7] From owner-ietf-nntp@academ.com Tue May 26 07:18:42 1998 Delivery-Date: Tue, 26 May 1998 07:18:42 -0400 Return-Path: owner-ietf-nntp@academ.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA00870 for ; Tue, 26 May 1998 07:18:42 -0400 (EDT) Received: from announcer.academ.com (majordomo@ANNOUNCER.ACADEM.COM [198.137.249.60]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id HAA04576 for ; Tue, 26 May 1998 07:21:04 -0400 (EDT) Received: (from majordomo@localhost) by announcer.academ.com (8.8.8/8.8.8) id GAA01918; Tue, 26 May 1998 06:10:29 -0500 (CDT) Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.8/8.8.8) with ESMTP id GAA01913 for ; Tue, 26 May 1998 06:10:28 -0500 (CDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by academ.com (8.8.8/8.8.8) with ESMTP id GAA03763; Tue, 26 May 1998 06:10:24 -0500 (CDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IXH53RG0PI8WW970@INNOSOFT.COM>; Tue, 26 May 1998 04:09:01 PDT Date: Tue, 26 May 1998 04:09:01 -0700 (PDT) From: Chris Newman Subject: Re: ietf-nntp Merge Newman's Authinfo draft into Main Draft? In-reply-to: <199805260125.UAA15759@academ.com> To: Stan Barber Cc: NNTPEXT WG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-nntp@academ.com Precedence: bulk Reply-To: ietf-nntp@academ.com On Mon, 25 May 1998, Stan Barber wrote: > Just because noone commented on the draft does not mean that there was > consensus on merging the draft back into the main draft. At best, it means > that the contents of the draft are not objectionable to any one on the > mailing list. I believe the NNTPEXT charter forbids adding the AUTHINFO command to the base spec in a way which meets IESG guidelines. NNTPEXT is forbidden from adding new features to the protocol -- this includes authentication technology which isn't already deployed. On the flip side, the IESG requires that if any authentication mechanism is included in the base spec, then there must be a mandatory-to-implement mechanism which does not use plaintext passwords. These two requirements end up being contradictory in this case. NNTPEXT has two choices: (A) Include no AUTHINFO command in base spec and document that current practice is to permit public access to NNTP servers with restrictions based on source IP address (often enforced by a border packet filter). (B) Update the NNTPEXT charter to permit us to add new authentication technology as necessary to meet IESG requirements for authentication commands. Then solve the problem documented in draft-newman-auth-mandatory-00.txt. Unless we get a definitive IESG statement that NNTPEXT is not permitted to do (A) and has to make incompatible changes to the NNTP protocol which will make all current servers incompliant, I'd prefer to go with (A). I happen to think the NNTPEXT charter was well written and there isn't justification to change it unless (A) is known to be a show-stopper. I know some form of question was posed to Marcus Leech, but we don't know how that question was worded and only have a second-hand report of the results. > The next step should be to have the draft published in the > Internet Drafts respository so that folks not participating in the list might > have a chance to comment. I just sent in the draft (with a list of open issues added). It should appear in a few days. - Chris From owner-ietf-nntp@academ.com Tue May 26 19:12:22 1998 Delivery-Date: Tue, 26 May 1998 19:12:22 -0400 Return-Path: owner-ietf-nntp@academ.com Received: from cnri.reston.va.us (ns.cnri.reston.va.us [132.151.1.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA13499 for ; Tue, 26 May 1998 19:12:21 -0400 (EDT) Received: from announcer.academ.com (majordomo@ANNOUNCER.ACADEM.COM [198.137.249.60]) by cnri.reston.va.us (8.8.5/8.8.7a) with ESMTP id TAA08635 for ; Tue, 26 May 1998 19:14:44 -0400 (EDT) Received: (from majordomo@localhost) by announcer.academ.com (8.8.8/8.8.8) id SAA03674; Tue, 26 May 1998 18:08:28 -0500 (CDT) Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by announcer.academ.com (8.8.8/8.8.8) with ESMTP id SAA03669 for ; Tue, 26 May 1998 18:08:27 -0500 (CDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by academ.com (8.8.8/8.8.8) with ESMTP id SAA13150; Tue, 26 May 1998 18:08:22 -0500 (CDT) Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V5.1-10 #8694) id <01IXHORVVR348WW8HB@INNOSOFT.COM>; Tue, 26 May 1998 16:07:51 PDT Date: Tue, 26 May 1998 16:02:37 -0700 (PDT) From: Ned Freed Subject: Re: ietf-nntp Merge Newman's Authinfo draft into Main Draft? In-reply-to: "Your message dated Tue, 26 May 1998 04:09:01 -0700 (PDT)" To: Chris Newman Cc: Stan Barber , NNTPEXT WG Message-id: <01IXHU7YEW9G8WW8HB@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <199805260125.UAA15759@academ.com> Sender: owner-ietf-nntp@academ.com Precedence: bulk Reply-To: ietf-nntp@academ.com > > Just because noone commented on the draft does not mean that there was > > consensus on merging the draft back into the main draft. At best, it means > > that the contents of the draft are not objectionable to any one on the > > mailing list. > I believe the NNTPEXT charter forbids adding the AUTHINFO command to the > base spec in a way which meets IESG guidelines. (With co-chair hat on) I agree. We cannot add brand new features like this in the base specification given the charter as it stands. > NNTPEXT is forbidden from adding new features to the protocol -- this > includes authentication technology which isn't already deployed. On the > flip side, the IESG requires that if any authentication mechanism is > included in the base spec, then there must be a mandatory-to-implement > mechanism which does not use plaintext passwords. These two requirements > end up being contradictory in this case. > NNTPEXT has two choices: > (A) Include no AUTHINFO command in base spec and document that current > practice is to permit public access to NNTP servers with restrictions > based on source IP address (often enforced by a border packet filter). Speaking simply as a participant, I believe this is the right thing to do. > (B) Update the NNTPEXT charter to permit us to add new authentication > technology as necessary to meet IESG requirements for authentication > commands. Then solve the problem documented in > draft-newman-auth-mandatory-00.txt. I really don't want to add NNTP to the list of protocols stuck on this issue, and that is the best thing we can hope for even if we manage to get past the charter issue. However, I do want to pursue SASL mechanisms as an NNTP extension. I think it would be a mistake not to. But we have to finish the base specification first. > Unless we get a definitive IESG statement that NNTPEXT is not permitted to > do (A) and has to make incompatible changes to the NNTP protocol which > will make all current servers incompliant, I'd prefer to go with (A). I > happen to think the NNTPEXT charter was well written and there isn't > justification to change it unless (A) is known to be a show-stopper. I > know some form of question was posed to Marcus Leech, but we don't > know how that question was worded and only have a second-hand report of > the results. Good point. > > The next step should be to have the draft published in the > > Internet Drafts respository so that folks not participating in the list might > > have a chance to comment. > I just sent in the draft (with a list of open issues added). It should > appear in a few days. Thanks! Ned