[要約] RFC 3767は、セキュアに利用可能な資格情報プロトコルに関するものであり、要約すると以下のようになります。1. 目的：ユーザーが安全に資格情報を利用できるようにするためのプロトコルを提供する。 2. 要約：このRFCは、資格情報の安全な取得と利用を可能にするプロトコルの仕様を提供する。 3. 目的：セキュリティ上のリスクを最小限に抑えながら、ユーザーが必要な資格情報にアクセスできるようにする。
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）The Internet Society（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および/または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.
多くのユーザーが選択したパスワードは、辞書攻撃に対して脆弱です。したがって、神聖なプロトコルは、攻撃者がクライアントまたはサーバーのいずれかを盗聴するか、盗聴するかによって、辞書攻撃を開始するための情報を取得できる情報を提供しないように設計されています。
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.
このプロトコルを使用する場合、2つの「パスワード」が含まれる可能性があることに注意してください。最初は、ユーザーを資格情報サーバーに認証するために使用され、2番目はダウンロード操作に続いて資格情報を復号化します（その一部）。コンテキストがそれを必要とする場合、前者をアカウントのパスワードと呼び、後者を資格情報と呼びます。
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]、または構造の形をとる場合があります。述べたように、ビープ音[ビープ]に基づくプロファイルは、メッセージトランスポートとセキュリティ（整合性、認証、および機密性）に指定されています。その場合、セキュリティ要件は、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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[RFC2119]に記載されているように解釈される。
This section defines the account management and "run-time" operations for the SACRED protocol.
このセクションでは、聖なるプロトコルのアカウント管理と「ランタイム」操作を定義します。
It also describes the message formats used, which are described in XML [XMLSCHEMA]. Appendix A provides an XML schema for these elements.
また、XML [XMLSchema]で説明されている使用されるメッセージ形式についても説明しています。付録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]で使用される要素と互換性のある神聖な要素を定義することであり、このプロトコルの実装もXKMを簡単にサポートし、逆も同様です。
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.
また、他の神聖なプロトコルインスタンス（例：異なる認証スキーム、資格形式、または輸送プロトコルの使用）がここで多くの定義を再利用できることを意図しています。
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の場合、これはサーバーがサポートするレルム（それぞれが「Realm」という名前のXML要素として）のリストで構成されています。少なくとも1つの領域が指定されている必要があります。
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の場合、これはパスワード検証剤（ハッシュされたユーザー名、パスワード、領域）と選択された領域で構成されています。そのようなデータの複数のセットは、付録で定義されているデータ構造によって許可されていますが、クライアントはここに1つだけを含める必要があります。
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の新しい資格情報に置き換えられます。それ以外の場合、「新しい」資格情報はそのアカウントに関連付けられています。新しい資格情報がアップロードされている場合、クライアントは、時間のローカルコンセプト（1つの場合）の概念、またはクロックがないことを示す（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).
アカウントに関連付けられた保存された資格情報に変更が加えられた場合、サーバーは、対応する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値は、その資格情報の対応するダウンロードResponseで最近受信された値でなければなりません。つまり、クライアントは、最近ダウンロードされた資格情報に基づいて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 Valueは、競合の検出にも役立ちます。たとえば、プラットフォームAへのダウンロード、プラットフォームBへのダウンロード、Bからの更新、Aからの更新。サーバーは、2番目のアップロードの競合を検出できます。この場合、サーバーはビープエラー（これは膠着状態である必要があります）で応答する必要があります。
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値をサーバーの現在の時刻に置き換えます。（これは、クライアントがclientsienceTypeを介して計算されるDigital Signatureにclientsifienfoの署名に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.
クライアントは、資格情報の資格情報セレクター文字列を含む可能性のあるダウンロードRequestメッセージをサーバーに送信します。いいえ、または空の資格情報セレクターは、アカウントに関連付けられたすべての資格情報に対してリクエストがあることを意味します。
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).
サーバーは、ダウンロードResponseまたはエラーメッセージで応答します。ダウンロードResponseには、アカウントに関連付けられている各資格情報に最後の変更が行われた時間（サーバーで）を表すlastModified時間を含む1つ以上の資格情報を含む1つ以上の資格情報が含まれます（たとえば、uploadRequestに続いて）。
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.
クライアントは、資格情報セレクターまたはすべての要素のいずれかを含むことができる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に資格情報セレクターが含まれている場合、リクエストにはLastModified Valueが含まれる場合があります。LastModified ValueがdeleteRequestに存在する場合、それはその資格情報の対応するダウンロードResponseで最近受信された値でなければなりません。値が一致しない場合、サーバーは資格情報を削除してはなりません。
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).
6つの神聖な作戦が上記で定義されています。このセクションでは、各操作（サポートされている場合）のセキュリティの要件を指定します。
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 Cipher Suiteは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の種類のリストが含まれています。この拡張性スキームは、[xkms]および[xbulk]で使用されるものと似ています。
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).
- 資格情報セレクターには、この特定の資格情報（このアカウント用）を識別できる文字列が含まれています。 - ペイロードには、ds：keyinfoまたは他の形式の資格情報のいずれかが含まれます。実装は、以下に定義されているDSのPKCS＃15形式：keyInfoをサポートする必要があります（sacredpkcs15要素）。-LastModifiedは、この資格情報が最後に変更された時間（サーバーで）を含む文字列です。-Timetolive（オプション）は、クライアントが尊重すべきヒントであり、ダウンロードされた資格情報が使用可能である秒数を指定します。-ProcessInfo（オプション）には、サーバーが処理することを目的とした（入力された）情報が含まれている場合があります。サーバーがProcessInfoデータをサポートしていない場合、そのデータを無視する可能性があります。-ClientInfo（オプション）には、クライアントが処理することを目的としているが、サーバーが無視する必要がある（入力された）情報が含まれている場合があります。クライアントがClientInfoデータのいずれかをサポートしていない場合、そのデータを無視する可能性があります（たとえば、clientInfoがデバイス固有の場合）。
The protocol described in this memo is realized as a [BEEP] profile.
このメモで説明されているプロトコルは、[ビープ]プロファイルとして実現されます。
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.
将来のメモは、神聖なビーププロファイルの代替バージョンを定義する場合があります。ビープピアが挨拶を送ると、どのプロファイルがサポートするかを示します。したがって、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, DownloadResponse, error, ok
チャンネル作成中に交換されるメッセージ：InforeQuest、CreateaCcountRequest、RemoveaCcountRequest、ModifyAccountRequest、downloadRequest、uploadRequest、deleteRequest、inforesponse、downloadResponse、エラー、OK
Messages starting one-to-one exchanges: InfoRequest, CreateAccountRequest, RemoveAccountRequest, ModifyAccountRequest, DownloadRequest, UploadRequest, DeleteRequest
1対1の交換の開始メッセージ：InforeQuest、CreateAccountre-equest、removeaccountre-equest、modifyAccountre-request、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
神聖なプロファイルの操作の1つを除くすべてがセキュリティ要件を持っているため（セクション2.3.1を参照）、神聖なプロファイルを開始する前に、ビープセッションはどちらかを使用して調整される可能性があります
http://iana.org/beep/TLS
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を使用してビープ音セッションを調整する例を示しています（つまり、ビープ音のセキュリティをオンにする方法を示しています）。
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 Peerが機密性が使用されているかどうかに基づいて、ビープピアがさまざまな挨拶を発行することを選択する方法の例については、[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>
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.
[ビープ]のセクション2.3.1.5からの「エラー」メッセージは、エラー情報を伝えるために使用されます。通常、エラーにフラグを立てた後、ピアはビープセッションの優雅なリリースを開始します。
The following BEEP error reply codes from [BEEP] are to be used:
[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)
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など）501パラメーターの構文エラー（例：非valid XML）504パラメーター実装されていない530認証が必要534認証メカニズムが不十分です（例：弱く、シーケンス排出など。）535認証失敗
The following SACRED-specific error reply codes can also be used:
次の神聖なエラー応答コードも使用できます。
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.)
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認証IDの使用は、実装固有です。使用すると、承認IDは資格情報セレクターフィールドの代替ではなく、資格情報へのアクセスの認可に影響を与えるために使用される場合があります。
The IANA has registered the BEEP profile specified in Section 4.
IANAは、セクション4で指定されたビープ音プロファイルを登録しています。
http://iana.org/beep/sacred
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".
このプロトコルにGSSAPIサービス名（SASLを使用する場合は必要）は「神聖」でなければなりません。
[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。攻撃者は、クライアントに選択した「ciphertext」を復号化させ、クライアントに結果のプレーンテキストを使用させようとすることができます - 攻撃者は辞書攻撃を実行できる場合があります（たとえば。ランダムな文字列は、DSA秘密キーとして使用されます）。 - サーバーまたは相互認証の使用は、この脆弱性に対抗します。V4。攻撃者は、リポジトリエントリを上書きすることができ、ユーザーがその後、自分が優れた資格情報であると思うものを使用すると、パスワードに関する情報（したがって「実際の」資格情報）を公開することができます。 - サーバーの実装は、データベースを保護するための措置を講じる必要があります。クライアントは、clientInfoフィールドを使用して保存できます。資格情報を介した署名。プライベートコンポーネントを使用する前に確認します。V5。攻撃者は、資格情報サーバーのリポジトリをコピーして、辞書攻撃を実行できます。 - サーバーの実装は、データベースを保護するための措置を講じる必要があります。V6。攻撃者は、サーバーを取得して、後の辞書攻撃を可能にする情報を明らかにしようとするために、クライアントを装っていようと試みることができます。 - このプロトコルの相互認証要件は、これを大幅にカウンターします。さらに、クレデンシャルサーバーは、単一のユーザーアカウントへのアクセスの試みを繰り返し（パスワードを変更する）、または同じパスワードを使用して多くのユーザーアカウントにアクセスしようとすることにより、ユーザーアカウントのパスワードに対するオンライン辞書攻撃から保護するメカニズムを提供することを選択できます。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。攻撃者は、多くの理由で中間の攻撃を試みることができます... - 相互認証とその後のメッセージの暗号化はこれを防ぎます。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メッセージがClearTextチャネルを介して送信された場合（またはその他の方法で公開されている場合）、攻撃者は辞書攻撃を取り付けてアカウントパスワードを回復することができます。これが、この操作にサーバー認証された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.
神聖なプロトコルのさまざまな操作は、サーバー認証TLSによって提供されるサーバー認証に依存します。神聖なクライアントは、RFC 2818 [RFC2818]のセクション3.1にリストされているチェックを実行することにより、正しいサーバーがTLS「パイプ」の遠端にあることに注意する必要があります。クライアントはまた、「開始」メッセージにオプションのBeep Servernameフィールドを含める必要があり、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.
Digest-MD5を使用して、神聖なアカウントのパスワードを他の、安全性の低いプロトコルで使用する場合、中間（MITM）攻撃をマウントできる場合があるように見えるかもしれません。ただし、Digest-MD5クライアントハッシュにはクライアントが選択した「Digest-uri-value」が含まれているため、これは当てはまりません。これは、Sacredの場合は「Sacred/<servername>」になります。MITM攻撃では、これらの値は別のものになります。したがって、記載されているようにMITM攻撃は阻止されます。なぜなら、Digest-Uri-Balueは神聖なサーバーが期待しているものと一致しないからです。
[BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[Beep] Rose、M。、「The Blocks Extensible Exchange Protocol Core」、RFC 3080、2001年3月。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[Digest-MD5] Leach、P。and C. Newman、「SASLメカニズムとしての消化認証を使用」、RFC 2831、2000年5月。
[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。and S. Farrell、「安全に利用可能な資格情報 - 要件」、RFC 3157、2001年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[SASL] Myers、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol - Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「TLSプロトコル -バージョン1.0」、RFC 2246、1999年1月。
[TLSAES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[TLSAES] Chown、P。、「輸送層セキュリティ（TLS）のための高度な暗号化標準（AES）ciphersuites」、RFC 3268、2002年6月。
[XMLDSIG] Eastlake, 3rd, D., Reagle, J. and D. Solo, "(Extensible Mark-Up Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[Xmldsig] Eastlake、3rd、D.、Reagle、J。and D. Solo、 "（拡張可能なマークアップ言語）XML-Signature構文と処理"、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.トンプソン。W3C推奨、2001年5月。http：//www.w3.org/tr/2001/rec-xmlschema-20010502/で入手可能
[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] Rescorla、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] Gustafson、D.、Just、M。and M. nystrom、「Securely Avaviling Credentials -Credential Server Framework」、RFC 3760、2004年4月。
[XKMS] Hallam-Baker, P. (ed), "XML Key Management Specification", http://www.w3.org/TR/xkms2/
[XKMS] Hallam-Baker、P。（ed）、「XML Key Management Specification」、http://www.w3.org/tr/xkms2/
[XBULK] Hughes, M (ed), "XML Key Management Specification - Bulk Operation", http://www.w3.org/TR/xkms2-xbulk/
[Xbulk] Hughes、M（ed）、「XML Key Management Specification -Bulk Operation」、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（Radia.perlman@sun.com）およびCharlie Kaufman（charliek@microsoft.com）は、このドキュメントの以前のバージョンを共同執筆しています。Michael Zolotarev（mzolotar@tpg.com.au）は最初の作業の多くを行い、以前のバージョンをSRPの使用に適応させました（その後、SRPがドロップされましたが、フレームワークの多くは生き残りました）。Marshall Rose（mrose@dbc.mtview.ca.us）は、特にビーププロファイルで大いに役立ちました。そして、次の人々は、この文書につながるメーリングリストの議論に積極的に関与していました。
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)
David Chizmadia、Dave Crocker（dcrocker@brandenburg.com）、ローレンスグリーンフィールド（leg@andrew.cmu.edu）、dale gustafson（degustafson@comcast.net）、mike（just.mike@tbs-sct.gc.ca）、ジョン・リン（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>
</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">
<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>
</schema>
</schema>
Appendix B: An Example of Tuning with BEEP
付録B：ビープ音を使用したチューニングの例
Here is what tuning BEEP for authentication and confidentiality looks like using TLS and SASL's DIGEST-MD5:
認証と機密性のためのビープ音をチューニングするものは、TLSとSASLのDigest-MD5を使用しているように見えるものです。
L: <wait for incoming connection>
I: <open connection>
... 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
... 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: </profile>
I: </start>
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
... 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
... the initiator starts a channel for DIGEST-MD5 and piggybacks initialization information for the mechanism ...
...イニシエーターは、Migest-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: </start>
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
... 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
... 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
... the initiator starts a channel for SACRED and piggybacks its initial SACRED request ...
...イニシエーターは、神聖でピギーバックのためのチャンネルを開始します。
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: END
... the listener creates the channel and piggybacks the response to the initial SACRED request
...リスナーはチャンネルを作成し、最初の神聖な要求への応答を豚に戻します
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
Appendix C: Provision SACRED using other Protocols
付録C：他のプロトコルを使用して神聖な提供を提供します
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.
神聖なPDUが送信される前に、セクション2.3で提供されたセキュリティマンデートに従ってアプリケーションプロトコルを保護する必要がある場合、神聖な環境では非ビープ環境で実装される場合があります。
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.
たとえば、SASLおよびTLSをサポートするアプリケーションプロトコルのペイロードとしてSacredが提供されている場合、適切な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をサポートしていない場合、SASLの交渉を促進するために1つ以上のPDUが定義され、神聖な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
Stephen Farrell、Distributed Systems Group、コンピューターサイエンス部門、トリニティカレッジダブリン、アイルランド電話：353-1-608-3070メール：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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。