[要約] RFC 4643は、NNTPに認証機能を追加するための拡張を提案しています。目的は、NNTPサーバーへの安全なアクセスを確保し、ユーザーの認証情報を保護することです。
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
認証用のネットワークニュース転送プロトコル（NNTP）拡張
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).
Copyright（c）The Internet Society（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.
このドキュメントでは、クライアントがサーバーに認証メカニズムを示し、認証プロトコル交換を実行することを可能にするネットワークニュース転送プロトコル（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ユーザー/パス認証方法を更新および形式化し、AuthINFOシンプルおよびAuthINFOジェネリック認証方法を非難します。さらに、このドキュメントは、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]は伝統的にニュースグループへの公開アクセスを提供するために使用されてきましたが、認証はいくつかの目的に役立つことがよくあります。たとえば、リソースの消費を制御し、ポストコマンドの虐待者を特定できるようにし、「ローカル」ニュースグループへのアクセスを制限します。
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]で文書化されたAd-Hoc 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].
また、[NNTP-Common]で文書化されているが、はるかに少ないユビキタスで文書化されているAd Hoc Authinfoの一般的なコマンドは、一般的なSASL [SASL]施設にNNTP固有の同等物を提供しました。このドキュメントは、authinfo sasl置換を支持してauthinfoジェネリックを非難し、NNTPは、単純なメール転送プロトコル（SMTP）[SMTP-Auth]、郵便局プロトコル（POP）[SMTP-Auth]を含む他のSASL対応アプリケーションプロトコル向けに開発された認証メカニズムから利益を得られるようにします。POP-AUTH]、インターネットメッセージアクセスプロトコル（IMAP）[IMAP]、LightWeight Directory Access Protocol（LDAP）[LDAP-Auth]、および大規模なExchangeプロトコル（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]と組み合わせて読み取られます。特に明記されている場合を除き、これら2つのドキュメント間の競合の場合、[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]のものと同じであり、このドキュメントで定義されていない用語は、その文書と同じ意味を持っています。
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].
「必須」、「必須」、「必要はない」、「そうは思わない」、「そうではない」、「5月」、および「オプション」は、「RFCで使用するためのキーワードで説明されていると解釈されます。要件レベルを示すために」[キーワード]。
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.
この拡張機能は、3つの新しいコマンドを提供します：authinfoユーザー、authinfo pass、およびauthinfo sasl。この拡張機能の機能ラベルは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.
サーバーは、機能コマンド（[nntp]セクション5.2）に応じて「authinfo」機能ラベルを宣伝するために、authinfoユーザーまたはauthinfo saslコマンドの少なくとも1つを実装する必要があります。ただし、この機能を成功させた後、この機能を宣伝してはなりません（セクション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.
「ユーザー」引数は、このドキュメントのセクション2.3で定義されているように、authinfoユーザー/パスがサポートされていることを示しています。「ユーザー」引数を宣伝する必要はなく、強力な暗号化層（たとえば、トランスポート層セキュリティ（TLS）[NNTP-TLS]）が使用されている場合、または後方互換性が指示されていない限り、authinfoユーザー/パスコマンドを提供する必要はありません。。
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」引数を宣伝する場合、機能コマンドに応じて「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]機能[s] 101機能リスト：[s]バージョン2 [s] reader [s] ihave starttls authinfo sasl[s]。[c] starttls 382 TLS交渉を続行し続けます[TLS交渉手続き、TLSによって保護されたさらなるコマンド] [c]能力[s] 101能力リスト：[s]バージョン2 [s]リーダー[s] ihave [s] ihaveauthinfoユーザーSASL [S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN OENTERAL [S] 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の応答を受け取って追加の特権を取得することができます。サーバーは、このような未承諾の認証要求を受け入れる必要があります。サーバーは、いかなる状況でも、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.
サーバーからの応答コードが認証交換が歓迎されていることを示していない限り、クライアントは、いかなる状況でも、最初の状況を超えた認証の手順を継続してはなりません。特に、38倍の応答コード以外は、クライアントが認証交換を継続してはならないことを示しています。
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コマンドを発行してはなりません。サーバーは、機能コマンドに応じてauthINFO機能を返してはなりません。また、サーバーは、502の応答で後続のauthINFOコマンドを拒否する必要があります。さらに、クライアントは認証後にモードリーダーコマンドを発行してはならず、サーバーはモードリーダーの機能を宣伝してはなりません。
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.
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].
このセクションでは、[nntp-common]のセクション3.1.1に記載されているように、authinfoユーザーとauthinfoパスコマンドの定義に取って代わります。
These commands MUST NOT be pipelined.
これらのコマンドをパイプ化してはなりません。
Syntax AUTHINFO USER username AUTHINFO PASS password
構文authinfoユーザーユーザー名authinfoパスパスワード
Responses 281 Authentication accepted 381 Password required [1] 481 Authentication failed/rejected 482 Authentication commands issued out of sequence 502 Command unavailable [2]
回答281認証受け入れ381パスワードが必要[1] 481認証失敗/拒否482シーケンス502コマンドから発行された認証コマンドは利用できない[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.
[1] authinfoユーザーにのみ有効です。クライアントが現在のコマンドを継続できることを示す従来の3XXコードとは異なり、レガシー381コードは、認証交換を完了するためにAuthINFOパスコマンドを使用する必要があることを意味します。
[2] If authentication has already occurred, AUTHINFO USER/PASS are not valid commands (see Section 2.2).
[2] 認証が既に発生している場合、authinfoユーザー/パスは有効なコマンドではありません（セクション2.2を参照）。
NOTE: Notwithstanding Section 3.2.1 of [NNTP], the server MUST NOT return 480 in response to AUTHINFO USER/PASS.
注：[NNTP]のセクション3.2.1にかかわらず、サーバーはAuthINFOユーザー/パスに応じて480を返してはなりません。
Parameters username = string identifying the user/client password = string representing the user's password
パラメーターユーザー名=文字列ユーザー/クライアントパスワードを識別する=ユーザーのパスワードを表す文字列
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ユーザーとAuthINFOパスコマンドを使用して、サーバーにクリアテキスト資格情報を表示します。これらの資格情報は、ユーザー名またはユーザー名とパスワードで構成されています（区別は、パスワードが秘密にされることが予想されることですが、ユーザー名はプロトコルに直接影響するわけではなく、ユーザーインターフェイスに影響を与える可能性があります）。ユーザー名は、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パスに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パスへの482の応答を返す必要があります。
- MUST use the argument of the most recent AUTHINFO USER for authentication; and
- 認証のために、最新のAuthINFOユーザーの引数を使用する必要があります。と
- MUST NOT return a 381 response to AUTHINFO PASS.
- AuthINFOパスへの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.
サーバーは、特定のユーザー名にパスワードが必要かどうかを判断する場合があります。したがって、同じサーバーは、381と他の応答コードの両方でAuthINFOユーザーに応答できます。
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ユーザー/passコマンドを拒否する必要があります。authinfoユーザー/パスコマンドが失敗した場合、クライアントは認証なしで続行できます。あるいは、クライアントは、別の認証メカニズムを試したり、別の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応答コードを使用して、試行されるコマンドに対してDataStreamが十分に安全であることを示します（[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.
サーバーは、ユーザー名とパスワードでホワイトスペース文字を許可する（ただし不要ではない）ことに注意してください。サーバーの実装では、ホワイトスペースでコマンドの引数を盲目的に分割する可能性があるため、ユーザー名またはパスワードにホワイトスペース文字の正確なシーケンスを保持しない場合があります。したがって、クライアントは、ホワイトスペースのユーザー名とパスワードをスキャンし、検出された場合は、ユーザーに問題の可能性を警告する必要があります。SASLプレーン[プレーン]メカニズムは、これらの問題に悩まされていないため、代替として推奨されます。
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平野[プレーン]メカニズムが推奨されます。
Example of successful AUTHINFO USER:
成功したauthinfoユーザーの例：
[C] AUTHINFO USER wilma [S] 281 Authentication accepted
[c] authinfoユーザーwilma [s] 281認証が受け入れられました
Example of successful AUTHINFO USER/PASS:
成功したauthinfoユーザー/パスの例：
[C] AUTHINFO USER fred [S] 381 Enter passphrase [C] AUTHINFO PASS flintstone [S] 281 Authentication accepted
[c] authinfoユーザーフレッド[s] 381パスフレーズの入力[c] authinfo pass flintstone [s] 281認証が受け入れられました
Example of AUTHINFO USER/PASS requiring a security layer:
AuthINFOユーザー/パスの例セキュリティレイヤーを必要とする：
[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ユーザー/パスの例：
[C] AUTHINFO USER barney [S] 381 Enter passphrase [C] AUTHINFO PASS flintstone [S] 481 Authentication failed
[c] authinfoユーザーbarney [s] 381 passphrase [c] authinfo pass flintstone [s] 481認証が失敗した
Example of AUTHINFO PASS before AUTHINFO USER:
authinfoユーザーの前のauthinfoパスの例：
[C] AUTHINFO PASS flintstone [S] 482 Authentication commands issued out of sequence
[c] authinfo pass flintstone [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]の形式プロファイルを定義します。[NNTP-Common]のセクション3.1.3に記載されているAuthINFO genericコマンドの使用は、SASL認証を実行する方法として、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]
[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.
注：[nntp]のセクション3.2.1にかかわらず、サーバーはauthinfo saslに応じて480を返してはなりません。
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] Challenge =サーバーチャレンジ。課題は、[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 Exchangeを実行してユーザーを認証します。オプションでは、このセッション中にその後のプロトコル相互作用のセキュリティレイヤーも交渉します。要求された認証メカニズムが無効である場合（例えば、サポートされていません）、サーバーは503の返信でauthinfo SASLコマンドを拒否します（[NNTP]のセクション3.2.1を参照）。要求された認証メカニズムに暗号化レイヤーが必要な場合、サーバーは483の返信でauthinfo SASLコマンドを拒否します（[NNTP]のセクション3.2.1を参照）。
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オクテットを超える場合、クライアントは初期応答パラメーターを省略することを選択できます（代わりに[SASL]のセクション5.1で定義されているように進みます）。
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の返信でauthinfo saslコマンドを拒否する必要があります（[nntp]のセクション3.2.1を参照）。クライアントがサーバーの課題のいずれかをデコードできない場合、「*」応答を使用して認証をキャンセルする必要があります。特に、サーバーとクライアントは、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] Exchangeによって生成された認証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.
クライアントがExchangeを正常に完了した場合、サーバーは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プロトコルは、最初のグリーティング応答（[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セキュリティレイヤーの両方が有効な場合、SASLエンコード後にTLSエンコードを適用する必要があります（クリアテキストデータは常にSASLエンコードされ、次に結果データはTLSエンコードされます）。
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 [プレーン]メカニズムも実装する必要があります。これは、Digest-MD5の機能が一部の環境では不十分であるためです（たとえば、サーバーは、プレーンテキストのパスワードを渡す必要がある場合があります。外部認証サービス）。SASLプレーンメカニズムは、AuthINFOユーザーがアクティブにアクティブになっていなくても、AuthINFOユーザーよりも好まれます。これは、AuthINFOユーザー/PASSがユーザー名とパスワードで使用されているホワイトスペース文字の使用に関して排除する制限を排除するためです。
Example of the [PLAIN] SASL mechanism under a TLS layer, using an initial client response:
最初のクライアント応答を使用して、TLS層の下での[プレーン] 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]機能[s] 101機能リスト：[s]バージョン2 [s] reader [s] starttls authinfo sasl [s] sasl cram-md5 digest-md5 gssapi [s] active newsgroups [s]。[c] starttls 382 TLS交渉を続行し続けます[TLS交渉手続き、TLSによって保護されたさらにコマンド] [c]機能[S] 101機能リスト：[S]バージョン2 [S] authinfoユーザーSASL [S] SASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN OENTERAL [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レイヤーの下での外部SASLメカニズムの例。クライアントTLS証明書から導出された認証ID、したがってゼロの長さの初期クライアント応答（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メカニズムの例（明確にするために空白が挿入されています。ベース64エンコードデータは、実際には埋め込まれた空白のない単一行として送信されます）：
[C] AUTHINFO SASL DIGEST-MD5 [S] 383 bm9uY2U9InNheUFPaENFS0dJZFBNSEMwd3RsZUxxT0ljT0kyd1FZSWU0 enplQXR1aVE9IixyZWFsbT0iZWFnbGUub2NlYW5hLmNvbSIscW9wPSJhdXRo LGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJj NCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0 aG09bWQ1LXNlc3M=
[c] authinfo sasl digest-md5 [s] 383 bm9uy2u9innheufpaenfs0djzfbnsemwd3rszuxxxt0ljt0kyd1fzswu0 enplqxr1ave9iixyzwfsbsbt0izwfnlly wub2nlly whubfdgfdgfdgfdgfdgfdgfdgfdgfdgfdgfdfdgfdfdgfdgfdgfdpdfdgfdgfdgfdgfdgfdgfdgfdgfdgfdgfnly aw50lgf1dggty29uziisy2lwagvypsjyyzqtndascmm0ltu2lhjj ncxkzxmsm2rlcyisbwf4ynvmptqwotysy2hcnnlddd11d11d11dgytocxhbgdvcml0 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]資格情報による認証の失敗の例。メカニズムは初期応答を利用できますが、クライアントはその長さのためにそれを使用しないことを選択し、ゼロ長サーバーチャレンジになります（ここでは、明確にするためにホワイトスペースが挿入されています。埋め込まれた空白のない単一のライン）：
[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
UQF ITWO5ZW435RH8PJY2SMQCNQC14V3NMAWTU4J DZHUNW = [S] 481認証エラー
Example of a client aborting in the midst of an exchange:
交換の真っin中に中絶するクライアントの例：
[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
command = / authinfo-sasl-command / authinfo-user-command / authinfo-pass-command
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-command = "authinfo" ws "sasl" wsメカニズム[ws initial-response] authinfo-user-command = "authinfo" ws "ws"ユーザー "ws username authinfo-pass-command =" authinfo "ws" ws "pass" "ws" pass "パスワード
initial-response = base64-opt username = 1*user-pass-char password = 1*user-pass-char user-pass-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]):
initial-response = base64-opt username = 1*user-pass-charパスワード= 1*user-pass-char user-pass-char = b-charノート：サーバーの実装は、authinfoユーザーを解析し、authinfoが特別に渡すことができます。ユーザー名またはパスワード内でホワイトスペースを使用できるようにします。このような実装は、追加の構文を受け入れます（[NNTP]のセクション9.8の「トークン」と矛盾するこれら2つのアイテムを作成します）：
user-pass-char =/ SP / TAB
user-pass-char = / sp /タブ
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をユーザー名/パスワードとして含めていません。
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-continuation = ("*" / 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
initial-response-content = / Response-283-Content / Response-383-Content
response-283-content = "283" SP base64 response-383-content = "383" SP base64-opt
Response-283-Content = "283" SP Base64 Response-383-Content = "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
capability-entry = / authinfo-capability / sasl-capability
authinfo-capability = "AUTHINFO" *(WS authinfo-variant)
authinfo-variant = "USER" / "SASL"
sasl-capability = "SASL" 1*(WS mechanism)
base64-opt = "=" / base64
mechanism = 1*20mech-char
mech-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
応答コード281生成：authinfo user、authinfo pass、authinfo sasl意味：認証が受け入れられました
Response code 283 Generated by: AUTHINFO SASL 1 argument: challenge Meaning: authentication accepted (with success data)
応答コード283生成：authinfo sasl 1引数：課題意味：認証が受け入れられます（成功データ付き）
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.
応答コード381生成：authinfoユーザー意味：authinfo passコマンドを介して必要なパスワード。このコードは、逆方向の互換性に使用されており、3XXコードの従来の使用に適合していないことに注意してください。
Response code 383 Generated by: AUTHINFO SASL 1 argument: challenge Meaning: continue with SASL exchange
応答コード383生成：authinfo sasl 1引数：課題意味：SASL Exchangeを継続する
Response code 481 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL Meaning: authentication failed/rejected
応答コード481生成：authinfo user、authinfo pass、authinfo sasl意味：認証の失敗/拒否
Response code 482 Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL Meaning: authentication commands issued out of sequence or SASL protocol error
応答コード482生成：authinfo user、authinfo pass、authinfo sasl意味：シーケンスまたはSASLプロトコルエラーから発行された認証コマンド
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 Exchange（ユーザー/パスを使用するときにユーザー名）で提示された認証IDは、操作後に提供された記事と同一性を関連付ける監査証跡に含める必要があり、この構成はデフォルトでなければなりません。これは、たとえば、投稿された記事にヘッダーを挿入したり、サーバーロギングメカニズムによって挿入することによって達成される場合があります。一部のユーザーまたは管理者がプライバシーの違反と考える場合があるため、サーバーは上記の手順を無効にするための機能を提供する場合があります。
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交渉が開始される前に得られた機密の知識を破棄する必要があります。さらに、セキュリティ層の確立時に機能コマンドを再発行する必要があり、他のプロトコル状態も再交渉する必要があります。
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」機能ラベルには、「ユーザー」と「SASL」（セクション2.1で定義されている）という2つの可能なオプションの引数があり、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
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 この拡張機能は、283と383の2つの新しい応答を定義し、その長さは512オクテットを超える可能性があります。これらの応答の最大長は、実装によってサポートされている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機能は機能によって宣伝されなくなります。さらに、認証が成功した後、モードリーダーの機能を宣伝してはなりません。
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 この拡張機能は、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は、Chris Newmanが最初に書いた文書から生まれました。
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.
かなりの量の認証テキストは、もともとStan Barberによって書かれたNNTPリビジョンまたは一般的な認証仕様からのものでした。Rob SiemborskiによってRFC 1734およびRFC 2554の改訂から、かなりの量のSASLテキストが解除されました。
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.
特別な謝辞は、この文書の中間改訂について個人的にコメントしたRuss Allbery、Clive Feather、および議論における継続的な（まだ散発的な）洞察のためのIETF NNTPワーキンググループのメンバーにも当てはまります。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF] Crocker、D.、ed。および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 Data Encodings」、RFC 4648、2006年10月。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[Digest-MD5] Leach、P。and C. Newman、「SASLメカニズムとしての消化認証を使用」、RFC 2831、2000年5月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[NNTP] Feather, C., "Network News Transfer Protocol (NNTP)", RFC 3977, October 2006.
[NNTP] Feather、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] Murchison、K.、Vinocur、J。、およびC. Newman、「Network News Transfer Protocol（NNTP）を使用したTransport Layer Security（TLS）を使用」、RFC 4642、2006年10月。
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL] Melnikov、A。およびK. Zeilenga、「Simple Authentication and Security Layer（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] Hoffman、P。and M. Blanchet、「国際化された文字列の準備（「StringPrep」）」、RFC 3454、2002年12月。
[BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[Beep] Rose、M。、「The Blocks Extensible Exchange Protocol Core」、RFC 3080、2001年3月。
[CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in Progress.
[CRAM-MD5] Nerenberg、L。、「Cram-MD5 SASLメカニズム」、進行中の作業。
[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] Crispin、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] Harrison、R。、「Lightweight Directory Access Protocol（LDAP）：認証方法とセキュリティメカニズム」、RFC 4513、2006年6月。
[NNTP-COMMON] Barber, S., "Common NNTP Extensions", RFC 2980, October 2000.
[NNTP-Common] Barber、S。、「Common 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.、ed。、「The Plain Simple Authentication and Security Layer（SASL）メカニズム」、RFC 4616、2006年8月。
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[Pop-auth] Myers、J。、「POP3認証コマンド」、RFC 1734、1994年12月。
[SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[SMTP-Auth] Myers、J。、「認証のためのSMTPサービス拡張」、RFC 2554、1999年3月。
Authors' Addresses
Jeffrey M. Vinocur Department of Computer Science Upson Hall Cornell University Ithaca, NY 14853 USA
ジェフリー・M・ヴィノクルコンピュータサイエンスのヴィノクルアップソンホールコーネル大学イサカ、ニューヨーク14853アメリカ
EMail: vinocur@cs.cornell.edu
Kenneth Murchison Carnegie Mellon University 5000 Forbes Avenue Cyert Hall 285 Pittsburgh, PA 15213 USA
ケネスマーチソンカーネギーメロン大学5000フォーブスアベニューサイエートホール285ピッツバーグ、ペンシルバニア州15213 USA
EMail: murch@andrew.cmu.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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）によって提供されます。