< draft-newman-nntpext-auth-00.txt   draft-newman-nntpext-auth-01.txt >
Network Working Group C. Newman Network Working Group C. Newman
Internet Draft Innosoft Internet Draft Innosoft
Document: draft-newman-nntpext-auth-00.txt May 1998 Document: draft-ietf-nntpext-auth-01.txt November 1998
Expires in six months Expires in six months
NNTP Authentication NNTP Authentication
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US
West Coast). West Coast).
Abstract Abstract
Although NNTP [NNTP] has historically provided public access to Although NNTP [NNTP] has traditionally provided public access to
newsgroups, it is often useful to use authentication to control newsgroups, it is often useful to use authentication to control
resource consumption. The NNTP AUTHINFO command described here resource consumption as well as to create restricted-access
provides a way to do this. 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 1. How to Read This Document
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED" and "MAY" in this document are to be interpreted as "RECOMMENDED" and "MAY" in this document are to be interpreted as
defined in "Key words for use in RFCs to Indicate Requirement defined in RFC 1123.
Levels" [KEYWORDS].
This document assumes you are familiar with NNTP [NNTP] and SASL This document assumes you are familiar with NNTP [NNTP] and SASL
[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 2. AUTHINFO and SASL Capabilities
A server supporting the AUTHINFO command as defined in this A server supporting the AUTHINFO command as defined in this
specification will advertise the "AUTHINFO" capability in response specification will advertise the "AUTHINFO" capability in response
to the "LIST EXTENSIONS" command. The AUTHINFO capability has one to the "LIST EXTENSIONS" command. The AUTHINFO capability has one
OPTIONAL argument "USER" which indicates that AUTHINFO USER and OPTIONAL argument "USER" which indicates that AUTHINFO USER and
AUTHINFO PASS are supported. AUTHINFO PASS are supported.
A server supporting one or more SASL mechanisms will advertise the A server supporting AUTHINFO SASL will advertise the "SASL"
"SASL" capability in response to the "LIST EXTENSIONS" command. capability in response to the "LIST EXTENSIONS" command. The SASL
The SASL capability is followed by a space-separated list of SASL capability is followed by a space-separated list of SASL mechanism
mechanism names. names.
Example: Example:
[C] LIST EXTENSIONS [C] LIST EXTENSIONS
[S] 202-Extensions supported: [S] 202-Extensions supported:
[S] OVER [S] OVER
[S] PAT [S] PAT
[S] LISTGROUP [S] LISTGROUP
[S] AUTHINFO USER [S] AUTHINFO USER
[S] SASL CRAM-MD5 GSSAPI [S] SASL CRAM-MD5 GSSAPI
[S] . [S] .
It is not required to issue LIST EXTENSIONS prior to attempting use
of AUTHINFO or any SASL mechanism.
3. Authentication Response Codes 3. Authentication Response Codes
An NNTP server MAY respond to any client command other than QUIT or An NNTP server MAY respond to any client command other than QUIT or
AUTHINFO with a 450 failure response. This indicates the client AUTHINFO with a 450 failure response. This indicates the client
MUST authenticate in order to use that command or access that MUST authenticate in order to use that command or access that
resource. resource.
If a client has previously authenticated, but is not authorized to If a client has previously authenticated, but is not authorized to
access a given resource, the server MAY respond with a 452 failure access a given resource, the server MAY respond with a 452 failure
response. response.
skipping to change at page 3, line 24 skipping to change at page 3, line 11
is volunteered by the client. Clients MUST accommodate servers is volunteered by the client. Clients MUST accommodate servers
that reject any authentication information volunteered by the that reject any authentication information volunteered by the
client. client.
4.1. AUTHINFO USER/PASS 4.1. AUTHINFO USER/PASS
AUTHINFO USER username AUTHINFO USER username
AUTHINFO PASS password AUTHINFO PASS password
These commands permit the client to use a plain-text password to These commands permit the client to use a clear-text password to
authenticate. A compliant implementation MUST NOT implement this authenticate. A compliant implementation MUST NOT implement this
mechanism without also implementing support for a strong encryption mechanism without also implementing support for a strong encryption
layer or a stronger authentication mechanism. Use of this layer or a stronger authentication mechanism. Use of this
mechanism is deprecated as it exposes the user's password to all mechanism is deprecated as it exposes the user's password to all
parties on the network between the client and the server. 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. The client begins by issuing the AUTHINFO USER username command.
If the server is willing to accept this form of authentication and If the server is willing to accept this form of authentication and
a password is required, the server responds with a 350 response. a password is required, the server responds with a 350 response.
The client continues by sending the AUTHINFO PASS password command. The client continues by sending the AUTHINFO PASS password command.
If the username/password combination is valid or no password is If the username/password combination is valid or no password is
required, the server responds with a 250 response and the client required, the server responds with a 250 response and the client
MAY then retry the command which resulted in a 450 response. MAY then retry the command which resulted in a 450 response.
If the server returns 501, this means that the authenticator If the server returns 501, this means that the command was
invocation was syntactically incorrect, or that this form of syntactically incorrect, or that this form of AUTHINFO is not
AUTHINFO is not supported. supported.
If the requested authenticator capability is not found or there is If the requested authenticator capability is not found or there is
some other unspecified server program error, the server MUST return some other unspecified server program error, the server MUST return
the 503 response code. the 503 response code.
Only US-ASCII printable characters SHOULD be used in the username
and password to permit maximal interoperability. If non-US-ASCII
characters are used in a username, they MUST use UTF-8. Passwords
MAY contain arbitrary binary data excluding NUL, CR and LF
characters. However, if a password is supplied to the client as a
sequence of characters (e.g., a password dialog box), those
characters MUST 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.1.2. Responses
250 Authorization accepted 250 Authorization accepted
350 Continue with authorization sequence 350 Continue with authorization sequence
450 Authorization required for this command 450 Authorization required for this command
452 Authorization rejected 452 Authorization rejected
501 Command not supported or Command Syntax Error 501 Command not supported or Command Syntax Error
503 Program error, function not performed 503 Program error, function not performed
4.2. AUTHINFO GENERIC Clients MUST support other response codes by processing them based
on the first digit.
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
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 4.2. AUTHINFO SASL
AUTHINFO SASL mechanism [initial-response] AUTHINFO SASL mechanism [initial-response]
The AUTHINFO SASL command permits NNTP clients to authenticate The AUTHINFO SASL command permits NNTP clients to authenticate
using SASL [SASL] mechanisms such as CRAM-MD5 [CRAM-MD5], using SASL [SASL] mechanisms such as CRAM-MD5 [CRAM-MD5],
KERBEROS_V4, GSSAPI or EXTERNAL. This profile of SASL uses the KERBEROS_V4, GSSAPI or EXTERNAL. This profile of SASL uses the
service name "news" for Kerberos and GSSAPI mechanisms. 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 The optional initial-response argument is a base64-encoded string
of the initial client response for SASL mechanisms with no initial of the initial client response for SASL mechanisms with no initial
server challenge. server challenge.
The server MAY continue the authentication with a 351 response The server MAY continue the authentication exchange with a 351
containing a base64-encoded server-challenge. The client replies response containing a base64-encoded server-challenge. The client
with a line containing a base64-encoded client-response followed by replies with a line containing a base64-encoded client-response
CRLF, or with a "*" followed by CRLF to cancel the exchange. The followed by CRLF, or with a "*" followed by CRLF to cancel the
server responds to "*" with a 501 response. exchange. The server responds to "*" with a 501 response.
The server indicates successful completion with either a 250 The server indicates successful completion with either a 250
success response, or a 251 success response which contains a success response, or a 251 success response which contains a
base64-encoded token with final server challenge data. The server base64-encoded token with final server challenge data. The server
indicates failure with a 452, 501, 503 error or other 45x code as indicates failure with a 452, 501, 503 error.
defined by future IESG-approved amendments to this specification.
If a security layer is negotiated, the server begins with the octet 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 immediately after the CRLF at the end of a 250 or 251 success
response, and the client begins with the octet immediately after response, and the client begins with the octet immediately after
the CRLF of the last client-response in the SASL exchange. In the CRLF of the last client-response in the SASL exchange. In
addition, after a security layer is negotiated, the client SHOULD addition, after a security layer is negotiated, the client SHOULD
re-issue the LIST EXTENSIONS command to reduce the impact of active re-issue the LIST EXTENSIONS command to reduce the impact of active
attacks prior to authentication. attacks prior to authentication.
4.3.1 Responses 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 250 Authorization accepted
251 final-server-challenge-data (client authorization accepted) 251 final-server-challenge-data (client authorization accepted)
351 server-challenge-data 351 server-challenge-data
450 Authorization required for this command
452 Authorization rejected 452 Authorization rejected
501 Command not supported or Command Syntax Error 501 Command not supported or Command Syntax Error
503 Program error, function not performed 503 Program error, function not performed
45x Treat unknown 45x codes as equivalent to 452
4.4. Transition Issues Clients MUST support other response codes by processing them based
on the first digit.
The implementations of AUTHINFO commonly in use prior to the 4.3. AUTHINFO SIMPLE
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 AUTHINFO SIMPLE command provided equiavlent functionality to
the new AUTHINFO SASL command, but with different response codes AUTHINFO USER and AUTHINFO PASS. It is now deprecated. Some
and without a response code equivalent to 251. Other information about current use is documented in "Common NNTP
implementations have used AUTHINFO GENERIC in incompatible ways. Extensions" [NNTP-EXT-INFO].
Some implementations have used AUTHINFO GENERIC with no arguments
as a request to list available SASL or non-SASL mechanisms. As a 4.4. AUTHINFO GENERIC
result, this specification has deprecated AUTHINFO GENERIC in favor
of an interoperable option. 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.
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 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 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 "_"
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 5. Security Considerations
The AUTHINFO USER and AUTHINFO PASS commands are subject to passive The AUTHINFO USER and AUTHINFO PASS commands are subject to passive
attacks and replay attacks and are therefore not safe for most attacks and replay attacks and are therefore not safe for most
real-world use. real-world use.
The AUTHINFO GENERIC and AUTHINFO SASL commands inherit the The AUTHINFO SASL command inherits the security considerations of
security considerations of the underlying mechanism choosen. the underlying mechanism and the security considerations of SASL.
When multiple authentication mechanisms are permitted by both When multiple authentication mechanisms are permitted by both
client and server, then an active attacker can cause a down- client and server, then an active attacker can cause a down-
negotiation to the weakest mechanism. For this reason, both negotiation to the weakest mechanism. For this reason, both
clients and servers SHOULD be configurable to forbid use of weaker clients and servers SHOULD be configurable to forbid use of weaker
mechanisms. mechanisms.
A SASL integrity protection layer can not protect protocol A SASL integrity protection layer can not protect protocol
exchanges conducted prior to authentication. For this reason, the exchanges conducted prior to authentication. For this reason, the
LIST EXTENSIONS command should be re-issued after successful LIST EXTENSIONS command SHOULD be re-issued after successful
negotiation of integrity protection, and other protocol state negotiation of integrity protection, and other protocol state
SHOULD be re-negotiated as well. SHOULD be re-negotiated as well. When integrity protection is
negotiated, the client MAY compare the list of available SASL
An IP level integrity protection layer [IPAUTH, IPESP] can provide mechanisms before and after authentication to detect active down-
better protection from some denial of service attacks than a SASL negotiation attacks.
integrity layer can provide, and is thus preferred when available.
6. Acknowledgements 6. Acknowledgements
A significant amount of this text was originally from the NNTP A significant amount of this text was originally from the NNTP
revision spec written by Stan Barber. revision spec written by Stan Barber.
7. References 7. References
[CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
for Simple Challenge/Response", RFC 2195, MCI, September 1997. for Simple Challenge/Response", RFC 2195, MCI, September 1997.
[IPAUTH] Atkinson, "IP Authentication Header", RFC 1826, Naval [DIGEST-MD5] Leach, P., Newman, C., "Using Digest Authentication as a
Research Laboratory, August 1995. SASL Mechanism", Work in Progress.
[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 [NNTP] Barber, S., "Network News Transport Protocol", Work in
Progress. Progress.
[NNTP-EXT-INFO] Barber, S., "Common NNTP Extensions", Work in Progress.
[SASL] Myers, "Simple Authentication and Security Layer (SASL)", RFC [SASL] Myers, "Simple Authentication and Security Layer (SASL)", RFC
2222, Netscape Communications, October 1997. 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 8. Authors' Addresses
Chris Newman Chris Newman
Innosoft International, Inc. Innosoft International, Inc.
1050 Lakes Drive 1050 Lakes Drive
West Covina, CA 91790 USA West Covina, CA 91790 USA
Email: chris.newman@innosoft.com Email: chris.newman@innosoft.com
 End of changes. 28 change blocks. 
124 lines changed or deleted 142 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/