wdiff draft-newman-nntpext-auth-00.txt draft-newman-nntpext-auth-01.txt

Network Working Group C. Newman
Internet Draft Innosoft
Document: draft-newman-nntpext-auth-00.txt May draft-ietf-nntpext-auth-01.txt November 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 traditionally provided public access to
newsgroups, it is often useful to use authentication to control
resource consumption. consumption as well as to create restricted-access
newsgroups. The NNTP AUTHINFO command described here provides a
way to do this.

0. Open Issues

Discussion is on the NNTPEXT WG mailing list <ietf-nntp-
request@academ.com>.

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?
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]. RFC 1123.

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

In the examples, commands from the client are indicated with [C],
and responses from the server are indicated with [S].

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 AUTHINFO 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] .

It is not required to issue LIST EXTENSIONS prior to attempting use
of AUTHINFO or any SASL mechanism.

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.

4.1. AUTHINFO USER/PASS

AUTHINFO USER username

AUTHINFO PASS password

These commands permit the client to use a plain-text clear-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. Any
implementation of this mechanism SHOULD include a configuration
option which disables it.

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 command 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

Only US-ASCII printable characters SHOULD be used by private agreement to
authenticate a client. Definition of new AUTHINFO GENERIC
mechanisms is discouraged in favor of SASL mechanisms which the username
and password to permit maximal interoperability. If non-US-ASCII
characters are not
NNTP-specific.

AUTHINFO GENERIC is used to identify in a specific entity to the
server using username, they MUST use UTF-8. Passwords
MAY contain 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 binary data excluding NUL, CR and LF
characters. However, if any. The authenticator and
arguments must not contain the sequence "..".

The server will attempt a password is supplied 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 as a 250, and the client can continue by reissuing the
command that prompted the 450. If the authentication fails, the
server will respond with
sequence of characters (e.g., a 452.

The client password dialog box), those
characters 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 be encoded as UTF-8.

Example:
[C] AUTHINFO USER fred
[S] 350 Enter Passphrase
[C] AUTHINFO PASS flintstone
[S] 250 Authorization accepted

4.1.2. Responses

4.3.

Clients MUST support other response codes by processing them based
on the first digit.

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

If AUTHINFO is implemented, then AUTHINFO SASL and the DIGEST-MD5
[DIGEST-MD5] mechanism MUST be implemented. This is necessary to
ensure that any two compliant clients and servers can be configured
to authenticate without using unencrypted clear-text passwords.
[NOTE: CRAM-MD5 is an expedient alternative choice as it's already
standards track.]

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 exchange 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. error.

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

In the following example, the username is "tim" and the password is
"tanstaaftanstaaf".

Example:
[C] AUTHINFO SASL CRAM-MD5
[S] 351 PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
[C] dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
[S] 250 Authorization accepted

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

Clients MUST support other response codes as equivalent by processing them based
on the first digit.

4.3. AUTHINFO SIMPLE

The AUTHINFO SIMPLE command provided equiavlent functionality to 452
AUTHINFO USER and AUTHINFO PASS. It is now deprecated. Some
information about current use is documented in "Common NNTP
Extensions" [NNTP-EXT-INFO].

4.4. AUTHINFO GENERIC

The AUTHINFO GENERIC command provided a service which is roughly
comparable to the authentication framework which SASL provides,
except that it requires authentication mechanisms to be designed
specifically for NNTP. It is now deprecated. Some information
about current use is documented in "Common NNTP Extensions" [NNTP-
EXT-INFO].

4.5. Transition Issues

The implementations of AUTHINFO USER/PASS 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

4.6. Formal Syntax

This amends the formal syntax for NNTP [NNTP] to add these
additional commands. The syntax is defined using ABNF [ABNF],
including the new AUTHINFO SASL command, but with different core rules from section 6 of ABNF.

authinfo-capability = "AUTHINFO" [SP "USER"] CRLF
sasl-capability = "SASL" 1*(SP sasl-mech) CRLF
command /= authinfo-user-command /
authinfo-pass-command /
authinfo-sasl-command
authinfo-user-command = "AUTHINFO" 1*WSP "USER" 1*WSP username
*WSP CRLF
authinfo-pass-command = "AUTHINFO" 1*WSP "PASS" 1*WSP password
*WSP CRLF
authinfo-sasl-command = "AUTHINFO" 1*WSP "SASL" 1*WSP sasl-mech
[1*WSP base64 *WSP] *(CRLF base64) CRLF
; client waits for server response codes after each CRLF
resp-sasl-data = ("351" / "251") SP base64

sasl-mech = 1*20mech-char
mech-char = %x41-5A / DIGIT / "-" / "_"
; mech names restricted to uppercase letters,
; digits, "-" 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. "_"
username = 1*UTF8-SAFE
password = 1*PASS-DATA
PASS-DATA = %x01-09 / %x0B-0C / %x0E-FF
UTF8-SAFE = %x01-09 / %x0B-0C / %x0E-7F / UTF8-2 /
UTF8-3 / UTF8-4 / UTF8-5 / UTF8-6
UTF8-1 = %x80-BF
UTF8-2 = %xC0-DF UTF8-1
UTF8-3 = %xE0-EF 2UTF8-1
UTF8-4 = %xF0-F7 3UTF8-1
UTF8-5 = %xF8-FB 4UTF8-1
UTF8-6 = %xFC-FD 5UTF8-1
base64 = *(4base64-char) [base64-terminal]
base64-char = ALPHA / DIGIT / "+" / "/"
; case sensitive
base64-terminal = (2base64-char "==") / (3base64-char "=")

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 command inherits the security considerations of
the underlying mechanism choosen. and the security considerations of SASL.

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 SHOULD be re-issued after successful
negotiation of integrity protection, and other protocol state
SHOULD be re-negotiated as well.

An IP level When integrity protection layer [IPAUTH, IPESP] can provide
better protection from some denial is
negotiated, the client MAY compare the list of service attacks than a available SASL
integrity layer can provide,
mechanisms before and is thus preferred when available. after authentication to detect active down-
negotiation attacks.

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

[DIGEST-MD5] Leach, P., Newman, C., "Using Digest 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 as a
SASL Mechanism", Work in RFCs to Indicate Requirement
Levels", RFC 2119, Harvard University, March 1997. Progress.

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

[NNTP-EXT-INFO] Barber, S., "Common NNTP Extensions", Work in Progress.

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

[UTF-8] Yergeau, F. "UTF-8, a transformation format of ISO 10646",
RFC 2279, Alis Technologies, January 1998.

8. Authors' Addresses

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

Email: chris.newman@innosoft.com