[要約] RFC 2222は、Simple Authentication and Security Layer（SASL）プロトコルに関する仕様であり、認証とセキュリティのための簡単なフレームワークを提供します。その目的は、クライアントとサーバー間の認証とセキュリティの手段を標準化し、安全な通信を確保することです。
Network Working Group J. Myers
Request for Comments: 2222 Netscape Communications
Category: Standards Track October 1997
Simple Authentication and Security Layer (SASL)
Simple Authentication and Security Layer（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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
Table of Contents
目次
1. Abstract .............................................. 2
2. Organization of this Document ......................... 2
2.1. How to Read This Document ............................. 2
2.2. Conventions Used in this Document ..................... 2
2.3. Examples .............................................. 3
3. Introduction and Overview ............................. 3
4. Profiling requirements ................................ 4
5. Specific issues ....................................... 5
5.1. Client sends data first ............................... 5
5.2. Server returns success with additional data ........... 5
5.3. Multiple authentications .............................. 5
6. Registration procedures ............................... 6
6.1. Comments on SASL mechanism registrations .............. 6
6.2. Location of Registered SASL Mechanism List ............ 6
6.3. Change Control ........................................ 7
6.4. Registration Template ................................. 7
7. Mechanism definitions ................................. 8
7.1. Kerberos version 4 mechanism .......................... 8
7.2. GSSAPI mechanism ...................................... 9
7.2.1 Client side of authentication protocol exchange ....... 9
7.2.2 Server side of authentication protocol exchange ....... 10
7.2.3 Security layer ........................................ 11
7.3. S/Key mechanism ....................................... 11
7.4. External mechanism .................................... 12
8. References ............................................ 13
9. Security Considerations ............................... 13
10. Author's Address ...................................... 14
Appendix A. Relation of SASL to Transport Security .......... 15
Full Copyright Statement .................................... 16
This document describes a method for adding authentication support to connection-based protocols. To use this specification, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating protection of subsequent protocol interactions. If its use is negotiated, a security layer is inserted between the protocol and the connection. This document describes how a protocol specifies such a command, defines several mechanisms for use by the command, and defines the protocol used for carrying a negotiated security layer over the connection.
このドキュメントでは、接続ベースのプロトコルに認証サポートを追加する方法について説明します。この仕様を使用するために、プロトコルには、サーバーに対してユーザーを識別および認証するためのコマンドと、オプションで後続のプロトコル対話の保護をネゴシエートするためのコマンドが含まれています。その使用がネゴシエートされる場合、セキュリティ層がプロトコルと接続の間に挿入されます。このドキュメントでは、プロトコルがこのようなコマンドを指定する方法を説明し、コマンドが使用するいくつかのメカニズムを定義し、ネゴシエートされたセキュリティレイヤーを接続で伝送するために使用されるプロトコルを定義します。
This document is written to serve two different audiences, protocol designers using this specification to support authentication in their protocol, and implementors of clients or servers for those protocols using this specification.
このドキュメントは、この仕様を使用してプロトコルでの認証をサポートするプロトコル設計者と、この仕様を使用するこれらのプロトコルのクライアントまたはサーバーの実装者という2つの異なる対象者に対応するように作成されています。
The sections "Introduction and Overview", "Profiling requirements", and "Security Considerations" cover issues that protocol designers need to understand and address in profiling this specification for use in a specific protocol.
「概要と概要」、「プロファイリング要件」、および「セキュリティに関する考慮事項」のセクションでは、プロトコル設計者が特定のプロトコルで使用するためにこの仕様をプロファイリングする際に理解し、対処する必要がある問題について説明します。
Implementors of a protocol using this specification need the protocol-specific profiling information in addition to the information in this document.
この仕様を使用するプロトコルの実装者は、このドキュメントの情報に加えて、プロトコル固有のプロファイリング情報を必要とします。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
例では、「C：」と「S：」は、それぞれクライアントとサーバーによって送信された行を示します。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [RFC 2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、および「MAY」は、「RFCで要件レベルを示すために使用するキーワード」[RFC 2119 ]。
Examples in this document are for the IMAP profile [RFC 2060] of this specification. The base64 encoding of challenges and responses, as well as the "+ " preceding the responses are part of the IMAP4 profile, not part of the SASL specification itself.
このドキュメントの例は、この仕様のIMAPプロファイル[RFC 2060]のものです。チャレンジとレスポンスのbase64エンコーディング、およびレスポンスの前の「+」は、IMAP4プロファイルの一部であり、SASL仕様自体の一部ではありません。
The Simple Authentication and Security Layer (SASL) is a method for adding authentication support to connection-based protocols. To use this specification, a protocol includes a command for identifying and authenticating a user to a server and for optionally negotiating a security layer for subsequent protocol interactions.
Simple Authentication and Security Layer（SASL）は、接続ベースのプロトコルに認証サポートを追加する方法です。この仕様を使用するために、プロトコルには、サーバーに対してユーザーを識別および認証するためのコマンドが含まれ、オプションで、後続のプロトコル相互作用のためにセキュリティ層をネゴシエートするためのコマンドが含まれます。
The command has a required argument identifying a SASL mechanism. SASL mechanisms are named by strings, from 1 to 20 characters in length, consisting of upper-case letters, digits, hyphens, and/or underscores. SASL mechanism names must be registered with the IANA. Procedures for registering new SASL mechanisms are given in the section "Registration procedures"
コマンドには、SASLメカニズムを識別する必須の引数があります。 SASLメカニズムの名前は、大文字、数字、ハイフン、アンダースコアで構成される1〜20文字の文字列です。 SASLメカニズム名はIANAに登録する必要があります。新しいSASLメカニズムを登録する手順については、「登録手順」のセクションを参照してください。
If a server supports the requested mechanism, it initiates an authentication protocol exchange. This consists of a series of server challenges and client responses that are specific to the requested mechanism. The challenges and responses are defined by the mechanisms as binary tokens of arbitrary length. The protocol's profile then specifies how these binary tokens are then encoded for transfer over the connection.
サーバーが要求されたメカニズムをサポートしている場合、認証プロトコルの交換を開始します。これは、要求されたメカニズムに固有の一連のサーバーチャレンジとクライアント応答で構成されます。チャレンジとレスポンスは、メカニズムにより、任意の長さのバイナリトークンとして定義されます。次に、プロトコルのプロファイルで、これらのバイナリトークンをエンコードして、接続を介して転送する方法を指定します。
After receiving the authentication command or any client response, a server may issue a challenge, indicate failure, or indicate completion. The protocol's profile specifies how the server indicates which of the above it is doing.
認証コマンドまたはクライアントの応答を受け取った後、サーバーはチャレンジを発行したり、失敗を示したり、完了を示したりする場合があります。プロトコルのプロファイルは、サーバーが上記のどれを実行しているかをどのように示すかを指定します。
After receiving a challenge, a client may issue a response or abort the exchange. The protocol's profile specifies how the client indicates which of the above it is doing.
チャレンジを受け取った後、クライアントは応答を発行するか、交換を中止できます。プロトコルのプロファイルは、クライアントが上記のどれを実行しているかをどのように示すかを指定します。
During the authentication protocol exchange, the mechanism performs authentication, transmits an authorization identity (frequently known as a userid) from the client to server, and negotiates the use of a mechanism-specific security layer. If the use of a security layer is agreed upon, then the mechanism must also define or negotiate the maximum cipher-text buffer size that each side is able to receive.
認証プロトコルの交換中に、メカニズムは認証を実行し、クライアントからサーバーに承認ID（ユーザーIDとも呼ばれる）を送信し、メカニズム固有のセキュリティ層の使用をネゴシエートします。セキュリティ層の使用が合意されている場合、メカニズムは、各サイドが受信できる最大の暗号文バッファサイズも定義またはネゴシエートする必要があります。
The transmitted authorization identity may be different than the identity in the client's authentication credentials. This permits agents such as proxy servers to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying. With any mechanism, transmitting an authorization identity of the empty string directs the server to derive an authorization identity from the client's authentication credentials.
送信される承認IDは、クライアントの認証資格情報のIDとは異なる場合があります。これにより、プロキシサーバーなどのエージェントは、自身の資格情報を使用して認証を行うことができますが、プロキシするIDのアクセス権限を要求できます。どのメカニズムでも、空の文字列の承認IDを送信すると、サーバーはクライアントの認証資格情報から承認IDを取得します。
If use of a security layer is negotiated, it is applied to all subsequent data sent over the connection. The security layer takes effect immediately following the last response of the authentication exchange for data sent by the client and the completion indication for data sent by the server. Once the security layer is in effect, the protocol stream is processed by the security layer into buffers of cipher-text. 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 buffer. The length of the cipher-text buffer must be no larger than the maximum size that was defined or negotiated by the other side.
セキュリティレイヤーの使用がネゴシエートされると、接続を介して送信される後続のすべてのデータに適用されます。セキュリティ層は、クライアントから送信されたデータに対する認証交換の最後の応答と、サーバーから送信されたデータの完了表示の直後に有効になります。セキュリティ層が有効になると、プロトコルストリームはセキュリティ層によって暗号文のバッファに処理されます。各バッファは、次のバッファの長さを表すネットワークバイトオーダーの4オクテットフィールドが付加されたオクテットのストリームとして接続を介して転送されます。暗号化テキストバッファの長さは、相手側で定義またはネゴシエートされた最大サイズを超えてはなりません。
In order to use this specification, a protocol definition must supply the following information:
この仕様を使用するには、プロトコル定義で次の情報を提供する必要があります。
1. A service name, to be selected from the IANA registry of "service" elements for the GSSAPI host-based service name form [RFC 2078].
1. GSSAPIホストベースのサービス名フォーム[RFC 2078]の「サービス」要素のIANAレジストリから選択されるサービス名。
2. A definition of the command to initiate the authentication protocol exchange. This command must have as a parameter the mechanism name being selected by the client.
2. 認証プロトコルの交換を開始するコマンドの定義。このコマンドには、クライアントが選択するメカニズム名をパラメーターとして含める必要があります。
The command SHOULD have an optional parameter giving an initial response. This optional parameter allows the client to avoid a round trip when using a mechanism which is defined to have the client send data first. When this initial response is sent by the client and the selected mechanism is defined to have the server start with an initial challenge, the command fails. See section 5.1 of this document for further information.
コマンドには、初期応答を与えるオプションのパラメーターが必要です（SHOULD）。このオプションのパラメーターを使用すると、クライアントが最初にデータを送信するように定義されたメカニズムを使用するときに、クライアントはラウンドトリップを回避できます。この初期応答がクライアントによって送信され、選択されたメカニズムがサーバーを初期チャレンジで開始するように定義されている場合、コマンドは失敗します。詳細については、このドキュメントのセクション5.1を参照してください。
3. A definition of the method by which the authentication protocol exchange is carried out, including how the challenges and responses are encoded, how the server indicates completion or failure of the exchange, how the client aborts an exchange, and how the exchange method interacts with any line length limits in the protocol.
3. 認証プロトコルの交換が実行される方法の定義。チャレンジと応答がエンコードされる方法、サーバーが交換の完了または失敗を示す方法、クライアントが交換を中止する方法、および交換メソッドがどのように相互作用するかなどプロトコルの行の長さの制限。
4. Identification of the octet where any negotiated security layer starts to take effect, in both directions.
4. ネゴシエートされたセキュリティレイヤーが双方向で有効になるオクテットの識別。
5. A specification of how the authorization identity passed from the client to the server is to be interpreted.
5. クライアントからサーバーに渡された許可IDの解釈方法の仕様。
Some mechanisms specify that the first data sent in the authentication protocol exchange is from the client to the server.
一部のメカニズムでは、認証プロトコル交換で送信される最初のデータがクライアントからサーバーへのものであることを指定しています。
If a protocol's profile permits the command which initiates an authentication protocol exchange to contain an initial client response, this parameter SHOULD be used with such mechanisms.
プロトコルのプロファイルで、認証プロトコル交換を開始するコマンドが初期クライアント応答を含めることを許可している場合、このパラメーターはそのようなメカニズムで使用する必要があります（SHOULD）。
If the initial client response parameter is not given, or if a protocol's profile does not permit the command which initiates an authentication protocol exchange to contain an initial client response, then the server issues a challenge with no data. The client's response to this challenge is then used as the initial client response. (The server then proceeds to send the next challenge, indicates completion, or indicates failure.)
初期クライアント応答パラメーターが指定されていない場合、またはプロトコルのプロファイルで、認証プロトコル交換を開始するコマンドが初期クライアント応答を含めることを許可していない場合、サーバーはデータのないチャレンジを発行します。このチャレンジに対するクライアントの応答は、最初のクライアント応答として使用されます。 （サーバーは次のチャレンジの送信に進み、完了を示すか、失敗を示します。）
Some mechanisms may specify that server challenge data be sent to the client along with an indication of successful completion of the exchange. This data would, for example, authenticate the server to the client.
一部のメカニズムでは、サーバーチャレンジデータを、交換が正常に完了したことを示すとともにクライアントに送信するように指定できます。このデータは、たとえば、サーバーをクライアントに対して認証します。
If a protocol's profile does not permit this server challenge to be returned with a success indication, then the server issues the server challenge without an indication of successful completion. The client then responds with no data. After receiving this empty response, the server then indicates successful completion.
プロトコルのプロファイルで、このサーバーチャレンジを成功の表示と共に返すことが許可されていない場合、サーバーは、正常に完了したことを示すことなくサーバーチャレンジを発行します。その後、クライアントはデータなしで応答します。この空の応答を受信した後、サーバーは正常に完了したことを示します。
Unless otherwise stated by the protocol's profile, only one successful SASL negotiation may occur in a protocol session. In this case, once an authentication protocol exchange has successfully completed, further attempts to initiate an authentication protocol exchange fail.
プロトコルのプロファイルで特に明記されていない限り、プロトコルセッションではSASLネゴシエーションが1つだけ成功する可能性があります。この場合、認証プロトコルの交換が正常に完了すると、認証プロトコルの交換を開始しようとするそれ以上の試行は失敗します。
In the case that a profile explicitly permits multiple successful SASL negotiations to occur, then in no case may multiple security layers be simultaneously in effect. If a security layer is in effect and a subsequent SASL negotiation selects no security layer, the original security layer remains in effect. If a security layer is in effect and a subsequent SASL negotiation selects a second security layer, then the second security layer replaces the first.
プロファイルが複数のSASLネゴシエーションの成功を明示的に許可する場合、複数のセキュリティレイヤーが同時に有効になることは決してありません。セキュリティレイヤーが有効で、後続のSASLネゴシエーションがセキュリティレイヤーを選択しない場合、元のセキュリティレイヤーは有効なままです。セキュリティ層が有効で、後続のSASLネゴシエーションが2番目のセキュリティ層を選択する場合、2番目のセキュリティ層が最初のセキュリティ層を置き換えます。
Registration of a SASL mechanism is done by filling in the template in section 6.4 and sending it in to iana@isi.edu. IANA has the right to reject obviously bogus registrations, but will perform no review of clams made in the registration form.
SASLメカニズムの登録は、セクション6.4のテンプレートに入力し、それをiana@isi.eduに送信することによって行われます。 IANAは明らかに偽の登録を拒否する権利を有しますが、登録フォームで行われたアサリの審査は行いません。
There is no naming convention for SASL mechanisms; any name that conforms to the syntax of a SASL mechanism name can be registered.
SASLメカニズムには命名規則はありません。 SASLメカニズム名の構文に準拠する任意の名前を登録できます。
While the registration procedures do not require it, authors of SASL mechanisms are encouraged to seek community review and comment whenever that is feasible. Authors may seek community review by posting a specification of their proposed mechanism as an internet-draft. SASL mechanisms intended for widespread use should be standardized through the normal IETF process, when appropriate.
登録手順では必要ありませんが、SASLメカニズムの作成者は、可能な場合はコミュニティのレビューとコメントを求めることをお勧めします。著者は、提案されたメカニズムの仕様をインターネットドラフトとして投稿することにより、コミュニティレビューを求めることができます。広範な使用を目的としたSASLメカニズムは、適切な場合、通常のIETFプロセスを通じて標準化する必要があります。
Comments on registered SASL mechanisms should first be sent to the "owner" of the mechanism. Submitters of comments may, after a reasonable attempt to contact the owner, request IANA to attach their comment to the SASL mechanism registration itself. If IANA approves of this the comment will be made accessible in conjunction with the SASL mechanism registration itself.
登録されたSASLメカニズムに関するコメントは、最初にメカニズムの「所有者」に送信する必要があります。コメントの提出者は、所有者に連絡する合理的な試みの後、SASLメカニズム登録自体にコメントを添付するようIANAに要求できます。 IANAがこれを承認した場合、コメントはSASLメカニズム登録自体と併せてアクセス可能になります。
SASL mechanism registrations will be posted in the anonymous FTP directory "ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-mechanisms/" and all registered SASL mechanisms will be listed in the periodically issued "Assigned Numbers" RFC [currently STD 2, RFC 1700]. The SASL mechanism description and other supporting material may also be published as an Informational RFC by sending it to "rfc-editor@isi.edu" (please follow the instructions to RFC authors [RFC 2223]).
SASLメカニズムの登録は、匿名FTPディレクトリ「ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-mechanisms/」に投稿され、登録されているすべてのSASLメカニズムは、定期的に発行される「割り当てられた番号」にリストされます。 "RFC [現在STD 2、RFC 1700]。 SASLメカニズムの説明とその他のサポート資料は、「rfc-editor@isi.edu」に送信することにより、情報RFCとして公開することもできます（RFC作成者[RFC 2223]への指示に従ってください）。
Once a SASL mechanism registration has been published by IANA, the author may request a change to its definition. The change request follows the same procedure as the registration request.
SASLメカニズムの登録がIANAによって公開されると、作成者はその定義の変更を要求できます。変更要求は、登録要求と同じ手順に従います。
The owner of a SASL mechanism may pass responsibility for the SASL mechanism to another person or agency by informing IANA; this can be done without discussion or review.
SASLメカニズムの所有者は、IANAに通知することにより、SASLメカニズムの責任を別の人または機関に渡すことができます。これは、ディスカッションやレビューなしで行うことができます。
The IESG may reassign responsibility for a SASL mechanism. The most common case of this will be to enable changes to be made to mechanisms where the author of the registration has died, moved out of contact or is otherwise unable to make changes that are important to the community.
IESGはSASLメカニズムの責任を再割り当てする場合があります。この最も一般的なケースは、登録の作成者が死亡した、連絡が取れなくなった、またはコミュニティにとって重要な変更を行うことができないメカニズムを変更できるようにすることです。
SASL mechanism registrations may not be deleted; mechanisms which are no longer believed appropriate for use can be declared OBSOLETE by a change to their "intended use" field; such SASL mechanisms will be clearly marked in the lists published by IANA.
SASLメカニズムの登録は削除できません。使用に適するとは考えられなくなったメカニズムは、「使用目的」フィールドを変更することで廃止と宣言できます。そのようなSASLメカニズムは、IANAによって公開されたリストで明確にマークされます。
The IESG is considered to be the owner of all SASL mechanisms which are on the IETF standards track.
IESGは、IETF標準トラックにあるすべてのSASLメカニズムの所有者であると見なされます。
To: iana@iana.org Subject: Registration of SASL mechanism X
To：iana@iana.org Subject：SASLメカニズムXの登録
SASL mechanism name:
SASLメカニズム名：
Security considerations:
セキュリティに関する考慮事項：
Published specification (optional, recommended):
公開された仕様（オプション、推奨）：
Person & email address to contact for further information:
詳細について連絡する人とメールアドレス：
Intended usage:
使用目的：
(One of COMMON, LIMITED USE or OBSOLETE)
（共通、限定使用、または廃止のいずれか）
Author/Change controller:
著者/変更コントローラ：
(Any other information that the author deems interesting may be added below this line.)
（著者が興味深いと考えるその他の情報は、この行の下に追加できます。）
The following mechanisms are hereby defined.
これにより、以下のメカニズムが定義されます。
The mechanism name associated with Kerberos version 4 is "KERBEROS_V4".
Kerberosバージョン4に関連付けられたメカニズム名は「KERBEROS_V4」です。
The first challenge consists of a random 32-bit number in network byte order. The client responds with a Kerberos ticket and an authenticator for the principal "service.hostname@realm", where "service" is the service name specified in the protocol's profile, "hostname" is the first component of the host name of the server with all letters in lower case, and where "realm" is the Kerberos realm of the server. The encrypted checksum field included within the Kerberos authenticator contains the server provided challenge in network byte order.
最初のチャレンジは、ネットワークバイトオーダーのランダムな32ビット数で構成されています。クライアントはKerberosチケットとプリンシパルの認証子「service.hostname@realm」で応答します。「service」はプロトコルのプロファイルで指定されたサービス名、「hostname」はサーバーのホスト名の最初のコンポーネントですすべて小文字で、「レルム」はサーバーのKerberosレルムです。 Kerberosオーセンティケーター内に含まれる暗号化されたチェックサムフィールドには、サーバーが提供するチャレンジがネットワークバイトオーダーで含まれています。
Upon decrypting and verifying the ticket and authenticator, the server verifies that the contained checksum field equals the original server provided random 32-bit number. Should the verification be successful, the server must add one to the checksum and construct 8 octets of data, with the first four octets containing the incremented checksum in network byte order, the fifth octet containing a bit-mask specifying the security layers supported by the server, and the sixth through eighth octets containing, in network byte order, the maximum cipher-text buffer size the server is able to receive. The server must encrypt using DES ECB mode the 8 octets of data in the session key and issue that encrypted data in a second challenge. The client considers the server authenticated if the first four octets of the un-encrypted data is equal to one plus the checksum it previously sent.
チケットとオーセンティケーターを復号化および検証すると、サーバーは、含まれているチェックサムフィールドが元のサーバーが提供するランダムな32ビット番号と等しいことを検証します。検証が成功した場合、サーバーは1をチェックサムに追加して8オクテットのデータを構築する必要があります。最初の4オクテットはネットワークのバイト順で増分されたチェックサムを含み、5番目のオクテットはビットマスクを含み、サーバー、およびネットワークバイト順で、サーバーが受信できる最大の暗号化テキストバッファーサイズを含む6〜8オクテット。サーバーは、DES ECBモードを使用してセッションキーのデータの8オクテットを暗号化し、2番目のチャレンジでその暗号化されたデータを発行する必要があります。暗号化されていないデータの最初の4つのオクテットが1と以前に送信したチェックサムの合計に等しい場合、クライアントはサーバーが認証されたと見なします。
The client must construct data with the first four octets containing the original server-issued checksum in network byte order, the fifth octet containing the bit-mask specifying the selected security layer, the sixth through eighth octets containing in network byte order the maximum cipher-text buffer size the client is able to receive, and the following octets containing the authorization identity. The client must then append from one to eight zero-valued octets so that the length of the data is a multiple of eight octets. The client must then encrypt using DES PCBC mode the data with the session key and respond with the encrypted data. The server decrypts the data and verifies the contained checksum. The server must verify that the principal identified in the Kerberos ticket is authorized to connect as that authorization identity. After this verification, the authentication process is complete.
クライアントは、最初の4つのオクテットがサーバーが発行した元のチェックサムをネットワークバイト順で含み、5番目のオクテットが選択したセキュリティレイヤーを指定するビットマスクを含み、6番目から8番目のオクテットがネットワークバイト順で最大暗号を含むデータを構築する必要があります。クライアントが受信できるテキストバッファーサイズ、および認証IDを含む次のオクテット。次に、クライアントは1〜8個のゼロ値オクテットを追加して、データの長さが8オクテットの倍数になるようにする必要があります。次に、クライアントはDES PCBCモードを使用してデータをセッションキーで暗号化し、暗号化されたデータで応答する必要があります。サーバーはデータを復号化し、含まれているチェックサムを検証します。サーバーは、Kerberosチケットで識別されたプリンシパルがその承認IDとして接続することを承認されていることを確認する必要があります。この確認の後、認証プロセスが完了します。
The security layers and their corresponding bit-masks are as follows:
セキュリティ層とそれに対応するビットマスクは次のとおりです。
1 No security layer 2 Integrity (krb_mk_safe) protection 4 Privacy (krb_mk_priv) protection
1セキュリティレイヤーなし2整合性（krb_mk_safe）保護4プライバシー（krb_mk_priv）保護
Other bit-masks may be defined in the future; bits which are not understood must be negotiated off.
他のビットマスクは将来定義されるかもしれません。理解できないビットはネゴシエートする必要があります。
EXAMPLE: The following are two Kerberos version 4 login scenarios to the IMAP4 protocol (note that the line breaks in the sample authenticators are for editorial clarity and are not in real authenticators)
例：以下は、IMAP4プロトコルへの2つのKerberosバージョン4ログインシナリオです（サンプルオーセンティケーターの改行は、編集を明確にするためのものであり、実際のオーセンティケーターではありません）。
S: * OK IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful
S: * OK IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + gcfgCA==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: A001 NO Kerberos V4 authentication failed
The mechanism name associated with all mechanisms employing the GSSAPI [RFC 2078] is "GSSAPI".
GSSAPI [RFC 2078]を使用するすべてのメカニズムに関連付けられているメカニズム名は「GSSAPI」です。
The client calls GSS_Init_sec_context, passing in 0 for input_context_handle (initially) and a targ_name equal to output_name from GSS_Import_Name called with input_name_type of GSS_C_NT_HOSTBASED_SERVICE and input_name_string of "service@hostname" where "service" is the service name specified in the protocol's profile, and "hostname" is the fully qualified host name of the server. The client then responds with the resulting output_token. If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client should expect the server to issue a token in a subsequent challenge. The client must pass the token to another call to GSS_Init_sec_context, repeating the actions in this paragraph.
クライアントはGSS_Init_sec_contextを呼び出し、（最初に）input_context_handleに0を渡し、GSS_Import_Nameからのoutput_nameに等しいtarg_nameをGSS_C_NT_HOSTBASED_SERVICEのinput_name_typeと「service @ hostname」のinput_name_stringで呼び出します。ここで、「service」はプロトコルのプロファイルで指定されたサービス名で、 hostname」は、サーバーの完全修飾ホスト名です。次に、クライアントは結果のoutput_tokenで応答します。 GSS_Init_sec_contextがGSS_S_CONTINUE_NEEDEDを返す場合、クライアントはサーバーが後続のチャレンジでトークンを発行することを期待する必要があります。クライアントはトークンをGSS_Init_sec_contextへの別の呼び出しに渡し、この段落のアクションを繰り返す必要があります。
When GSS_Init_sec_context returns GSS_S_COMPLETE, the client takes the following actions: If the last call to GSS_Init_sec_context returned an output_token, then the client responds with the output_token, otherwise the client responds with no data. The client should then expect the server to issue a token in a subsequent challenge. The client passes this token to GSS_Unwrap and interprets the first octet of resulting cleartext as a bit-mask specifying the security layers supported by the server and the second through fourth octets as the maximum size output_message to send to the server. The client then constructs data, with the first octet containing the bit-mask specifying the selected security layer, the second through fourth octets containing in network byte order the maximum size output_message the client is able to receive, and the remaining octets containing the authorization identity. The client passes the data to GSS_Wrap with conf_flag set to FALSE, and responds with the generated output_message. The client can then consider the server authenticated.
GSS_Init_sec_contextがGSS_S_COMPLETEを返すと、クライアントは次のアクションを実行します。GSS_Init_sec_contextへの最後の呼び出しがoutput_tokenを返した場合、クライアントはoutput_tokenで応答し、そうでない場合、クライアントはデータなしで応答します。クライアントは、サーバーが後続のチャレンジでトークンを発行することを期待する必要があります。クライアントはこのトークンをGSS_Unwrapに渡し、結果のクリアテキストの最初のオクテットをサーバーがサポートするセキュリティレイヤーを指定するビットマスクとして解釈し、2番目から4番目のオクテットをサーバーに送信する最大サイズのoutput_messageとして解釈します。次に、クライアントはデータを構築します。最初のオクテットには、選択したセキュリティレイヤーを指定するビットマスクが含まれ、2番目から4番目のオクテットには、クライアントが受信できる最大サイズのoutput_messageがネットワークバイト順に含まれ、残りのオクテットには認証IDが含まれます。 。クライアントは、conf_flagをFALSEに設定してGSS_Wrapにデータを渡し、生成されたoutput_messageで応答します。その後、クライアントはサーバーが認証されたと見なすことができます。
The server passes the initial client response to GSS_Accept_sec_context as input_token, setting input_context_handle to 0 (initially). If GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED, the server returns the generated output_token to the client in challenge and passes the resulting response to another call to GSS_Accept_sec_context, repeating the actions in this paragraph.
サーバーは、クライアントの初期応答をGSS_Accept_sec_contextにinput_tokenとして渡し、input_context_handleを0に設定します（最初は）。 GSS_Accept_sec_contextがGSS_S_CONTINUE_NEEDEDを返す場合、サーバーは生成されたoutput_tokenをチャレンジ中のクライアントに返し、結果の応答をGSS_Accept_sec_contextへの別の呼び出しに渡し、この段落のアクションを繰り返します。
When GSS_Accept_sec_context returns GSS_S_COMPLETE, the client takes the following actions: If the last call to GSS_Accept_sec_context returned an output_token, the server returns it to the client in a challenge and expects a reply from the client with no data. Whether or not an output_token was returned (and after receipt of any response from the client to such an output_token), the server then constructs 4 octets of data, with the first octet containing a bit-mask specifying the security layers supported by the server and the second through fourth octets containing in network byte order the maximum size output_token the server is able to receive. The server must then pass the plaintext to GSS_Wrap with conf_flag set to FALSE and issue the generated output_message to the client in a challenge. The server must then pass the resulting response to GSS_Unwrap and interpret the first octet of resulting cleartext as the bit-mask for the selected security layer, the second through fourth octets as the maximum size output_message to send to the client, and the remaining octets as the authorization identity. The server must verify that the src_name is authorized to authenticate as the authorization identity. After these verifications, the authentication process is complete.
GSS_Accept_sec_contextがGSS_S_COMPLETEを返す場合、クライアントは次のアクションを実行します。GSS_Accept_sec_contextへの最後の呼び出しがoutput_tokenを返した場合、サーバーはチャレンジでそれをクライアントに返し、データのないクライアントからの応答を期待します。 output_tokenが返されたかどうか（およびクライアントからそのようなoutput_tokenへの応答を受け取った後）、サーバーは4オクテットのデータを作成します。最初のオクテットには、サーバーでサポートされているセキュリティレイヤーを指定するビットマスクが含まれています。サーバーが受信できるoutput_tokenの最大サイズをネットワークバイト順で含む2番目から4番目のオクテット。次に、サーバーは、conf_flagをFALSEに設定してプレーンテキストをGSS_Wrapに渡し、生成されたoutput_messageをチャレンジでクライアントに発行する必要があります。次に、サーバーは結果の応答をGSS_Unwrapに渡し、結果のクリアテキストの最初のオクテットを選択したセキュリティレイヤーのビットマスクとして解釈し、2番目から4番目のオクテットをクライアントに送信する最大サイズのoutput_messageとして解釈し、残りのオクテットを次のように解釈します。認可アイデンティティ。サーバーは、src_nameが許可IDとして認証することを許可されていることを確認する必要があります。これらの検証の後、認証プロセスが完了します。
The security layers and their corresponding bit-masks are as follows:
セキュリティ層とそれに対応するビットマスクは次のとおりです。
1 No security layer 2 Integrity protection. Sender calls GSS_Wrap with conf_flag set to FALSE 4 Privacy protection. Sender calls GSS_Wrap with conf_flag set to TRUE
1セキュリティレイヤーなし2整合性保護。送信者は、conf_flagをFALSEに設定してGSS_Wrapを呼び出します4プライバシー保護。送信者は、conf_flagをTRUEに設定してGSS_Wrapを呼び出します
Other bit-masks may be defined in the future; bits which are not understood must be negotiated off.
他のビットマスクは将来定義されるかもしれません。理解できないビットはネゴシエートする必要があります。
The mechanism name associated with S/Key [RFC 1760] using the MD4 digest algorithm is "SKEY".
MD4ダイジェストアルゴリズムを使用してS / Key [RFC 1760]に関連付けられたメカニズム名は「SKEY」です。
The client sends an initial response with the authorization identity.
クライアントは、認証IDを使用して初期応答を送信します。
The server then issues a challenge which contains the decimal sequence number followed by a single space and the seed string for the indicated authorization identity. The client responds with the one-time-password, as either a 64-bit value in network byte order or encoded in the "six English words" format.
次に、サーバーは、10進数のシーケンス番号とそれに続く単一のスペース、および指定された許可IDのシード文字列を含むチャレンジを発行します。クライアントは、ネットワークバイトオーダーの64ビット値として、または「6つの英単語」形式でエンコードされたワンタイムパスワードで応答します。
The server must verify the one-time-password. After this verification, the authentication process is complete.
サーバーは、ワンタイムパスワードを確認する必要があります。この確認の後、認証プロセスが完了します。
S/Key authentication does not provide for any security layers.
S / Key認証はセキュリティ層を提供しません。
EXAMPLE: The following are two S/Key login scenarios in the IMAP4 protocol.
例：以下は、IMAP4プロトコルでの2つのS / Keyログインシナリオです。
S: * OK IMAP4 Server
C: A001 AUTHENTICATE SKEY
S: +
C: bW9yZ2Fu
S: + OTUgUWE1ODMwOA==
C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
S: A001 OK S/Key authentication successful
S: * OK IMAP4 Server
C: A001 AUTHENTICATE SKEY
S: +
C: c21pdGg=
S: + OTUgUWE1ODMwOA==
C: BsAY3g4gBNo=
S: A001 NO S/Key authentication failed
The following is an S/Key login scenario in an IMAP4-like protocol which has an optional "initial response" argument to the AUTHENTICATE command.
以下は、AUTHENTICATEコマンドへのオプションの「初期応答」引数を持つIMAP4のようなプロトコルでのS / Keyログインシナリオです。
S: * OK IMAP4-Like Server
C: A001 AUTHENTICATE SKEY bW9yZ2Fu
S: + OTUgUWE1ODMwOA==
C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
S: A001 OK S/Key authentication successful
The mechanism name associated with external authentication is "EXTERNAL".
外部認証に関連するメカニズム名は「EXTERNAL」です。
The client sends an initial response with the authorization identity.
クライアントは、認証IDを使用して初期応答を送信します。
The server uses information, external to SASL, to determine whether the client is authorized to authenticate as the authorization identity. If the client is so authorized, the server indicates successful completion of the authentication exchange; otherwise the server indicates failure.
サーバーは、SASLの外部にある情報を使用して、クライアントが承認IDとして認証することを承認されているかどうかを判断します。クライアントがそのように承認されている場合、サーバーは認証交換が正常に完了したことを示します。そうでない場合、サーバーは失敗を示します。
The system providing this external information may be, for example, IPsec or TLS.
この外部情報を提供するシステムは、たとえば、IPsecまたはTLSです。
If the client sends the empty string as the authorization identity (thus requesting the authorization identity be derived from the client's authentication credentials), the authorization identity is to be derived from authentication credentials which exist in the system which is providing the external authentication.
クライアントが空の文字列を承認IDとして送信する（したがって、承認IDがクライアントの認証資格情報から派生することを要求する）場合、承認IDは、外部認証を提供しているシステムに存在する認証資格情報から派生します。
[RFC 2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC 2060] Crispin、M.、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 2060、1996年12月。
[RFC 2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[RFC 2078] Linn、J。、「Generic Security Service Application Program Interface、Version 2」、RFC 2078、1997年1月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC 2119] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、RFC 2119、1997年3月。
[RFC 2223] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC 2223] Postel、J。、およびJ. Reynolds、「Instructions to RFC Authors」、RFC 2223、1997年10月。
[RFC 1760] Haller, N., "The S/Key One-Time Password System", RFC 1760, February 1995.
[RFC 1760] Haller、N。、「S / Keyワンタイムパスワードシステム」、RFC 1760、1995年2月。
[RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC 1700] Reynolds、J。、およびJ. Postel、「Assigned Numbers」、STD 2、RFC 1700、1994年10月。
Security issues are discussed throughout this memo.
セキュリティの問題は、このメモ全体で議論されています。
The mechanisms that support integrity protection are designed such that the negotiation of the security layer and authorization identity is integrity protected. When the client selects a security layer with at least integrity protection, this protects against an active attacker hijacking the connection and modifying the authentication exchange to negotiate a plaintext connection.
整合性保護をサポートするメカニズムは、セキュリティ層と承認IDのネゴシエーションが整合性保護されるように設計されています。クライアントが少なくとも整合性保護を備えたセキュリティ層を選択すると、アクティブな攻撃者が接続を乗っ取り、認証交換を変更してプレーンテキスト接続をネゴシエートするのを防ぎます。
When a server or client supports multiple authentication mechanisms, each of which has a different security strength, it is possible for an active attacker to cause a party to use the least secure mechanism supported. To protect against this sort of attack, a client or server which supports mechanisms of different strengths should have a configurable minimum strength that it will use. It is not sufficient for this minimum strength check to only be on the server, since an active attacker can change which mechanisms the client sees as being supported, causing the client to send authentication credentials for its weakest supported mechanism.
サーバーまたはクライアントが複数の認証メカニズムをサポートし、それぞれに異なるセキュリティ強度がある場合、アクティブな攻撃者が、サポートされている最も安全性の低いメカニズムをパーティに使用させる可能性があります。この種の攻撃から保護するには、さまざまな強度のメカニズムをサポートするクライアントまたはサーバーに、使用する構成可能な最小強度が必要です。アクティブな攻撃者がクライアントがサポートしていると見なすメカニズムを変更し、クライアントがサポートしている最も弱いメカニズムの認証資格情報を送信する可能性があるため、この最小強度チェックをサーバー上で行うだけでは不十分です。
The client's selection of a SASL mechanism is done in the clear and may be modified by an active attacker. It is important for any new SASL mechanisms to be designed such that an active attacker cannot obtain an authentication with weaker security properties by modifying the SASL mechanism name and/or the challenges and responses.
クライアントによるSASLメカニズムの選択は平文で行われ、アクティブな攻撃者によって変更される可能性があります。新しいSASLメカニズムは、SASLメカニズム名やチャレンジとレスポンスを変更して、アクティブな攻撃者がより弱いセキュリティプロパティの認証を取得できないように設計することが重要です。
Any protocol interactions prior to authentication are performed in the clear and may be modified by an active attacker. In the case where a client selects integrity protection, it is important that any security-sensitive protocol negotiations be performed after authentication is complete. Protocols should be designed such that negotiations performed prior to authentication should be either ignored or revalidated once authentication is complete.
認証前のプロトコルの相互作用はすべてクリアテキストで実行され、アクティブな攻撃者によって変更される可能性があります。クライアントが整合性保護を選択する場合、認証が完了した後で、セキュリティに配慮したプロトコルネゴシエーションを実行することが重要です。認証の前に実行されたネゴシエーションが無視されるか、認証が完了すると再検証されるように、プロトコルを設計する必要があります。
John G. Myers Netscape Communications 501 E. Middlefield Road Mail Stop MV-029 Mountain View, CA 94043-4042
John G. Myers Netscape Communications 501 E. Middlefield Road Mail Stop MV-029 Mountain View、CA 94043-4042
EMail: jgmyers@netscape.com
Questions have been raised about the relationship between SASL and various services (such as IPsec and TLS) which provide a secured connection.
SASLと、安全な接続を提供するさまざまなサービス（IPsecやTLSなど）との関係についての質問がありました。
Two of the key features of SASL are:
SASLの主な機能は次の2つです。
1. The separation of the authorization identity from the identity in the client's credentials. This permits agents such as proxy servers to authenticate using their own credentials, yet request the access privileges of the identity for which they are proxying.
1. 許可IDとクライアントの資格情報のIDの分離。これにより、プロキシサーバーなどのエージェントは、自身の資格情報を使用して認証を行うことができますが、プロキシするIDのアクセス権限を要求できます。
2. Upon successful completion of an authentication exchange, the server knows the authorization identity the client wishes to use. This allows servers to move to a "user is authenticated" state in the protocol.
2. 認証交換が正常に完了すると、サーバーはクライアントが使用したい許可IDを認識します。これにより、サーバーはプロトコルの「ユーザー認証済み」状態に移行できます。
These features are extremely important to some application protocols, yet Transport Security services do not always provide them. To define SASL mechanisms based on these services would be a very messy task, as the framing of these services would be redundant with the framing of SASL and some method of providing these important SASL features would have to be devised.
これらの機能は一部のアプリケーションプロトコルにとって非常に重要ですが、Transport Securityサービスは常にそれらを提供するわけではありません。これらのサービスのフレーミングはSASLのフレーミングと冗長であり、これらの重要なSASL機能を提供するいくつかの方法を考案する必要があるため、これらのサービスに基づいてSASLメカニズムを定義することは非常に厄介なタスクになります。
Sometimes it is desired to enable within an existing connection the use of a security service which does not fit the SASL model. (TLS is an example of such a service.) This can be done by adding a command, for example "STARTTLS", to the protocol. Such a command is outside the scope of SASL, and should be different from the command which starts a SASL authentication protocol exchange.
SASLモデルに適合しないセキュリティサービスの使用を既存の接続内で有効にしたい場合があります。 （TLSはそのようなサービスの例です。）これは、プロトコルに「STARTTLS」などのコマンドを追加することで実行できます。このようなコマンドはSASLの範囲外であり、SASL認証プロトコル交換を開始するコマンドとは異なる必要があります。
In certain situations, it is reasonable to use SASL underneath one of these Transport Security services. The transport service would secure the connection, either service would authenticate the client, and SASL would negotiate the authorization identity. The SASL negotiation would be what moves the protocol from "unauthenticated" to "authenticated" state. The "EXTERNAL" SASL mechanism is explicitly intended to handle the case where the transport service secures the connection and authenticates the client and SASL negotiates the authorization identity.
特定の状況では、これらのトランスポートセキュリティサービスのいずれかの下でSASLを使用するのが妥当です。トランスポートサービスは接続を保護し、どちらのサービスもクライアントを認証し、SASLは承認IDをネゴシエートします。 SASLネゴシエーションにより、プロトコルが「非認証」状態から「認証済み」状態に移行します。 "EXTERNAL" SASLメカニズムは、トランスポートサービスが接続を保護してクライアントを認証し、SASLが承認IDをネゴシエートするケースを処理することを明示的に意図しています。
When using SASL underneath a sufficiently strong Transport Security service, a SASL security layer would most likely be redundant. The client and server would thus probably want to negotiate off the use of a SASL security layer.
十分に強力なトランスポートセキュリティサービスの下でSASLを使用する場合、SASLセキュリティレイヤーはおそらく冗長になります。したがって、クライアントとサーバーは、おそらくSASLセキュリティ層の使用について交渉することを望むでしょう。
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright（C）The Internet Society（1997）。全著作権所有。
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 implmentation may be prepared, copied, published andand 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。