ietf-nntp Separate AUTHINFO spec
Chris Newman
Chris.Newman at INNOSOFT.COM
Wed May 13 17:18:28 PDT 1998
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 at innosoft.com
Newman [Page 7]
More information about the ietf-nntp
mailing list