[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
CVS gsasl/doc/specification
|
From: |
gsasl-commit |
|
Subject: |
CVS gsasl/doc/specification |
|
Date: |
Mon, 17 Jan 2005 23:10:27 +0100 |
Update of /home/cvs/gsasl/doc/specification
In directory dopio:/tmp/cvs-serv16483
Added Files:
draft-ietf-nntpext-authinfo-06.txt
Log Message:
Add.
--- /home/cvs/gsasl/doc/specification/draft-ietf-nntpext-authinfo-06.txt
2005/01/17 22:10:27 NONE
+++ /home/cvs/gsasl/doc/specification/draft-ietf-nntpext-authinfo-06.txt
2005/01/17 22:10:27 1.1
NNTP Extensions Working Group J. Vinocur
Internet Draft Cornell University
Updates: 2970 (if approved) K. Murchison
Expires: July 2005 Oceana Matrix Ltd.
C. Newman
Sun Microsystems
January 2005
NNTP Extension for Authentication
draft-ietf-nntpext-authinfo-06
Status of this memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance
with RFC 3668.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document defines an extension the Network News Transport
Protocol [NNTP] which allows a client to indicate an authentication
mechanism to the server, perform an authentication protocol
exchange, and optionally negotiate a security layer for subsequent
protocol interactions during the remainder of an NNTP session.
Vinocur, et. al. Expires July 2005 [Page 1]
Internet Draft NNTP Authentication January 2005
Section 3.1 of [NNTP-COMMON] summarizes some ad-hoc authentication
methods currently used in the NNTP protocol. This document updates
and formalizes the AUTHINFO USER/PASS authentication method and
deprecates the AUTHINFO SIMPLE and AUTHINFO GENERIC authentication
methods. Additionally, this document defines a profile of the
Simple Authentication and Security Layer [SASL] for NNTP.
Table of Contents
0. Changes from Previous Version ............................ 2
1. Introduction ............................................. 3
1.1. Conventions Used in this Document ................... 4
2. The AUTHINFO Extension ................................... 4
2.1. Advertising the AUTHINFO Extension .................. 4
2.2. Authenticating with the AUTHINFO Extension .......... 6
2.3. AUTHINFO USER/PASS Command .......................... 7
2.3.1. Usage .......................................... 7
2.3.2. Description .................................... 7
2.3.3. Examples ....................................... 9
2.4. AUTHINFO SASL Command ............................... 9
2.4.1. Usage .......................................... 10
2.4.2. Description .................................... 10
2.4.3. Examples ....................................... 14
3. Augmented BNF Syntax for the AUTHINFO Extension .......... 16
3.1. Commands ............................................ 16
3.2. Command Continuation ................................ 17
3.3. Responses ........................................... 17
3.4. Capability entries .................................. 17
3.5. General non-terminals ............................... 17
4. Summary of Response Codes ................................ 17
5. Authentication Tracking/Logging .......................... 18
6. Security Considerations .................................. 18
7. IANA Considerations ...................................... 19
7.1. IANA Considerations for SASL/GSSAPI services ........ 19
7.2. IANA Considerations for NNTP extensions ............. 19
8. References ............................................... 21
8.1. Normative References ................................ 21
8.2. Informative References .............................. 21
9. Authors' Addresses ....................................... 22
10. Acknowledgments ......................................... 22
11. Intellectual Property Rights ............................ 22
12. Copyright ............................................... 23
0. Changes from Previous Version
New:
o Reintroduced the "SASL" capability to list available SASL mechs.
o Noted that MODE READER must not be used nor advertised after
Vinocur, et. al. Expires July 2005 [Page 2]
Internet Draft NNTP Authentication January 2005
authentication.
o Extended the length of the AUTHINFO SASL command to accommodate
large initial responses.
Changed:
o CAPABILITIES replaces LIST EXTENSIONS.
o Use of an unknown SASL mechanism results in 503 not 501.
o Use common language between this draft and STARTTLS regarding
unsolicited use of the extension and resetting of server state and
caching of info obtained prior to a security layer.
o Capabilities are now case-insensitive.
o Changed reference to IANA requirements in [NNTP] from Section 8 to
Section 3.3.4.
Clarified:
o Rewrote the CAPABILITIES after security layer text yet again.
o Neither the first WSP character following "USER"/"PASS" nor the
CRLF are part of the username/password.
o The MODE READER state change does not get discarded after a SASL
security layer is negotiated.
Outstanding issues:
o Make sure we correctly reference the text in [NNTP] regarding MODE
READER use after authentication.
1. Introduction
Although NNTP [NNTP] has traditionally been used to provide public
access to newsgroups, authentication is often useful, for example
to control resource consumption, to allow abusers of the POST
command to be identified, and to restrict access to "local"
newsgroups.
The ad-hoc AUTHINFO USER and AUTHINFO PASS commands, documented in
[NNTP-COMMON], provide a very weak authentication mechanism in
widespread use by the installed base. Due to their ubiquity they
are formalized in this specification but, because of their
insecurity, only for use in combination with appropriate security
layers.
The ad-hoc AUTHINFO GENERIC command, also documented in [NNTP-
COMMON] but much less ubiquitous, provided an NNTP-specific
equivalent of the generic SASL [SASL] facility. This document
deprecates AUTHINFO GENERIC in favor of an AUTHINFO SASL
replacement so that NNTP can benefit from authentication mechanisms
developed for other SASL-enabled application protocols including
SMTP, POP, IMAP, LDAP, and BEEP.
Vinocur, et. al. Expires July 2005 [Page 3]
Internet Draft NNTP Authentication January 2005
This specification is to be read in conjunction with the NNTP base
specification [NNTP]. Except where specifically stated otherwise,
in the case of a conflict between these two documents [NNTP] takes
precedence over this one.
It is also recommended that this specification be read in
conjunction with the SASL base specification [SASL].
1.1. Conventions Used in this Document
The notational conventions used in this document are the same as
those in [NNTP] and any term not defined in this document has the
same meaning as in that one.
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", "MAY", and "OPTIONAL" in this document are to be interpreted
as described in "Key words for use in RFCs to Indicate Requirement
Levels" [KEYWORDS].
Terms related to authentication are defined in "On Internet
Authentication" [AUTH].
In the examples, commands from the client are indicated with [C],
and responses from the server are indicated with [S].
2. The AUTHINFO Extension
The AUTHINFO extension is used to authenticate a user. Note that
authorization is a matter of site policy, not network protocol, and
is therefore not discussed in this document. The server determines
authorization in whatever manner is defined by its implementation
as configured by the site administrator.
This extension provides three new commands: AUTHINFO USER, AUTHINFO
PASS, and AUTHINFO SASL. The capability label for this extension
is AUTHINFO.
2.1. Advertising the AUTHINFO Extension
A server MUST implement at least one of the AUTHINFO USER or
AUTHINFO SASL commands in order to advertise the AUTHINFO
capability in the response to the CAPABILITIES command. However,
this capability is not advertised after successful authentication
(see section 2.2). This capability MAY be advertised both before
and after any use of MODE READER, with the same semantics.
The AUTHINFO capability label contains an argument list detailing
which authentication commands are available.
Vinocur, et. al. Expires July 2005 [Page 4]
Internet Draft NNTP Authentication January 2005
The "USER" argument indicates that AUTHINFO USER/PASS is supported
as defined by Section 2.3 of this document. The "USER" argument
MUST NOT be advertised, and the AUTHINFO USER/PASS commands SHOULD
NOT be provided, unless a strong encryption layer (e.g. TLS [NNTP-
TLS]) is in use or backward compatibility dictates otherwise.
The "SASL" argument indicates that AUTHINFO SASL is supported as
defined by Section 2.4 of this document. If the server advertises
the "SASL" argument, then it MUST also advertise the "SASL"
capability in response to the CAPABILITIES command. The SASL
capability is followed by a whitespace-separated list of available
SASL mechanism names.
The server may list the AUTHINFO capability with no arguments,
which indicates that it complies with this specification and does
not permit any authentication commands in its current state. In
this case, the client MUST NOT attempt to utilize any AUTHINFO
commands, even if it contains logic to do so (e.g. for backward
compatibility with servers that are not compliant with this
specification).
Future extensions may add additional arguments to this capability.
Unrecognized arguments SHOULD be ignored or brought to the
attention of the user.
As the AUTHINFO command is related to security, cached results of
CAPABILITIES from a previous session MUST NOT be relied on, as per
section 11.6 of [NNTP].
Example (here, the STARTTLS extension [NNTP-TLS] is also in use):
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] IHAVE
[S] STARTTLS
[S] AUTHINFO SASL
[S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI
[S] LIST ACTIVE NEWSGROUPS
[S] .
[C] STARTTLS
[S] 382 Continue with TLS negotiation
[TLS negotiation proceeds, further commands protected by TLS layer]
[C] CAPABILITIES
[S] 101 Capability list:
[S] VERSION 2
[S] READER
[S] IHAVE
Vinocur, et. al. Expires July 2005 [Page 5]
Internet Draft NNTP Authentication January 2005
[S] AUTHINFO USER SASL
[S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN EXTERNAL
[S] LIST ACTIVE NEWSGROUPS
[S] .
2.2. Authenticating with the AUTHINFO Extension
An NNTP server responds to a client command with a 480 response to
indicate that the client MUST authenticate and/or authorize in
order to use that command or access the indicated resource. Use of
the AUTHINFO command as described below is one such way that a
client can authenticate/authorize to the server. The client MAY
therefore use an AUTHINFO command after receiving a 480 response.
A client intending to use an AUTHINFO command SHOULD issue the
CAPABILITIES command to obtain the available authentication
commands and mechanisms before attempting authentication.
If a server advertises the AUTHINFO capability, a client MAY
attempt the first step of authentication at any time during a
session to acquire additional privileges without having received a
480 response. Servers SHOULD accept such unsolicited
authentication requests. A server MUST NOT under any circumstances
reply to an AUTHINFO command with a 480 response.
A client MUST NOT under any circumstances continue with any steps
of authentication beyond the first, unless the response code from
the server indicates that the authentication exchange is welcomed.
In particular, anything other than a 38x response code indicates
that the client MUST NOT continue the authentication exchange.
After a successful authentication, the client MUST NOT issue
another AUTHINFO command in the same session. A server MUST NOT
return the AUTHINFO capability in response to a CAPABILITIES
command and a server MUST reject any subsequent AUTHINFO commands
with a 502 response. Additionally, per section 3.4.2 of [NNTP],
the client MUST NOT issue a MODE READER command after
authentication and a server MUST NOT advertise the MODE-READER
capability.
In agreement with [SASL], the server MUST continue to advertise the
SASL capability in response to a CAPABILITIES command with the same
list of SASL mechanisms as before authentication (thereby enabling
the client to detect a possible active down-negotiation attack).
Other capabilities returned in response to a CAPABILITIES command
received after authentication MAY be different than those returned
before authentication. For example, an NNTP server may not want to
advertise support for a specific extension unless a client has been
authenticated.
Vinocur, et. al. Expires July 2005 [Page 6]
Internet Draft NNTP Authentication January 2005
It should be noted that a server may perform a successful
authentication exchange with a client and yet still deny access to
some or all resources; the permanent 502 response indicates a
resource is unavailable even though authentication has been
performed (this is in contrast to the temporary 480 error
indicating that a resource is unavailable now but may become
available after authentication).
2.3. AUTHINFO USER/PASS Command
This section supersedes the definition of the AUTHINFO USER and
AUTHINFO PASS commands as documented in Section 3.1.1 of [NNTP-
COMMON].
2.3.1. Usage
These commands MUST NOT be pipelined.
Syntax
AUTHINFO USER username
AUTHINFO PASS password
Responses
281 Authentication accepted
381 Password required [1]
481 Authentication failed/rejected
482 Authentication commands issued out of sequence
502 Command unavailable [2]
[1] Only valid for AUTHINFO USER. Note that unlike traditional 3xx
codes which indicate that the client may continue the current
command, the legacy 381 code means that the AUTHINFO PASS command
must be used to complete the authentication exchange.
[2] If authentication has already occurred, AUTHINFO USER/PASS are
not valid commands (see section 2.2).
NOTE: Notwithstanding section 3.2.1 of [NNTP], the server MUST NOT
return 480 in response to AUTHINFO USER/PASS.
Parameters
username = UTF-8 string identifying the user/client
password = UTF-8 string representing the user's password
2.3.2. Description
The AUTHINFO USER and AUTHINFO PASS commands are used to present
clear text credentials to the server. These credentials consist of
Vinocur, et. al. Expires July 2005 [Page 7]
Internet Draft NNTP Authentication January 2005
a username or a username plus a password (the distinction is that a
password is expected to be kept secret while a username is not;
[890 lines skipped]
- CVS gsasl/doc/specification,
gsasl-commit <=