RFC4643 日本語訳
4643 Network News Transfer Protocol (NNTP) Extension forAuthentication. J. Vinocur, K. Murchison. October 2006. (Format: TXT=51411 bytes) (Updates RFC2980) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Vinocur
Request for Comments: 4643 Cornell University
Updates: 2980 K. Murchison
Category: Standards Track Carnegie Mellon University
October 2006
Vinocurがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 4643のコーネル大学アップデート: 2980年のK.マーチソンカテゴリ: 標準化過程カーネギーメロン大学2006年10月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはクライアントが認証機構をサーバに示して、認証プロトコル交換を実行して、その後のプロトコル相互作用のために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.
このドキュメントは、RFC2980で指定されたAUTHINFO USER/PASS認証方法をアップデートして、正式にして、AUTHINFO SIMPLEとAUTHINFO GENERIC認証方法を非難します。 さらに、このドキュメントはNNTPのためにSimple AuthenticationとSecurity Layer(SASL)のプロフィールを定義します。
Vinocur, et al. Standards Track [Page 1] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[1ページ]。
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
1. 序論… 3 1.1. このドキュメントで中古のコンベンション… 3 2. AUTHINFO拡張子… 4 2.1. AUTHINFO拡張子の広告を出します… 4 2.2. AUTHINFO拡張子で、認証します。 5 2.3. AUTHINFOユーザ/パスコマンド… 6 2.3.1. 用法… 7 2.3.2. 記述… 7 2.3.3. 例… 9 2.4. AUTHINFO SASLは命令します… 9 2.4.1. 用法… 10 2.4.2. 記述… 11 2.4.3. 例… 14 3. AUTHINFO拡張子のためのBNF構文を増大させます… 16 3.1. コマンド… 16 3.2. 継続を命令してください… 17 3.3. 応答… 17 3.4. 能力エントリー… 17 3.5. 一般非端末… 18 4. 応答コードの概要… 18 5. 認証追跡/伐採… 18 6. セキュリティ問題… 19 7. IANA問題… 20 7.1. SASL/GSSAPIサービスのためのIANA問題… 20 7.2. NNTP拡張子のためのIANA問題… 20 8. 承認… 21 9. 参照… 22 9.1. 標準の参照… 22 9.2. 有益な参照… 22
Vinocur, et al. Standards Track [Page 2] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[2ページ]。
1. Introduction
1. 序論
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]に記録された臨時のAUTHINFO USERと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]に記録されましたが、あまりそれほど遍在していない臨時のAUTHINFO GENERICコマンドは、ジェネリックSASL[SASL]施設のNNTP特有の同等物を提供しました。 このドキュメントはAUTHINFO SASL交換を支持してNNTPが他のSASLの可能にされたアプリケーション・プロトコルのために開発された認証機構の利益を得ることができるように、AUTHINFO GENERICを非難します、シンプルメールトランスファプロトコル(SMTP)[SMTP-AUTH]、ポストオフィスプロトコル(POP)[POP-AUTH]、インターネットMessage Accessプロトコル(IMAP)[IMAP]、ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[LDAP-AUTH]、およびBlocks Extensive 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]に関連して読まれるのも、お勧めです。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
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].
“MUST"、「必須NOT」がキーワードが、「必要でした」、“SHOULD"、「」、「5月」、このドキュメントで「任意」は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で説明されるように解釈されることであるべきです。
Terms related to authentication are defined in "On Internet Authentication" [AUTH].
認証に関連する用語は「インターネット認証」[AUTH]で定義されます。
Vinocur, et al. Standards Track [Page 3] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[3ページ]。
In the examples, commands from the client are indicated with [C], and responses from the server are indicated with [S].
例では、クライアントからのコマンドは[C]で示されます、そして、サーバからの応答は[S]で示されます。
2. The AUTHINFO Extension
2. AUTHINFO拡張子
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パス、およびAUTHINFO SASL。 この拡大のための能力ラベルはAUTHINFOです。
2.1. Advertising the AUTHINFO Extension
2.1. 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 USERか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ユーザ/パスが支えられるのを示します。 「ユーザ」議論の広告を出してはいけません、そして、AUTHINFOユーザ/パスコマンドを提供するべきではありません、そうでなければ、強い暗号化層(例えば、トランスポート層セキュリティ(TLS)[NNTP-TLS])が使用中の、または、後方の互換性命令でないなら。
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
サーバは、議論のないAUTHINFO能力を記載するかもしれなくて、現状のときに少しの認証コマンドも可能にしません。(能力はこの仕様に従うのを示します)。 この場合、クライアントは、どんなAUTHINFOコマンドも利用するのを試みてはいけません、そうでなければそれがそうするかもしれない論理を含んでも
Vinocur, et al. Standards Track [Page 4] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[4ページ]。
(e.g., for backward compatibility with servers that are not compliant with this specification).
(例えば、この仕様で対応でないサーバとの後方の互換性のための。)
Future extensions may add additional arguments to this capability. Unrecognized arguments 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として、コマンドはセキュリティに関連して、前のセッションからのCAPABILITIESのキャッシュされた結果は当てにされてはいけません、[NNTP]のセクション12.6に従って。 しかしながら、そのようなものがキャッシュしたクライアント5月の使用は、活発な下がっている交渉攻撃を検出するために結果として生じます。
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]101Capabilityは記載します: [S]バージョン2[S]読者[S]IHAVE[S]STARTTLS[S]AUTHINFO SASL[S]SASL CRAM-MD5 DIGEST-MD5 GSSAPI[S]LIST ACTIVE NEWSGROUPS[S] [C] TLS交渉[TLS交渉は続きます、TLSによって保護されたより遠いコマンド][C]CAPABILITIES[S]101CapabilityとSTARTTLS[S]382Continueは記載します: [S]バージョン2 [S] 読者の明瞭な外部の[S]リスト活動的な[S]IHAVE[S]AUTHINFOユーザSASL[S]SASL一夜漬け-MD5ダイジェスト-MD5 GSSAPIニュースグループ[S]。
2.2. Authenticating with the AUTHINFO Extension
2.2. AUTHINFOと共に拡大を認証します。
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コマンドを使用するかもしれません。 CAPABILITIESが認証を試みる前に利用可能な認証コマンドとメカニズムを入手すると命令するAUTHINFOコマンドSHOULD問題を使用するつもりであるクライアント。
Vinocur, et al. Standards Track [Page 5] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[5ページ]。
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応答を受けていなくて追加特権を取得するためにセッションの間、認証の第一歩を試みるかもしれません。 サーバSHOULDはそのような求められていない認証要求を受け入れます。 サーバは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.
クライアントはどうあっても1番目を超えて認証のどんなステップも続行してはいけません、サーバからの応答コードが、認証交換が歓迎されるのを示さない場合。 特に、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能力を返してはいけません、そして、サーバは502応答でどんなその後のAUTHINFOコマンドも拒絶しなければなりません。 さらに、クライアントは認証の後にMODE READERコマンドを発行してはいけません、そして、サーバはMODE-読者能力の広告を出してはいけません。
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メカニズムの同じリストがあるCAPABILITIESコマンドに対応して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誤りと対照的になっています)、リソースが入手できないのを示します。
2.3. AUTHINFO USER/PASS Command
2.3. AUTHINFOユーザ/パスコマンド
This section supersedes the definition of the AUTHINFO USER and AUTHINFO PASS commands as documented in Section 3.1.1 of [NNTP-COMMON].
このセクションは.1セクション3.1[NNTP-COMMON]に記録されるようにAUTHINFO USERとAUTHINFO PASSコマンドの定義に取って代わります。
Vinocur, et al. Standards Track [Page 6] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[6ページ]。
2.3.1. Usage
2.3.1. 用法
These commands MUST NOT be pipelined.
これらのコマンドを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]
応答281Authentication受け入れられた381Password必要な[1]481Authenticationは順序が狂って入手できない502Commandが発行された482のAuthenticationコマンドを失敗したか、または拒絶しました。[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 USERだけにおいて、有効です。 伝統的な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.
以下に注意してください。 .1セクション3.2[NNTP]にもかかわらず、サーバはAUTHINFO USER/PASSに対応して480を返してはいけません。
Parameters
username = string identifying the user/client
password = string representing the user's password
ユーザのパスワードを表すユーザ/クライアントパスワード=ストリングを特定するパラメタユーザ名=ストリング
2.3.2. Description
2.3.2. 記述
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 USERへの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
サーバがユーザ名とパスワードの両方を必要とするなら、後者の前に前者を送らなければなりません。 サーバは、パスワードが受信されるまでユーザ名をキャッシュする必要があるでしょう。 それは、パスワードがあるのを必要とするかもしれません。
Vinocur, et al. Standards Track [Page 7] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[7ページ]。
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 USERへの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.
サーバは、パスワードが与えられたユーザ名に必要であるかどうか決定するかもしれません。 したがって、同じサーバは381と他の応答コードの両方でAUTHINFO USERに反応できます。
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]によって提供されたそれなどの)がアクティブでなくて、この構成SHOULDであるときはいつも、それを無効にするのにおいて構成可能であるのが、デフォルトであるという. クライアントとサーバの間のネットワークのすべてのパーティーへのユーザのパスワードがこのコマンドSHOULDのあらゆる実装であると暴露するようにことになってください。 サーバは、コマンドには、試みられて、datastreamが不十分に安全であることを示すのに483応答コードを使用するでしょう(.1セクション3.2[NNTP]を見てください)。
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.
サーバがユーザ名とパスワードに余白キャラクタを許容するかもしれないことに(しかし、必要ではありません)注意してください。 サーバ実装は、余白で盲目的にコマンド議論を分けて、したがって、ユーザ名かパスワードに余白キャラクタの完全系列を保存しないかもしれません。 したがって、クライアントSHOULDは、余白のためのユーザ名とパスワードをスキャンして、いずれか検出されるなら、問題SASL PLAIN[PLAIN]メカニズムの見込みのユーザが代替手段としてお勧めであると警告します、これらの問題に苦しまないとき。
Vinocur, et al. Standards Track [Page 8] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[8ページ]。
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.
また、歴史的に、ユーザ名が何らかの方法でcanonicalizedされないことに注意してください。 サーバは比較のためにユーザ名を準備するのに[StringPrep]アルゴリズムの[SASLprep]プロフィールを使用するかもしれませんが、そうするのはレガシー実装に関する相互運用性問題を引き起こすかもしれません。 canonicalizationが望まれているなら、SASL PLAIN[PLAIN]メカニズムは代替手段としてお勧めです。
2.3.3. Examples
2.3.3. 例
Example of successful AUTHINFO USER:
うまくいっているAUTHINFO USERに関する例:
[C] AUTHINFO USER wilma
[S] 281 Authentication accepted
[C] AUTHINFO USER wilma[S]281Authenticationは受け入れました。
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 fred[S]381Enterパスフレーズ[C]AUTHINFO PASS flintstone[S]281Authenticationは受け入れました。
Example of AUTHINFO USER/PASS requiring a security layer:
セキュリティ層を必要とするAUTHINFO USER/PASSに関する例:
[C] AUTHINFO USER fred@stonecanyon.example.com
[S] 483 Encryption or stronger authentication required
[C] AUTHINFO USER fred@stonecanyon.example.com [S]483Encryptionか、より強い認証が必要です。
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 USERバニー[S]381Enterパスフレーズ[C]AUTHINFO PASS flintstone[S]481Authenticationは失敗しました。
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]482Authenticationコマンドは系列から外へ出ました。
2.4. AUTHINFO SASL Command
2.4. AUTHINFO SASLコマンド
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.
このセクションはSimple AuthenticationとSecurity Layer[SASL]の正式なプロフィールを定義します。 SASL認証を実行する方法として、.3セクション3.1[NNTP-COMMON]に記録されるAUTHINFO GENERICコマンドの使用はAUTHINFO SASLコマンドを支持して推奨しないです。 サーバSHOULD NOTはCAPABILITIESによって返された能力のリストにAUTHINFO GENERICの広告を出します。
Vinocur, et al. Standards Track [Page 9] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[9ページ]。
2.4.1. Usage
2.4.1. 用法
This command MUST NOT be pipelined.
このコマンドを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]
応答281Authenticationは、SASL交換[1]481AuthenticationとAuthentication受け入れられた(成功データがある)[1]383挑戦Continueが失敗したか、または拒絶した283挑戦が482SASLプロトコル誤り502Command入手できないと受け入れました。[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.
以下に注意してください。 .1セクション3.2[NNTP]にもかかわらず、サーバは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] 挑戦はサーバ挑戦と等しいです。 指定されるとして[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メカニズムのいずれにも、可能なコード化された初期の応答最も大きいそれに増強されます。
Vinocur, et al. Standards Track [Page 10] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[10ページ]。
2.4.2. Description
2.4.2. 記述
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回答でAUTHINFO SASLコマンドを拒絶します(.1セクション3.2[NNTP]を見てください)。 要求された認証機構が暗号化層を必要とするなら、サーバは483回答でAUTHINFO SASLコマンドを拒絶します(.1セクション3.2[NNTP]を見てください)。
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で定義されるように続かなければなりません。
Vinocur, et al. Standards Track [Page 11] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[11ページ]。
[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の八重奏を超えることができることに注意してください。 クライアントSHOULDとサーバはそれらのサポートしている認証機構に、可能な初期の応答の最大のコード化されたサイズを扱うことができなければなりません。この要件はクライアントかサーバがプロトコル実装の他の部品に持っているどんなコマンドや議論長さの制限からも独立しています。
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]).
初期の応答議論の使用が512の八重奏を超えるAUTHINFO SASLコマンドを引き起こすなら、クライアントは、初期の応答パラメタを省略するのを選ぶかもしれません(代わりに[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コマンドを拒絶しなければなりません(.1セクション3.2[NNTP]を見てください)。 クライアントがそうすることができないなら、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]交換で生成された承認のアイデンティティは簡単なユーザ名です、そして、クライアントとサーバの両方がトランスミッションか比較のためにこれらの名前を準備するのに[StringPrep]アルゴリズムの[SASLprep]プロフィールを使用しなければなりません。 承認のアイデンティティの準備が空のストリングを失敗するか、またはもたらすなら(それが空のストリングとして伝えられなかったなら)、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
クライアントが首尾よく交換を終了するなら、サーバは281か283回答のどちらかを発行します。 サーバがクライアントを認証できないなら、それはAUTHINFO SASLコマンドを拒絶しなければなりません。
Vinocur, et al. Standards Track [Page 12] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[12ページ]。
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.
481回答で。 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.)
セキュリティ層が実施すると、初期の挨拶応答(5.1[NNTP]を見る)を送った直後NNTPプロトコルは状態にリセットされます、MODE READERコマンドであるなら発行された例外でそれ(もしあれば)の効果は逆にされません。 サーバはSASL交渉自体から得られなかったクライアントから得られた現在のニュースグループや記事番号などの少しの知識も捨てなければなりません。 同様に、クライアントSHOULDは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コード化を適用しなければなりません(いつもcleartextデータは最初にコード化された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[PLAIN]メカニズムSHOULD。また、実装されてください、いくつかの環境に、DIGEST-MD5の機能性が不十分であるので(例えば、サーバは、外部認証サービスに平文パスワードをそらす必要があるかもしれません)。 SASL PLAINメカニズムはAUTHINFO USERより好まれます、強い暗号化層の能動態がなくても、余白キャラクタの使用への尊敬がユーザ名とパスワードで使用されている状態でAUTHINFO USER/PASSが持っている制限を排除するので。
Vinocur, et al. Standards Track [Page 13] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[13ページ]。
2.4.3. Examples
2.4.3. 例
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]101Capabilityは記載します: [S]バージョン2[S]読者[S]STARTTLS[S]AUTHINFO SASL[S]SASL CRAM-MD5 DIGEST-MD5 GSSAPI[S]LIST ACTIVE NEWSGROUPS[S][C] TLS交渉[TLS交渉は続きます、TLSによって保護されたより遠いコマンド][C]CAPABILITIES[S]101CapabilityとSTARTTLS[S]382Continueは記載します: [S]バージョン2[S]読者[S]AUTHINFO USER SASL[S]SASL CRAM-MD5 DIGEST-MD5 GSSAPI PLAIN EXTERNAL[S]LIST ACTIVE NEWSGROUPS[S] [C] AUTHINFO SASL PLAIN AHRlc3QAMTIzNA=[S]281Authenticationは受け入れました。
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層の下におけるEXTERNAL SASLメカニズムに関する例、承認のアイデンティティを使用するのは、クライアントTLS証明書を得て、その結果、ゼロ・レングスの初期のクライアント応答(AUTHINFO SASLの前のコマンドは、前の例と同じであり、省略された)を得ました:
[C] AUTHINFO SASL EXTERNAL =
[S] 281 Authentication accepted
[C] AUTHINFO SASL EXTERNAL=[S]281Authenticationは受け入れました。
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ダイジェスト-MD5[S]383bm9uY2U9InNheUFPaENFS0dJZFBNSEMwd3RsZUxxT0ljT0kyd1FZSWU0 enplQXR1aVE9IixyZWFsbT0iZWFnbGUub2NlYW5hLmNvbSIscW9wPSJhdXRo LGF1dGgtaW50LGF1dGgtY29uZiIsY2lwaGVyPSJyYzQtNDAscmM0LTU2LHJj NCxkZXMsM2RlcyIsbWF4YnVmPTQwOTYsY2hhcnNldD11dGYtOCxhbGdvcml0 aG09bWQ1LXNlc3M=
Vinocur, et al. Standards Track [Page 14] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[14ページ]。
[C] dXNlcm5hbWU9InRlc3QiLHJlYWxtPSJlYWdsZS5vY2VhbmEuY29tIixub25j
ZT0ic2F5QU9oQ0VLR0lkUE1IQzB3dGxlTHFPSWNPSTJ3UVlJZTR6emVBdHVp
UT0iLGNub25jZT0iMFkzSlFWMlRnOVNjRGlwK08xU1ZDMHJoVmcvLytkbk9J
aUd6LzdDZU5KOD0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLWNvbmYsY2lwaGVy
PXJjNCxtYXhidWY9MTAyNCxkaWdlc3QtdXJpPSJubnRwL2xvY2FsaG9zdCIs
cmVzcG9uc2U9ZDQzY2Y2NmNmZmE5MDNmOWViMDM1NmMwOGEzZGIwZjI=
[S] 283 cnNwYXV0aD1kZTJlMTI3ZTVhODFjZGE1M2Q5N2FjZGEzNWNkZTgzYQ==
[C] dXNlcm5hbWU9InRlc3QiLHJlYWxtPSJlYWdsZS5vY2VhbmEuY29tIixub25j ZT0ic2F5QU9oQ0VLR0lkUE1IQzB3dGxlTHFPSWNPSTJ3UVlJZTR6emVBdHVp UT0iLGNub25jZT0iMFkzSlFWMlRnOVNjRGlwK08xU1ZDMHJoVmcvLytkbk9J aUd6LzdDZU5KOD0iLG5jPTAwMDAwMDAxLHFvcD1hdXRoLWNvbmYsY2lwaGVy PXJjNCxtYXhidWY9MTAyNCxkaWdlc3QtdXJpPSJubnRwL2xvY2FsaG9zdCIs cmVzcG9uc2U9ZDQzY2Y2NmNmZmE5MDNmOWViMDM1NmMwOGEzZGIwZjIは[S]283cnNwYXV0aD1kZTJlMTI3ZTVhODFjZGE1M2Q5N2FjZGEzNWNkZTgzYQ=と等しいです。
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 S383はC YIICOAYJKoZIhvcSAQICAQBuggInMIICI6ADAgEFoQMCAQ6iBwMFACAAAACj ggE/YYIBOzCCATegAwIBBaEYGxZURVNULk5FVC5JU0MuVVBFTk4uRURVoiQw IqADAgEDoRswGRsEbmV3cxsRbmV0bmV3cy51cGVubi5lZHWjge8wgeygAwIB EKEDAgECooHfBIHcSQfLKC8vm2i17EXmomwk6hHvjBY/BnKnvvDTrbno3198 vlX2RSUt+CjuAKhcDcj4DW0gvZEqH7t5v9yWedzztlpaThebBat6hQNr9NJP ozh1/+74HUwhGWb50KtjuftO/ftQ8q0nTuYKgIq6PM4tp2ddo1IfpjfdNR9Eと等しいです;
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]481Authenticationと等しいです。
Example of attempting to use a mechanism that is not supported by the server:
サーバによってサポートされないメカニズムを使用するのを試みる例:
[C] AUTHINFO SASL EXAMPLE
[S] 503 Mechanism not recognized
Mechanismが認識しなかった[C]AUTHINFO SASL EXAMPLE[S]503
Vinocur, et al. Standards Track [Page 15] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[15ページ]。
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]483Encryptionか、より強い認証が必要です。
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]482SASLプロトコル誤り
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]383PDE1NDE2NzQ5My4zMjY4MzE3QHRlc3RAZXhhbXBsZS5jb20+[C]abcd=efg[S]504Base64
3. Augmented BNF Syntax for the AUTHINFO Extension
3. AUTHINFO拡張子のための増大しているBNF構文
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はこれらの規則を有効にするのを最初に、試みる前に、インポートされるべきです。
3.1. Commands
3.1. コマンド
This syntax extends the non-terminal "command", which represents an NNTP command.
この構文は非端末「コマンド」を広げています。(それは、NNTPコマンドを表します)。
command =/ authinfo-sasl-command /
authinfo-user-command /
authinfo-pass-command
authinfo通過authinfoユーザコマンドauthinfo-sasl=/命令/コマンド/コマンド
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"W"SASL"W、メカニズム、[W、初期の応答、]、"AUTHINFO"W「ユーザ」Wユーザ名authinfo通過コマンド="AUTHINFO"authinfoユーザコマンド=WはパスワードをWに「通ります」。
initial-response = base64-opt username = 1*user-pass-char password = 1*user-pass-char user-pass-char = B-CHAR
初期の応答は1*ユーザパスbase64選んでいるユーザ名=炭のパスワード=1*ユーザパス炭のユーザパス炭=B-CHARと等しいです。
Vinocur, et al. Standards Track [Page 16] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[16ページ]。
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 PASSを分析するかもしれません。 そのような実装は追加構文(これらの2つの項目を[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、ユーザ名/パスワードとして。
3.2. Command Continuation
3.2. コマンド継続
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-sasl383=/継続
authinfo-sasl-383-continuation = ("*" / base64-opt) CRLF
authinfo-sasl383継続は(base64「*」/選びます)のCRLFと等しいです。
3.3. Responses
3.3. 応答
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
応答383初期の応答内容応答283=/内容/内容
response-283-content = "283" SP base64 response-383-content = "383" SP base64-opt
「283」SP base64応答383応答283内容=内容=「383」はSP base64選ばれます。
3.4. Capability Entries
3.4. 能力エントリー
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
sasl能力エントリーauthinfo=/能力/能力
authinfo-capability = "AUTHINFO" *(WS authinfo-variant) authinfo-variant = "USER" / "SASL" sasl-capability = "SASL" 1*(WS mechanism)
authinfo-能力が"AUTHINFO"*と等しい、(W、authinfo-異形、)、authinfo-異形=「ユーザ」/"SASL"sasl-能力は"SASL"1*と等しいです。(WSメカニズム)
Vinocur, et al. Standards Track [Page 17] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[17ページ]。
3.5. General Non-terminals
3.5. 一般非端末
base64-opt = "=" / base64 mechanism = 1*20mech-char mech-char = UPPER / DIGIT / "-" / "_"
=「=」/base64メカニズム=1*20mech-炭mech-炭=上側の/ケタ/「-」/"_"をbase64選んでください。
4. Summary of Response Codes
4. 応答コードの概要
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
以下による応答コード281Generated AUTHINFOユーザ、AUTHINFOパス、AUTHINFO SASL意味: 認証は受け入れました。
Response code 283
Generated by: AUTHINFO SASL
1 argument: challenge
Meaning: authentication accepted (with success data)
以下による応答コード283Generated AUTHINFO SASL1議論: Meaningに挑戦してください: 認証は受け入れました。(成功データがある)
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.
以下による応答コード381Generated AUTHINFOユーザ意味: パスワードがAUTHINFO PASSコマンドで必要です。 このコードが遅れている互換性に使用されて、3xxコードの伝統的な使用に従わないことに注意してください。
Response code 383
Generated by: AUTHINFO SASL
1 argument: challenge
Meaning: continue with SASL exchange
以下による応答コード383Generated AUTHINFO SASL1議論: Meaningに挑戦してください: SASL交換を続行してください。
Response code 481
Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL
Meaning: authentication failed/rejected
以下による応答コード481Generated AUTHINFOユーザ、AUTHINFOパス、AUTHINFO SASL意味: 失敗されるか、または拒絶された認証
Response code 482
Generated by: AUTHINFO USER, AUTHINFO PASS, AUTHINFO SASL
Meaning: authentication commands issued out of sequence or
SASL protocol error
以下による応答コード482Generated AUTHINFOユーザ、AUTHINFOパス、AUTHINFO SASL意味: 認証コマンドは系列かSASLプロトコル誤りから外へ出ました。
5. Authentication Tracking/Logging
5. 認証追跡/伐採
This section contains implementation suggestions and notes of best current practice; it does not specify further network protocol requirements.
このセクションは最も良い現在の習慣の実装提案と注意を含みます。 それはさらなるネットワーク・プロトコル要件を指定しません。
Vinocur, et al. Standards Track [Page 18] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[18ページ]。
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.
一度認証されています、含まれていて、承認のアイデンティティはポストの操作の間、どんな記事も提供しているアイデンティティ、およびこの構成SHOULDを関連づけながら、監査証跡でAUTHINFO交換(ユーザ名いつ使用USER/PASS)にSHOULDを寄贈したか。デフォルトになってください。 例えば、これは掲示された記事にヘッダーを挿入するか、サーバ伐採メカニズムによって達成されるかもしれません。 サーバは上で説明された手順を無効にするのに施設を提供するかもしれません、何人かのユーザか管理者が、それがプライバシーの違反であると考えるとき。
6. Security Considerations
6. セキュリティ問題
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は、SHOULDがセキュリティ層の設立のときに再発行されると命令します、そして、他のプロトコルはまた、SHOULDが再交渉されると述べます。
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つの試みまでの接続が失敗したSHOULD NOT低下です。
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.
実装はTLS[NNTP-TLS]や、この構成SHOULDのような対外安全保障層の存在なしで受け身の盗聴攻撃(AUTHINFO USER/PASSやSASL[PLAIN]などの)に被害を受け易い認証機構を広告を出しもしませんし、使用もしない構成にデフォルトをサポートしなければなりません。
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.
複数の認証機構がクライアントとサーバの両方によって受入れられるとき、活発な攻撃者は最も弱いメカニズムに下がっている交渉を引き起こす場合があります。 この理由、両方のクライアント、およびサーバSHOULDに関しては、弱いメカニズムの使用を禁じるのにおいて構成可能であってください。許容できる最低限の強さはこの仕様の範囲の外にある政策決定です。
Vinocur, et al. Standards Track [Page 19] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[19ページ]。
7. IANA Considerations
7. IANA問題
7.1. IANA Considerations for SASL/GSSAPI Services
7.1. SASL/GSSAPIサービスのためのIANA問題
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は"nntp"というSASL/GSSAPIサービス名を登録しました。 [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 、gt。
7.2. IANA Considerations for NNTP Extensions
7.2. NNTP拡張子のためのIANA問題
This section gives a formal definition of the AUTHINFO extension, as required by Section 3.3.3 of [NNTP] for the IANA registry.
このセクションは必要に応じて.3セクション3.3[NNTP]でAUTHINFO拡張子の公式の定義をIANA登録に与えます。
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つの可能な任意の議論があって、AUTHINFOコマンドのどの異形を示す「ユーザ」と"SASL"(セクション2.1で定義されるように)がサポートされます。
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つの新しいコマンドを定義して、AUTHINFO USER、AUTHINFO PASS、AUTHINFO SASL、振舞い、議論、および応答はセクション2.3と2.4で定義されます。
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メカニズムのいずれにも、可能な初期の応答最も大きいそれに増強されます。
Vinocur, et al. Standards Track [Page 20] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[20ページ]。
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の八重奏を超えるかもしれない2つの新しい応答、283、および383を定義します。 これらの応答の最大の長さは収容できる中で実装によってサポートされたSASLメカニズムのいずれにも、可能な挑戦最も大きいそれに増強されます。
o This extension does not alter pipelining, but AUTHINFO commands
cannot be pipelined.
o この拡大はパイプライン処理を変更しませんが、AUTHINFOコマンドをpipelinedされることができません。
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コマンドがいったん首尾よく使用されると、CAPABILITIESはもうAUTHINFO能力の広告を出すことができません。 さらに、うまくいっている認証の後にMODE-読者能力の広告を出してはいけません。
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コマンドのどんな使用でも影響を受けないです。 しかしながら、うまくいっている認証に続いて、同じセッションのときに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 、gt。
8. Acknowledgements
8. 承認
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テキストのかなりの量は改正からRFC1734とRFC2554までロブSiemborskiによって撤廃されました。
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、クライヴFeather、および他のもののものになります、議論における絶え間ない(まだ過疎の)洞察のためのIETF NNTP作業部会のメンバーと同様に。
Vinocur, et al. Standards Track [Page 21] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[21ページ]。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 4234, October 2005.
エド[ABNF]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[AUTH] Haller, N. and R. Atkinson, "On Internet
Authentication", RFC 1704, October 1994.
[AUTH] ハラーとN.とR.アトキンソン、「インターネット認証」、RFC1704、1994年10月。
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[BASE64]Josefsson、2006年10月のS.、「Base16、Base32、およびBase64データEncodings」RFC4648。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication
as a SASL Mechanism", RFC 2831, May 2000.
[ダイジェスト-MD5] リーチ、P.、およびC.ニューマン(「SASLメカニズムとしてダイジェスト認証を使用します」、RFC2831)は2000がそうするかもしれません。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[NNTP] Feather, C., "Network News Transfer Protocol (NNTP)",
RFC 3977, October 2006.
[NNTP]はC.、「ネットワークの電子情報を転送するプロトコル(NNTP)」、RFC3977 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.ニューマン、「ネットニュースがあるトランスポート層セキュリティ(TLS)を使用して、プロトコル(NNTP)を移してください」、RFC4642、2006年10月。
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication
and Security Layer (SASL)", RFC 4422, June 2006.
[SASL] メリニコフとA.とK.Zeilenga、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、2006年6月。
[SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
[SASLprep]Zeilenga、K.、「SASLprep:」 「ユーザ名とパスワードのためのStringprepプロフィール」、RFC4013、2005年2月。
[StringPrep] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[StringPrep] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、2002年12月。
9.2. Informative References
9.2. 有益な参照
[BEEP] Rose, M., "The Blocks Extensible Exchange Protocol
Core", RFC 3080, March 2001.
[鳴ります] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
[CRAM-MD5] Nerenberg, L., "The CRAM-MD5 SASL Mechanism", Work in
Progress.
[一夜漬け-MD5] ネーレンバーグ、L.、「一夜漬け-MD5 SASLメカニズム」が進行中で働いています。
[GSSAPI] Melnikov, A., "SASL GSSAPI mechanisms", Work in
Progress.
[GSSAPI] メリニコフ、A.、「SASL GSSAPIメカニズム」、ProgressのWork。
Vinocur, et al. Standards Track [Page 22] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[22ページ]。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
VERSION 4rev1", RFC 3501, March 2003.
[IMAP] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
[LDAP-AUTH] Harrison, R., "Lightweight Directory Access Protocol
(LDAP): Authentication Methods and Security
Mechanisms", RFC 4513, June 2006.
[LDAP-AUTH] ハリソン、R.、「軽量のディレクトリアクセスは以下について議定書の中で述べ(LDAP)」。 「認証方法とセキュリティー対策」、RFC4513、6月2006日
[NNTP-COMMON] Barber, S., "Common NNTP Extensions", RFC 2980, October
2000.
[NNTP一般的な] バーバー、S.、「一般的なNNTP拡張子」、RFC2980、2000年10月。
[PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4616, August
2006.
[明瞭な] Zeilenga、K.、エド、「明瞭な簡易認証とセキュリティ層(SASL)のメカニズム」、RFC4616、8月2006日
[POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734,
December 1994.
[POP-AUTH] マイアーズ、J.、「POP3 AUTHenticationコマンド」、RFC1734、1994年12月。
[SMTP-AUTH] Myers, J., "SMTP Service Extension for Authentication",
RFC 2554, March 1999.
[SMTP-AUTH] マイアーズ、J.、「認証のためのSMTPサービス拡張子」、RFC2554、1999年3月。
Authors' Addresses
作者のアドレス
Jeffrey M. Vinocur Department of Computer Science Upson Hall Cornell University Ithaca, NY 14853 USA
ジェフリーM.Vinocurコンピュータサイエンス学部Upsonコーネル大学イタケー、ホールニューヨーク14853米国
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 Hall285PA15213ピッツバーグ(米国)
EMail: murch@andrew.cmu.edu
メール: murch@andrew.cmu.edu
Vinocur, et al. Standards Track [Page 23] RFC 4643 NNTP Authentication October 2006
Vinocur、他 規格はNNTP認証2006年10月にRFC4643を追跡します[23ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Vinocur, et al. Standards Track [Page 24]
Vinocur、他 標準化過程[24ページ]
一覧
スポンサーリンク
