RFC1734 日本語訳

Network Working Group                                           J. Myers
Request for Comments: 1734                               Carnegie Mellon
Category: Standards Track                                  December 1994

コメントを求めるワーキンググループJ.マイアーズの要求をネットワークでつないでください: 1734年のカーネギーメロンCategory: 標準化過程1994年12月

                      POP3 AUTHentication command

POP3 AUTHenticationコマンド

Status of this Memo

この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)の現行版を参照してください。 このメモの分配は無制限です。

1. Introduction

1. 序論

   This document describes the optional AUTH command, for indicating an
   authentication mechanism to the server, performing an authentication
   protocol exchange, and optionally negotiating a protection mechanism
   for subsequent protocol interactions.  The authentication and
   protection mechanisms used by the POP3 AUTH command are those used by
   IMAP4.

このドキュメントは任意のAUTHコマンドについて説明します、認証機構をサーバに示すために、認証プロトコル交換を実行して、その後のプロトコル相互作用のために任意に保護メカニズムを交渉して。 メカニズムがPOP3 AUTHコマンドで使用した認証と保護はIMAP4によって使用されたものです。

2. The AUTH command

2. AUTHコマンド

   AUTH mechanism

AUTHメカニズム

         Arguments:
             a string identifying an IMAP4 authentication mechanism,
             such as defined by [IMAP4-AUTH].  Any use of the string
             "imap" used in a server authentication identity in the
             definition of an authentication mechanism is replaced with
             the string "pop".

議論: [IMAP4-AUTH]によって定義されるようにIMAP4認証機構を特定するストリング。 サーバ証明のアイデンティティに認証機構の定義に使用されるストリング"imap"のどんな使用もストリング「ポップス」に取り替えます。

         Restrictions:
             may only be given in the AUTHORIZATION state

制限: AUTHORIZATION状態で与えるだけであるかもしれません。

         Discussion:
             The AUTH command indicates an authentication mechanism to
             the server.  If the server supports the requested
             authentication mechanism, it performs an authentication
             protocol exchange to authenticate and identify the user.
             Optionally, it also negotiates a protection mechanism for
             subsequent protocol interactions.  If the requested
             authentication mechanism is not supported, the server

議論: AUTHコマンドは認証機構をサーバに示します。サーバが要求された認証機構をサポートするなら、それは、ユーザを認証して、特定するために認証プロトコル交換を実行します。 また、任意に、それはその後のプロトコル相互作用のために保護メカニズムを交渉します。 要求された認証機構がサポートされないならサーバ

Myers                                                           [Page 1]

RFC 1734                       POP3 AUTH                   December 1994

マイアーズ[1ページ]RFC1734POP3 AUTH1994年12月

             should reject the AUTH command by sending a negative
             response.

否定応答を送ることによって、AUTHコマンドを拒絶するべきです。

             The authentication protocol exchange consists of a series
             of server challenges and client answers that are specific
             to the authentication mechanism.  A server challenge,
             otherwise known as a ready response, is a line consisting
             of a "+" character followed by a single space and a BASE64
             encoded string.  The client answer consists of a line
             containing a BASE64 encoded string.  If the client wishes
             to cancel an authentication exchange, it should issue a
             line with a single "*".  If the server receives such an
             answer, it must reject the AUTH command by sending a
             negative response.

認証プロトコル交換は一連の認証機構に特定のサーバ挑戦とクライアント答えから成ります。 別の方法で持ち合わせの応答として知られているサーバ挑戦は「+」 シングルスペースがあとに続いたキャラクタとBASE64から成る系列がストリングをコード化したということです。 クライアント答えはコード化されたBASE64を含んでいると結ばれる系列から成ります。 クライアントが認証交換を中止したいなら、それは単一の「*」で系列を発行するべきです。 サーバがそのような答えを受けるなら、それは、否定応答を送ることによって、AUTHコマンドを拒絶しなければなりません。

             A protection mechanism provides integrity and privacy
             protection to the protocol session.  If a protection
             mechanism is negotiated, it is applied to all subsequent
             data sent over the connection.  The protection mechanism
             takes effect immediately following the CRLF that concludes
             the authentication exchange for the client, and the CRLF of
             the positive response for the server.  Once the protection
             mechanism is in effect, the stream of command and response
             octets is processed into buffers of ciphertext.  Each
             buffer is transferred over the connection as a stream of
             octets prepended with a four octet field in network byte
             order that represents the length of the following data.
             The maximum ciphertext buffer length is defined by the
             protection mechanism.

保護メカニズムはプロトコルセッションまで保全とプライバシー保護を提供します。 保護メカニズムが交渉されるなら、それは接続の上に送られたすべての順次データに適用されます。 すぐにクライアントへの認証交換、およびサーバのための積極的な応答のCRLFを結論づけるCRLFに続いて、保護メカニズムは実施します。保護メカニズムがいったん有効になると、コマンドと応答八重奏のストリームは暗号文に関するバッファの中に処理されます。 八重奏のストリームが以下のデータの長さを表すネットワークバイトオーダーにおける4八重奏分野でprependedされたとき、各バッファを接続の上に移します。 最大の暗号文バッファ長は保護メカニズムによって定義されます。

             The server is not required to support any particular
             authentication mechanism, nor are authentication mechanisms
             required to support any protection mechanisms.  If an AUTH
             command fails with a negative response, the session remains
             in the AUTHORIZATION state and client may try another
             authentication mechanism by issuing another AUTH command,
             or may attempt to authenticate by using the USER/PASS or
             APOP commands.  In other words, the client may request
             authentication types in decreasing order of preference,
             with the USER/PASS or APOP command as a last resort.

サーバはどんな特定の認証機構もサポートするのに必要ではありません、そして、認証機構はどんな保護メカニズムもサポートする必要はありません。否定応答に応じてAUTHコマンドが失敗するなら、AUTHORIZATION状態とクライアントのセッションの残りは、AUTHが命令するか、またはUSER/PASSかAPOPを使用することによって認証するのを試みるかもしれない別のものにコマンドを発行することによって、別の認証機構を試すかもしれません。 言い換えれば、クライアントは、認証が最後の手段としてUSER/PASSかAPOPコマンドがある減少しているよく使われる順をタイプするよう要求するかもしれません。

             Should the client successfully complete the authentication
             exchange, the POP3 server issues a positive response and
             the POP3 session enters the TRANSACTION state.

クライアントは首尾よく認証交換を終了するべきです、そして、POP3サーバは積極的な応答を発行します、そして、POP3セッションはTRANSACTION状態に入れます。

         Possible Responses:
             +OK maildrop locked and ready
             -ERR authentication exchange failed

可能な応答: + OKの郵便受けロックされて持ち合わせの-ERR認証交換は失敗しました。

Myers                                                           [Page 2]

RFC 1734                       POP3 AUTH                   December 1994

マイアーズ[2ページ]RFC1734POP3 AUTH1994年12月

         Examples:
             S: +OK POP3 server ready
             C: AUTH KERBEROS_V4
             S: + AmFYig==
             C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
                +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
                WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
             S: + or//EoAADZI=
             C: DiAF5A4gA+oOIALuBkAAmw==
             S: +OK Kerberos V4 authentication successful
                ...
             C: AUTH FOOBAR
             S: -ERR Unrecognized authentication type

例: S: + OK POP3のサーバ持ち合わせのC: AUTHケルベロス_V4 S: + AmFYig=C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh S: +か//EoAADZIがCと等しいです: DiAF5A4gA+oOIALuBkAAmw== S: +はうまくいった状態でケルベロスV4認証を承認します… C: AUTH FOOBAR S: -ERR Unrecognized認証タイプ

              Note: the line breaks in the first client answer  are
              for editorial clarity and are not in real authentica-
              tors.

以下に注意してください。 最初のクライアント答えにおけるラインブレイクは、編集の明快ためにあって、本当のauthentica- torsにありません。

Myers                                                           [Page 3]

RFC 1734                       POP3 AUTH                   December 1994

マイアーズ[3ページ]RFC1734POP3 AUTH1994年12月

3. Formal Syntax

3. 正式な構文

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in RFC 822.

以下の構文仕様はRFC822の指定されるとしての増大しているBN記法(BNF)記法を使用します。

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

別の方法で注意されるのを除いて、すべての英字がケース神経が鈍いです。 トークンストリングを定義する上側の、または、下側のケースキャラクタの使用は編集の明快だけのためのものです。 実装は大文字と小文字を区別しないファッションでこれらのストリングを受け入れなければなりません。

   ATOM_CHAR       ::= <any CHAR except atom_specials>

原子_は以下を炭にします:= <は原子_特別番組>以外のあらゆるCHARです。

   atom_specials   ::= "(" / ")" / "{" / SPACE / CTLs / "%" / "*" /
                       <"> / "\"

原子_特別番組:、:= 「(「/」)」/、「「/スペース/ CTLs /「%」/「*」/<「>/「\」」

   auth            ::= "AUTH" 1*(SPACE / TAB) auth_type *(CRLF base64)
                       CRLF

auth:、:= "AUTH"1*(SPACE / TAB)auth_タイプ*(CRLF base64)CRLF

   auth_type       ::= 1*ATOM_CHAR

auth_は以下をタイプします:= 1*原子_炭

   base64          ::= *(4base64_CHAR) [base64_terminal]

base64:、:= *(4base64_炭) [base64_端末]

   base64_char     ::= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" /
           "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" /
                       "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" /
                       "Y" / "Z" /
                       "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" /
                       "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" /
                       "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" /
                       "y" / "z" /
                       "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" /
                       "8" / "9" / "+" / "/"
                       ;; Case-sensitive

base64_は以下を炭にします:= "A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" / "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "+" / "/" ;; 大文字と小文字を区別

   base64_terminal ::= (2base64_char "==") / (3base64_char "=")

base64_端末:、:= (2base64_炭の「=」) / (3base64_炭の「=」)

   CHAR            ::= <any 7-bit US-ASCII character except NUL,
                        0x01 - 0x7f>

以下を炭にしてください:= <米国-ASCII文字が除くどんな7ビットNUL、0×01も--0x7f>。

   continue_req    ::= "+" SPACE base64 CRLF

_reqに以下を続けてください:= 「+」 SPACE base64 CRLF

   CR              ::= <ASCII CR, carriage return, 0x0C>

CR:、:= <ASCII CR、復帰、0x0C>。

   CRLF            ::= CR LF

CRLF:、:= CR LF

   CTL             ::= <any ASCII control character and DEL,
                        0x00 - 0x1f, 0x7f>

CTL:、:= そして、<、どんなASCII制御文字、もDEL、0×00--0x1f、0x7f>。

Myers                                                           [Page 4]

RFC 1734                       POP3 AUTH                   December 1994

マイアーズ[4ページ]RFC1734POP3 AUTH1994年12月

   LF              ::= <ASCII LF, line feed, 0x0A>

LF:、:= <ASCII LF、改行、0x0A>。

   SPACE           ::= <ASCII SP, space, 0x20>

以下を区切ってください:= <ASCII SP、スペース、0×20>。

   TAB             ::= <ASCII HT, tab, 0x09>

以下にタブを付けてください:= <ASCII HT、タブ、0×09>。

4. References

4. 参照

   [IMAP4-AUTH]  Myers, J., "IMAP4 Authentication Mechanisms", RFC 1731,
   Carnegie Mellon, December 1994.

[IMAP4-AUTH] マイアーズ、J.、「IMAP4認証機構」、RFC1731、カーネギー・メロン、1994年12月。

5. Security Considerations

5. セキュリティ問題

   Security issues are discussed throughout this memo.

このメモ中で安全保障問題について議論します。

6. Author's Address

6. 作者のアドレス

   John G. Myers
   Carnegie-Mellon University
   5000 Forbes Ave
   Pittsburgh, PA 15213

ジョンG.マイアーズカーネギーメロン大学5000フォーブズ・Aveピッツバーグ、PA 15213

   EMail: jgm+@cmu.edu

メール: jgm+@cmu.edu

Myers                                                           [Page 5]

マイアーズ[5ページ]