RFC5034 日本語訳

Network Working Group                                      R. Siemborski
Request for Comments: 5034                                  Google, Inc.
Obsoletes: 1734                                             A. Menon-Sen
Updates: 2449                                     Oryx Mail Systems GmbH
Category: Standards Track                                      July 2007

Siemborskiがコメントのために要求するワーキンググループR.をネットワークでつないでください: 5034 Google Inc.は以下を時代遅れにします。 1734A.メノン-銭のアップデート: 2449年のオリックスメールシステムGmbHカテゴリ: 標準化過程2007年7月

                    The Post Office Protocol (POP3)
Simple Authentication and Security Layer (SASL) Authentication Mechanism

ポスト紙オフィスプロトコル(POP3)簡易認証とセキュリティ層(SASL)の認証機構

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 IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

Abstract

要約

   This document defines a profile of the Simple Authentication and
   Security Layer (SASL) for the Post Office Protocol (POP3).  This
   extension allows a POP3 client to indicate an authentication
   mechanism to the server, perform an authentication protocol exchange,
   and optionally negotiate a security layer for subsequent protocol
   interactions during this session.

このドキュメントはポストオフィスプロトコル(POP3)のためにSimple AuthenticationとSecurity Layer(SASL)のプロフィールを定義します。 この拡大で、POP3クライアントは、認証機構をサーバに示して、認証プロトコル交換を実行して、その後のプロトコル相互作用のために任意に今会期中にセキュリティ層を交渉します。

   This document seeks to consolidate the information related to POP3
   AUTH into a single document.  To this end, this document obsoletes
   and replaces RFC 1734, and updates the information contained in
   Section 6.3 of RFC 2449.

このドキュメントはPOP3 AUTHに関連する情報をただ一つのドキュメントに統合しようとします。 このために、このドキュメントは、RFC1734を時代遅れにして、取り替えて、RFC2449のセクション6.3に含まれた情報をアップデートします。

Siemborski & Menon-Sen      Standards Track                     [Page 1]

RFC 5034           POP3 SASL Authentication Mechanism          July 2007

Siemborskiとメノン-銭の規格はPOP3 SASL認証機構2007年7月にRFC5034を追跡します[1ページ]。

1.  Introduction

1. 序論

   The POP3 (see [RFC1939]) AUTH command (see [RFC1734]) has suffered
   several problems in its specification.  The first is that it was very
   similar to a SASL framework defined by [RFC4422], but pre-dated the
   initial SASL specification.  It was therefore missing some key
   components, such as a way to list the available authentication
   mechanisms.

POP3([RFC1939]を見る)AUTHコマンド([RFC1734]を見る)は仕様によるいくつかの問題を受けました。 1番目は[RFC4422]によって定義されたSASLフレームワークと非常に同様でしたが、初期のSASL仕様より前に起こったということです。 したがって、それは利用可能な認証機構を記載する方法などのいくつかの主要な成分を逃していました。

   Later, [RFC2449] attempted to remedy this situation by adding the
   CAPA command and allowing an initial client response with the AUTH
   command, but problems remained in the clarity of the specification of
   how the initial client response was to be handled.

その後、[RFC2449]は、AUTHコマンドでキャパコマンドを加えて、初期のクライアント応答を許容することによってこの事態を改善するのを試みましたが、問題はどう扱われるかに関する初期のクライアント応答がことであった仕様の明快に残っていました。

   Together, this means creating a full POP3 AUTH implementation
   requires an understanding of material in at least five different
   documents (and [RFC3206] provides additional response codes that are
   useful during authentication).

これは、完全なPOP3 AUTH実装を作成するのが少なくとも5通の異なったドキュメントにおける、材料の理解を必要とすることを([RFC3206]は認証の間に役に立つ追加応答コードを提供します)一緒に、意味します。

   This document attempts to combine the information in [RFC1734] and
   [RFC2449] to simplify this situation.  Additionally, it aims to
   clarify and update the older specifications where appropriate.

このドキュメントは、この状況を簡素化するために[RFC1734]と[RFC2449]の情報を結合するのを試みます。 さらに、それは、適切であるところで、より古い仕様をはっきりさせて、アップデートすることを目指します。

2.  Conventions Used in This Document

2. 本書では使用されるコンベンション

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。

   Formal syntax is defined by [RFC4234].

正式な構文は[RFC4234]によって定義されます。

3.  The SASL Capability

3. SASL能力

   This section supersedes the definition of the SASL Capability in
   section 6.3 of [RFC2449].

このセクションは[RFC2449]のセクション6.3でSASL Capabilityの定義に取って代わります。

   CAPA tag:
      SASL

キャパタグ: SASL

   Arguments:
      Supported SASL Mechanisms

議論: SASLメカニズムであるとサポートされます。

   Added commands:
      AUTH

加えられたコマンド: AUTH

Siemborski & Menon-Sen      Standards Track                     [Page 2]

RFC 5034           POP3 SASL Authentication Mechanism          July 2007

Siemborskiとメノン-銭の規格はPOP3 SASL認証機構2007年7月にRFC5034を追跡します[2ページ]。

   Standard commands affected:
      None

標準のコマンドは影響しました: なし

   Announced states / possible differences:
      both / no

州/違いの可能性は発表しました: 両方、/ノー

   Commands valid in states:
      AUTHORIZATION

州で有効なコマンド: 承認

   Specification reference:
      This document and [RFC4422]

仕様参照: そしてこのドキュメント。[RFC4422]

   Discussion:
      The SASL capability permits the use of the AUTH command (as
      defined in Section 4 of this document) to begin a SASL negotiation
      (as defined in [RFC4422]).  The argument to the SASL capability is
      a space-separated list of SASL mechanisms that are supported.

議論: SASL能力は、AUTHコマンド(このドキュメントのセクション4で定義されるように)の使用がSASL交渉を始めるのを許容します([RFC4422]で定義されるように)。 SASL能力への議論はサポートされるSASLメカニズムのスペースで切り離されたリストです。

      If a server either does not support the CAPA command or does not
      advertise the SASL capability, clients SHOULD NOT attempt the AUTH
      command.  If a client does attempt the AUTH command in such a
      situation, it MUST NOT supply the client initial response
      parameter (for backwards compatibility with [RFC1734]).

サーバがキャパコマンドをサポートしないか、またはSASL能力の広告を出さないなら、クライアントSHOULD NOTはAUTHコマンドを試みます。 クライアントがそのような状況におけるAUTHコマンドを試みるなら、それはクライアントの初期の応答パラメタ([RFC1734]との遅れている互換性のための)を提供してはいけません。

      Note that the list of available mechanisms MAY change after a
      successful STLS command (see [RFC2595]).  However, as required by
      [RFC2449], implementations MUST continue to include the SASL
      capability even after a successful AUTH command has been completed
      (even though no further AUTH commands may be issued).

うまくいっているSTLSが命令した([RFC2595]を見てください)後に利用可能なメカニズムのリストが変化するかもしれないことに注意してください。 しかしながら、必要に応じて、[RFC2449]で、うまくいっているAUTHコマンドが終了した(さらなるAUTHコマンドを全く発行しないかもしれませんが)後にさえ実装はずっとSASL能力を含まなければなりません。

   Example
      S: +OK pop.example.com BlurdyBlurp POP3 server ready
      C: CAPA
      S: +OK List of capabilities follows
      S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
      S: STLS
      S: IMPLEMENTATION BlurdyBlurp POP3 server
      S: .

例S: + OKのpop.example.com BlurdyBlurp POP3サーバ持ち合わせのC: 高級キューバタバコS: 能力の+OK ListはSに続きます: SASLの明瞭なダイジェスト-MD5 GSSAPI匿名のS: STLS S: IMPLEMENTATION BlurdyBlurp POP3サーバS: .

4.  The AUTH Command

4. AUTHコマンド

   AUTH mechanism [initial-response]

AUTHメカニズム[初期の応答]

      Arguments:

議論:

         mechanism: A string identifying a SASL authentication
         mechanism.

メカニズム: SASL認証機構を特定する五弦。

Siemborski & Menon-Sen      Standards Track                     [Page 3]

RFC 5034           POP3 SASL Authentication Mechanism          July 2007

Siemborskiとメノン-銭の規格はPOP3 SASL認証機構2007年7月にRFC5034を追跡します[3ページ]。

         initial-response: An optional initial client response, as
         defined in Section 3 of [RFC4422].  If present, this response
         MUST be encoded as Base64 (specified in Section 4 of
         [RFC4648]), or consist only of the single character "=", which
         represents an empty initial response.

初期の応答: [RFC4422]のセクション3で定義されるような任意の初期のクライアント応答。 存在しているなら、この応答は、Base64([RFC4648]のセクション4では、指定される)としてコード化されなければならないか、または単に単一のキャラクタ「=」から成らなければなりません。(それは、空の初期の応答を表します)。

      Restrictions:

制限:

         After an AUTH command has been successfully completed, no more
         AUTH commands may be issued in the same session.  After a
         successful AUTH command completes, a server MUST reject any
         further AUTH commands with an -ERR reply.

首尾よくAUTHコマンドを終了した後に、同じセッションのときにそれ以上のAUTHコマンドを全く発行しないかもしれません。 後aうまくいっているAUTHコマンドが完成する、サーバは-ERR回答でどんなさらなるAUTHコマンドも拒絶しなければなりません。

         The AUTH command may only be given during the AUTHORIZATION
         state.

AUTHORIZATION状態の間、AUTHコマンドを与えるだけであるかもしれません。

      Discussion:

議論:

         The AUTH command initiates a SASL authentication exchange
         between the client and the server.  The client identifies the
         SASL mechanism to use with the first parameter of the AUTH
         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 not supported, the server
         rejects the AUTH command with an -ERR reply.

AUTHコマンドはクライアントとサーバの間のSASL認証交換を起こします。クライアントはAUTHコマンドの最初のパラメタと使用するSASLメカニズムを同一視します。 サーバが要求された認証機構をサポートするなら、それは、ユーザを認証するためにSASL交換を実行します。 また、任意に、それはその後のプロトコル相互作用のために今会期中にセキュリティ層を交渉します。 要求された認証機構がサポートされないなら、サーバは-ERR回答でAUTHコマンドを拒絶します。

         The authentication protocol exchange consists of a series of
         server challenges and client responses that are specific to the
         chosen SASL mechanism.

認証プロトコル交換は一連の選ばれたSASLメカニズムに特定のサーバ挑戦とクライアント応答から成ります。

         A server challenge is sent as a line consisting of a "+"
         character, followed by a single space and a string encoded
         using Base64, as specified in Section 4 of [RFC4648].  This
         line MUST NOT contain any text other than the BASE64-encoded
         challenge.

[RFC4648]のセクション4で指定されるようにBase64を使用することでコード化されたシングルスペースとストリングが支えた「+」キャラクタから成る系列としてサーバ挑戦を送ります。 この系列はBASE64によってコード化された挑戦以外の少しのテキストも含んではいけません。

         A client response consists of a line containing a string
         encoded as Base64.  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 AUTH
         command by sending an -ERR reply.

クライアント応答はBase64としてコード化されたストリングを含む系列から成ります。 クライアントが認証交換を中止したいなら、それは単一の「*」で系列を発行します。 サーバがそのような応答を受けるなら、それは、-ERR回答を送ることによって、AUTHコマンドを拒絶しなければなりません。

         The optional initial-response argument to the AUTH 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

AUTHコマンドへの任意の初期の応答議論は、初期のクライアント応答をサポートする認証機構を使用するとき、周遊旅行を保存するのに使用されます。 初期の応答議論は省略されるかどうか、そして、選ぶメカニズムが必要である

Siemborski & Menon-Sen      Standards Track                     [Page 4]

RFC 5034           POP3 SASL Authentication Mechanism          July 2007

Siemborskiとメノン-銭の規格はPOP3 SASL認証機構2007年7月にRFC5034を追跡します[4ページ]。

         an initial client response, the server MUST proceed by issuing
         an empty challenge, as defined in Section 3 of [RFC4422].  In
         POP3, an empty server challenge is defined as a line with only
         a "+", followed by a single space.  It MUST NOT contain any
         other data.

初期のクライアント応答、サーバは続かなければなりません。[RFC4422]のセクション3で定義されるように空の挑戦を発行することによって、続いてください。 POP3では、空のサーバ挑戦はシングルスペースがあとに続いた「+」だけで系列と定義されます。 それはいかなる他のデータも含んではいけません。

         For the purposes of the initial client response, the 255-octet
         limit on the length of a single command, defined in Section 4
         of [RFC2449], still applies.  If specifying an initial response
         would cause the AUTH command to exceed this length, the client
         MUST NOT use the initial-response parameter (and must proceed
         instead by sending its initial response after an empty
         challenge from the server, as in Section 3 of [RFC4422]).

初期のクライアント応答の目的のために、[RFC2449]のセクション4で定義されたただ一つのコマンドの長さにおける255八重奏の限界はまだ申し込まれています。 指定するなら、初期の応答はこの長さを超えるAUTHコマンドを引き起こして、クライアントは初期の応答パラメタ(そして、代わりに空の挑戦の後に[RFC4422]のセクション3のようにサーバから初期の応答を送ることによって、続かなければならない)を使用してはいけません。

         If the client needs to send a zero-length initial response, it
         MUST transmit the response as a single equals sign ("=").  This
         indicates that the response is present, but contains no data.

クライアントが、ゼロ・レングスの初期の応答を送る必要があるなら、それはただ一つの等号(「=」)として応答を伝えなければなりません。 これは、応答が存在しているのを示しますが、データを全く含んでいません。

         If the client uses an initial-response argument to the AUTH
         command with a SASL mechanism that does not support an initial
         client send, the server MUST reject the AUTH command with an
         -ERR reply.

AUTHへの初期の応答議論が初期のクライアントをサポートしないSASLメカニズムで命令するクライアント用途が発信するなら、サーバは-ERR回答でAUTHコマンドを拒絶しなければなりません。

         If the server cannot Base64 decode a client response, it MUST
         reject the AUTH command with an -ERR reply.  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 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はクライアント応答を解読して、それは-ERR回答でAUTHコマンドを拒絶しなければなりません。 クライアントがそうすることができないなら、Base64はサーバの挑戦のどれかを解読して、「*」応答を使用して、それは認証を中止しなければなりません。 そして、特に、サーバとクライアントが拒絶しなければならない、(無視しない、)、どんなキャラクタも、明らかにBase64アルファベットを許容して、ストリングの端以外に、どこでもパッド文字('=')を含むBase64キャラクタの少しの系列も拒絶してはいけません(例えば、「=AAA」と「AAAはBBBと等しいこと」は許容されていません)。

         Excepting the initial client response, these BASE64 strings may
         be of arbitrary length, depending on the authentication
         mechanism in use.  Clients and servers MUST be able to handle
         the largest encoded challenges and responses generated by the
         authentication mechanisms they support.  This requirement is
         independent of any line-length limitations the client or server
         may have in other parts of its protocol implementation.

初期のクライアント応答を除いて、使用中の認証機構によって、これらのBASE64ストリングは任意の長さのものであるかもしれません。 クライアントとサーバはそれらがサポートする認証機構によって生成された最も大きいコード化された挑戦と応答を扱うことができなければなりません。 この要件はクライアントかサーバがプロトコル実装の他の部品に持っているどんな行長制限からも独立しています。

         If the server is unable to authenticate the client, it MUST
         reject the AUTH command with an -ERR reply.  Should the client
         successfully complete the exchange, the server issues a +OK
         reply.  Additionally, upon success, the POP3 session enters the
         TRANSACTION state.

サーバがクライアントを認証できないなら、それは-ERR回答でAUTHコマンドを拒絶しなければなりません。 クライアントが首尾よく交換を終了するなら、サーバは+OK回答を発行します。 さらに、成功では、POP3セッションはTRANSACTION状態に入ります。

Siemborski & Menon-Sen      Standards Track                     [Page 5]

RFC 5034           POP3 SASL Authentication Mechanism          July 2007

Siemborskiとメノン-銭の規格はPOP3 SASL認証機構2007年7月にRFC5034を追跡します[5ページ]。

         The authorization identity generated by the SASL exchange is a
         simple username, and SHOULD use the SASLprep profile (see
         [RFC4013]) of the StringPrep algorithm (see [RFC3454]) to
         prepare these names for matching.  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.

SASL交換で生成された承認のアイデンティティは簡単なユーザ名です、そして、SHOULDはマッチングのためにこれらの名前を準備するのに、StringPrepアルゴリズム([RFC3454]を見る)のSASLprepプロフィール([RFC4013]を見る)を使用します。 承認のアイデンティティの準備が空のストリングを失敗するか、またはもたらすなら(それが空のストリングとして伝えられなかったなら)、サーバは認証に失敗しなければなりません。

         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 server MUST discard any
         knowledge previously obtained from the client, which was not
         obtained from the SASL negotiation itself.  Likewise, the
         client MUST discard any knowledge obtained from the server,
         such as the list of available POP3 service extensions.

セキュリティ層が実施すると、サーバは以前にSASL交渉自体から得られなかったクライアントから得られたどんな知識も捨てなければなりません。 同様に、クライアントはサーバから得られた利用可能なPOP3サービス拡張子のリストなどのどんな知識も捨てなければなりません。

         When both Transport Layer Security (TLS) (see [RFC4346]) and
         SASL security layers are in effect, the TLS encoding MUST be
         applied after the SASL encoding when sending data.  (According
         to [RFC2595], STLS can only be issued before AUTH in any case.)

Transport Layer Security(TLS)([RFC4346]を見る)とSASLセキュリティ層の両方が有効であるときに、データを送るとき、SASLコード化の後にTLSコード化を適用しなければなりません。 (どのような場合でも、[RFC2595]に従って、AUTHの前でSTLSを発行できるだけです。)

         Note that POP3 does not allow for additional data to be sent
         with a message indicating a successful outcome (see Section 3.6
         of [RFC4422]).

POP3が、メッセージがうまくいっている結果を示していて追加データが送られるのを許容しないことに注意してください([RFC4422]のセクション3.6を見てください)。

         The service name specified by this protocol's profile of SASL
         is "pop".

このプロトコルのSASLのプロフィールによって指定されたサービス名は「大衆的です」。

         If an AUTH command fails, the client may try another
         authentication mechanism or present different credentials by
         issuing another AUTH command (or by using one of the other POP3
         authentication mechanisms).  Likewise, the server MUST behave
         as if the client had not issued the AUTH command.

AUTHコマンドが失敗するなら、クライアントは、別のAUTHコマンド(または他のPOP3認証機構の1つを使用することによって)を発行することによって、別の認証機構か現在の異なった資格証明書を試みるかもしれません。 同様に、まるでクライアントがAUTHコマンドを発行していないかのようにサーバは振る舞わなければなりません。

         To ensure interoperability, client and server implementations
         of this extension MUST implement the PLAIN SASL mechanism
         [RFC4616] running over TLS [RFC2595].

TLS[RFC2595]をひいて、この拡大の相互運用性、クライアント、およびサーバ実装を確実にするのは、PLAIN SASLがメカニズム[RFC4616]であると実装しなければなりません。

         A server implementation MUST implement a configuration in which
         it does NOT advertise or permit any plaintext password
         mechanisms, unless the STLS command has been used to negotiate
         a TLS session (see [RFC2595]).  As described by RFC 4616, this
         configuration SHOULD be the default configuration.  Before
         using a plaintext password mechanism over a TLS session, client

サーバ実装はそれがどんな平文パスワードメカニズムも広告を出しもしませんし、可能にもしない構成を実装しなければなりません、STLSコマンドがTLSセッションを交渉するのに使用されていない場合([RFC2595]を見てください)。 デフォルトが構成であったなら4616、RFCによるこの構成SHOULDについて説明するので。 TLSセッション、クライアントの上で平文パスワードメカニズムを使用する前に

Siemborski & Menon-Sen      Standards Track                     [Page 6]

RFC 5034           POP3 SASL Authentication Mechanism          July 2007

Siemborskiとメノン-銭の規格はPOP3 SASL認証機構2007年7月にRFC5034を追跡します[6ページ]。

         implementations MUST verify the TLS server certificate as
         required by RFC 2595, Section 2.4.  Client and server
         implementations SHOULD implement additional SASL mechanisms
         that do not send plaintext passwords, such as the GSSAPI
         [RFC4752] mechanism.

実装は必要に応じてRFC2595、セクション2.4でTLSサーバ証明書について確かめなければなりません。 クライアントとサーバ実装SHOULDは平文パスワードを送らない追加SASLメカニズムを実装します、GSSAPI[RFC4752]メカニズムなどのように。

5.  Formal Syntax

5. 正式な構文

   The following syntax specification uses the Augmented Backus-Naur
   Form notation as specified in [RFC4234].  The rules CRLF, ALPHA, and
   DIGIT are imported from [RFC4234].  The sasl-mech rule is from
   [RFC4422].

以下の構文仕様は[RFC4234]の指定されるとしてのAugmentedバッカス記法記法を使用します。 規則のCRLF、アルファー、およびDIGITは[RFC4234]からインポートされます。 sasl-mech規則は[RFC4422]から来ています。

   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.

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

      auth-command     = "AUTH" SP sasl-mech [SP initial-response]
                         *(CRLF [base64]) [CRLF cancel-response] CRLF

"AUTH"SP sasl-mech[SPの初期の応答]*(CRLF[base64])[CRLFキャンセル応答]auth-コマンド=CRLF

      initial-response = base64 / "="

初期の応答はbase64/「=」と等しいです。

      cancel-response  = "*"

キャンセル応答は「*」と等しいです。

      base64           = base64-terminal /
                         ( 1*(4base64-CHAR) [base64-terminal] )

base64はbase64-端末/と等しいです。(1*(4base64-炭)[base64端末の])

      base64-char      = ALPHA / DIGIT / "+" / "/"
                         ;; Case-sensitive

「base64-炭=アルファー/ DIGIT /「+」/」/、」、。 大文字と小文字を区別

      base64-terminal  = (2base64-char "==") / (3base64-char "=")

base64-端末=(2base64-炭の「=」)/(3base64-炭の「=」)

      continue-req     = "+" SP [base64] CRLF

「+」 reqが継続的な=SP[base64]CRLF

   Additionally, the ABNF specified in [RFC2449] is updated as follows:

さらに、以下の通り[RFC2449]で指定されたABNFをアップデートします:

      response         =/ continue-req

reqを応答=/続けています。

Siemborski & Menon-Sen      Standards Track                     [Page 7]

RFC 5034           POP3 SASL Authentication Mechanism          July 2007

Siemborskiとメノン-銭の規格はPOP3 SASL認証機構2007年7月にRFC5034を追跡します[7ページ]。

6.  Examples

6. 例

   Here is an example of a client attempting AUTH PLAIN (see [RFC4616])
   under TLS and making use of the initial client response:

ここに、TLSの下でAUTH PLAIN([RFC4616]を見る)を試みて、初期のクライアント応答を利用するクライアントの例は、あります:

        S: +OK pop.example.com BlurdyBlurp POP3 server ready
        C: CAPA
        S: +OK List of capabilities follows
        S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
        S: STLS
        S: IMPLEMENTATION BlurdyBlurp POP3 server
        S: .
        C: STLS
        S: +OK Begin TLS negotiation now
            (TLS negotiation proceeds, further commands protected by TLS
            layer)
        C: CAPA
        S: +OK List of capabilities follows
        S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
        S: IMPLEMENTATION BlurdyBlurp POP3 server
        S: .
        C: AUTH PLAIN dGVzdAB0ZXN0AHRlc3Q=
        S: +OK Maildrop locked and ready

S: + OKのpop.example.com BlurdyBlurp POP3サーバ持ち合わせのC: 高級キューバタバコS: 能力の+OK ListはSに続きます: SASLのダイジェスト-MD5 GSSAPIの匿名のS: STLS S: IMPLEMENTATION BlurdyBlurp POP3サーバS: . C: STLS S: +は現在、Begin TLS交渉を承認します。(TLS交渉は続いて、さらなるコマンドはTLS層) Cで保護されました: 高級キューバタバコS: 能力の+OK ListはSに続きます: SASLの明瞭なダイジェスト-MD5 GSSAPI匿名のS: IMPLEMENTATION BlurdyBlurp POP3サーバS: . C: AUTHの明瞭なdGVzdAB0ZXN0AHRlc3Q= S: +はロックされていて準備ができていた状態でMaildropを承認します。

   Here is another client that is attempting AUTH PLAIN under a TLS
   layer, this time without the initial response.  Parts of the
   negotiation before the TLS layer was established have been omitted:

ここに、すなわち、別のクライアントは、初期の応答なしでTLS層の下におけるAUTH PLAIN、今回を試みながら、います。 TLS層が確立される前に交渉の部品は省略されました:

            (TLS negotiation proceeds, further commands protected by TLS
            layer)
        C: CAPA
        S: +OK List of capabilities follows
        S: SASL PLAIN DIGEST-MD5 GSSAPI ANONYMOUS
        S: IMPLEMENTATION BlurdyBlurp POP3 server
        S: .
        C: AUTH PLAIN
            (note that there is a space following the '+' on the
            following line)
        S: +
        C: dGVzdAB0ZXN0AHRlc3Q=
        S: +OK Maildrop locked and ready

(TLS交渉売り上げ、TLS層) Cで保護されたさらなるコマンド: 高級キューバタバコS: 能力の+OK ListはSに続きます: SASLの明瞭なダイジェスト-MD5 GSSAPI匿名のS: IMPLEMENTATION BlurdyBlurp POP3サーバS: . C: AUTH PLAIN('+'に続くスペースが以下の系列にあることに注意する)S: + C: dGVzdAB0ZXN0AHRlc3Q= S: +はロックされていて準備ができていた状態でMaildropを承認します。

Siemborski & Menon-Sen      Standards Track                     [Page 8]

RFC 5034           POP3 SASL Authentication Mechanism          July 2007

Siemborskiとメノン-銭の規格はPOP3 SASL認証機構2007年7月にRFC5034を追跡します[8ページ]。

   Here is an example using a mechanism in which the exchange begins
   with a server challenge (the long lines are broken for editorial
   clarity only):

ここに、例が交換がサーバ挑戦で始まるメカニズムを使用することであります(長い系列は編集の明快だけために壊されます):

         S: +OK pop.example.com BlurdyBlurp POP3 server ready
         C: CAPA
         S: +OK List of capabilities follows
         S: SASL DIGEST-MD5 GSSAPI ANONYMOUS
         S: STLS
         S: IMPLEMENTATION BlurdyBlurp POP3 server
         S: .
         C: AUTH DIGEST-MD5
         S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0
              RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh
              cnNldD11dGYtOA==
         C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2
            QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw
            MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9In
            BvcC9lbHdvb2QuaW5ub3NvZnQuY29tIixyZXNwb25zZT1iMGQ1NmQyZjA1
            NGMyNGI2MjA3MjMyMjEwNjQ2OGRiOSxxb3A9YXV0aA==
         S: + cnNwYXV0aD0wYjk3MTQ2MmNlZjVlOGY5MzBkYjlhMzNiMDJmYzlhMA==
         C:
         S: +OK Maildrop locked and ready

S: + OKのpop.example.com BlurdyBlurp POP3サーバ持ち合わせのC: 高級キューバタバコS: 能力の+OK ListはSに続きます: SASLのダイジェスト-MD5 GSSAPIの匿名のS: STLS S: IMPLEMENTATION BlurdyBlurp POP3サーバS: . C: AUTHダイジェスト-MD5 S: + cmVhbG09ImVsd29vZC5pbm5vc29mdC5jb20iLG5vbmNlPSJPQTZNRzl0 RVFHbTJoaCIscW9wPSJhdXRoIixhbGdvcml0aG09bWQ1LXNlc3MsY2hh cnNldD11dGYtOA=C: Y2hhcnNldD11dGYtOCx1c2VybmFtZT0iY2hyaXMiLHJlYWxtPSJlbHdvb2QuaW5ub3NvZnQuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLG5jPTAw MDAwMDAxLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLGRpZ2VzdC11cmk9In BvcC9lbHdvb2QuaW5ub3NvZnQuY29tIixyZXNwb25zZT1iMGQ1NmQyZjA1 NGMyNGI2MjA3MjMyMjEwNjQ2OGRiOSxxb3A9YXV0aA== S: + cnNwYXV0aD0wYjk3MTQ2MmNlZjVlOGY5MzBkYjlhMzNiMDJmYzlhMA=C: S: +はロックされていて準備ができていた状態でMaildropを承認します。

7.  Security Considerations

7. セキュリティ問題

   Security issues are discussed throughout this document.

このドキュメント中で安全保障問題について議論します。

8.  IANA Considerations

8. IANA問題

   The IANA has updated its site to refer to this RFC instead of
   [RFC1734] in http://www.iana.org/assignments/pop3-extension-mechanism
   (the POP3 extension registry), and also in
   http://www.iana.org/assignments/gssapi-service-names (the GSSAPI/SASL
   service name registry).

IANAは、 http://www.iana.org/assignments/pop3-extension-mechanism (POP3拡大登録)、および http://www.iana.org/assignments/gssapi-service-names (登録というGSSAPI/SASLサービス名)でも[RFC1734]の代わりにこのRFCについて言及するためにサイトをアップデートしました。

9.  Acknowledgments

9. 承認

   The authors would like to acknowledge the contributions of John
   Myers, Randall Gellens, Chris Newman, Laurence Lundblade, and other
   contributors to RFC 1734 and RFC 2554, on which this document draws
   heavily.

作者はこのドキュメントが大いに引き込まれるRFC1734とRFC2554のジョン・マイアーズ、ランドルGellens、クリス・ニューマン、ローレンスLundblade、および他の貢献者の貢献を承諾したがっています。

   The authors would also like to thank Ken Murchison, Randall Gellens,
   Alexey Melnikov, Mark Crispin, Arnt Gulbrandsen, Lisa Dusseault,
   Frank Ellermann, and Philip Guenther for their reviews of this
   document.

また、作者は彼らのこのドキュメントのレビューについてケン・マーチソン、ランドルGellens、Alexeyメリニコフ、マーク・クリスピン、Arnt Gulbrandsen、リサDusseault、フランクEllermann、およびフィリップ・グンサーに感謝したがっています。

Siemborski & Menon-Sen      Standards Track                     [Page 9]

RFC 5034           POP3 SASL Authentication Mechanism          July 2007

Siemborskiとメノン-銭の規格はPOP3 SASL認証機構2007年7月にRFC5034を追跡します[9ページ]。

10.  Changes From RFC 1734, RFC 2449.

10. RFC1734、RFC2449年からの変化。

   1. Updated references to newer versions of various specifications,
       particularly RFC 4422.

1. 様々な仕様、特にRFC4422の、より新しいバージョンの参照をアップデートしました。

   2. The SASL-based semantics defined in RFC 2449 are now normative for
       the AUTH extension.

2. AUTH拡張子に、RFC2449で定義されたSASLベースの意味論は現在、規範的です。

   3. The proper behaviour and handling of initial client responses is
       defined, with examples and references to SASL.

3. 初期のクライアント応答の適切なふるまいと取り扱いはSASLの例と参照で定義されます。

   4. New minimum requirement of support for TLS+PLAIN.

4. TLS+PLAINのサポートの新しい必要最小限。

   5. The SASLprep profile SHOULD be used to prepare authorization
       identities.

5. SASLprepはSHOULDの輪郭を描きます。承認のアイデンティティを準備するのが使用されてください。

   6. Clarify that the TLS encoding should be applied after any encoding
       applied by SASL security layers.

6. はっきりさせてください。いずれのTLSコード化も次々と適用されるべきであるのはSASLセキュリティ層のそばで適用されました。

   7. Note that the mechanism list can change after STLS.

7. メカニズムリストがSTLSの後に変化できることに注意してください。

   8. Explicitly mention that "=" means a zero-length initial response.

8. 「=」がゼロ・レングスの初期の応答を意味すると明らかに言及してください。

   9. Note that POP3 doesn't allow additional data to be sent with +OK.

9. POP3が、追加データが+ OKと共に送られるのを許容しないことに注意してください。

11. Normative References

11. 引用規格

   [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, May 1996.

[RFC1939] マイアーズ、J.、およびM.ローズ、「郵便局は議定書を作ります--バージョン3インチ、STD53、RFC1939、1996年5月。」

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC2449]  Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension
              Mechanism", RFC 2449, November 1998.

[RFC2449] GellensとR.とニューマン、C.とL.Lundblade、「POP3拡張機能」、RFC2449、1998年11月。

   [RFC2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC
              2595, June 1999.

[RFC2595] ニューマン、C.、「IMAP、POP3、およびACAPとTLSを使用します」、RFC2595、1999年6月。

   [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
              Internationalized Strings ("stringprep")", RFC 3454,
              December 2002.

[RFC3454] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、2002年12月。

   [RFC4013]  Zeilenga, K., "SASLprep: Stringprep Profile for User Names
              and Passwords", RFC 4013, February 2005.

[RFC4013]Zeilenga、K.、「SASLprep:」 「ユーザ名とパスワードのためのStringprepプロフィール」、RFC4013、2005年2月。

   [RFC4234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
              Syntax Specifications: ABNF", RFC 4234, October 2005.

エド[RFC4234]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。

Siemborski & Menon-Sen      Standards Track                    [Page 10]

RFC 5034           POP3 SASL Authentication Mechanism          July 2007

Siemborskiとメノン-銭の規格はPOP3 SASL認証機構2007年7月にRFC5034を追跡します[10ページ]。

   [RFC4422]  Melnikov, A., Ed., and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422, June
              2006.

[RFC4422]メリニコフ、A.、エド、K.Zeilenga、エド、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、6月2006日

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, October 2006.

[RFC4648]Josefsson、2006年10月のS.、「Base16、Base32、およびBase64データEncodings」RFC4648。

   [RFC4616]  Zeilenga, K., Ed., "The PLAIN Simple Authentication and
              Security Layer (SASL) Mechanism", RFC 4616, August 2006.

[RFC4616] Zeilenga、K.、エド、「明瞭な簡易認証とセキュリティ層(SASL)のメカニズム」、RFC4616、8月2006日

12. Informative References

12. 有益な参照

   [RFC1734]  Myers, J., "POP3 AUTHentication command", RFC 1734,
              December 1994.

[RFC1734] マイアーズ、J.、「POP3 AUTHenticationコマンド」、RFC1734、1994年12月。

   [RFC3206]  Gellens, R., "The SYS and AUTH POP Response Codes", RFC
              3206, February 2002.

[RFC3206] Gellens、R.、「SYSとAUTHは応答コードを飛び出す」RFC3206、2002年2月。

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。

   [RFC4752]  Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple
              Authentication and Security Layer (SASL) Mechanism", RFC
              4752, November 2006.

[RFC4752] メリニコフ、A.、エド、「ケルベロスV5("GSSAPI")簡易認証とセキュリティ層(SASL)のメカニズム」、RFC4752、11月2006日

Authors' Addresses

作者のアドレス

   Robert Siemborski
   Google, Inc.
   1600 Ampitheatre Parkway
   Mountain View, CA 94043

ロバートSiemborski Google Inc.1600Ampitheatre Parkwayマウンテンビュー、カリフォルニア 94043

   Phone: +1 650 623 6925
   EMail: robsiemb@google.com

以下に電話をしてください。 +1 6925年の650 623メール: robsiemb@google.com

   Abhijit Menon-Sen
   Oryx Mail Systems GmbH

Abhijitメノン-銭のオリックスメールシステムGmbH

   EMail: ams@oryx.com

メール: ams@oryx.com

Siemborski & Menon-Sen      Standards Track                    [Page 11]

RFC 5034           POP3 SASL Authentication Mechanism          July 2007

Siemborskiとメノン-銭の規格はPOP3 SASL認証機構2007年7月にRFC5034を追跡します[11ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   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, THE IETF TRUST 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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

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 currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Siemborski & Menon-Sen      Standards Track                    [Page 12]

Siemborskiとメノン-銭の標準化過程[12ページ]