Network Working Group J. Vinocur
Request for Comments: 4643 Cornell University
Updates: 2980 K. Murchison
Category: Standards Track Carnegie Mellon University
October 2006
Network News Transfer Protocol (NNTP)
Extension for Authentication
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document defines an extension to the Network News Transfer Protocol (NNTP) that allows a client to indicate an authentication mechanism to the server, to perform an authentication protocol exchange, and optionally to negotiate a security layer for subsequent protocol interactions during the remainder of an NNTP session.
この文書では、クライアントは、サーバへの認証メカニズムを示すために、認証プロトコル交換を実行するために、そして必要に応じてANの残りの間、その後のプロトコル相互作用のためのセキュリティ層を交渉することを可能にするネットワークニュース転送プロトコル（NNTP）への拡張を定義しますNNTPセッション。
This document updates and formalizes the AUTHINFO USER/PASS authentication method specified in RFC 2980 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.
このドキュメントの更新およびRFC 2980で指定されたAUTHINFO USER / PASS認証方法を形式化し、AUTHINFOのSIMPLEとAUTHINFO GENERIC認証方法を非難します。また、この文書では、NNTPのための簡易認証セキュリティー層（SASL）のプロファイルを定義します。
Table of Contents
目次
1. Introduction ............................................. 3
1.1. Conventions Used in This Document ................... 3
2. The AUTHINFO Extension ................................... 4
2.1. Advertising the AUTHINFO Extension .................. 4
2.2. Authenticating with the AUTHINFO Extension .......... 5
2.3. AUTHINFO USER/PASS Command .......................... 6
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 .................................. 11
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 ............................... 18
4. Summary of Response Codes ................................ 18
5. Authentication Tracking/Logging .......................... 18
6. Security Considerations .................................. 19
7. IANA Considerations ...................................... 20
7.1. IANA Considerations for SASL/GSSAPI Services ........ 20
7.2. IANA Considerations for NNTP Extensions ............. 20
8. Acknowledgements ......................................... 21
9. References ............................................... 22
9.1. Normative References ................................ 22
9.2. Informative References .............................. 22
Although NNTP [NNTP] has traditionally been used to provide public access to newsgroups, authentication is often useful for several purposes; for example, to control resource consumption, to allow abusers of the POST command to be identified, and to restrict access to "local" newsgroups.
NNTPは、[NNTP]伝統的にニュースグループへのパブリックアクセスを提供するために使用されてきたが、認証には、多くの場合、いくつかの目的のために有用です。例えば、POSTコマンドの乱用者を識別できるようにするために、リソースの消費を制御するため、および「ローカル」ニュースグループへのアクセスを制限します。
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.
[NNTP-COMMON]に記載のアドホックAUTHINFOユーザとAUTHINFO PASSコマンドは、インストールベースによって広く使用されている非常に弱い認証メカニズムを提供します。それらの普遍性に、彼らは唯一の適切なセキュリティ層と組み合わせて使用する（ため、その不安の）本明細書に形式化されているが、。
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 Simple Mail Transfer Protocol (SMTP) [SMTP-AUTH], Post Office Protocol (POP) [POP-AUTH], Internet Message Access Protocol (IMAP) [IMAP], Lightweight Directory Access Protocol (LDAP) [LDAP-AUTH], and Blocks Extensive Exchange Protocol (BEEP) [BEEP].
アドホックAUTHINFO GENERICコマンド、また[NNTP-COMMON]に記載が、はるかに少ないユビキタスは、一般的なSASL [SASL]施設のNNTP特異的等価物を提供しました。 NNTPは、簡易メール転送プロトコル（SMTP）[SMTP-AUTH]、ポストオフィスプロトコル（POP）[含む他のSASL対応アプリケーションプロトコル用に開発された認証メカニズムの恩恵を受けることができるように、この文書では、AUTHINFO SASL交換の賛成でAUTHINFO GENERICを非難しますPOP-AUTH]、インターネットメッセージアクセスプロトコル（IMAP）[IMAP]、LDAP（Lightweight Directory Access Protocol）の[LDAP-AUTH]、およびブロック豊富な交換プロトコル（BEEP）[BEEP]。
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.
この仕様は、[NNTP] NNTPベースの仕様と併せて読まれるべきです。具体的には、これら二つの文書の間の競合の場合、特に明記しない場合を除いて、[NNTP]これよりも優先されます。
It is also recommended that this specification be read in conjunction with the SASL base specification [SASL].
また、この仕様はSASLベース仕様[SASL]と併せて読むことが推奨されます。
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 it does in that one.
この文書で使用されている表記規則は、[NNTP]と同じであり、それは1つの場合と同様、この文書で定義されていない用語は同じ意味を持っています。
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].
キーワード「REQUIRED」、「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」RFCsにおける使用のためのキーワード」で説明したように、このドキュメントの「MAY」、および「OPTIONAL」は解釈されるべきです要件レベル」[KEYWORDS]を示すために。
Terms related to authentication are defined in "On Internet Authentication" [AUTH].
認証に関連する用語は、「オンインターネット認証」[AUTH]で定義されています。
In the examples, commands from the client are indicated with [C], and responses from the server are indicated with [S].
実施例では、クライアントからのコマンドは、[C]で示され、そしてサーバからの応答は、[S]で示されています。
The AUTHINFO extension is used to authenticate a user. Note that authorization is a matter of site policy, not network protocol, and therefore it is not discussed in this document. The server determines authorization in whatever manner is defined by its implementation as configured by the site administrator.
AUTHINFO拡張は、ユーザーを認証するために使用されます。その承認はサイトポリシーではなく、ネットワークプロトコルの問題であり、したがって、それは、この文書で説明されていません。サーバーは、サイト管理者によって設定された方法は、その実装によって定義されているもので、許可を決定します。
This extension provides three new commands: AUTHINFO USER, AUTHINFO PASS, and AUTHINFO SASL. The capability label for this extension is AUTHINFO.
AUTHINFOのUSER、AUTHINFO PASS、およびAUTHINFO SASL：この拡張モジュールは、3の新しいコマンドを提供します。この拡張のための能力ラベルはAUTHINFOです。
A server MUST implement at least one of the AUTHINFO USER or AUTHINFO SASL commands in order to advertise the "AUTHINFO" capability label in response to the CAPABILITIES command ([NNTP] Section 5.2). However, this capability MUST NOT be advertised after successful authentication (see Section 2.2). This capability MAY be advertised both before and after any use of the MODE READER command ([NNTP] Section 5.3), with the same semantics.
サーバーが実装しなければならないAUTHINFOユーザーまたはAUTHINFO SASLの少なくとも一つは、capabilitiesコマンド（[NNTP]セクション5.2）に対応して「AUTHINFO」機能ラベルを宣伝するために、コマンド。ただし、この機能は、認証が成功した後に広告を出してはならない（2.2節を参照してください）。この機能は、同じ意味で、MODEのREADERコマンド（[NNTP]セクション5.3）のいずれかの使用前と後の両方公示されるかもしれません。
The AUTHINFO capability label contains an argument list detailing which authentication commands are available.
AUTHINFO機能ラベルは、コマンドが利用可能な認証詳述引数リストが含まれています。
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., Transport Layer Security (TLS) [NNTP-TLS]) is in use or backward compatibility dictates otherwise.
「USER」引数は、このドキュメントのセクション2.3で定義されているようAUTHINFOのUSER / PASSがサポートされていることを示しています。 「USER」引数が広告を出してはならない、と強力な暗号化層（例えば、トランスポート層セキュリティ（TLS）[NNTP-TLS]）が使用されているか、下位互換性が示されない限りAUTHINFO USER / PASSコマンドは、提供されるべきではありません。
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.
「SASL」引数は、このドキュメントのセクション2.4で定義されているようAUTHINFO SASLがサポートされていることを示しています。サーバは、「SASL」引数を宣伝している場合、それはまた、capabilitiesコマンドに応じて、「SASL」機能をアドバタイズする必要があります。 SASL能力は、利用可能なSASL機構名の空白で区切られたリストが続きます。
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 that might otherwise cause it to do so (e.g., for backward compatibility with servers that are not compliant with this specification).
サーバーは、それがこの仕様に準拠しており、現在の状態で任意の認証コマンドを許可しないことを示す、引数なしでAUTHINFO機能をリストアップしてもよいです。この場合、クライアントは、それがそうでない場合（この仕様に準拠していないサーバとの下位互換性のために、例えば）それはそうすることがありますロジックが含まれている場合でも、いずれかのAUTHINFOコマンドを利用することを試みてはいけません。
Future extensions may add additional arguments to this capability. Unrecognized arguments MUST be ignored by the client.
将来の拡張機能は、この機能に追加の引数を追加することができます。認識されない引数は、クライアントによって無視されなければなりません。
As the AUTHINFO command is related to security, cached results of CAPABILITIES from a previous session MUST NOT be relied on, as per Section 12.6 of [NNTP]. However, a client MAY use such cached results in order to detect active down-negotiation attacks.
AUTHINFOコマンドは、セキュリティに関連していると、前のセッションからの能力をキャッシュされた結果は、[NNTP]のセクション12.6に従って、当てにしてはなりません。ただし、クライアントがアクティブダウン交渉の攻撃を検出するために、このようなキャッシュされた結果を使用するかもしれません。
Example of AUTHINFO capabilities before and after the use of the STARTTLS [NNTP-TLS] extension:
STARTTLS [NNTP-TLS]拡張の使用前後AUTHINFO機能の例：
[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] [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] IHAVE [S] AUTHINFO USER SASL [S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN EXTERNAL [S] LIST ACTIVE NEWSGROUPS [S] .
[C] CAPABILITIES [S] 101の能力リスト：[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はTLSネゴシエーション[TLSネゴシエーション進み、TLSによって保護され、さらに、コマンド]に進み、[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] READER [S] IHAVE [S] AUTHINFOユーザSASL [S]のSASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN EXTERNAL [S] LIST ACTIVE NEWSGROUPS [S]。
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.
NNTPサーバは、クライアントが認証および/またはそのコマンドを使用するか、指定されたリソースにアクセスするために承認しなければならないことを示すために、480応答でクライアントコマンドに応答します。 AUTHINFOコマンドの使用以下に説明するように、クライアントがサーバーに認可/認証できることをこのような方法の1つです。クライアントは、したがって、480応答を受信した後、AUTHINFOコマンドを使用するかもしれません。 AUTHINFOコマンドを使用しようとするクライアントは、機能が認証を試みる前に、利用可能な認証コマンドとメカニズムを得るために、コマンドを発行する必要があります。
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.
サーバがAUTHINFO機能をアドバタイズした場合、クライアントは480応答を受信したことなく、追加の権限を取得するために、セッション中にいつでも認証の第1段階を試みるかもしれません。サーバーは、このような迷惑認証要求を受け入れる必要があります。サーバは、どのような状況下で480応答とAUTHINFOコマンドに応答してはいけません。
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.
クライアントは、サーバからの応答コードが認証交換が歓迎されていることを示していない限り、最初に越えた認証のいずれかの手順に進み、どのような状況の下ではいけません。特に、38X応答コード以外のものは、クライアントが認証交換を継続してはならないことを示しています。
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, the client MUST NOT issue a MODE READER command after authentication, and a server MUST NOT advertise the MODE-READER capability.
認証が成功すると、クライアントは、同じセッションで別のAUTHINFOコマンドを発行してはなりません。サーバーは、capabilitiesコマンドに応じてAUTHINFO機能を返してはならない、とサーバーは、その後のAUTHINFOは502応答でコマンドを拒絶しなければなりません。さらに、クライアントは、認証後のMODE READERコマンドを発行してはならない、とサーバはMODE-READERの機能をアドバタイズしてはなりません。
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 that it did 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 from 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.
[SASL]と一致して、サーバが機能は、認証前にやったSASLメカニズムの同じリストでコマンドに応答してSASLの機能をアドバタイズし続けなければならない（ことが可能アクティブダウン交渉攻撃を検出するようにクライアントを有効にします）。その他の機能は、認証が認証の前に戻ったものとは異なる場合があります後に受信capabilitiesコマンドに応答して返さ。たとえば、NNTPサーバは、クライアントが認証されていない限り、特定の拡張子をサポートすることを通知したくない場合があります。
Note 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 that a resource is unavailable even though authentication has been performed (this is in contrast to the temporary 480 error, which indicates that a resource is unavailable now but may become available after authentication).
サーバーがクライアントとの認証に成功交換を行い、それでもなお、一部またはすべてのリソースへのアクセスを拒否することができることに注意してください。永久502応答リソースが認証（これはリソースが現在利用できないが、認証後に利用可能になることを示している一時的な480エラーとは対照的である）が行われているにもかかわらず、使用できないことを示しています。
This section supersedes the definition of the AUTHINFO USER and AUTHINFO PASS commands as documented in Section 3.1.1 of [NNTP-COMMON].
このセクションでは、AUTHINFOユーザの定義を優先して、[NNTP-COMMON]のセクション3.1.1に記載のようにAUTHINFO PASSコマンド。
These commands MUST NOT be pipelined.
これらのコマンドは、パイプライン化されてはなりません。
Syntax AUTHINFO USER username AUTHINFO PASS password
構文AUTHINFO USERユーザ名AUTHINFO PASSパスワード
Responses 281 Authentication accepted 381 Password required [1] 481 Authentication failed/rejected 482 Authentication commands issued out of sequence 502 Command unavailable [2]
応答281認証は、[1] 481認証/ [2]配列から利用できない502コマンドを発行した482の認証コマンドを拒否失敗必要381パスワードを受け付け
[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.
[1] AUTHINFOユーザーにのみ有効です。クライアントは、現在のコマンドを続行する可能性があることを示し、伝統的なの3xxコードとは異なり、従来の381コードはAUTHINFO PASSコマンドは、認証情報の交換を完了するために使用されなければならない、ということを意味します。
[2] If authentication has already occurred, AUTHINFO USER/PASS are not valid commands (see Section 2.2).
[2]認証が既に発生している場合は、AUTHINFOのUSER / PASS有効なコマンド（2.2節を参照）ではありません。
NOTE: Notwithstanding Section 3.2.1 of [NNTP], the server MUST
NOT return 480 in response to AUTHINFO USER/PASS.
Parameters username = string identifying the user/client password = string representing the user's password
パラメータusername =文字列は、ユーザ/クライアントのパスワードを識別=ユーザのパスワードを表す文字列
The AUTHINFO USER and AUTHINFO PASS commands are used to present clear text credentials to the server. These credentials consist of a username or a username plus a password (the distinction is that a password is expected to be kept secret, whereas a username is not; this does not directly affect the protocol but may have an impact on user interfaces). The username is supplied through the AUTHINFO USER command, and the password through the AUTHINFO PASS command.
AUTHINFOのUSERおよびAUTHINFO PASSコマンドは、サーバーにクリアテキストの資格情報を提示するために使用されています。これらの証明書は、ユーザ名またはユーザ名プラスパスワードから成る（区別パスワードがユーザ名がないのに対し、秘密にされることが期待されていることであり、これは直接プロトコルに影響を及ぼさないが、ユーザーインターフェイスに影響を与えることができます）。ユーザー名は、AUTHINFO USERコマンドを介して供給され、およびAUTHINFO PASSコマンドでパスワードれます。
If the server requires only a username, it MUST NOT give a 381 response to AUTHINFO USER and MUST give a 482 response to AUTHINFO PASS.
サーバーは、ユーザー名のみを必要とする場合、それはAUTHINFOユーザーに381応答を与えてはならないとAUTHINFO PASSに482応答を与える必要があります。
If the server requires both username and password, the former MUST be sent before the latter. The server will need to cache the username until the password is received; it MAY require that the password be sent in the immediately next command (in other words, only caching the username until the next command is sent). The server:
サーバは、ユーザ名とパスワードの両方が必要な場合、前者は後者の前に送らなければなりません。サーバはパスワードが受信されるまで、ユーザ名をキャッシュする必要があります。それは、パスワードは（次のコマンドが送信されるまで、他の言葉で、ユーザー名のみをキャッシュする）すぐに次のコマンドで送信されることを必要とする場合があります。サーバー：
- MUST return a 381 response to AUTHINFO USER;
- AUTHINFOユーザーに381応答を返さなければなりません。
- MUST return a 482 response to AUTHINFO PASS if there is no cached username;
- キャッシュされたユーザ名が存在しない場合AUTHINFO PASSに482応答を返さなければなりません。
- MUST use the argument of the most recent AUTHINFO USER for authentication; and
- 認証のための最も最近のAUTHINFOのUSERの引数を使用する必要があります。そして
- MUST NOT return a 381 response to AUTHINFO PASS.
- AUTHINFO PASSに381応答を返してはなりません。
The server MAY determine whether a password is needed for a given username. Thus the same server can respond with both 381 and other response codes to AUTHINFO USER.
サーバーは、パスワードが与えられたユーザ名のために必要とされているかどうかを判断することができます。このように、同じサーバーは、AUTHINFOユーザーに381やその他の応答コードの両方に対応することができます。
Should the client successfully present proper credentials, the server issues a 281 reply. If the server is unable to authenticate the client, it MUST reject the AUTHINFO USER/PASS command with a 481 reply. If an AUTHINFO USER/PASS command fails, the client MAY proceed without authentication. Alternatively, the client MAY try another authentication mechanism or present different credentials by issuing another AUTHINFO command.
クライアントが正常に適切な資格情報を提示する必要があり、サーバーは281応答を発行します。サーバがクライアントを認証できない場合は、481応答でAUTHINFO USER / PASSコマンドを拒絶しなければなりません。 AUTHINFO USER / PASSコマンドが失敗した場合、クライアントは認証なしで進めることができます。また、クライアントは、別の認証機構を試すか、別のAUTHINFOコマンドを発行することにより、別の資格情報を提示することができます。
The AUTHINFO PASS command permits the client to use a clear-text password to authenticate. A compliant implementation MUST NOT implement this command without also implementing support for TLS [NNTP-TLS]. Use of this command without an active strong encryption layer 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 command SHOULD be configurable to disable it whenever a strong encryption layer (such as that provided by [NNTP-TLS]) is not active, and this configuration SHOULD be the default. The server will use the 483 response code to indicate that the datastream is insufficiently secure for the command being attempted (see Section 3.2.1 of [NNTP]).
AUTHINFO PASSコマンドは、認証するためにクリアテキストのパスワードを使用するようにクライアントを許可します。準拠した実装では、TLS [NNTP-TLS]のサポートを実装せずにこのコマンドを実装してはなりません。それは、クライアントとサーバー間のネットワーク上のすべての関係者にユーザーのパスワードを公開してアクティブな強力な暗号化層なしでこのコマンドの使用は、推奨されません。 （例えば[NNTP-TLS]によって提供されるような）強力な暗号化レイヤがアクティブでないときには、このコマンドのいずれかの実装では、それを無効にするように構成されるべきであり、この構成はデフォルトであるべきです。サーバーがコマンドを試行されるためにデータストリームが十分に安全であることを示すために、483応答コードを使用する（[NNTP]のセクション3.2.1を参照）。
Note that a server MAY (but is not required to) allow white space characters in usernames and passwords. A server implementation MAY blindly split command arguments at white space and therefore may not preserve the exact sequence of white space characters in the username or password. Therefore, a client SHOULD scan the username and password for white space and, if any is detected, warn the user of the likelihood of problems. The SASL PLAIN [PLAIN] mechanism is recommended as an alternative, as it does not suffer from these issues.
サーバーMAYは、ユーザー名とパスワードで空白文字を許可する（ただし、する必要はありません）ことに注意してください。サーバの実装は、盲目的にホワイトスペースでコマンド引数を分割することができるため、ユーザー名やパスワードに空白文字の正確な配列を保存しない場合があります。そのため、クライアントは空白のユーザー名とパスワードをスキャンし、いずれかが検出された場合、問題の可能性をユーザーに警告するべきです。それはこれらの問題に悩まされないようSASL PLAIN [PLAIN]メカニズムは、代替として推奨されます。
Also note that historically the username is not canonicalized in any way. Servers MAY use the [SASLprep] profile of the [StringPrep] algorithm to prepare usernames for comparison, but doing so may cause interoperability problems with legacy implementations. If canonicalization is desired, the SASL PLAIN [PLAIN] mechanism is recommended as an alternative.
また、歴史的にユーザ名がどのような方法で正規化されていないことに注意してください。サーバは、比較のためにユーザ名を準備するために、[STRINGPREP]アルゴリズムの[SASLprep]プロファイルを使用することができるが、そうすることは、従来の実装との相互運用性の問題を引き起こす可能性があります。正規化が望まれる場合、SASL PLAIN [PLAIN]メカニズムは、代替として推奨されています。
Example of successful AUTHINFO USER:
成功AUTHINFOのUSERの例：
[C] AUTHINFO USER wilma [S] 281 Authentication accepted
[C] AUTHINFOユーザウィルマ[S] 281認証可
Example of successful AUTHINFO USER/PASS:
成功AUTHINFOのUSER / PASSの例：
[C] AUTHINFO USER fred [S] 381 Enter passphrase [C] AUTHINFO PASS flintstone [S] 281 Authentication accepted
[C] AUTHINFO USERフレッド[S] 381は、入力パスフレーズ[C] AUTHINFO PASSフリント[S] 281認証受け入れ
Example of AUTHINFO USER/PASS requiring a security layer:
セキュリティ層を必要AUTHINFOユーザ/ PASSの例：
[C] AUTHINFO USER fred@stonecanyon.example.com [S] 483 Encryption or stronger authentication required
[C] AUTHINFOユーザfred@stonecanyon.example.com [S] 483暗号化または強力な認証に必要な
Example of failed AUTHINFO USER/PASS:
失敗したAUTHINFOのUSER / PASSの例：
[C] AUTHINFO USER barney [S] 381 Enter passphrase [C] AUTHINFO PASS flintstone [S] 481 Authentication failed
[C] AUTHINFOユーザバーニー[S] 381 [C] AUTHINFO PASSフリント[S] 481認証が失敗したパスフレーズを入力してください
Example of AUTHINFO PASS before AUTHINFO USER:
AUTHINFOのUSER前AUTHINFO PASSの例：
[C] AUTHINFO PASS flintstone [S] 482 Authentication commands issued out of sequence
[C] AUTHINFO PASSフリント[S]配列から発行された482個の認証コマンド
This section defines a formal profile of the Simple Authentication and Security Layer [SASL]. The use of the AUTHINFO GENERIC command as documented in Section 3.1.3 of [NNTP-COMMON], as a way to perform SASL authentication, is deprecated in favor of the AUTHINFO SASL command. A server SHOULD NOT advertise AUTHINFO GENERIC in the list of capabilities returned by CAPABILITIES.
このセクションでは、簡易認証セキュリティー層[SASL]の正式なプロファイルを定義します。 SASL認証を実行するための方法として、[NNTP-COMMON]のセクション3.1.3に記載のようにAUTHINFO GENERICコマンドを使用することは、AUTHINFO SASLコマンドを支持して非難されています。サーバは、能力によって返された機能のリストにAUTHINFO GENERICを宣伝すべきではありません。
This command MUST NOT be pipelined.
このコマンドは、パイプライン化されてはなりません。
Syntax AUTHINFO SASL mechanism [initial-response]
構文AUTHINFO SASL機構[初期応答]
This command MAY exceed 512 octets. The maximum length of this command is increased to that which can accommodate the largest encoded initial response possible for any of the SASL mechanisms supported by the implementation.
このコマンドは、512個のオクテットを超えてもよいです。このコマンドの最大長さは、実装によってサポートされるSASLメカニズムの任意の可能な最大の符号化された初期応答を受け入れることができるものに上昇させます。
Responses 281 Authentication accepted 283 challenge Authentication accepted (with success data) [1] 383 challenge Continue with SASL exchange [1] 481 Authentication failed/rejected 482 SASL protocol error 502 Command unavailable [2]
281認証は、[1] 383チャレンジSASL交換を続行し（成功データと）受け入れ283チャレンジ認証を受け入れ応答[1] 481認証が失敗した/使用不能482 SASLプロトコルエラー502コマンドを拒否[2]
[1] These responses MAY exceed 512 octets. The maximum length of these responses is increased to that which can accommodate the largest encoded challenge possible for any of the SASL mechanisms supported by the implementation.
[1]これらの応答は512個のオクテットを超える可能性があります。これらの応答の最大長さは、実装によってサポートされるSASLメカニズムの任意の可能な最大の符号化されたチャレンジに対応できるものに上昇させます。
[2] If authentication has already occurred, AUTHINFO SASL is not a valid command (see Section 2.2).
[2]認証が既に発生している場合は、AUTHINFO SASLが有効なコマンドではありません（2.2節を参照してください）。
NOTE: Notwithstanding Section 3.2.1 of [NNTP], the server MUST
NOT return 480 in response to AUTHINFO SASL.
Parameters mechanism = String identifying a [SASL] authentication mechanism. initial-response = Optional initial client response. If present, the response MUST be encoded as specified in Section 4 of [BASE64]. [3] challenge = Server challenge. The challenge MUST be encoded as specified in Section 4 of [BASE64].
パラメータ機構= [SASL]認証メカニズムを識別する文字列。初期応答=オプションの初期のクライアント応答。 [BASE64]のセクション4で指定されるように存在する場合、応答は、符号化されなければなりません。 [3]挑戦=サーバーの挑戦。 [BASE64]のセクション4で指定されるような課題は、符号化されなければなりません。
[3] This argument MAY exceed 497 octets. The maximum length of this argument is increased to that which can accommodate the largest encoded initial response possible for any of the SASL mechanisms supported by the implementation.
[3]この引数は、497個のオクテットを超えてもよいです。この引数の最大長さは、実装によってサポートされるSASLメカニズムの任意の可能な最大の符号化された初期応答を受け入れることができるものに上昇させます。
The AUTHINFO SASL command initiates a [SASL] exchange between the client and the server. The client identifies the SASL mechanism to be used with the first parameter of the AUTHINFO SASL command. If the server supports the requested authentication mechanism, it performs the SASL exchange to authenticate the user. Optionally, it also negotiates a security layer for subsequent protocol interactions during this session. If the requested authentication mechanism is invalid (e.g., is not supported), the server rejects the AUTHINFO SASL command with a 503 reply (see Section 3.2.1 of [NNTP]). If the requested authentication mechanism requires an encryption layer, the server rejects the AUTHINFO SASL command with a 483 reply (see Section 3.2.1 of [NNTP]).
AUTHINFO SASLコマンドは、クライアントとサーバ間の[SASL]交換を開始します。クライアントは、AUTHINFO SASLコマンドの最初のパラメータで使用するSASLメカニズムを識別する。サーバは要求された認証メカニズムをサポートしている場合、それは、ユーザを認証するためにSASL交換を行います。必要に応じて、それはまた、このセッション中に後続のプロトコル相互作用のためのセキュリティ層を交渉します。要求された認証機構が無効である場合（例えば、サポートされていない）、サーバは503応答（[NNTP]のセクション3.2.1を参照）AUTHINFO SASLコマンドを拒否する。要求された認証機構は、暗号化層を必要とする場合、サーバーは483リプライ（[NNTP]の3.2.1項を参照）でAUTHINFO SASLコマンドを拒否します。
The service name specified by this protocol's profile of SASL is "nntp".
SASLのこのプロトコルのプロファイルで指定されたサービス名は「NNTP」です。
The SASL exchange consists of a series of server challenges and client responses that are specific to the chosen [SASL] mechanism.
SASL交換が選ばれた[SASL]メカニズムに固有のサーバーチャレンジとクライアントの一連の応答で構成されています。
A server challenge is sent as a 383 reply with a single argument containing the [BASE64]-encoded string supplied by the SASL mechanism. A server challenge that has zero length MUST be sent as a single equals sign ("=") and MUST be included (in order to comply with the [NNTP] requirement that responses always have the same number of arguments).
サーバチャレンジはSASL機構によって供給された[BASE64]エンコードされた文字列を含む単一の引数と383の応答として送信されます。ゼロの長さを有するサーバチャレンジは、単一の等号（「=」）として送信されなければならないと（応答は常に引数の数が同じ[NNTP]要件を遵守するために）を含まなければなりません。
A client response consists of a line containing a [BASE64]-encoded string. A client response that has zero length MUST be sent as a single equals sign ("=") and MUST be included (for consistency with the server challenge format). If the client wishes to cancel the authentication exchange, it issues a line with a single "*". If the server receives such a response, it MUST reject the AUTHINFO SASL command by sending a 481 reply.
クライアントの応答は、[BASE64]エンコードされた文字列を含む行で構成されています。ゼロの長さを有するクライアントの応答は、単一の等号（「=」）として送信されなければならないと（サーバチャレンジフォーマットとの整合性のために）を含まなければなりません。クライアントが認証交換を中止したい場合は、「*」の単一の行を発行します。サーバがそのような応答を受信した場合、それは481応答を送信することにより、AUTHINFO SASLコマンドを拒絶しなければなりません。
Note that these [BASE64]-encoded strings can be much longer than normal NNTP responses. Clients and servers MUST be able to handle the maximum encoded size of challenges and responses generated by their supported authentication mechanisms. This requirement is independent of any line length limitations the client or server may have in other parts of its protocol implementation.
これらの[BASE64]でエンコード文字列は、通常のNNTP応答よりもはるかに長くなることに注意してください。クライアントとサーバーはそのサポートされる認証メカニズムによって生成されたチャレンジとレスポンスの最大エンコードサイズを扱うことができなければなりません。この要件は、クライアントまたはサーバーがそのプロトコル実装の他の部分で持っている可能性のある行の長さの制限とは無関係です。
The optional initial response argument to the AUTHINFO SASL command is used to save a round trip when using authentication mechanisms that support an initial client response. If the initial response argument is omitted and the chosen mechanism requires an initial client response, the server MUST proceed as defined in section 5.1 of
AUTHINFO SASLコマンドにオプションの初期応答引数は、初期のクライアント応答をサポートする認証メカニズムを使用した場合の往復を保存するために使用されます。初期応答引数を省略し、選択されたメカニズムは、初期のクライアント応答を必要とした場合のセクション5.1で定義されているように、サーバは続行しなければなりません
[SASL]. In NNTP, a server challenge that contains no data is equivalent to a zero-length challenge and is encoded as a single equals sign ("=").
[SASL]。 NNTPでは、データを含まないサーバチャレンジは、長さゼロの挑戦に相当し、単一の等号（「=」）として符号化されます。
Note that the [BASE64]-encoded initial response argument can exceed 497 octets, and therefore that the AUTHINFO SASL command can exceed 512 octets. Clients SHOULD and servers MUST be able to handle the maximum encoded size of initial responses possible for their supported authentication mechanisms. This requirement is independent of any command or argument length limitations the client or server may have in other parts of its protocol implementation.
[BASE64]が497個のオクテットを超えることができる初期応答引数でエンコードすることを、したがってAUTHINFO SASLコマンドが512個のオクテットを超えることができることに留意されたいです。クライアントはすべきであり、サーバーは、サポートされている認証メカニズムのための可能な初期応答の最大エンコードサイズを扱うことができなければなりません。この要件は、クライアントまたはサーバーがそのプロトコル実装の他の部分で持つかもしれないコマンドや引数の長さの制限とは無関係です。
If use of the initial response argument would cause the AUTHINFO SASL command to exceed 512 octets, the client MAY choose to omit the initial response parameter (and instead proceed as defined in Section 5.1 of [SASL]).
初期応答引数の使用がAUTHINFO SASLコマンドは512個のオクテットを超過する場合は、クライアントは初期応答パラメータを省略することを選択するかもしれない（とのセクション5.1で定義されるように代わりに進み[SASL]）。
If the client is transmitting an initial response of zero length, it MUST instead transmit the response as a single equals sign ("="). This indicates that the response is present, but that it contains no data.
クライアントは、長さゼロの初期応答を送信している場合、それは代わりに、単一の等号（「=」）のような応答を送信しなければなりません。これは、応答が存在することを示しているが、それは何のデータが含まれていないこと。
If the client uses an initial-response argument to the AUTHINFO SASL command with a SASL mechanism that does not support an initial client response, the server MUST reject the AUTHINFO SASL command with a 482 reply.
クライアントが初期のクライアント応答をサポートしていないSASLメカニズムとAUTHINFO SASLコマンドへの初期応答の引数を使用している場合、サーバーは482応答でAUTHINFO SASLコマンドを拒絶しなければなりません。
If the server cannot [BASE64] decode any client response, it MUST reject the AUTHINFO SASL command with a 504 reply (see Section 3.2.1 of [NNTP]). If the client cannot BASE64 decode any of the server's challenges, it MUST cancel the authentication using the "*" response. In particular, servers and clients MUST reject (and not ignore) any character not explicitly allowed by the BASE64 alphabet, and they MUST reject any sequence of BASE64 characters that contains the pad character ('=') anywhere other than the end of the string (e.g., "=AAA" and "AAA=BBB" are not allowed).
サーバは[BASE64]すべてのクライアント応答を復号化できない場合は、504応答（[NNTP]のセクション3.2.1を参照）AUTHINFO SASLコマンドを拒絶しなければなりません。クライアントは、BASE64は、サーバの課題のいずれかをデコードすることができない場合は、「*」レスポンスを使用して認証をキャンセルしなければなりません。具体的には、サーバとクライアントは、（無視しません）拒絶しなければなりません任意の文字は、明示的にBASE64アルファベットで許可されていない、と彼らは、文字列の末尾以外のパッド文字（「=」）どこかが含まれているBASE64の任意の文字列を拒絶しなければなりません（例えば、 "= AAA" と "AAA = BBB" が許可されていません）。
The authorization identity generated by this [SASL] exchange is a simple username, and both client and server MUST use the [SASLprep] profile of the [StringPrep] algorithm to prepare these names for transmission or comparison. If preparation of the authorization identity fails or results in an empty string (unless it was transmitted as the empty string), the server MUST fail the authentication with a 481 reply.
この[SASL]交換により生成された認可IDは、単純なユーザー名であり、クライアントとサーバーの両方が、送信または比較のためにこれらの名前を準備するために、[STRINGPREP]アルゴリズムの[SASLprep]プロファイルを使用しなければなりません。 （それは空の文字列として送信された場合を除く）認可IDの作成が失敗した場合や、空の文字列での結果ならば、サーバは481応答での認証に失敗しなければなりません。
Should the client successfully complete the exchange, the server issues either a 281 or a 283 reply. If the server is unable to authenticate the client, it MUST reject the AUTHINFO SASL command with a 481 reply. If an AUTHINFO SASL command fails, the client MAY proceed without authentication. Alternatively, the client MAY try another authentication mechanism, or present different credentials by issuing another AUTHINFO command.
クライアントが正常に交換を完了する必要があり、サーバーの問題のいずれか281か283回答。サーバがクライアントを認証できない場合は、481応答でAUTHINFO SASLコマンドを拒絶しなければなりません。 AUTHINFO SASLコマンドが失敗した場合、クライアントは認証なしで進めることができます。また、クライアントは、別の認証機構を試すか、別のAUTHINFOコマンドを発行することにより、別の資格情報を提示することができます。
If the SASL mechanism returns additional data on success (e.g., server authentication), the NNTP server issues a 283 reply with a single argument containing the [BASE64]-encoded string supplied by the SASL mechanism. If no additional data is returned on success, the server issues a 281 reply.
SASL機構が成功（例えば、サーバー認証）に追加のデータを返す場合、NNTPサーバはSASL機構によって供給された[BASE64]エンコードされた文字列を含む単一の引数と283応答を発行します。追加データが成功した場合に返されない場合、サーバは281応答を発行します。
If a security layer is negotiated during the SASL exchange, it takes effect for the client on the octet immediately following the CRLF that concludes the last response generated by the client. For the server, it takes effect immediately following the CRLF of its success reply.
セキュリティ層がSASL交換の間に交渉された場合、それはすぐに、クライアントによって生成された最後の応答を終えるCRLF、次のオクテット上のクライアントのために有効になります。サーバーの場合、それはその成功リプライのCRLFの直後に有効になります。
When a security layer takes effect, the NNTP protocol is reset to the state immediately after the initial greeting response (see 5.1 of [NNTP]) has been sent, with the exception that if a MODE READER command has been issued, the effects of it (if any) are not reversed. The server MUST discard any knowledge obtained from the client, such as the current newsgroup and article number, that was not obtained from the SASL negotiation itself. Likewise, the client SHOULD discard and MUST NOT rely on any knowledge obtained from the server, such as the capability list, that was not obtained from the SASL negotiation itself. (Note that a client MAY compare the advertised SASL mechanisms before and after authentication in order to detect an active down-negotiation attack.)
セキュリティ層が有効になるときは、NNTPプロトコルは、直ちに初期グリーティング応答モードREADERコマンドが発行された場合以外は、送られてきた（[NNTP]の5.1を参照）後の状態にリセットされ、それの効果（もしあれば）逆になっていません。サーバーは、SASL交渉自体から得られなかった現在のニュースグループと記事数、として、クライアントから得た知識を捨てなければなりません。同様に、クライアントが破棄すべきであると、このようなSASL交渉自体から得られなかった機能のリストとして、サーバから取得したすべての知識に頼ってはなりません。 （クライアントがアクティブダウン交渉の攻撃を検出するために、認証の前後に広告を出してSASLメカニズムを比較することができることに注意してください。）
When both TLS [NNTP-TLS] and SASL security layers are in effect, the TLS encoding MUST be applied after the SASL encoding (the cleartext data is always SASL encoded first, and then the resultant data is TLS encoded).
TLS [NNTP-TLS]との両方SASLセキュリティ層が有効である場合、TLS符号化が（クリアテキストデータが常にSASLが最初に符号化し、その後、得られたデータは、TLSが符号化された）SASL符号化後に適用されなければなりません。
To ensure interoperability, client and server implementations of this extension MUST implement the [DIGEST-MD5] SASL mechanism.
相互運用性を確保するために、この拡張機能のクライアントとサーバの実装は、[DIGEST-MD5] SASLメカニズムを実装しなければなりません。
If AUTHINFO USER/PASS and AUTHINFO SASL are both implemented, the SASL [PLAIN] mechanism SHOULD also be implemented, as the functionality of DIGEST-MD5 is insufficient for some environments (e.g., the server may need to pass off the plaintext password to an external authentication service). The SASL PLAIN mechanism is preferred over AUTHINFO USER, even if there is not a strong encryption layer active, because it eliminates limitations that AUTHINFO USER/PASS has with regards to the use of white space characters being used in usernames and passwords.
AUTHINFOのUSER / PASSとAUTHINFO SASLの両方実装されている場合、SASL [PLAIN]メカニズムは、DIGEST-MD5の機能は、いくつかの環境（例えば、サーバーが平文パスワードをオフに渡す必要があるかもしれないため不十分であるとして、実装されるべき外部認証サービス）。それがAUTHINFOのUSER / PASSは、ユーザー名とパスワードに使用されている空白文字の使用に関して持っていることの制限がなくなるためSASL PLAIN機構は、アクティブな強力な暗号化層が存在しない場合でも、AUTHINFOユーザーよりも好ましいです。
Example of the [PLAIN] SASL mechanism under a TLS layer, using an initial client response:
初期クライアントの応答を使用してTLS層の下の[PLAIN] SASL機構の例：
[C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [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] [C] CAPABILITIES [S] 101 Capability list: [S] VERSION 2 [S] READER [S] AUTHINFO USER SASL [S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN EXTERNAL [S] LIST ACTIVE NEWSGROUPS [S] . [C] AUTHINFO SASL PLAIN AHRlc3QAMTIzNA== [S] 281 Authentication accepted
[C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] READER [S] STARTTLS [S] AUTHINFO SASL [S]のSASL CRAM-MD5 DIGEST-MD5 GSSAPI [S] LIST ACTIVE NEWSGROUPS [S]。 [C] STARTTLS [S] 382はTLSネゴシエーションを続行[TLSネゴシエーション進み、TLSによって保護され、さらに、コマンド] [C] CAPABILITIES [S] 101の能力リスト：[S] VERSION 2 [S] READER [S] AUTHINFOユーザSASL [ S]のSASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN EXTERNAL [S] LIST ACTIVE NEWSGROUPS [S]。 [C] AUTHINFO SASL PLAIN AHRlc3QAMTIzNA == [S] 281認証可
Example of the EXTERNAL SASL mechanism under a TLS layer, using the authorization identity derived from the client TLS certificate, and thus a zero-length initial client response (commands prior to AUTHINFO SASL are the same as the previous example and have been omitted):
クライアントTLS証明書から派生認証アイデンティティを使用して、TLS層の下EXTERNAL SASL機構の一例、および、したがってゼロ長初期のクライアント応答（前AUTHINFO SASLへのコマンドは、前の例と同じであり、省略されています）。
[C] AUTHINFO SASL EXTERNAL = [S] 281 Authentication accepted
[C] AUTHINFO SASL EXTERNAL = [S] 281認証可
Example of the [DIGEST-MD5] SASL mechanism, which includes a server challenge and server success data (white space has been inserted for clarity; base64-encoded data is actually sent as a single line with no embedded white space):
サーバチャレンジとサーバ成功データを含む[DIGEST-MD5] SASL機構（ホワイトスペースは明確にするために挿入された、Base64でエンコードされたデータは、実際には埋め込まれたホワイトスペースを有する単一の行として送信される）の例：
[C] AUTHINFO SASL DIGEST-MD5 [S] 383 bm9uY2U9InNheUFPaENFS0dJZFBNSEMwd3RsZUxxT0ljT0kyd1FZSWU0 enplQXR1aVE9IixyZWFsbT0iZWFnbGUub2NlYW5hLmNvbSIscW9wPSJhdXRo LGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJj NCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0 aG09bWQ1LXNlc3M=
[C] AUTHINFO SASL DIGEST-MD5 [S] 383 bm9uY2U9InNheUFPaENFS0dJZFBNSEMwd3RsZUxxT0ljT0kyd1FZSWU0 enplQXR1aVE9IixyZWFsbT0iZWFnbGUub2NlYW5hLmNvbSIscW9wPSJhdXRo LGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJj NCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0 aG09bWQ1LXNlc3M =
[C] dXNlcm5hbWU9InRlc3QiLHJlYWxtPSJlYWdsZS5vY2VhbmEuY29tIixub25j ZT0ic2F5QU9oQ0VLR0lkUE1IQzB3dGxlTHFPSWNPSTJ3UVlJZTR6emVBdHVp UT0iLGNub25jZT0iMFkzSlFWMlRnOVNjRGlwK08xU1ZDMHJoVmcvLytkbk9J aUd6LzdDZU5KOD0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLWNvbmYsY2lwaGVy PXJjNCxtYXhidWY9MTAyNCxkaWdlc3QtdXJpPSJubnRwL2xvY2FsaG9zdCIs cmVzcG9uc2U9ZDQzY2Y2NmNmZmE5MDNmOWViMDM1NmMwOGEzZGIwZjI= [S] 283 cnNwYXV0aD1kZTJlMTI3ZTVhODFjZGE1M2Q5N2FjZGEzNWNkZTgzYQ==
[C] dXNlcm5hbWU9InRlc3QiLHJlYWxtPSJlYWdsZS5vY2VhbmEuY29tIixub25j ZT0ic2F5QU9oQ0VLR0lkUE1IQzB3dGxlTHFPSWNPSTJ3UVlJZTR6emVBdHVp UT0iLGNub25jZT0iMFkzSlFWMlRnOVNjRGlwK08xU1ZDMHJoVmcvLytkbk9J aUd6LzdDZU5KOD0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLWNvbmYsY2lwaGVy PXJjNCxtYXhidWY9MTAyNCxkaWdlc3QtdXJpPSJubnRwL2xvY2FsaG9zdCIs cmVzcG9uc2U9ZDQzY2Y2NmNmZmE5MDNmOWViMDM1NmMwOGEzZGIwZjI = [S] 283 cnNwYXV0aD1kZTJlMTI3ZTVhODFjZGE1M2Q5N2FjZGEzNWNkZTgzYQ ==
Example of a failed authentication due to bad [GSSAPI] credentials. Note that although the mechanism can utilize the initial response, the client chooses not to use it because of its length, resulting in a zero-length server challenge (here, white space has been inserted for clarity; base64-encoded data is actually sent as a single line with no embedded white space):
悪い[GSSAPI]資格証明書による認証失敗の例。機構は、初期応答を利用することができるが、クライアントはここで、ホワイトスペースを明確にするために挿入された長さゼロのサーバチャレンジ（その結果、その長さのためにそれを使用しないことを選択したことに注意してください。base64エンコードデータが実際として送信されます埋め込まれていないホワイトスペースを持つ単一の行）：
[C] AUTHINFO SASL GSSAPI [S] 383 = [C] YIICOAYJKoZIhvcSAQICAQBuggInMIICI6ADAgEFoQMCAQ6iBwMFACAAAACj ggE/YYIBOzCCATegAwIBBaEYGxZURVNULk5FVC5JU0MuVVBFTk4uRURVoiQw IqADAgEDoRswGRsEbmV3cxsRbmV0bmV3cy51cGVubi5lZHWjge8wgeygAwIB EKEDAgECooHfBIHcSQfLKC8vm2i17EXmomwk6hHvjBY/BnKnvvDTrbno3198 vlX2RSUt+CjuAKhcDcj4DW0gvZEqH7t5v9yWedzztlpaThebBat6hQNr9NJP ozh1/+74HUwhGWb50KtjuftO/ftQ8q0nTuYKgIq6PM4tp2ddo1IfpjfdNR9E 95GFi3y1uBT7lQOwtQbRJUjPSO3ijdue9V7cNNVmYsBsqNsaHhvlBJEXf4WJ djH8yG+Dw/gX8fUTtC5fDpB5zLt01mkSXh6Wc4UhqQtwZBI2t/+TpX1okbg6 Hr1ZZupeH6SByjCBx6ADAgEQooG/BIG8GnCmcXWtqhXh48dGTLHQgJ04K5Fj RMMq2qPSbiha9lq0osqR2KAnQA6LioWYxU+6yPKpBDSC5WOT441fUfkM8iAL kW3uNc+luFCGcnDsacrmoVU7Y6Akcp9m7Fm7orRc+TWSWPpBg3OR2oG3ATW0 0NAz8TT06VOLVxIMUTINKdYVI/Ja7f3sy+/N4LGkJqScCQOwlo5tfDWn/UQF iTWo5Zw435rH8pjy2smQCnqC14v3NMAWTu4j+dzHUNw= [S] 481 Authentication error
[C] AUTHINFO SASL GSSAPI [S] 383 = [C] YIICOAYJKoZIhvcSAQICAQBuggInMIICI6ADAgEFoQMCAQ6iBwMFACAAAACj GGE / YYIBOzCCATegAwIBBaEYGxZURVNULk5FVC5JU0MuVVBFTk4uRURVoiQw IqADAgEDoRswGRsEbmV3cxsRbmV0bmV3cy51cGVubi5lZHWjge8wgeygAwIB EKEDAgECooHfBIHcSQfLKC8vm2i17EXmomwk6hHvjBY / BnKnvvDTrbno3198 vlX2RSUt + CjuAKhcDcj4DW0gvZEqH7t5v9yWedzztlpaThebBat6hQNr9NJP ozh1 / + 74HUwhGWb50KtjuftO / ftQ8q0nTuYKgIq6PM4tp2ddo1IfpjfdNR9E 95GFi3y1uBT7lQOwtQbRJUjPSO3ijdue9V7cNNVmYsBsqNsaHhvlBJEXf4WJ djH8yG + Dwの/ gX8fUTtC5fDpB5zLt01mkSXh6Wc4UhqQtwZBI2t / + TpX1okbg6 Hr1ZZupeH6SByjCBx6ADAgEQooG / BIG8GnCmcXWtqhXh48dGTLHQgJ04K5Fj RMMq2qPSbiha9lq0osqR2KAnQA6LioWYxU + 6yPKpBDSC5WOT441fUfkM8iAL kW3uNc + luFCGcnDsacrmoVU7Y6Akcp9m7Fm7orRc + TWSWPpBg3OR2oG3ATW0 0NAz8TT06VOLVxIMUTINKdYVI / Ja7f3sy + / N4LGkJqScCQOwlo5tfDWn / UQF iTWo5Zw435rH8pjy2smQCnqC14v3NMAWTu4j + dzHUNw = [S] 481認証エラー
Example of a client aborting in the midst of an exchange:
為替の真っ只中に中止クライアントの例：
[C] AUTHINFO SASL GSSAPI [S] 383 = [C] * [S] 481 Authentication aborted as requested
要求されたように[C] AUTHINFO SASL GSSAPI [S] 383 = [C] * [S] 481認証は中止しました
Example of attempting to use a mechanism that is not supported by the server:
サーバーによってサポートされていないメカニズムを使用しようとする例：
[C] AUTHINFO SASL EXAMPLE [S] 503 Mechanism not recognized
[C] AUTHINFO SASL例[S] 503メカニズムを認識しません
Example of attempting to use a mechanism that requires a security layer:
セキュリティ層を必要とメカニズムを使用しようとする例：
[C] AUTHINFO SASL PLAIN [S] 483 Encryption or stronger authentication required
[C] AUTHINFO SASL PLAIN [S] 483暗号化または強力な認証に必要な
Example of using an initial response with a mechanism that doesn't support it (the server must start the exchange when using [CRAM-MD5]):
（[CRAM-MD5]を使用するときに、サーバーが交換を開始しなければならない）をサポートしていない機構を初期応答の使用例：
[C] AUTHINFO SASL CRAM-MD5 AHRlc3QAMTIzNA== [S] 482 SASL protocol error
[C] AUTHINFO SASL CRAM-MD5 AHRlc3QAMTIzNA == [S] 482 SASLプロトコルエラー
Example of an authentication that failed due to an incorrectly encoded response:
原因間違ってエンコードされた応答に失敗した認証の例：
[C] AUTHINFO SASL CRAM-MD5 [S] 383 PDE1NDE2NzQ5My4zMjY4MzE3QHRlc3RAZXhhbXBsZS5jb20+ [C] abcd=efg [S] 504 Base64 encoding error
[C] AUTHINFO SASL CRAM-MD5 [S] 383 PDE1NDE2NzQ5My4zMjY4MzE3QHRlc3RAZXhhbXBsZS5jb20 + [C] ABCD = EFG [S] 504 Base64エンコードエラー
This section describes the formal syntax of the AUTHINFO extension using ABNF [ABNF]. It extends the syntax in Section 9 of [NNTP], and non-terminals not defined in this document are defined there. The [NNTP] ABNF should be imported first before attempting to validate these rules.
このセクションでは、ABNF [ABNF]を使用してAUTHINFO拡張の正式な構文について説明します。これは、[NNTP]のセクション9の構文を拡張し、この文書で定義されていない非端末はそこに定義されています。 [NNTP] ABNFはこれらの規則を検証しようとする前に、最初にインポートする必要があります。
This syntax extends the non-terminal "command", which represents an NNTP command.
この構文は、NNTPコマンドを表す非終端「コマンド」、延びています。
command =/ authinfo-sasl-command / authinfo-user-command / authinfo-pass-command
コマンド= / AUTHINFO-SASLコマンド/ AUTHINFOユーザコマンド/ AUTHINFO域通過コマンド
authinfo-sasl-command = "AUTHINFO" WS "SASL" WS mechanism [WS initial-response] authinfo-user-command = "AUTHINFO" WS "USER" WS username authinfo-pass-command = "AUTHINFO" WS "PASS" WS password
AUTHINFO-SASLコマンドは= "AUTHINFO" WS "SASL" WS機構[WS初期応答] AUTHINFOユーザコマンド= "AUTHINFO" WS "USER" WS名AUTHINFO域通過コマンド= "AUTHINFO" WS "PASS" WSパスワード
initial-response = base64-opt username = 1*user-pass-char password = 1*user-pass-char user-pass-char = B-CHAR
初期応答= base64でOPTのユーザー名= 1 *ユーザーパス文字のパスワード= 1 *ユーザーパスchar型のユーザー・パスCHAR = B-CHAR
NOTE: a server implementation MAY parse AUTHINFO USER and AUTHINFO PASS specially so as to allow white space to be used within the username or password. Such implementations accept the additional syntax (making these two items inconsistent with "token" in Section 9.8 of [NNTP]):
注：サーバーの実装は、AUTHINFO USERを解析することができると空白は、ユーザー名やパスワード内で使用することが可能となるようにAUTHINFOは特別に渡します。そのような実装では、追加の構文（[NNTP]のセクション9.8に「トークン」と矛盾これら二つのアイテムを作る）を受け入れます。
user-pass-char =/ SP / TAB
ユーザパスチャー= / SP / TAB
In doing so, the grammar can become ambiguous if the username or password begins or ends with white space. To solve this ambiguity, such implementations typically treat everything after the first white space character following "USER"/"PASS", up to, but not including, the CRLF, as the username/password.
ユーザ名またはパスワードが始まるか、空白で終わる場合そうすることで、文法があいまいになることができます。この曖昧さを解決するために、そのような実装は、通常、ユーザー名/パスワードとして、CRLFを含めまで、「USER」/「PASS」に続く最初の空白文字の後にすべての治療ではなく。
This syntax extends the non-terminal "command-continuation", which represents the further material sent by the client in the case of multi-stage commands.
この構文は、多段のコマンドの場合には、クライアントによって送信される更なる物質を表す非末端「コマンド継続」、延びています。
command-continuation =/ authinfo-sasl-383-continuation
コマンド継続= / AUTHINFO-SASL-383-継続
authinfo-sasl-383-continuation = ("*" / base64-opt) CRLF
AUTHINFO-SASL-383-継続=（ "*" / base64でOPT）CRLF
This syntax extends the non-terminal "initial-response-content", which represents an initial response line sent by the server.
この構文は、サーバによって送信された初期応答ラインを表す非終端「初期応答内容」、延びています。
initial-response-content =/ response-283-content / response-383-content
初期応答内容= /応答-283-コンテンツ/レスポンス-383-コンテンツ
response-283-content = "283" SP base64 response-383-content = "383" SP base64-opt
応答-283-コンテンツ= "283" SPのbase64で応答-383-コンテンツ= "383" SPのbase64でOPT
This syntax extends the non-terminal "capability-entry", which represents a capability that may be advertised by the server.
この構文は、サーバによって通知することができる能力を表す非末端「機能エントリ」を、延びています。
capability-entry =/ authinfo-capability / sasl-capability
機能-エントリ= / AUTHINFO-機能/ SASL-機能
authinfo-capability = "AUTHINFO" *(WS authinfo-variant) authinfo-variant = "USER" / "SASL" sasl-capability = "SASL" 1*(WS mechanism)
AUTHINFO-能力= "AUTHINFO" *（WS AUTHINFOバリアント）AUTHINFOバリアント= "USER" / "SASL" SASL-能力= "SASL" 1 *（WS機構）
base64-opt = "=" / base64 mechanism = 1*20mech-char mech-char = UPPER / DIGIT / "-" / "_"
base64でOPT = "=" / BASE64メカニズム= 1 * 20mech-char型のメカ-CHAR = UPPER / DIGIT / " - " / "_"
This section contains a list of each new response code defined in this document and indicates whether it is multi-line, which commands can generate it, what arguments it has, and what its meaning is.
このセクションでは、この文書で定義されたそれぞれの新しい応答コードのリストが含まれ、それが持っているものの引数、それはそれを生成できるコマンドを複数行、であるかどうかを示す、と何の意味があります。
Response code 281 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL Meaning: authentication accepted
AUTHINFOユーザ、AUTHINFO PASS、AUTHINFO SASL意味：によって生成された応答コード281認証が受け付け
Response code 283 Generated by: AUTHINFO SASL 1 argument: challenge Meaning: authentication accepted (with success data)
AUTHINFO SASL 1つの引数：挑戦意味：（成功データ付き）認証受け入れによって生成された応答コード283
Response code 381 Generated by: AUTHINFO USER Meaning: password required via AUTHINFO PASS command. Note that this code is used for backwards compatibility and does not conform to the traditional use of 3xx codes.
AUTHINFOのUSER意味：AUTHINFO PASSコマンドを使って必要なパスワードによって生成された応答コード381。このコードは、後方互換性のために使用され、3XXコードの伝統的な使用に適合しないことに留意されたいです。
Response code 383 Generated by: AUTHINFO SASL 1 argument: challenge Meaning: continue with SASL exchange
AUTHINFO SASL 1引数：挑戦意味：によって生成された応答コード383は、SASL交換を続けます
Response code 481 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL Meaning: authentication failed/rejected
AUTHINFOのUSER、AUTHINFO PASS、AUTHINFO SASL意味：：によって生成された応答コード481認証が失敗/拒否
Response code 482 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL Meaning: authentication commands issued out of sequence or SASL protocol error
AUTHINFOのUSER、AUTHINFO PASS、AUTHINFO SASL意味：シーケンスまたはSASLプロトコルエラーのうち、発行した認証コマンドによって生成された応答コード482
This section contains implementation suggestions and notes of best current practice; it does not specify further network protocol requirements.
このセクションでは、実装の提案と現在のベストプラクティスのノートが含まれています。それは、ネットワークプロトコルの要件を指定していません。
Once authenticated, the authorization identity presented in the AUTHINFO exchange (username when using USER/PASS) SHOULD be included in an audit trail associating the identity with any articles supplied during a POST operation, and this configuration SHOULD be the default. This may be accomplished, for example, by inserting headers in the posted articles or by a server logging mechanism. The server MAY provide a facility for disabling the procedure described above, as some users or administrators may consider it a violation of privacy.
認証されると、AUTHINFO交換（ユーザ名USER / PASSを使用して）で提示認可IDは、POST操作の間に供給される任意の記事でアイデンティティを関連付ける監査証跡に含まれるべきであり、この設定がデフォルトであるべきです。これは、例えば、投稿記事内、または、サーバのログメカニズムによってヘッダを挿入することにより、達成することができます。一部のユーザーまたは管理者がプライバシーの侵害検討することができるように、サーバーは、上記の手順を無効にするための機能を提供することができます。
Security issues are discussed throughout this memo.
セキュリティの問題は、このメモ中で議論されています。
In general, the security considerations of [SASL] and any implemented SASL mechanisms are applicable here; only the most important are highlighted specifically below. Also, this extension is not intended to cure the security considerations described in section 12 of [NNTP]; those considerations remain relevant to any NNTP implementation.
一般的に、[SASL]のセキュリティ問題と任意の実装SASLメカニズムはここで適用可能です。唯一の最も重要なのは、以下に具体的に強調表示されます。また、この拡張は、[NNTP]のセクション12に記載のセキュリティ問題を硬化することを意図していません。これらの考察は任意のNNTP実装に関連したまま。
Before the [SASL] negotiation has begun, any protocol interactions may have been performed in the clear and may have been modified by an active attacker. For this reason, clients and servers MUST discard any sensitive knowledge obtained prior to the start of the SASL negotiation upon the establishment of a security layer. Furthermore, the CAPABILITIES command SHOULD be re-issued upon the establishment of a security layer, and other protocol state SHOULD be re-negotiated as well.
[SASL]ネゴシエーションが始まる前に、任意のプロトコル相互作用は明確で実行されていてもよいし、活発な攻撃者によって修正されていてもよいです。このため、クライアントとサーバは、前のセキュリティ層の確立時にSASL交渉の開始に得た機密知識を捨てなければなりません。また、capabilitiesコマンドは、セキュリティ層の確立時に再発行されるべきであり、他のプロトコル状態は、同様に再ネゴシエートされるべきです。
Servers MAY implement a policy whereby the connection is dropped after a number of failed authentication attempts. If they do so, they SHOULD NOT drop the connection until at least 3 attempts at authentication have failed.
サーバーは、接続が失敗した認証試行回数後に落下させる政策を実施することができます。彼らがそうする場合、認証に少なくとも3回の試行が失敗するまで、彼らは接続を切断すべきではありません。
Implementations MUST support a configuration where authentication mechanisms that are vulnerable to passive eavesdropping attacks (such as AUTHINFO USER/PASS and SASL [PLAIN]) are not advertised or used without the presence of an external security layer such as TLS [NNTP-TLS], and this configuration SHOULD be the default.
実装は、（例えばAUTHINFOのUSER / PASSとSASL [PLAIN]のような）受動的盗聴攻撃に対して脆弱な認証メカニズムは、例えば、TLS [NNTP-TLS]などの外部セキュリティ層の存在なしにアドバタイズまたは使用されないコンフィギュレーションをサポートしなければなりませんそして、この設定がデフォルトであるべきです。
When multiple authentication mechanisms are permitted by both client and server, 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 weak mechanisms. The minimum strength acceptable is a policy decision that is outside the scope of this specification.
複数の認証メカニズムは、クライアントとサーバの両方で許可されている場合は、アクティブな攻撃者は、最も弱いメカニズムにダウン交渉を引き起こす可能性があります。このため、クライアントとサーバの両方が弱いメカニズムの使用を禁止する設定可能であるべきです。許容される最小強度は、本明細書の範囲外であるポリシー決定です。
The IANA has registered the SASL/GSSAPI service name "nntp". This service name refers to authenticated use of Usenet news service when it is provided via the [NNTP] protocol.
IANAはSASL / GSSAPIサービス名「NNTP」を登録しました。それは[NNTP]プロトコルを介して提供されている場合、このサービス名は、Usenetニュースサービスの認証された使用を意味します。
o Published Specification: This document.
O発行仕様：このドキュメント。
o Contact for Further Information: Authors of this document.
詳しい情報についてはO接点：この文書の著者。
o Change Controller: IESG <iesg@ietf.org>.
Oの変更コントローラ：IESG <iesg@ietf.org>。
This section gives a formal definition of the AUTHINFO extension, as required by Section 3.3.3 of [NNTP] for the IANA registry.
IANAレジストリのために[NNTP]のセクション3.3.3で必要とされるこのセクションでは、AUTHINFO拡張の正式な定義を与えます。
o This extension provides an extensible mechanism for NNTP authentication via a variety of methods.
Oこの拡張は、様々な方法を介して、NNTP認証のための拡張可能なメカニズムを提供します。
o The capability label for this extension is "AUTHINFO".
Oこの拡張のための能力ラベルは「AUTHINFO」です。
o The "AUTHINFO" capability label has two possible optional arguments, "USER" and "SASL" (as defined in Section 2.1), indicating which variants of the AUTHINFO command are supported.
O「AUTHINFO」機能ラベルは、2つの可能なオプションの引数を、「USER」があり、「SASL」（セクション2.1で定義されるように）、AUTHINFOコマンドの変異体が支持されているかを示します。
o This extension also provides the "SASL" capability label, whose arguments list the available SASL mechanisms.
Oこの拡張はまた、その引数が利用できるSASLメカニズムを一覧表示する「SASL」機能ラベルを提供します。
o This extension defines three new commands, AUTHINFO USER, AUTHINFO PASS, and AUTHINFO SASL, whose behavior, arguments, and responses are defined in Sections 2.3 and 2.4.
Oこの拡張は、3の新しいコマンド、その動作が、引数、および応答セクション2.3と2.4で定義されているAUTHINFOのUSER、AUTHINFO PASS、およびAUTHINFO SASLを、定義されています。
o This extension does not associate any new responses with pre-existing NNTP commands.
Oこの拡張は、既存のNNTPコマンドで、新しい応答を関連付けることはありません。
o This extension may affect the overall behavior of both server and client in that the AUTHINFO SASL command may require that subsequent communication be transmitted via an intermediary security layer.
Oこの拡張は、AUTHINFO SASLコマンドは、その後の通信が仲介セキュリティ層を介して送信することを要求することができるという点で、サーバーとクライアントの両方の全体的な動作に影響を与える可能性があります。
o The length of the AUTHINFO SASL command (as defined in this document) may exceed 512 octets. The maximum length of this command is increased to that which can accommodate the largest initial response possible for any of the SASL mechanisms supported by the implementation.
O（本書で定義されるような）AUTHINFO SASLコマンドの長さが512個のオクテットを超える可能性があります。このコマンドの最大長さは、実装によってサポートされるSASLメカニズムの任意の可能な最大の初期応答を受け入れることができるものに上昇させます。
o This extension defines two new responses, 283 and 383, whose lengths may exceed 512 octets. The maximum length of these responses is increased to that which can accommodate the largest challenge possible for any of the SASL mechanisms supported by the implementation.
Oこの拡張は、その長さが512個のオクテットを超える可能性が二つの新しい応答、283及び383を定義します。これらの応答の最大長さは、実装によってサポートされるSASLメカニズムの任意の可能な最大の課題に対応できるものに上昇させます。
o This extension does not alter pipelining, but AUTHINFO commands cannot be pipelined.
Oこの拡張は、パイプラインを変更しませんが、AUTHINFOコマンドをパイプライン化することができません。
o Use of this extension may alter the capabilities list; once the AUTHINFO command has been used successfully, the AUTHINFO capability can no longer be advertised by CAPABILITIES. Additionally, the MODE-READER capability MUST NOT be advertised after successful authentication.
Oこの拡張機能を使用すると、機能のリストを変更することができます。 AUTHINFOコマンドが正常に使用された後、AUTHINFO機能は、もはや性能によって宣伝することはできません。また、MODE-READER機能は、認証が成功した後に広告を出してはなりません。
o This extension does not cause any pre-existing command to produce a 401, 480, or 483 response.
Oこの拡張機能は、任意の既存のコマンドでは、401、480、または483応答を生成することはありません。
o This extension is unaffected by any use of the MODE READER command; however, the MODE READER command MUST NOT be used in the same session following successful authentication.
Oこの拡張は、モードREADERコマンドのいずれかを使用することによって影響を受けません。ただし、MODEのREADERコマンドは、認証に成功した後、同じセッションで使用してはいけません。
o Published Specification: This document.
O発行仕様：このドキュメント。
o Contact for Further Information: Authors of this document.
詳しい情報についてはO接点：この文書の著者。
o Change Controller: IESG <iesg@ietf.org>.
Oの変更コントローラ：IESG <iesg@ietf.org>。
This RFC originated from a document initially written by Chris Newman.
このRFCは、最初はクリス・ニューマンによって書かれた文書に由来しました。
A significant amount of the authentication text was originally from the NNTP revision or common authentication specs written by Stan Barber. A significant amount of the SASL text was lifted from the revisions to RFC 1734 and RFC 2554 by Rob Siemborski.
認証テキスト、かなりの量は、NNTPの改定やスタン・バーバーによって書かれた共通の認証仕様出身でした。 SASLテキスト、かなりの量は、ロブSiemborskiによってRFC 1734およびRFC 2554に改正から持ち上げました。
Special acknowledgement also goes to Russ Allbery, Clive Feather, and others who commented privately on intermediate revisions of this document, as well as the members of the IETF NNTP Working Group for continual (yet sporadic) insight in discussion.
特別承認もラスAllbery、クライヴフェザー、中間、この文書の改訂版だけでなく、議論の継続的な（まだ散発的）な洞察力のためのIETF NNTPワーキンググループのメンバーに個人的コメント、他に行きます。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[AUTH] Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
"インターネット認証について" [AUTH]ハラー、N.とR.アトキンソン、RFC 1704、1994年10月。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[BASE64] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[DIGEST-MD5]リーチ、P.とC.ニューマン、RFC 2831、2000年5月 "SASLメカニズムとしてダイジェスト認証を使用します"。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[NNTP]フェザー、C.、 "ネットワークニュース転送プロトコル（NNTP）"、RFC 3977、2006年10月。
[NNTP-TLS] Murchison, K., Vinocur, J., and C. Newman, "Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)", RFC 4642, October 2006.
[NNTP-TLS]マーチソン、K.、Vinocur、J.、およびC.ニューマン、RFC 4642、2006年10月 "ネットワークニュース転送プロトコル（NNTP）とトランスポート層セキュリティ（TLS）を使用します"。
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL]メルニコフ、A.およびK. Zeilenga、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。
[SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[SASLprep] Zeilenga、K.、 "SASLprep：ユーザ名とパスワードのためのstringprepプロフィール"、RFC 4013、2005年2月。
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
【STRINGPREP]ホフマン、P.及びM.ブランシェ、 "国際化された文字列の調製（" 文字列準備 "）"、RFC 3454、2002年12月。
[BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[BEEP]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
[CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in Progress.
[CRAM-MD5] Nerenberg、L.、 "CRAM-MD5 SASLメカニズム"、ProgressのWork。
[GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", Work in Progress.
[GSSAPI]メルニコフは、A.、 "SASL GSSAPIメカニズムは" 進行中の作業します。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、2003年3月。
[LDAP-AUTH] Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, June 2006.
[LDAP-AUTH]ハリソン、R.、 "ライトウェイトディレクトリアクセスプロトコル（LDAP）：認証方法とセキュリティメカニズム"、RFC 4513、2006年6月。
[NNTP-COMMON] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000.
[NNTP-COMMON]理容室、S.、 "共通NNTP拡張機能"、RFC 2980、2000年10月。
[PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[PLAIN] Zeilenga、K.、エド。、 "PLAIN簡易認証セキュリティー層（SASL）メカニズム"、RFC 4616、2006年8月。
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[POP-AUTH]マイヤーズ、J.、 "POP3認証コマンド"、RFC 1734、1994年12月。
[SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTP-AUTH]マイヤーズ、J.、 "認証のためのSMTPサービス拡張子"、RFC 2554、1999年3月。
Authors' Addresses
著者のアドレス
Jeffrey M. Vinocur Department of Computer Science Upson Hall Cornell University Ithaca, NY 14853 USA
コンピュータサイエンスアップソンホールコーネル大学イサカ、NY 14853 USAのジェフリーM. Vinocur部門
EMail: vinocur@cs.cornell.edu
メールアドレス：vinocur@cs.cornell.edu
Kenneth Murchison Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213 USA
ケネス・マーチソンカーネギーメロン大学5000フォーブス・アベニューCyertホール285ピッツバーグ、PA 15213 USA
EMail: murch@andrew.cmu.edu
メールアドレス：murch@andrew.cmu.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。