Network Working Group S. Farrell, Ed.
Request for Comments: 3767 Trinity College Dublin
Category: Standards Track June 2004
Securely Available Credentials Protocol
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 (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration. The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP).
この文書は、ユーザがローカルにソフトウェアをインストールし、信頼されているワークステーションを使用して、信用証明書サーバから暗号クレデンシャル（例えば、秘密鍵、PKCS 15位構造）を取得することができるプロトコルを記述し、ないユーザー固有の構成を有します。プロトコルのペイロードは、XMLで記述されています。また、このメモは、プロトコルのブロック拡張可能交換プロトコル（BEEP）プロファイルを指定します。セキュリティ要件は、TLSおよび/または（BEEPを介して）DIGEST-MD5のサポートを義務化によって満たされます。
Table Of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Protocol. . . . . . . . . . . . . . . . . . . . . . . . . 3
3. BEEP Profile for SACRED. . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A: XML Schema . . . . . . . . . . . . . . . . . . . . . . 17
Appendix B: An Example of Tuning with BEEP . . . . . . . . . . . . 20
Appendix C: Provision SACRED using other Protocols . . . . . . . . 23
Editor's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 25
Digital credentials, such as private keys and corresponding certificates, are used to support various Internet protocols, e.g. S/MIME, IPSec, and TLS. In a number of environments, end users wish to use the same credentials on different end-user devices. In a "typical" desktop environment, the user already has many tools available to allow import/export of these credentials. However, this is not very practical. In addition, with some devices, especially wireless and other more constrained devices, the tools required simply do not exist.
そのような秘密鍵とそれに対応する証明書などのデジタル資格情報は、例えば、様々なインターネットプロトコルをサポートするために使用されていますS / MIME、IPSecの、およびTLS。環境の数では、エンドユーザーが異なるエンドユーザデバイスで同じ資格情報を使用したいです。 「典型的な」デスクトップ環境では、ユーザーはすでにこれらの資格情報のインポート/エクスポートを可能にするために使用できる多くのツールを持っています。しかし、これは非常に実用的ではありません。また、いくつかの特に無線機器、および他のより制約の装置で、単純に必要なツールは存在しません。
This document describes a protocol for the secure exchange of such credentials and is a realization of the abstract protocol framework described in [RFC3760].
この文書では、そのような資格情報を安全に交換するためのプロトコルを記述して、[RFC3760]に記載の抽象プロトコルフレームワークの実現です。
Many user-chosen passwords are vulnerable to dictionary attacks. So the SACRED protocol is designed to give no information with which an attacker can acquire information for launching a dictionary attack, whether by eavesdropping or by impersonating either the client or server.
多くのユーザーが選択したパスワードは、辞書攻撃に対して脆弱です。だから、SACREDプロトコルは、攻撃者が盗聴するかどうかによって、あるいはクライアントまたはサーバを偽装することで、辞書攻撃を起動するための情報を取得することができたとの情報を全く与えないように設計されています。
The protocol also allows a user to create or delete an account, change her account password and/or credentials, and upload the new values to the server. The protocol ensures that only someone that knew the old account password is able to modify the credentials as stored on the credential server. The protocol does not preclude configuring a server to disallow some operations (e.g. credential upload) for some users. The account management operations as a whole are optional implementations for both credential servers and clients.
このプロトコルはまた、アカウントを作成または削除をユーザーに許可する自分のアカウントのパスワードおよび/または資格情報を変更し、サーバーに新しい値をアップロードします。プロトコルは、古いアカウントのパスワードを知っていただけで、誰かが信用証明書サーバに保存されているとして、資格情報を変更することが可能であることを保証します。プロトコルは、一部のユーザーのためにいくつかの操作（例えば、資格アップロード）を禁止するようにサーバを構成排除するものではありません。全体として、アカウント管理操作は、資格のサーバーとクライアントの両方のためのオプションの実装です。
Note that there are potentially two "passwords" involved when using this protocol - the first used to authenticate the user to the credential server, and the second to decrypt (parts of) the credential following a download operation. Where the context requires it, we refer to the former as the account password and the latter as the credential password.
このプロトコルを使用する場合、潜在的に二つの「パスワード」関与があることに注意してください - 信用証明書サーバに対してユーザを認証するために使用される第一、及び第二のダウンロード操作下記（の一部）証明書を復号化します。文脈がそれを必要とする場合、我々は、アカウントのパスワードと資格情報のパスワードと後者の前者を参照してください。
Using a protocol such as this is somewhat less secure than using a smart card, but can be used until smart cards and smart card readers on workstations become ubiquitous, and can be useful even after smart cards are ubiquitous, as a backup strategy when a user's smart card is lost or malfunctioning.
このようなプロトコルを使用すると、スマートカードを使用するよりもやや少ない安全ですが、ワークステーション上のスマートカードおよびスマートカードリーダーが広く普及し、スマートカードは時にユーザーのバックアップ戦略として、ユビキタスであっても、後に役立つことができまで使用することができますスマートカードを紛失したり、誤動作しています。
The protocol sets out to meet the requirements in [REQS]. Cryptographic credentials may take the form of private keys, PKCS #15 [PKCS15], or structures. As stated, a profile based on BEEP [BEEP] is specified for message transport and security (integrity, authentication, and confidentiality). In that case, the security requirements are met by mandating support (via BEEP) for TLS [TLS] and/or DIGEST-MD5 [DIGEST-MD5].
プロトコルは[REQS]に要件を満たすように設定しています。暗号クレデンシャルは秘密鍵、PKCS＃15の[PKCS15]、または構造の形態をとることができます。述べたように、BEEP [BEEP]に基づいてプロファイルがメッセージトランスポートおよびセキュリティ（保全性、認証、機密性）のために指定されています。その場合には、セキュリティ要件がTLS [TLS]および/またはDIGEST-MD5 [DIGEST-MD5]のために（BEEPを介して）サポートを義務化することによって満たされます。
We assume the only authentication information available to the user is a username and password.
私たちは、ユーザーが利用できる唯一の認証情報は、ユーザー名とパスワードであると仮定します。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
This section defines the account management and "run-time" operations for the SACRED protocol.
このセクションでは、アカウント管理やSACREDプロトコルのための「実行時」操作を定義しています。
It also describes the message formats used, which are described in XML [XMLSCHEMA]. Appendix A provides an XML schema for these elements.
また、[XMLSCHEMA] XMLで記述されて使用されるメッセージフォーマットを記載しています。付録Aは、これらの要素のためのXMLスキーマを提供します。
The approach taken here is to define SACRED elements that are compatible with the elements used in [XKMS] and [XMLDSIG], so that an implementation of this protocol can easily also support XKMS, and vice versa.
ここで採用したアプローチは、このプロトコルの実装を容易にまたその逆XKMSをサポートする、とすることができるように、[XMLDSIG] [XKMS]および使用される要素と互換性のあるSACRED要素を定義することです。
It is also intended that other SACRED protocol instances (e.g. using a different authentication scheme, credential format, or transport protocol) could re-use many of the definitions here.
また、他のSACREDプロトコルインスタンスはここで定義の多くを再利用することができ（例えば、異なる認証方式、信用証明書フォーマット、またはトランスポートプロトコルを使用して）ことが意図されています。
These operations MAY be implemented, that is, they are OPTIONAL.
これらの操作はつまり、彼らは任意であり、実施することができます。
This operation does NOT REQUIRE authentication.
この操作は、認証を必要としません。
The purpose of this operation is to provide the client with the values required for account creation.
この操作の目的は、アカウントの作成に必要な値をクライアントに提供することです。
The client sends an InfoRequest message (which has no content).
クライアントは、（コンテンツがありません）InfoRequestメッセージを送信します。
The server responds with an InfoResponse message which contains the authentication mechanism parameters for the server and the list of supported ProcessInfo types. For DIGEST-MD5, this consists of the list of realms (each as an XML element named "Realm") which the server supports. There MUST be at least one realm specified.
サーバは、サーバとサポートProcessInfoタイプのリストのための認証機構パラメータを含むInfoResponseメッセージで応答します。 DIGEST-MD5の場合、これは、サーバーがサポートする、レルム（「レルム」という名前のXML要素として、それぞれ）のリストで構成されます。指定された少なくとも一つの領域があるに違いありません。
Clients MUST be able to select one from a list of Realms and MUST be able to disregard any other information present (allowed for extensibility).
クライアントは、レルムのリストから1つを選択できなければならないと（拡張に許可）存在する任意の他の情報を無視することができなければなりません。
This operation REQUIRES server authentication.
この操作は、サーバー認証が必要です。
The purpose of this operation is to setup a new account on the server. The information required for a "new" account will depend on the SASL [SASL] mechanism used.
この操作の目的は、セットアップにサーバー上に新しいアカウントです。 「新規」アカウントに必要な情報が使用さSASL [SASL]メカニズムに依存します。
The client sends a CreateAccountRequest, which contains the account name (e.g. username). It also contains the elements required to create an account for a particular authentication mechanism. The actual information is defined according to the authentication mechanism. For DIGEST-MD5, this consists of the password verifier (the hashed username, password and realm) and the chosen realm. Although more than one set of such data is allowed by the data structures defined in the appendix, clients SHOULD only include one here.
クライアントは、アカウント名（例えば、ユーザ名）が含まれCreateAccountRequestを送信します。また、特定の認証機構のアカウントを作成するために必要な要素が含まれています。実際の情報は、認証メカニズムに従って定義されます。 DIGEST-MD5の場合、これは、パスワード検証（ハッシュ化されたユーザ名、パスワード、および領域）と選択した領域で構成されています。このようなデータの複数のセットが付録で定義されたデータ構造によって許可されているが、クライアントは、ここでしかものを含むべきです。
The server responds with an error or acknowledgement message.
サーバーは、エラーまたは確認メッセージで応答します。
This operation REQUIRES mutual authentication.
この操作は、相互認証を必要とします。
The purpose of this operation is to delete the entire account.
この操作の目的は、全体のアカウントを削除することです。
The client sends a RemoveAccountRequest message (which has no content) to the server.
クライアントは、サーバに（コンテンツがありません）RemoveAccountRequestメッセージを送信します。
The server MUST delete all information relating to the account and respond with an error or acknowledgement message.
サーバーは、アカウントに関連するすべての情報を削除し、エラーや確認メッセージで応じなければなりません。
This operation REQUIRES mutual authentication.
この操作は、相互認証を必要とします。
The purpose of this operation is to allow the client to change the information required for authentication. The information required will depend on the authentication method used.
この操作の目的は、クライアントが認証に必要な情報を変更することができるようにすることです。必要な情報は、使用する認証方式によって異なります。
The client sends a ModifyAccountRequest message, which contains the elements required to change the authentication information for the account, for a particular authentication mechanism. The actual information is defined according to the authentication mechanism. For [DIGEST-MD5], it will consist of a realm and password verifier value.
クライアントは、特定の認証メカニズムのために、アカウントの認証情報を変更するために必要な要素が含まれているModifyAccountRequestメッセージを送信します。実際の情報は、認証メカニズムに従って定義されます。 [DIGEST-MD5]のために、それはレルムとパスワード検証値からなるであろう。
Once the account information has been changed, the server will respond with an error or acknowledgement message.
アカウント情報が変更されると、サーバーはエラーまたは確認メッセージで応答します。
These operations MUST be supported by all conformant implementations.
これらの操作は、すべての準拠実装でサポートしなければなりません。
This operation REQUIRES mutual authentication.
この操作は、相互認証を必要とします。
The purpose of this operation is to allow the client to deposit a credential with the server.
この操作の目的は、クライアントがサーバーとの資格を堆積させることです。
The client sends an UploadRequest message to the server which MUST contain one Credential.
クライアントは1つの資格を含まなければならないサーバにUploadRequestメッセージを送信します。
If a credential with the same credential selector field as in the UploadRequest (a "matching" credential) already exists for the account, then that credential is replaced with the new credential from the UploadRequest. Otherwise a "new" credential is associated with that account. If a new credential is being uploaded, then the client SHOULD include (in LastModified) its local concept of the time (if it has one), or an indicator that it has no clock. The actual value of LastModified can be anything, (but the element has to be present) since this will be overwritten by the server in any case.
UploadRequest（「マッチング」資格）と同じクレデンシャルセレクタフィールドを持つ資格がすでにアカウントに存在する場合、その資格はUploadRequestから新しい信任状に置き換えられます。それ以外の場合は、「新しい」資格は、そのアカウントに関連付けられています。新しい資格がアップロードされている場合、クライアントは（LastModifiedの中で）その現地時間の概念（ある場合）、またはそれは時計を持っていないことを示すインジケータを含むべきです。 LastModifiedの実際の値は、何もすることができる（しかし、要素が存在しなければならない）、これはいずれの場合も、サーバによって上書きされるからです。
If any change is made to the stored credentials associated with the account, then the server MUST update the corresponding LastModified value (returned in DownloadResponse messages) to the current time (at the server).
任意の変更がアカウントに関連付けられて記憶された信任状に形成されている場合、サーバは、（サーバにおける）現在の時刻に（DownloadResponseメッセージで返される）は、対応するLastModifiedの値を更新する必要があります。
The LastModified value in the UploadRequest MUST be the value which was most recently received in a corresponding DownloadResponse for that credential. This means the clients are strongly RECOMMENDED to only produce an UploadRequest based on recently downloaded credentials, since otherwise the LastModified value may be out of date.
UploadRequestでLastModifiedの値は、最も最近にその資格のための対応するDownloadResponseで受信された値でなければなりません。これは、クライアントが強くそうLastModifiedの値が古くなっている可能性があるためだけで、最近ダウンロードした資格情報に基づいてUploadRequestを生成することが推奨されていることを意味します。
The LastModified value can also be of use in detecting conflicts. For example, download to platform A, download to platform B, update from B, update from A. The server could detect a conflict on the second upload. In this case the server MUST respond with a BEEP error (which SHOULD be StaleCredential).
LastModifiedの値も競合を検出する際に使用のものとすることができます。例えば、サーバが第二アップロード時に衝突を検出することができAからプラットフォームB、Bからの更新、更新をダウンロードし、プラットフォームAにダウンロードします。この場合、サーバは、（StaleCredentialべきである）BEEPエラーで応答しなければなりません。
The server replaces the provided LastModified value with the current time at the server before storing the credential. (Note that this means that it would be unwise for a client to include the LastModified field in a ClientInfo digital signature which is calculated over the CredentialType.)
サーバーは、資格情報を格納する前に、サーバーで現在の時刻を提供LastModifiedの値を置き換えます。 （これは、クライアントがCredentialTypeにわたって計算さCLIENTINFOデジタル署名でLastModifiedのフィールドを含めるすることが賢明であろうことを意味することに注意してください。）
The server responds with an error or acknowledgement message.
サーバーは、エラーまたは確認メッセージで応答します。
This operation REQUIRES mutual authentication.
この操作は、相互認証を必要とします。
The purpose of this operation is to allow a client to get one or more credentials from a server (the purpose of the entire protocol really!).
この操作の目的は、クライアントがサーバから1つ以上の資格情報を取得できるようにすることです（実際には全体のプロトコルの目的を！）。
The client sends a DownloadRequest message to the server which MAY contain a credential selector string for the credential. No, or an empty credential selector means the request is for all credentials associated with the account.
クライアントは、資格の資格セレクタ文字列を含むかもしれサーバーにDownloadRequestメッセージを送信します。いいえ、または空のクレデンシャルセレクタは、要求がアカウントに関連付けられたすべての資格情報であることを意味します。
The server responds with a DownloadResponse or an error message. A DownloadResponse contains one or more credential payloads, including the LastModified time which represents the time (at the server) when the last change was made to each credential associated with the account (e.g. subsequent to an UploadRequest).
サーバーはDownloadResponseまたはエラーメッセージで応答します。 DownloadResponseは、最後の変更がアカウントに関連付けられたそれぞれの資格（例えばUploadRequest以降）に行われた場合（サーバーで）時間を表すLastModifiedの時間を含む1つまたは複数の資格ペイロードを含んでいます。
This operation REQUIRES mutual authentication.
この操作は、相互認証を必要とします。
The purpose of this operation is to allow the client to delete one or all credentials associated with the account.
この操作の目的は、クライアントがアカウントに関連付けられている1つのまたはすべてのクレデンシャルを削除できるようにすることです。
The client sends a DeleteRequest message to the server which can contain either a CredentialSelector or an All element.
クライアントはCredentialSelectorまたはすべての要素のいずれかを含むことができ、サーバーにDeleteRequestメッセージを送信します。
If the DeleteRequest contains an All element, then all of the credentials associated with that account are deleted.
DeleteRequestは、すべての要素が含まれている場合は、そのアカウントに関連付けられた資格情報のすべてが削除されます。
If the DeleteRequest contains a CredentialSelector, then the request MAY include a LastModified value. If the LastModified value is present in the DeleteRequest, then it MUST be the value which was most recently received in a corresponding DownloadResponse for that credential. If the value does not match, then the server MUST NOT delete the credentials.
DeleteRequestはCredentialSelectorが含まれている場合、その要求はLastModifiedの値を含んでいてもよいです。 LastModifiedの値がDeleteRequestに存在する場合、それは最近その資格のための対応DownloadResponseで受信した値でなければなりません。値が一致しない場合、サーバーは認証情報を削除してはなりません。
If no "matching" credential exists, the server returns an error.
何の「マッチング」の資格が存在しない場合、サーバーはエラーを返します。
The server responds to this request with an error or acknowledgement message.
サーバーはエラーまたは受信確認メッセージで、この要求に応答します。
Six SACRED operations are defined above. In this section we specify the requirements for security for each of the operations (where supported).
シックス・SACRED操作は、上記で定義されています。 （サポートされている場合）この節では、それぞれの操作のためのセキュリティ要件を指定します。
Operation Security REQUIRED
--------- -----------------
Information request NONE
Create account Server authentication,
Confidentiality, Integrity
Remove account Mutual authentication,
Confidentiality, Integrity
Modify account Mutual authentication,
Confidentiality, Integrity
Credential upload Mutual authentication,
Confidentiality, Integrity
Credential download Mutual authentication,
Confidentiality, Integrity
Credential delete Mutual authentication,
Confidentiality, Integrity
The security requirements can be met by several mechanisms. This document REQUIRES credential servers to support TLS and DIGEST-MD5. Clients MUST support DIGEST-MD5 and TLS with server authentication.
セキュリティ要件は、いくつかのメカニズムによって満たすことができます。この文書では、TLSとDIGEST-MD5をサポートするために、資格のサーバーを必要とします。クライアントは、サーバー認証とDIGEST-MD5およびTLSをサポートしなければなりません。
The mandatory-to-implement TLS cipher suite for SACRED is TLS_RSA_WITH_3DES-EDE_CBC_SHA. Implementations SHOULD also support TLS_RSA_WITH_AES_128_CBC_SHA [TLSAES].
SACREDための実装に必須のTLS暗号スイートはTLS_RSA_WITH_3DES-EDE_CBC_SHAです。また、実装はTLS_RSA_WITH_AES_128_CBC_SHA [TLSAES]をサポートすべきです。
When performing mutual authentication using DIGEST-MD5 for the client, DIGEST-MD5 MUST only be used "within" a TLS server-authenticated "pipe", and MUST only be used for client authentication. That is, we do not use the DIGEST-MD5 security services (confidentiality, integrity etc.).
クライアントのためにDIGEST-MD5を使用して相互認証を行う際には、DIGEST-MD5はTLSサーバ認証「パイプ」「内」で使用されなければならない、とだけクライアント認証を使用しなければなりません。つまり、私たちは、DIGEST-MD5のセキュリティサービス（機密性、完全性など）を使用していません。
When more than one credential is stored under a single account, the client can select a single credential using the optional credential selector string.
複数の資格が単一のアカウントの下に格納されている場合、クライアントは、オプションの資格セレクタ文字列を使用して、単一の資格情報を選択することができます。
There is no concept of a "default credential" - all credentials MUST have an associated selector unique for that account. The selector is REQUIRED for upload requests and OPTIONAL for download requests. If the selector is omitted in a download request, it MUST be interpreted as a request for all the stored credentials.
「デフォルトの資格」の概念はありません - すべてのクレデンシャルは、そのアカウントのユニークな関連したセレクタを持たなければなりません。セレクタは、アップロードのリクエストに必要であり、ダウンロード要求のためのオプションです。セレクタは、ダウンロード要求に省略されている場合、それはすべての保存された資格情報の要求として解釈されなければなりません。
An empty selector string value (i.e. "") in a credential download request is to be interpreted as if the selector string were omitted, i.e. a download request containing this is a request for all credentials.
信用証明書のダウンロード要求に空のセレクタ文字列値（すなわち「」）セレクタ文字列が省略された場合、これを含有する、すなわちダウンロード要求は、すべての資格の要求であると解釈されるべきです。
It is an error to have more than one credential stored under the same account where both have the same credential selector string.
両方が同じクレデンシャルセレクタ文字列を持っている同じアカウントで保存された複数の資格を持っているエラーです。
All messages sent to the server MAY contain ProcessInfo values. This field MAY be used by other specifications or for vendor extensions. For example, a server might require clients to include a phone number in this field. The information response message contains a list of the types of ProcessInfo that the server supports. This extensibility scheme is similar to that used in [XKMS] and [XBULK].
サーバーに送信されたすべてのメッセージがProcessInfoの値が含まれる場合があります。このフィールドは、他の仕様により、またはベンダー拡張のために使用されるかもしれません。例えば、サーバは、このフィールドに電話番号が含まれるように、クライアントが必要な場合があります。情報応答メッセージは、サーバーがサポートするProcessInfoの種類のリストが含まれています。この拡張方式は[XBULK] [XKMS]および使用されるものと同様です。
Where no specific response message is defined for an operation (e.g. for UploadRequest), then the transport will indicate success or failure.
特別応答メッセージが（例えばUploadRequestための）動作のために定義されていない場合、その後、搬送が成功または失敗を示すことになります。
All of the response messages defined here MAY contain a Status string, containing a value intended for human consumption.
ここで定義された応答メッセージのすべてが人間の消費のために意図された値を含む、ステータス文字列を含むかもしれません。
A number of messages involve the Credential element. It has the following fields (all optional fields may occur exactly zero or one times unless otherwise stated):
メッセージの数は、資格の要素を含んでいます。これは、次のフィールドを（特に断りのない限り、すべてのオプションフィールドが正確にゼロまたは1回発生する可能性があります）があります。
- CredentialSelector contains a string by which this particular credential (for this account) can be identified. - PayLoad contains either a ds:KeyInfo or some other form of credential. Implementations MUST support the PKCS #15 form of ds:KeyInfo defined below (the SacredPKCS15 element). - LastModified is a string containing the time (at the server) at which this credential was last modified. - TimeToLive (optional) is a hint clients SHOULD honor, which specifies the number of seconds the downloaded credential is to be usable. - ProcessInfo (optional) MAY contain any (typed) information that the server is intended to process. If the server doesn't support any of the ProcessInfo data, it MAY ignore that data. - ClientInfo (optional) MAY contain any (typed) information that the client is intended to process, but which the server MUST ignore. If the client doesn't support any of the ClientInfo data, it MAY ignore that data (e.g. if the ClientInfo is device specific).
- CredentialSelectorは、（このアカウント用）は、この特定の資格を識別することが可能な文字列が含まれています。 KeyInfoや資格のいくつかの他の形式： - ペイロードには、DSのいずれかが含まれています。 KeyInfoは以下に定義（SacredPKCS15素子）：実装は、DSのPKCS＃15形式をサポートしなければなりません。 - LastModifiedのは、この資格が最後に変更されたときの（サーバーで）時間を含む文字列です。 - （オプション）のTimeToLiveは、ダウンロードした資格が使用できるように秒数を指定し、クライアントが尊重すべきであるヒントは、です。 - サーバが処理することを意図していることを任意の（入力した）情報が含まれる場合があります（オプション）ProcessInfo。サーバがProcessInfoデータのいずれかをサポートしていない場合は、そのデータを無視してもよい（MAY）。 - CLIENTINFO（オプション）は、クライアントが処理することを意図していることを任意の（入力した）情報が含まれる場合がありますが、サーバーは無視しなければなりません。クライアントはCLIENTINFOデータのいずれかをサポートしていない場合、それは無視することがデータ（例えばCLIENTINFOは、特定のデバイスの場合）。
The protocol described in this memo is realized as a [BEEP] profile.
このメモで説明されたプロトコルは、[BEEP]プロフィールとして実現されます。
Future memos may define alternative versions of the BEEP profile for SACRED. When a BEEP peer sends its greeting, it indicates which profiles it is willing to support. Accordingly, when the BEEP client asks to start a channel, it indicates the versions it supports, and if any of these are acceptable to the BEEP server; the latter specifies which profile it is starting.
将来のメモはSACREDためのBEEPプロフィールの代替バージョンを定義することができます。 BEEPピアはその挨拶を送信すると、サポートしていく所存ですプロファイルを示します。 BEEPクライアントがチャネルを開始するために要求する際に、それがサポートしているバージョンを示しており、これらのいずれかがBEEPサーバに受け入れられる場合。それをプロファイル後者の指定を開始しています。
Profile Identification: http://iana.org/beep/sacred
プロフィール同定：http://iana.org/beep/sacred
Messages Exchanged during Channel Creation: InfoRequest, CreateAccountRequest, RemoveAccountRequest, ModifyAccountRequest, DownloadRequest, UploadRequest, DeleteRequest, InfoResponse,
チャンネルの作成時に交換されるメッセージ：InfoRequest、CreateAccountRequest、RemoveAccountRequest、ModifyAccountRequest、DownloadRequest、UploadRequest、DeleteRequest、InfoResponse、
DownloadResponse,
error,
ok
Messages starting one-to-one exchanges: InfoRequest, CreateAccountRequest, RemoveAccountRequest, ModifyAccountRequest, DownloadRequest, UploadRequest, DeleteRequest
InfoRequest、CreateAccountRequest、RemoveAccountRequest、ModifyAccountRequest、DownloadRequest、UploadRequest、DeleteRequest：一対一の交換を開始するメッセージ
Messages in positive replies: ok, InfoResponse, DownloadResponse
正の返信のメッセージ：OK、InfoResponse、DownloadResponse
Messages in negative replies: error
負の返信のメッセージ：エラー
Messages in one-to-many changes: none
なし：1対多の変更のメッセージ
Message Syntax: c.f.,Section 3
メッセージ構文：C.F.、第3節
Message Semantics: c.f., Section 2
メッセージの意味：C.F.、第2節
Contact Information: c.f., the editor's address section of this memo
お問い合わせ先：C.F.、このメモの編集者のアドレス部
Because all but one of the operations of the SACRED profile have security requirements (cf., Section 2.3.1), before starting the SACRED profile, the BEEP session will likely be tuned using either
SACREDプロファイルの操作のうちの1つを除くすべてのセキュリティ要件を持っているので（参照、セクション2.3.1）、SACREDプロフィールを開始する前に、BEEPセッションは、おそらくどちらか使用して調整されます
http://iana.org/beep/TLS
ｈっｔｐ：／／いあな。おｒｇ／べえｐ／ＴＬＳ
or
または
http://iana.org/beep/TLS followed by http://iana.org/SASL/DIGEST-MD5
http://iana.org/beep/TLS http://iana.org/SASL/DIGEST-MD5続きます
Appendix B gives an example of tuning a BEEP session using DIGEST-MD5 (i.e. it shows how to turn on BEEP security).
付録Bは、DIGEST-MD5を使用して、BEEPセッションを調整する例を示し（すなわち、それはBEEPセキュリティをオンにする方法を示して）。
Regardless, upon completion of the negotiation process, a tuning reset occurs in which both BEEP peers issue a new greeting. Consult Section 3 of [BEEP] for an example of how a BEEP peer may choose to issue different greetings based on whether confidentiality is in use.
かかわらず、交渉プロセスが完了すると、チューニングのリセットは、両方のBEEPピアが新しい挨拶を発行起こります。 BEEPピアは、機密性が使用されているかどうかに基づいて異なる挨拶を発行することもできます方法の例については、[BEEP]のセクション3を参照してください。
Any of the messages listed in section 3.2 below may be exchanged during channel initialization (c.f., Section 2.3.1.2 of [BEEP]), e.g.,
セクション3.2以下に記載されているメッセージのいずれかが、例えば、チャネルの初期化（C.F.、[BEEP]のセクション2.3.1.2）の間で交換することができます
C: <start number='1'>
C: <profile uri='http://iana.org/beep/sacred'>
C: <![CDATA[<DownloadRequest ...>]]>
C: </profile>
C: </start>
S: <profile uri='http://iana.org/beep/sacred'> S: <![CDATA[<DownloadResponse ...>]]> S: </profile>
S：<プロファイルのuri = 'のhttp：//iana.org/beep/sacred'> S：<！[CDATA [<DownloadResponse ...>]]> S：</プロフィール>
Note that BEEP imposes both encoding and length limitations on the messages that are piggybacked during channel initialization.
BEEPは、チャネルの初期化中にピギーバックされたメッセージの両方の符号化と長さの制限を課すことに留意されたいです。
All messages are exchanged as "application/beep+xml" (c.f., Section 6.4 of [BEEP]):
すべてのメッセージは、 "アプリケーション/ビープ音+ XML"（C.F.、[BEEP]の6.4節）として交換されています。
Role MSG RPY ERR
---- --- --- ---
I InfoRequest InfoResponse error
I CreateAccountRequest ok error
I RemoveAccountRequest ok error
I ModifyAccountRequest ok error
I DownloadRequest DownloadResponse error
I UploadRequest ok error
I DeleteRequest Ok error
The "error" message from Section 2.3.1.5 of [BEEP] is used to convey error information. Typically, after flagging an error, a peer will initiate a graceful release of the BEEP session.
[BEEP]のセクション2.3.1.5から「エラー」メッセージは、エラー情報を伝えるために使用されます。典型的には、エラーにフラグを付ける後、ピアがBEEPセッションの優雅な解放を開始します。
The following BEEP error reply codes from [BEEP] are to be used:
[BEEP]から次のBEEPエラー応答コードが使用されます。
code Meaning ==== ======= 421 service not available 450 requested action not taken (e.g., lock already in use) 451 requested action aborted (e.g., local error in processing)
コード意味==== ======= 421サービスは利用できません450要求されたアクションはない取られ（例えば、既に使用中のロック）451が動作中止要求さ（例えば、処理中にローカルエラー）
454 temporary authentication failure 500 general syntax error (e.g., poorly-formed XML) 501 syntax error in parameters (e.g., non-valid XML) 504 parameter not implemented 530 authentication required 534 authentication mechanism insufficient (e.g., too weak, sequence exhausted, etc.) 535 authentication failure 537 action not authorized for user 538 authentication mechanism requires encryption 550 requested action not taken (e.g., no requested profiles are acceptable) 553 parameter invalid 554 transaction failed (e.g., policy violation)
454一時的な認証失敗500の一般的な構文エラー（例えば、不完全に形成されたXML）パラメータ（例えば、非有効XML）501構文エラーが530認証が必要実装504パラメータではない、例えば、弱すぎる、配列排気など（534認証機構不十分利用者538の認証メカニズムのために許可されていない。）535、認証失敗537アクションは、暗号化550が取られていないアクションを要求した要求する（例えば、何も要求されたプロファイルは許容されません）553パラメータの無効な554トランザクションが（例えば、ポリシー違反）が失敗しました
The following SACRED-specific error reply codes can also be used:
以下SACRED固有のエラー応答コードを使用することもできます。
code Meaning ==== ======= 555 Extension (ProcessInfo) used not supported 556 Required extension (ProcessInfo) not present 557 StaleCredential (A bad LastModified value was contained in an UploadRequest.)
コード意味==== ======= 555拡張（ProcessInfo）は556必須拡張（ProcessInfo）をサポートしていない使用557 StaleCredentialを提示しない（悪いLastModifiedの値がUploadRequestに含まれていました。）
The use of the SASL authorization identity in this protocol is implementation-specific. If used, the authorization identity is not a substitute for the credential selector field, but may be used to affect authorization for access to credentials.
このプロトコルでSASL認証アイデンティティの使用は実装固有です。使用した場合、承認のアイデンティティは資格セレクター・フィールドに代わるものではありませんが、資格情報へのアクセスの許可に影響を与えるために使用することができます。
The IANA has registered the BEEP profile specified in Section 4.
IANAは、第4節で指定されたBEEPプロファイルを登録しています。
http://iana.org/beep/sacred
ｈっｔｐ：／／いあな。おｒｇ／べえｐ／さｃれｄ
The sacred protocol SHOULD be run over port 1118.
神聖なプロトコルは、ポート1118上で実行する必要があります。
The GSSAPI service name (required when using SASL) for this protocol SHALL be "sacred".
このプロトコルのために（SASLを使用する場合に必要）GSSAPIのサービス名は「神聖な」ものでなければなりません。
[REQS] calls for specifications to state how they address the vulnerabilities listed below.
[REQS]は、彼らは、下記の脆弱性に対処方法を述べるために仕様を求めています。
V1. A passive attacker can watch all packets on the network and later carry out a dictionary attack. - The use of DIGEST-MD5 and/or TLS counters this vulnerability. V2. An attacker can attempt to masquerade as a credential server in an attempt to get a client to reveal information online that allows for a later dictionary attack. - The use of server or mutual authentication counters this vulnerability. V3. An attacker can attempt to get a client to decrypt a chosen "ciphertext" and get the client to make use of the resulting plaintext - the attacker may then be able to carry out a dictionary attack (e.g. if the plaintext resulting from "decryption" of a random string is used as a DSA private key). - The use of server or mutual authentication counters this vulnerability. V4. An attacker could overwrite a repository entry so that when a user subsequently uses what they think is a good credential, they expose information about their password (and hence the "real" credential). - Server implementations SHOULD take measures to protect the database. Clients MAY use the ClientInfo field to store e.g. a signature over the Credential, which they then verify before using the private component. V5. An attacker can copy a credential server's repository and carry out a dictionary attack. - Server implementations SHOULD take measures to protect the database. V6. An attacker can attempt to masquerade as a client in an attempt to get a server to reveal information that allows for a later dictionary attack. - The mutual authentication requirements of this protocol counter this to a great extent. Additionally, credential servers MAY choose to provide mechanisms that protect against online dictionary attacks against user account passwords, either by repeated access attempts to a single user account (varying the password) or by attempting to access many user accounts using the same password. V7. An attacker can persuade a server that a successful login has occurred, even if it hasn't. - Client authentication prevents this.
V1。受動的攻撃者は、ネットワーク上のすべてのパケットを監視し、後で辞書攻撃を行うことができます。 - DIGEST-MD5および/またはTLSを使用すると、この脆弱性に対抗します。 V2。攻撃者は、後で辞書攻撃を可能にした情報をオンラインで明らかにするために、クライアントを取得しようとする試みで、信用証明書サーバになりすますことを試みることができます。 - サーバまたは相互認証カウンターの使用この脆弱性を解決します。 V3。攻撃者が選択した「暗号文」を解読し、得られた平文を使用するようにクライアントを取得するためにクライアントを取得しようとすることができます - 平文の「解読」から生じた場合、攻撃者は、辞書攻撃（例えばを行うことができるかもしれランダムな文字列は、DSA秘密鍵）として使用されています。 - サーバまたは相互認証カウンターの使用この脆弱性を解決します。 V4。ユーザーは、その後、彼らは良い資格だと思うものを使用したとき、彼らは自分のパスワード（それゆえ「本物」の資格）についての情報を公開するように、攻撃者は、リポジトリのエントリを上書きすることができます。 - サーバの実装は、データベースを保護するための措置をとるべきです。クライアントは、例えば格納するCLIENTINFOフィールドを使用してもよい（MAY）彼らはその後、民間のコンポーネントを使用する前に確認する資格、オーバー署名。 V5。攻撃者は、信用証明書サーバのリポジトリをコピーして、辞書攻撃を行うことができます。 - サーバの実装は、データベースを保護するための措置をとるべきです。 V6。攻撃者は、サーバーが後で辞書攻撃を可能にした情報を明らかにするために取得しようとする試みにクライアントを偽装しようとすることができます。 - このプロトコルの相互認証の要件が大幅にこれに対抗します。また、クレデンシャルサーバは、（パスワードを変更すること）1つのユーザーアカウントに繰り返しアクセス試行によって、または同じパスワードを使用して、多くのユーザーアカウントにアクセスしようとするのいずれかによって、ユーザーアカウントのパスワードに対するオンライン辞書攻撃から保護メカニズムを提供することを選択するかもしれません。 V7。攻撃者は、そうでない場合であっても、成功したログインが発生したサーバーを説得することができます。 - クライアント認証は、これを防ぐことができます。
V8. (Upload) An attacker can overwrite someone else's credentials on the server. - Only if they know the account password already (thanks to mutual authentication). V9. (When using password-based authentication) An attacker can force a password change to a known (or "weak") password. - Client authentication counters this. V10. An attacker can attempt a man-in-the-middle attack for lots of reasons... - Mutual authentication and the encryption of subsequent messages prevents this. V11. User enters password instead of name. - Since the DIGEST-MD5 mechanism is only used after TLS tuning, the user's name is also protected. V12. An attacker could attempt various denial-of-service attacks. - No specific countermeasures against DoS are proposed.
V8。 （アップロード）攻撃者は、サーバー上の誰か他の人の資格情報を上書きすることができます。 - 彼らはすでにアカウントのパスワードを知っている場合にのみ（相互認証のおかげで）。 V9。 （パスワードベースの認証を使用する場合）、攻撃者は、既知の（又は「弱」）パスワードとパスワードの変更を強制することができます。 - クライアント認証カウンターこれ。 V10。攻撃者は理由の多くのためのman-in-the-middle攻撃を試みることができます... - 相互認証とその後のメッセージの暗号化は、これを防ぐことができます。 V11。ユーザーは、名前の代わりにパスワードを入力します。 - DIGEST-MD5機構はTLSのみの調整後に使用されているので、ユーザーの名前も保護されています。 V12。攻撃者は、様々なサービス拒否攻撃を試みることができます。 - DoS攻撃に対する具体的な対策が提案されていません。
If the CreateAccountRequest message were sent over a cleartext channel (or otherwise exposed), then an attacker could mount a dictionary attack and recover the account password. This is why the server authenticated TLS transport is REQUIRED for this operation.
CreateAccountRequestメッセージはクリアテキストチャネル（または露光）を介して送信された場合、攻撃者は、辞書攻撃をマウントして、アカウントのパスワードを回復することができます。サーバー認証されたTLSトランスポートが、この操作に必要なのはこのためです。
If someone steals the server database they can launch a dictionary attack. If the dictionary attack is successful, the attacker can decrypt the user's credentials. An attacker that has learned the user's account password can also upload new credentials, assuming the user is authorized to modify the credentials, because someone who knows the user's account password is assumed to be the user. However, if someone steals the server database and is unsuccessful at obtaining the user's account password through a dictionary attack, they will be unable to upload new credentials.
誰かがサーバーのデータベースを盗む場合、彼らは、辞書攻撃を仕掛けることができます。辞書攻撃が成功すると、攻撃者は、ユーザーの資格情報を解読することができます。ユーザーのアカウントのパスワードを学習している攻撃者は、ユーザーのアカウントのパスワードを知っている人は、利用者であると想定されるため、ユーザは、資格情報を変更する権限があると仮定すると、新しい資格情報をアップロードすることができます。誰かがサーバーのデータベースを盗み、辞書攻撃を介してユーザのアカウントのパスワードを取得するに失敗した場合しかし、彼らは新しい資格情報をアップロードすることができません。
Credential servers SHOULD incorporate measures that act to counter denial of service attacks. In particular, they SHOULD drop inactive connections and minimize the use of resources by un-authenticated connections. A number of recommendations are listed at [DDOS].
資格のサーバーは、サービス拒否攻撃に対抗するように作用する措置を盛り込むべきです。特に、それらは、非アクティブな接続をドロップし、認証されていない接続によってリソースの使用を最小限に抑える必要があります。推奨の数は[DDOS]に記載されています。
Various operations in the SACRED protocol depend upon server authentication being provided by server authenticated TLS. SACRED clients SHOULD take care that the correct server is at the far end of the TLS "pipe" by performing the checks which are listed in section 3.1 of RFC 2818 [RFC2818]. Clients SHOULD also include the optional BEEP serverName field in their "start" message and SHOULD then ensure that the BEEP serverName is consistent with the checks on the TLS server described in RFC 2818. Failure to carry out these checks could allow a spoof server access to a user's credential.
SACREDプロトコルにおける様々な動作は、サーバー認証がTLS認証サーバによって提供さに依存します。 SACREDクライアントが正しいサーバーがRFC 2818のセクション3.1 [RFC2818]に記載されているチェックを実行することによって、TLS「パイプ」の遠端にあることを注意しなければなりません。クライアントはまた、彼らの「開始」メッセージにオプションのBEEPサーバー名フィールドを含むべきであるし、その後BEEP serverNameはRFCでの偽装サーバへのアクセスを許可することができ、これらのチェックを実行する2818失敗を説明TLSサーバ上のチェックと一致していることを確認する必要がありますユーザーの資格情報。
If the SACRED account password were to be used in some other, less secure protocol, using DIGEST-MD5, then it might appear to be the case that a man-in-the-middle (MITM) attack could be mounted. However, this is not the case since the DIGEST-MD5 client hash includes a client-selected "digest-uri-value", which in SACRED's case will be "sacred/<serverName>". In a MITM attack, those values will be something else. A MITM attack as described is therefore thwarted, because digest-uri-value wouldn't match what the SACRED server is expecting.
SACREDアカウントのパスワードがDIGEST-MD5を使用して、いくつかの他、安全性の低いプロトコルで使用された場合、のman-in-the-middle（MITM）攻撃が取り付けることができる場合のように見えるかもしれません。 DIGEST-MD5クライアントハッシュがSACREDの場合には「神聖/ <サーバ名>」になり、クライアントが選択した「ダイジェスト-URI値」を含んでいるのでしかし、このケースではありません。 MITM攻撃では、これらの値は、何か他のものになります。 MITM攻撃説明するようにダイジェスト-uriの値がSACREDサーバーが予想されているものと一致しないので、したがって、妨害されています。
[BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[BEEP]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[DIGEST-MD5]リーチ、P.とC.ニューマン、RFC 2831、2000年5月 "SASLメカニズムとしてダイジェスト認証を使用します"。
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax Standard," RSA Laboratories, June 2000.
[PKCS15] "PKCS＃15 V1.1：暗号トークン情報構文規格、" RSA Laboratories社、2000年6月。
[REQS] Arsenault, A. and S. Farrell, "Securely Available Credentials - Requirements", RFC 3157, August 2001.
[REQS] Arsenault、A.とS.ファレル、 "しっかり利用可能な資格情報 - 要求事項"、RFC 3157、2001年8月。
[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月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0", RFC 2246, January 1999.
[TLS]ダークス、T.とC.アレン、 "TLSプロトコル - バージョン1.0"、RFC 2246、1999年1月。
[TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
、RFC 3268、2002年6月[TLSAES]のchown、P.、 "トランスポート層セキュリティ（TLS）用のAdvanced Encryption Standard（AES）暗号の組み合わせ"。
[XMLDSIG] Eastlake, 3rd, D., Reagle, J. and D. Solo, "(Extensible Mark-Up Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[XMLDSIG]イーストレイク、第三、D.、Reagle、J.とD.ソロ、 "（拡張マークアップ言語）XML-署名構文と処理"、RFC 3275、2002年3月。
[XMLSCHEMA] "XML Schema Part 1: Structures", D. Beech, M. Maloney, N. Mendelsohn, and H. Thompson. W3C Recommendation, May 2001. Available at http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
[XMLSCHEMA "XMLスキーマパート1：構造"、D.ブナ、M.マロニー、N.メンデルゾーン、およびH.トンプソン。 http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/の利用可能なW3C勧告、2001年5月
[DDOS] "Recommendations for the Protection against Distributed Denial-of-Service Attacks in the Internet", http://www.iwar.org.uk/comsec/resources/dos/ddos_en.htm
[DDOS]「インターネットにおける分散型サービス拒否攻撃に対する保護のための提言」、http://www.iwar.org.uk/comsec/resources/dos/ddos_en.htm
[RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818, May 2000.
[RFC2818]レスコラ、E.、 "TLSオーバーHTTP"、RFC 2818、2000年5月。
[RFC3760] Gustafson, D., Just, M. and M. Nystrom, "Securely Available Credentials - Credential Server Framework," RFC 3760, April 2004.
[RFC3760]グスタフソン、D.、ちょうど、M.とM. Nystrom、 "しっかり利用可能な資格情報 - 資格・サーバー・フレームワーク、" RFC 3760、2004年4月。
[XKMS] Hallam-Baker, P. (ed), "XML Key Management Specification", http://www.w3.org/TR/xkms2/
[XKMS]ハラム - ベイカー、P.（編）、 "XMLキー管理仕様"、http://www.w3.org/TR/xkms2/
[XBULK] Hughes, M (ed), "XML Key Management Specification - Bulk Operation", http://www.w3.org/TR/xkms2-xbulk/
[XBULK]ヒューズ、M（編）、 "XMLキー管理仕様 - 一括操作"、http://www.w3.org/TR/xkms2-xbulk/
Acknowledgements
謝辞
Radia Perlman (radia.perlman@sun.com) and Charlie Kaufman (charliek@microsoft.com) co-authored earlier versions of this document. Michael Zolotarev (mzolotar@tpg.com.au) did much of the initial work, adapting an earlier version to the use of SRP (though SRP was subsequently dropped, much of the framework survives). Marshall Rose (mrose@dbc.mtview.ca.us) helped out a lot, in particular, with the BEEP profile. And the following people were actively involved in the mailing list discussions leading to this document:
このドキュメントのラディア・パールマン（radia.perlman@sun.com）とチャーリー・カウフマン（charliek@microsoft.com）共著以前のバージョン。マイケルZolotarev（mzolotar@tpg.com.auは）（SRPが、その後、生き残っフレームワークの多くを落としたが）SRPの使用に以前のバージョンを適応させる、最初の仕事の多くをしました。マーシャルローズ（mrose@dbc.mtview.ca.us）はBEEPプロファイルで、特に、多くのことを手伝いました。そして、次の人は積極的にこの文書につながるメーリングリストでの議論に関与していました。
David Chizmadia,
Dave Crocker (dcrocker@brandenburg.com),
Lawrence Greenfield (leg+@andrew.cmu.edu),
Dale Gustafson (degustafson@comcast.net),
Mike Just (just.mike@tbs-sct.gc.ca),
John Linn (jlinn@rsasecurity.com),
Neal McBurnett (neal@bcn.boulder.co.us),
Keith Moore (moore@cs.utk.edu),
RL "Bob" Morgan (rlmorgan@washington.edu),
Magnus Nystrom (magnus@rsasecurity.com),
Eamon O'Tuathail (eamon.otuathail@clipcode.com),
Gareth Richards (grichards@rsasecurity.com)
Of course, any and all errors remain the editor's responsibility.
もちろん、任意およびすべてのエラーは、エディタの責任残っています。
Appendix A: XML Schema
付録A：XMLスキーマ
<?xml version="1.0" encoding="UTF-8"?> <schema targetNamespace="urn:sacred-2002-12-19" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:sacred="urn:sacred-2002-12-19" xmlns="http://www.w3.org/2001/XMLSchema"> <import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation= "http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd"/> <!-- extensibility holes --> <complexType name="ProcessInfoType"> <sequence maxOccurs="unbounded"> <any namespace="##other"/> </sequence> </complexType> <element name="ProcessInfo" type="sacred:ProcessInfoType"/> <complexType name="ClientInfoType"> <sequence maxOccurs="unbounded"> <any namespace="##other"/> </sequence> </complexType> <element name="ClientInfo" type="sacred:ClientInfoType"/> <!-- Where to put authenentication information --> <complexType name="AuthInfoType"> <choice maxOccurs="unbounded"> <element name="DigestMD5AuthInfo"> <complexType> <sequence> <element name="PasswordVerifier" type="base64Binary"/> <element name="Realm" type="string" /> </sequence> </complexType> </element> <any namespace="##other"/> </choice> </complexType> <element name="AuthInfo" type="sacred:AuthInfoType"/> <!-- authentication mechanism parameters --> <complexType name="AuthParamsType"> <choice maxOccurs="unbounded"> <element name=" DigestMD5AuthParams"> <complexType> <sequence> <element name="Realm" type="string" minOccurs="1" maxOccurs="unbounded"/> </sequence>
<？xmlのバージョン= "1.0" エンコード= "UTF-8"> <スキーマのtargetNamespace = "壷：神聖-2002-12-19" のxmlns：DS = "http://www.w3.org/2000/09 / XMLDSIG＃ "のxmlns：神聖= "壷：神聖-2002-12-19" のxmlns = "http://www.w3.org/2001/XMLSchema"> <インポート名前空間=" のhttp：//www.w3。 ORG / 2000/09 / XMLDSIG＃」のschemaLocation = "http://www.w3.org/TR/xmldsig-core/xmldsig-core-schema.xsd" /> <！ - 拡張穴 - > <complexTypeの名前= "ProcessInfoType"> <配列のmaxOccurs = "無制限"> <名前空間= "##他の" /> </配列> </ complexTypeの> <要素名= "ProcessInfo" タイプ= "神聖：ProcessInfoType" /> <complexTypeの名前= "ClientInfoType"> <シーケンスのmaxOccurs = "無制限"> <任意の名前空間= "##他の" /> </シーケンス> </ complexTypeの> <要素名= "CLIENTINFO" タイプ= "聖なる：ClientInfoType" /> < ！ - authenentication情報を配置する - > <complexTypeの名= "AuthInfoType"> <選択肢のmaxOccurs = "無制限"> <要素名= "DigestMD5AuthInfo"> <complexTypeの> <シーケンス> <要素名= "PasswordVerifier" タイプ= "base64Binaryの" /> <要素名= "レルム" タイプ= "STリング」/> </シーケンス> </ complexTypeの> </要素> <任意の名前空間= "##他の" /> </選択> </ complexTypeの> <要素名= "AUTHINFO" タイプ= "聖なる：AuthInfoType" / > <！ - 認証機構パラメータ - > <complexTypeの名= "AuthParamsType"> <選択肢のmaxOccurs = "無制限"> <要素名= "DigestMD5AuthParams "> <complexTypeの> <シーケンス> <要素名=" レルム" タイプ= "文字列" のminOccurs = "1" のmaxOccurs = "無制限" /> </シーケンス>
</complexType>
</element>
<any namespace="##other"/>
</choice>
</complexType>
<element name="AuthParams" type="sacred:AuthParamsType"/>
<!-- Protocol messsages -->
<!-- "account handling" operations -->
<!-- Information request -->
<element name="InfoRequest"/>
<element name="InfoResponse">
<complexType>
<sequence>
<element name="Status" type="string" minOccurs="0"/>
<element name="ServerId" type="string"/>
<element ref="sacred:AuthParams"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- Create Account Request -->
<element name="CreateAccountRequest">
<complexType>
<sequence>
<element name="UserId" type="string"/>
<element ref="sacred:AuthInfo"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- remove account request -->
<element name="RemoveAccountRequest">
<complexType>
<sequence>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- password change request -->
<element name="ModifyAccountRequest">
<complexType>
<sequence>
<element ref="sacred:AuthInfo"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- "run-time" operations -->
<!-- DownLoad Request --> <element name="DownloadRequest"> <complexType> <sequence> <element name="CredentialSelector" type="string" minOccurs="0"/> <element ref="sacred:ProcessInfo" minOccurs="0"/> </sequence> </complexType> </element> <!-- Download Response --> <element name="DownloadResponse"> <complexType> <sequence> <element name="Status" type="string" minOccurs="0"/> <element name="Credential" type="sacred:CredentialType" maxOccurs="unbounded"/> </sequence> </complexType> </element> <!-- Upload request --> <element name="UploadRequest"> <complexType> <sequence> <element name="Credential" type="sacred:CredentialType"/> </sequence> </complexType> </element> <element name="DeleteRequest"> <complexType> <sequence> <choice> <sequence> <element name="CredentialSelector" type="string"/> <element name="LastModified" type="dateTime" minOccurs="0"/> </sequence> <element name="All"/> </choice> <element ref="sacred:ProcessInfo" minOccurs="0"/> </sequence> </complexType> </element> <!-- Credential related structures --> <!-- A new ds:KeyInfo thing --> <element name="SacredPKCS15" type="base64Binary"/> <!-- credential --> <complexType name="CredentialType">
<！ - ダウンロード要求 - > <要素名= "DownloadRequest"> <complexTypeの> <シーケンス> <要素名= "CredentialSelector" タイプ= "文字列" のminOccurs = "0" /> <要素refが= "神聖：ProcessInfo "minOccurs属性=" 0 "/> </シーケンス> </ complexTypeの> </要素> <！ - ダウンロードレスポンス - > <要素名=" DownloadResponse "> <complexTypeの> <シーケンス> <要素名=" ステータス」タイプ= "文字列" のminOccurs = "0" /> <要素名= "資格" タイプ= "聖なる：CredentialType" のmaxOccurs = "無制限" /> </シーケンス> </ complexTypeの> </要素> < - アップロード！要求 - > <要素名= "UploadRequest"> <complexTypeの> <シーケンス> <要素名= "資格" タイプ= "聖なる：CredentialType" /> </シーケンス> </ complexTypeの> </要素> <要素名= "DeleteRequest"> <complexTypeの> <シーケンス> <選択> <シーケンス> <要素名= "CredentialSelector" タイプ= "文字列" /> <要素名= "LastModifiedの" タイプ= "dateTimeの" のminOccurs = "0" /> < /シーケンス> <要素名= "すべて" /> </選択> <要素REF = "聖なる：ProcessInfo" のminOccurs = "0" /> </シーケンス> </ complexTypeの> </要素> < - Crede！ ntial関連構造 - > < - 新しいDS：！キー情報の事 - > <要素名= "SacredPKCS15" タイプ= "base64Binaryの" /> < - 資格 - > <complexTypeの名前= "CredentialType">
<sequence> <element name="CredentialSelector" type="string"/> <element name="LastModified" type="dateTime"/> <element name="Payload" type="ds:KeyInfoType" minOccurs="0"/> <element name="TimeToLive" type="string" minOccurs="0"/> <element ref="sacred:ProcessInfo" minOccurs="0"/> <element ref="sacred:ClientInfo" minOccurs="0"/> </sequence> </complexType>
<シーケンス> <要素名= "CredentialSelector" タイプ= "文字列" /> <要素名= "LastModifiedの" タイプ= "dateTimeの" /> <要素名= "ペイロード" タイプ= "DS：KeyInfoType" のminOccurs = "0" /> <要素名= "生存時間" タイプ= "文字列" のminOccurs = "0" /> <要素REF = "神聖：ProcessInfo" のminOccurs = "0" /> <要素REF = "神聖：CLIENTINFO" のminOccurs = "0 「/> </シーケンス> </ complexTypeの>
</schema>
</スキーマ>
Appendix B: An Example of Tuning with BEEP
付録B：BEEPとチューニングの例
Here is what tuning BEEP for authentication and confidentiality looks like using TLS and SASL's DIGEST-MD5:
ここでは、認証と機密保持のためのチューニングBEEPは、TLSとSASL DIGEST-MD5を使用して次のようになります。
L: <wait for incoming connection> I: <open connection>
L：<着信接続を待つ> I：<オープン接続>
... each peer sends a greeting indicating the services that it offers ...
...各ピアは、それが提供するサービスを示す挨拶を送ります...
L: RPY 0 0 . 0 233 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5' /> L: <profile uri='http://iana.org/beep/TLS' /> L: <profile uri='http://iana.org/beep/sacred' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END
L：RPY 0 0。 0 233 L：コンテンツタイプ：アプリケーション/ビープ音+のxml L：L：<挨拶> L：<プロファイルのuri = 'のhttp：//iana.org/beep/SASL/DIGEST-MD5' /> L：<プロファイルURI = 'のhttp：//iana.org/beep/TLS' /> L：<プロファイルのuri = 'のhttp：//iana.org/beep/sacred' /> L：</挨拶> L：END I：RPY 0 0。 0 52 I：のContent-Type：I：<挨拶/> I：END Iアプリケーション/ビープ音+ xmlの
... the initiator starts a channel for TLS and piggybacks a request to start the TLS negotiation ...
...イニシエータは、TLSのためのチャネルを開始し、TLSネゴシエーションを開始するための要求をピギーバック...
I: MSG 0 1 . 52 149 I: Content-Type: application/beep+xml I: I: <start number='1' serverName="sacred.example.org"> I: <profile uri='http://iana.org/beep/TLS'> I: <ready />
I：MSG 0 1。 52 149 I：のContent-Type：アプリケーション/ビープ音+ xmlのI：I：<開始番号= '1' サーバ名= "sacred.example.org"> I：<プロファイルのuri = 'のhttp：//iana.org/beep / TLS '> I：＆LT;レディ/>
I: </profile> I: </start> I: END
I：</プロフィール> I </スタート> I：END
... the listener creates the channel and piggybacks its readiness to start TLS ...
...リスナーがチャンネルを作成し、TLSを開始するための準備状況をピギーバック...
L: RPY 0 1 . 233 112 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/TLS'> L: <proceed /> L: </profile> L: END
L：RPY 0 1。 233 112 L：コンテンツタイプ：アプリケーション/ビープ+ XMLのL：L <プロファイルURI = 'HTTP：//iana.org/beep/TLS'> L：＆LT; /> L進む</プロファイル> Lを： 終わり
... upon receiving the reply, the initiator starts up TLS ...
...返信を受信すると、イニシエータは、TLSを起動します...
... successful transport security negotiation ...
...成功したトランスポート・セキュリティネゴシエーション...
... a new greeting is sent (cf., Section 9 of RFC 3080), note that the listener no longer advertises TLS (we're already running it)
...新しい挨拶は、（参照、RFC 3080のセクション9）送信されたリスナーは、もはやTLSをアドバタイズしていることに注意していない（我々はすでにそれを実行しています）
L: RPY 0 0 . 0 186 L: Content-Type: application/beep+xml L: L: <greeting> L: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5' /> L: <profile uri='http://iana.org/beep/sacred' /> L: </greeting> L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: <greeting /> I: END
L：RPY 0 0。 0 186 L：コンテンツタイプ：アプリケーション/ビープ音+のxml L：L：<挨拶> L：<プロファイルのuri = 'のhttp：//iana.org/beep/SASL/DIGEST-MD5' /> L：<プロファイルURI = 'のhttp：//iana.org/beep/sacred' /> L：</挨拶> L：END I：RPY 0 0。 0 52 I：のContent-Type：I：<挨拶/> I：END Iアプリケーション/ビープ音+ xmlの
... the initiator starts a channel for DIGEST-MD5 and piggybacks initialization information for the mechanism ...
...イニシエータは、DIGEST-MD5のためのチャネルを開始し、機構のための初期化情報をピギーバック...
I: MSG 0 1 . 52 178 I: Content-Type: application/beep+xml I: I: <start number='1'> I: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'> I: <blob> ... </blob> I: </profile>
I：MSG 0 1。 52 178 I：のContent-Type：アプリケーション/ビープ音+ xmlのI：I：<数=開始 '1'> I：<プロファイルのuri = 'のhttp：//iana.org/beep/SASL/DIGEST-MD5'> I ：＆LT;ブロブ> ...＆LT; /ブロブ> I </プロフィール>
I: </start> I: END
I：</スタート> I：END
... the listener creates the channel and piggybacks a challenge ...
...リスナーがチャンネルを作成し、挑戦をピギーバック...
L: RPY 0 1 . 186 137 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'> L: <blob> ... </blob> L: </profile> L: END
L：RPY 0 1。 186 137 L：コンテンツタイプ：アプリケーション/ビープ音+のxml L：L：<プロファイルのuri = 'のhttp：//iana.org/beep/SASL/DIGEST-MD5'> L：＆LT;ブロブ> ...＆ LT; /ブロブ> L </プロフィール> L：END
... the initiator sends a response to the challenge ...
...イニシエータは、チャレンジへの応答を送信します...
I: MSG 1 0 . 0 58 I: Content-Type: application/beep+xml I: I: <blob> ... </blob> I: END
I：MSG 1 0。 0 58 I：のContent-Type：アプリケーション/ビープ音+ xmlのI：I：<ブロブ> ... </ブロブ> I：END
... the listener accepts the challenge and tells the initiator that it is now authenticated ...
...リスナーは挑戦を受け入れ、それが今で認証されていることをイニシエータに伝えます...
L: RPY 1 0 . 0 66 L: Content-Type: application/beep+xml L: L: <blob status='complete' /> L: END
L：RPY 1 0。 0 66 L：コンテンツタイプ：アプリケーション/ビープ音+のxml L：L：<ブロブステータス= '完全' /> L：END
... the initiator starts a channel for SACRED and piggybacks its initial SACRED request ...
...イニシエータはSACREDためのチャネルを開始し、その初期SACRED要求を背負い...
I: MSG 0 2 . 230 520 I: Content-Type: application/beep+xml I: I: <start number='3'> I: <profile uri='http://iana.org/beep/sacred' /> I: <?xml version="1.0" encoding="UTF-8"?> I: <sacred:DownloadRequest I: xmlns:sacred="urn:sacred-2002-12-19" I: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" I: xsi:schemaLocation="urn:sacred-2002-12-19 sacred.xsd"> I: <CredentialSelector> I: magnus-credentials</CredentialSelector> I: </sacred:DownloadRequest> I: </start>
I：MSG 0 2。 230 520 I：コンテンツタイプ：アプリケーション/ビープ+ XMLはI：I：<開始番号= '3'> Iが：<プロファイルURI = 'HTTP：//iana.org/beep/sacred' /> I：＆LT ;？xmlのバージョン= "1.0" エンコード= "UTF-8"> I：＆LT;神聖：DownloadRequest I：のxmlns：神聖= "URN：神聖-2002年12月19日" I：のxmlns：XSI = "HTTP ：//www.w3.org/2001/XMLSchema-instance」私は：XSI：のschemaLocation = "URN：神聖-2002-12-19 sacred.xsd"> I：＆LT; CredentialSelector> I：マグナス・クレデンシャル＆LT。 / CredentialSelector> I：＆LT; /神聖：DownloadRequest> I </開始>
I: END
I：END
... the listener creates the channel and piggybacks the response to the initial SACRED request
...リスナーがチャンネルを作成し、初期SACRED要求に対する応答をピギーバック
L: RPY 0 2 . 323 805 L: Content-Type: application/beep+xml L: L: <profile uri='http://iana.org/beep/sacred' /> L: <?xml version="1.0" encoding="UTF-8"?> L: <sacred:DownloadResponse L: xmlns:sacred="urn:sacred-2002-12-19" L: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" L: xsi:schemaLocation="urn:sacred-2002-12-19 sacred.xsd"> L: <Status>Success</Status> L: <Credential> L: <CredentialSelector> L: magnus-credential</CredentialSelector> L: <LastModified>2002-11-22T00:00:08Z</LastModified> L: <Payload> L: <sacred:SacredPKCS15 L: xmlns:sacred="urn:sacred-2002-12-19">GpM7 L: </sacred:SacredPKCS15> L: </Payload> L: </Credential> L: </sacred:DownloadResponse> L: </profile> L: END
L：RPY 0 2。 323 805 L：コンテンツタイプ：アプリケーション/ビープ+ XMLのL：L <プロファイルURI = 'HTTP：//iana.org/beep/sacred' /> L：？＆LT; XMLバージョン= "1.0" エンコード= "UTF-8"> L：？＆LT;神聖：DownloadResponseのL：のxmlns：神聖= "URN：神聖-2002年12月19日" L：のxmlns：XSI = "http://www.w3.org/2001 / XMLスキーマ・インスタンス」L：XSI：のschemaLocation = "URN：神聖-2002-12-19 sacred.xsd"> L：＆LT;ステータス>サクセス＆LT; /ステータス> L：＆LT;資格> L：＆LT ; CredentialSelector> L：マグナス・クレデンシャル＆LT; / CredentialSelector> L：＆LT; LastModifiedの> 2002-11-22T00：00：08Z＆LT; / LastModifiedの> L：＆LT;ペイロード> L：＆LT;神聖：SacredPKCS15 L ：のxmlns：神聖= "URN：神聖-2002年12月19日"> GpM7 L：＆LT; /神聖：SacredPKCS15> L：＆LT; /ペイロード> L：＆LT; /資格> L：＆LT; /神聖：DownloadResponse> L：</プロフィール> L：END
Appendix C: Provision SACRED using other Protocols
付録C：他のプロトコルを使用してプロビジョニングSACRED
SACRED may be implemented in a non-BEEP environment, provided that before any SACRED PDUs are sent, the application protocol must be protected according to the security mandates provided in Section 2.3.
SACREDは任意SACRED PDUが送信される前に、アプリケーションプロトコルは、セクション2.3に提供されるセキュリティの任務に応じて保護されなければならないことを条件とする、非BEEP環境で実施することができます。
For example, if SACRED is provisioned as the payload of an application protocol that supports SASL and TLS, then the appropriate SASL and/or TLS negotiation must successfully occur before exchanging Sacred PDUs.
SACREDはSASLとTLSをサポートするアプリケーションプロトコルのペイロードとしてプロビジョニングされている場合、例えば、適切なSASLおよび/またはTLSネゴシエーションが成功神聖PDUを交換する前に発生しなければなりません。
Alternatively, if the application protocol doesn't support SASL, then one or more PDUs are defined to facilitate a SASL negotiation, and the appropriate negotiation must occur before exchanging Sacred PDUs.
アプリケーションプロトコルは、SASLをサポートしていない場合、あるいは、1つのまたは複数のPDUはSASLネゴシエーションを容易にするために定義され、そして適切な交渉は神聖PDUを交換する前に発生しなければなりません。
Editor's Address
編集者の住所
Stephen Farrell, Distributed Systems Group, Computer Science Department, Trinity College Dublin, IRELAND Phone: +353-1-608-3070 EMail: stephen.farrell@cs.tcd.ie
+ 353-1-608-3070 Eメール：：stephen.farrell@cs.tcd.ieシステムグループ、コンピュータサイエンス学部、トリニティカレッジダブリン、アイルランド電話を分散スティーブン・ファレル、
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。