Network Working Group M. Nystrom
Request for Comments: 2808 RSA Laboratories
Category: Informational April 2000
The SecurID(r) SASL Mechanism
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
SecurID is a hardware token card product (or software emulation thereof) produced by RSA Security Inc., which is used for end-user authentication. This document defines a SASL [RFC2222] authentication mechanism using these tokens, thereby providing a means for such tokens to be used in SASL environments. This mechanism is only for authentication, and has no effect on the protocol encoding and is not designed to provide integrity or confidentiality services.
SecurIDは、エンドユーザの認証に使用されるRSAセキュリティ社によって製造ハードウェアトークンカード産物（またはそのソフトウェアエミュレーション）です。この文書は、それによってSASL環境で使用されるようなトークンのための手段を提供し、これらのトークンを使用してSASL [RFC2222]認証メカニズムを定義します。このメカニズムは、認証だけのためのものであり、プロトコルのエンコーディングには影響を与えませんし、整合性や機密性サービスを提供するように設計されていません。
This memo assumes the reader has basic familiarity with the SecurID token, its associated authentication protocol and SASL.
このメモは、読者がSecurIDトークン、その関連する認証プロトコルとSASLの基本的な知識を有している前提としています。
How to read this document
この文書の読み方
The key words "MUST", "MUST NOT", "SHALL", "SHOULD" and "MAY" in this document are to be interpreted as defined in [RFC2119].
キーワード「MUST」は、「MUST NOT」、および本書では[RFC2119]で定義されるように解釈されるべきである、「MAY」、「SHOULD」「SHALL」。
In examples, "C:" and "S:" indicate messages sent by the client and server respectively.
例では、「C：」と「S：」はそれぞれクライアントとサーバから送られたメッセージを示しています。
The SECURID SASL mechanism is a good choice for usage scenarios where a client, acting on behalf of a user, is untrusted, as a one-time passcode will only give the client a single opportunity to act maliciously. This mechanism provides authentication only.
SECURID SASLメカニズムは、ワンタイムパスコードのみをクライアントに悪意を持って行動する単一の機会を与えるように、クライアントは、ユーザーに代わって行動する、信頼されていない使用シナリオに適しています。このメカニズムは、認証のみを提供します。
The SECURID SASL mechanism provides a formal way to integrate the existing SecurID authentication method into SASL-enabled protocols including IMAP [RFC2060], ACAP [RFC2244], POP3 [RFC1734] and LDAPv3 [RFC2251].
SECURID SASL機構は、IMAP [RFC2060]、ACAP [RFC2244]、POP3 [RFC1734]とのLDAPv3 [RFC2251]を含むSASL対応プロトコルに既存のSecurID認証方式を統合するための正式な方法を提供します。
The SECURID SASL mechanism provides two-factor based user authentication as defined below.
以下に定義されるようSECURID SASL機構は、二要素ベースのユーザ認証を提供します。
There are basically three entities in the authentication mechanism described here: A user, possessing a SecurID token, an application server, to which the user wants to connect, and an authentication server, capable of authenticating the user. Even though the application server in practice may function as a client with respect to the authentication server, relaying authentication credentials etc. as needed, both servers are, unless explicitly mentioned, collectively termed "the server" here. The protocol used between the application server and the authentication server is outside the scope of this memo. The application client, acting on behalf of the user, is termed "the client".
ユーザー、ユーザーを認証できるのSecurIDトークン、ユーザーが接続したい先のアプリケーションサーバ、および認証サーバを、有する：ここで説明した認証メカニズムにおける3つのエンティティは基本的にあります。実際には、アプリケーション・サーバーが必要に応じて等の認証資格情報を中継、認証サーバに対するクライアントとして機能することができるにもかかわらず、明示的に言及しない限り、両方のサーバーをまとめ、ここで、「サーバー」と呼ばれる、あります。アプリケーションサーバと認証サーバとの間で使用されるプロトコルは、このメモの範囲外です。アプリケーションクライアントは、ユーザーに代わって動作する、「クライアント」と呼ばれています。
The mechanism is based on the use of a shared secret key, or "seed", and a personal identification number (PIN), which is known both by the user and the authentication server. The secret seed is stored on a token that the user possesses, as well as on the authentication server. Hence the term "two-factor authentication", a user needs not only physical access to the token but also knowledge about the PIN in order to perform an authentication. Given the seed, current time of day, and the PIN, a "PASSCODE(r)" is generated by the user's token and sent to the server.
機構は、ユーザと認証サーバの両方によって知られている共有秘密鍵、または「シード」、および個人識別番号（PIN）の使用に基づいています。秘密のシードは、ユーザが所有しているトークン上だけでなく、認証サーバ上に格納されています。したがって、用語「二要素認証」は、ユーザが物理的トークンへのアクセスだけでなく、認証を行うためにPINについての知識だけではないが必要です。種子、現在の時刻、およびPIN、「パスコード（R）」を与えられたユーザーのトークンとサーバに送信することによって生成されます。
The SECURID SASL mechanism provides one service:
SECURID SASLメカニズムは、一つのサービスを提供しています。
- User authentication where the user provides information to the server, so that the server can authenticate the user.
- サーバがユーザを認証できるように、ユーザは、サーバに情報を提供し、ユーザー認証。
This mechanism is identified with the SASL key "SECURID".
このメカニズムは、SASLキー「SECURID」で識別されます。
a) The client generates the credentials using local information (seed, current time and user PIN/password).
a）のクライアントは、ローカル情報（シード、現在の時刻とユーザーPIN /パスワード）を使用して認証情報を生成します。
b) If the underlying protocol permits, the client sends credentials to the server in an initial response message. Otherwise, the client sends a request to the server to initiate the authentication mechanism, and sends credentials after the server's response (see [RFC2222] section 5.1 for more information regarding the initial response option).
b）の基礎となるプロトコルが許可した場合、クライアントは、最初の応答メッセージに、サーバーに資格情報を送信します。そうでない場合、クライアントは認証メカニズムを開始するサーバーにリクエストを送信し、サーバの応答後に資格情報を送信する（初期応答オプションの詳細については、[RFC2222]セクション5.1を参照してください）。
Unless the server requests a new PIN (see below), the contents of the client's initial response SHALL be as follows:
サーバが（下記参照）新しいPINを要求しない限り、以下のように、クライアントの初期応答の内容がなければなりません。
(1) An authorization identity. When this field is empty, it defaults to the authentication identity. This field MAY be used by system administrators or proxy servers to login with a different user identity. This field MUST NOT be longer than 255 octets, SHALL be terminated by a NUL (0) octet, and MUST consist of UTF-8-encoded [RFC2279] printable characters only (US-ASCII [X3.4] is a subset of UTF-8).
（1）認可ID。認証IDにこのフィールドが空の場合、それがデフォルトになります。このフィールドには、別のユーザーIDでログインし、システム管理者またはプロキシサーバによって使用されるかもしれません。このフィールドは、[RFC2279]印字可能な文字のみ（US-ASCII [X3.4]はUTFのサブセットである255オクテットより、NUL（0）オクテットで終了するものとはならず、UTF-8でエンコードで構成されなければなりません-8）。
(2) An authentication identity. The identity whose passcode will be used. If this field is empty, it is assumed to have been transferred by other means (e.g. if the underlying protocol has support for this, like [RFC2251]). This field MUST NOT be longer than 255 octets, SHALL be terminated by a NUL (0) octet, and MUST consist of UTF-8-encoded printable characters only.
（2）認証アイデンティティ。そのパスコードアイデンティティが使用されます。このフィールドが空の場合、それは他の手段によって転送されたものとする（例えば、基礎となるプロトコルのような、このためのサポートを有する場合、[RFC2251]）。このフィールドは、NUL（0）オクテットで終了するものと、より長い255オクテットてはならず、唯一のUTF-8でエンコードされた印刷可能な文字で構成する必要があります。
(3) A passcode. The one-time password that will be used to grant access. This field MUST NOT be shorter than 4 octets, MUST NOT be longer than 32 octets, SHALL be terminated by a NUL (0) octet, and MUST consist of UTF-8-encoded printable characters only. Passcodes usually consist of 4-8 digits.
（3）パスコードを。アクセス権を付与するために使用されるワンタイムパスワード。このフィールドは、NUL（0）オクテットで終了するものと、より長い32オクテットてはならない（MUST NOT）、より短い4つのオクテットてはならず、唯一のUTF-8でエンコードされた印刷可能な文字で構成する必要があります。パスコードは、通常、4-8の数字で構成されています。
The ABNF [RFC2234] form of this message is as follows:
次のように、このメッセージのABNF [RFC2234]の形式です。
credential-pdu = authorization-id authentication-id passcode [pin]
資格-PDU =認可ID認証IDパスコード[ピン]
authorization-id = 0*255VUTF8 %x00
承認-ID = 0 * 255VUTF8％のX00
authentication-id = 0*255VUTF8 %x00
認証ID = 0 * 255VUTF8％のX00
passcode = 4*32VUTF8 %x00
パスコード= 4 * 32VUTF8％のX00
pin ::= 4*32VUTF8 %x00
VUTF8 = <Visible (printable) UTF8-encoded characters>
VUTF8 = <可視（印刷可能）UTF8エンコード文字>
Regarding the <pin> rule, see d) below.
<ピン>ルールについては、下記）Dを参照してください。
c) The server verifies these credentials using its own information. If the verification succeeds, the server sends back a response indicating success to the client. After receiving this response, the client is authenticated. Otherwise, the verification either failed or the server needs an additional set of credentials from the client in order to authenticate the user.
C）サーバは、自身の情報を使用して、これらの資格情報を検証します。検証が成功すると、サーバーはクライアントに成功を示す応答を返します。この応答を受け取った後、クライアントが認証されます。そうでない場合、検証はどちらか失敗したか、サーバがユーザを認証するために、クライアントからの資格情報の追加セットを必要とします。
d) If the server needs an additional set of credentials, it requests them now. This request has the following format, described in ABNF notation:
サーバーは、資格情報の追加セットを必要とする場合はD）、それは今、それらを要求します。この要求は、ABNF表記で説明以下の形式を持っています。
server-request = passcode | pin
サーバー要求=パスコード|ピン
passcode = "passcode" %x00
パスコード= "パスコード" ％のX00
pin = "pin" %x00 [suggested-pin]
ピン=「ピン」％のX00 [示唆ピン]
suggested-pin = 4*32VUTF8 %x00 ; Between 4 and 32 UTF-8 characters
提案ピン= 4 * 32VUTF8％のX00。 UTF-8文字、4〜32
The 'passcode' choice will be sent when the server requests another passcode. The 'pin' choice will be sent when the server requests a new user PIN. The server will either send an empty string or suggest a new user PIN in this message.
サーバが別のパスコードを要求したときに「パスコードチョイスが送信されます。サーバが新しいユーザPINを要求したときに「ピン」選択が送信されます。サーバーは、どちらかの空の文字列を送信したり、このメッセージで新しいユーザPINを提案します。
e) The client generates a new set of credentials using local information and depending on the server's request and sends them to the server. Authentication now continues as in c) above.
e）のクライアントは、ローカルの情報を使用して、サーバーの要求に応じて、資格情報の新しいセットを生成し、サーバに送信します。認証は、現在、上記）は、Cのように継続します。
Note 1: Case d) above may occur e.g. when the clocks on which the server and the client relies are not synchronized.
注1：この場合d）は、例えば、発生することがありとき、サーバーとクライアントが依存するクロックが同期していません。
Note 2: If the server requests a new user PIN, the client MUST respond with a new user PIN (together with a passcode), encoded as a UTF-8 string. If the server supplies the client with a suggested PIN, the client accepts this by replying with the same PIN, but MAY replace it with another one. The length of the PIN is application-dependent as are any other requirements for the PIN, e.g. allowed characters. If the server for some reason does not accept the received PIN, the client MUST be prepared to receive either a message indicating the failure of the authentication or a repeated request for a new PIN. Mechanisms for transferring knowledge about PIN requirements from the server to the client are outside the scope of this memo. However, some information MAY be provided in error messages transferred from the server to the client when applicable.
注2：サーバが新しいユーザPINを要求する場合、クライアントはUTF-8文字列としてエンコードされた新しいユーザPIN（一緒にパスコード付き）、で応じなければなりません。サーバが提案PINをクライアントに提供した場合、クライアントは、同じPINを返信することでこれを受け入れますが、別のものと交換してもよい（MAY）。 PIN、例えばするための任意の他の要件は、ピンの長さは、アプリケーションに依存しています使用できる文字。何らかの理由で、サーバは、受信したPINを受け入れない場合、クライアントは、認証の失敗、または新しいPINのために繰り返し要求を示すメッセージのいずれかを受け取るために準備しなければなりません。サーバからクライアントにPINの要件についての知識を転送するためのメカニズムは、このメモの範囲外です。しかし、いくつかの情報は、サーバからクライアントに適用可能な転送エラーメッセージに提供することができます。
The following example shows the use of the SECURID SASL mechanism with IMAP4. The example is only designed to illustrate the protocol interaction but do provide valid encoding examples.
次の例では、IMAP4とSECURID SASL機構の使用を示します。例は唯一のプロトコル相互作用を例示するために設計されたが、有効な符号化の例を実行します。
The base64 encoding of the last client response, as well as the "+ " preceding the response, is part of the IMAP4 profile, and not a part of this specification itself.
応答に先行する最後のクライアント応答のbase64エンコーディング、ならびに「+」は、IMAP4プロファイルはなく、本明細書自体の部分の一部です。
S: * OK IMAP4 server ready C: A001 CAPABILITY S: * CAPABILITY IMAP4 AUTH=CRAM-MD5 AUTH=SECURID S: A001 OK done C: A002 AUTHENTICATE SECURID S: + C: AG1hZ251cwAxMjM0NTY3OAA= S: A002 OK Welcome, SECURID authenticated user: magnus
S：* OK IMAP4サーバ準備C：A001能力のS：* CAPABILITY IMAP4 AUTH = CRAM-MD5 AUTH = SECURID S：A002 AUTHENTICATE SECURID S：A001はOK Cを行って+ C：AG1hZ251cwAxMjM0NTY3OAA = S：A002ようこそOK、SECURIDは、ユーザーを認証し：マグナス
The following examples show the use of the SECURID SASL mechanism with LDAPv3. The examples are only designed to illustrate the protocol interaction, but do provide valid encoding examples. Usernames, passcodes and PINs are of course fictitious. For readability, all messages are shown in the value-notation defined in [X680]. <credential-pdu> values are shown hex-encoded in the 'credentials' field of LDAP's 'BindRequest' and <server-request> values are shown hex-encoded in the 'serverSaslCreds' field of LDAP's 'BindResponse'.
次の例では、LDAPv3のでSECURID SASLメカニズムの使用を示しています。例は唯一のプロトコルの相互作用を示すために設計されていますが、有効なエンコード例を提供します。ユーザ名、パスコードやPINはもちろん架空のものです。読みやすくするために、すべてのメッセージは、[X680]で定義された値表記で示されています。 <資格-PDU>の値は、16進数でエンコードされたLDAPの「BindRequest」と<サーバー要求>値の資格情報]フィールドに16進数でエンコードされたLDAPの「BindResponse」の「serverSaslCreds」フィールドに示されて表示されます。
Initial response message, successful authentication.
初期応答メッセージ、認証に成功。
C: { messageID 1, protocolOp bindRequest : { version 1, name '434E3D4D41474E5553'H, -- "CN=MAGNUS" authentication sasl : { mechanism '53454355524944'H, -- "SECURID" credentials '006d61676e757300313233343536373800'H } } }
C：{メッセージID 1、protocolOp bindRequest：{バージョン1、名前 '434E3D4D41474E5553'H、 - "CN =マグナス" 認証SASL：{メカニズム' 53454355524944'H、 - "SECURID" クレデンシャル「006d61676e757300313233343536373800'H}}}
S: { messageID 1, protocolOp bindResponse : { resultCode success, matchedDN ''H, errorMessage ''H, } }
S：{メッセージID 1、protocolOp bindResponse：{結果コード成功、matchedDN '' H、にErrorMessage '' H、}}
Initial response message, server requires second passcode.
初期応答メッセージは、サーバーは、第二のパスコードが必要です。
C: { messageID 1, protocolOp bindRequest : { version 1, name '434E3D4D41474E5553'H, -- "CN=MAGNUS" authentication sasl : { mechanism '53454355524944'H, -- "SECURID" credentials '006d61676e757300313233343536373800'H } } }
C：{メッセージID 1、protocolOp bindRequest：{バージョン1、名前 '434E3D4D41474E5553'H、 - "CN =マグナス" 認証SASL：{メカニズム' 53454355524944'H、 - "SECURID" クレデンシャル「006d61676e757300313233343536373800'H}}}
S: { messageID 1, protocolOp bindResponse : { resultCode saslBindInProgress, matchedDN ''H, errorMessage ''H, serverSaslCreds '70617373636f646500'H } }
S：{メッセージID 1、protocolOp bindResponse：{resultCodeがsaslBindInProgress、matchedDN '' H、にErrorMessage '' H、serverSaslCreds「70617373636f646500'H}}
C: { messageID 1, protocolOp bindRequest : { version 1, name '434E3D4D41474E5553'H, -- "CN=MAGNUS" authentication sasl : { mechanism '53454355524944'H, -- "SECURID" credentials '006d61676e757300383736353433323100'H } } }
C：{メッセージID 1、protocolOp bindRequest：{バージョン1、名前 '434E3D4D41474E5553'H、 - "CN =マグナス" 認証SASL：{メカニズム' 53454355524944'H、 - "SECURID" クレデンシャル「006d61676e757300383736353433323100'H}}}
S: { messageID 1, protocolOp bindResponse : { resultCode success, matchedDN ''H, errorMessage ''H, } }
S：{メッセージID 1、protocolOp bindResponse：{結果コード成功、matchedDN '' H、にErrorMessage '' H、}}
Initial response message, server requires new PIN and passcode, and supplies client with a suggested new PIN (which the client accepts).
初期応答メッセージは、サーバが新しいPINとパスコードを必要とし、（クライアントが受け入れる）提案新しいPINをクライアントに提供します。
C: { messageID 1, protocolOp bindRequest : { version 1, name '434E3D4D41474E5553'H, -- "CN=MAGNUS" authentication sasl : { mechanism '53454355524944'H, -- "SECURID" credentials '006d61676e757300313233343536373800'H } } }
C：{メッセージID 1、protocolOp bindRequest：{バージョン1、名前 '434E3D4D41474E5553'H、 - "CN =マグナス" 認証SASL：{メカニズム' 53454355524944'H、 - "SECURID" クレデンシャル「006d61676e757300313233343536373800'H}}}
S: { messageID 1, protocolOp bindResponse : { resultCode saslBindInProgress, matchedDN ''H, errorMessage ''H, serverSaslCreds '70696e006b616c6c6500'H } }
S：{メッセージID 1、protocolOp bindResponse：{resultCodeがsaslBindInProgress、matchedDN '' H、にErrorMessage '' H、serverSaslCreds「70696e006b616c6c6500'H}}
C: { messageID 1, protocolOp bindRequest : { version 1, name '434E3D4D41474E5553'H, -- "CN=MAGNUS" authentication sasl : { mechanism '53454355524944'H, -- "SECURID" credentials '006d61676e7573003837343434363734006b616c6c6500'H } } }
C：{メッセージID 1、protocolOp bindRequest：{バージョン1、名前 '434E3D4D41474E5553'H、 - "CN =マグナス" 認証SASL：{メカニズム' 53454355524944'H、 - "SECURID" クレデンシャル「006d61676e7573003837343434363734006b616c6c6500'H}}}
S: { messageID 1, protocolOp bindResponse : { resultCode success, matchedDN ''H, errorMessage ''H, } }
S：{メッセージID 1、protocolOp bindResponse：{結果コード成功、matchedDN '' H、にErrorMessage '' H、}}
This mechanism only provides protection against passive eavesdropping attacks. It does not provide session privacy, server authentication or protection from active attacks. In particular, man-in-the-middle attacks, were an attacker acts as an application server in order to acquire a valid passcode are possible.
このメカニズムは、受動的な盗聴攻撃に対する保護を提供します。これは、能動的な攻撃からのセッションのプライバシー、サーバ認証や保護を提供していません。具体的には、man-in-the-middle攻撃、攻撃者が可能であり、有効なパスコードを取得するために、アプリケーション・サーバーとして機能しました。
In order to protect against such attacks, the client SHOULD make sure that the server is properly authenticated. When user PINs are transmitted, user authentication SHOULD take place on a server-authenticated and confidentiality-protected connection.
このような攻撃から保護するために、クライアントは、サーバが正しく認証されていることを確認する必要があります。ユーザーのPINが送信されると、ユーザ認証は、サーバー認証および機密保護された接続上で行われるべきです。
Server implementations MUST protect against replay attacks, since an attacker could otherwise gain access by replaying a previous, valid request. Clients MUST also protect against replay of PIN-change messages.
攻撃者はそうでない場合は、以前の、有効な要求を再生することによってアクセスを得る可能性があるので、サーバーの実装は、リプレイ攻撃から保護しなければなりません。また、クライアントはPIN-変更メッセージのリプレイから保護しなければなりません。
It is possible for an attacker to listen to most of a passcode, guess the remainder, and then race the legitimate user to complete the authentication. As for OTP [RFC2289], conforming server implementations MUST protect against this race condition. One defense against this attack is outlined below and borrowed from [RFC2289]; implementations MAY use this approach or MAY select an alternative defense.
攻撃者は、パスコードのほとんどに耳を傾け、残りを推測して、認証を完了するために、正当な利用者をレースすることが可能です。 OTP [RFC2289]については、準拠したサーバーの実装は、この競合状態から保護しなければなりません。この攻撃に対する一つの防衛は以下に概説し、[RFC2289]から借りています。実装は、このアプローチを使用したり、代わりの防衛を選択することができます。
One possible defense is to prevent a user from starting multiple simultaneous authentication sessions. This means that once the legitimate user has initiated authentication, an attacker would be blocked until the first authentication process has completed. In this approach, a timeout is necessary to thwart a denial of service attack.
一つの可能な防衛は複数の同時認証セッションを開始するからユーザーを防ぐためです。これは、正当なユーザーが認証を開始した後、最初の認証処理が完了するまで、攻撃者がブロックされることを意味しています。このアプローチでは、タイムアウトは、サービス拒否攻撃を阻止する必要があります。
By registering the SecurID protocol as a SASL mechanism, implementers will have a well-defined way of adding this authentication mechanism to their product. Here is the registration template for the SECURID SASL mechanism:
SASLメカニズムとしてのSecurIDプロトコルを登録することで、実装者は、自社の製品にこの認証機構を追加することの明確な方法があります。ここでSECURID SASLメカニズムの登録テンプレートは次のとおりです。
SASL mechanism name: SECURID Security Considerations: See corresponding section of this memo Published specification: This memo Person & email address to contact for further information: See author's address section below Intended usage: COMMON Author/Change controller: See author's address section below
SASLメカニズム名：SECURIDセキュリティに関する注意事項：詳細のために連絡するためにこのメモ人とEメールアドレス：このメモ公開された仕様書の該当するセクションを参照してくださいCOMMON著者/変更コントローラ：以下を参照してください作者のアドレス部意図している用法下記の著者のアドレスを参照してください
RSA Security Inc. does not make any claims on the general constructions described in this memo, although underlying techniques may be covered. Among the underlying techniques, the SecurID technology is covered by a number of US patents (and foreign counterparts), in particular US patent no. 4,885,778, no. 5,097,505, no. 5,168,520, and 5,657,388.
基本となる技術が覆われていてもよいが、RSA Security Inc.のは、このメモに記載されている一般的な構造上の任意の主張をしません。基礎となる技術の中で、SecurIDの技術は、特定の米国特許なしに、米国特許（および外国のカウンターパート）の数で覆われています。 4885778、ありません。 5097505、ありません。 5168520、および5657388。
SecurID is a registered trademark, and PASSCODE is a trademark, of RSA Security Inc.
SecurIDは登録商標であり、パスコードは、RSA Security Inc.の商標です
[RFC1734] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994.
[RFC1734]マイヤーズ、J.、 "POP3認証コマンド"、RFC 1734、1994年12月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC2060]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 2060、1996年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer", RFC 2222, October 1997.
[RFC2222]マイヤーズ、J.、 "簡易認証セキュリティー層"、RFC 2222、1997年10月。
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[RFC2234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 2234、1997年11月。
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[RFC2244]ニューマン、C.及びJ.マイヤーズ、 "ACAP - アプリケーション構成アクセスプロトコル"、RFC 2244、1997年11月。
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]ワール、M.、ハウズ、T.およびS. Kille、 "軽量のディレクトリアクセスプロトコル（V3）"、RFC 2251、1997年12月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2279] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、RFC 2279、1998年1月。
[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time Password System", RFC 2289, February 1998.
[RFC2289]ハラー、N.、メッツ、C.、Nesser、P.とM.わら、 "ワンタイムパスワードシステム"、RFC 2289、1998年2月。
[X3.4] ANSI, "ANSI X3.4: Information Systems - Coded Character Sets - 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII)," American National Standards Institute.
[X3.4] ANSIは、「ANSIのX3.4：情報システムは - コード化文字セットの - 7ビットの情報交換（7ビットASCII）、のための米国標準コード」米国規格協会。
[X680] ITU-T, "Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation," International Telecommunication Union, 1997.
[X680] ITU-T、 "情報技術 - 抽象構文記法1（ASN.1）：基本的な記法の仕様" 国際電気通信連合、1997年。
The author gratefully acknowledges the contributions of various reviewers of this memo, in particular the ones from John Myers. They have significantly clarified and improved the utility of this specification.
作者は感謝ジョン・マイヤーズからのもの、特に、このメモの様々な査読の貢献を認めています。彼らは非常に明確にし、この仕様の有用性を改善しています。
Magnus Nystrom RSA Laboratories Box 10704 121 29 Stockholm Sweden
マグナスNystrom RSA研究所ボックス10704 121 29ストックホルムスウェーデン
Phone: +46 8 725 0900 EMail: magnus@rsasecurity.com
電話：+46 8 725 0900 Eメール：magnus@rsasecurity.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。