Network Working Group S. Farrell, Ed.
Request for Comments: 3767 Trinity College Dublin
Category: Standards Track June 2004
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和/或DIGEST-MD5（通过BEEP）来满足安全要求。
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
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.
数字凭证（如私钥和相应的证书）用于支持各种Internet协议，例如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.
请注意，使用此协议时可能涉及两个“密码”——第一个用于向凭据服务器验证用户身份，第二个用于在下载操作后解密凭据（部分）。如果上下文需要，我们将前者称为帐户密码，后者称为凭证密码。
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,
该协议旨在满足[REQS]中的要求。加密凭证可以采用私钥、PKCS#15[PKCS15]或结构的形式。如上所述，为消息传输和安全性（完整性、，
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].
身份验证和机密性）。在这种情况下，通过强制支持（通过BEEP）TLS[TLS]和/或DIGEST-MD5[DIGEST-MD5]来满足安全要求。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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]中使用的元素兼容的神圣元素，以便此协议的实现也可以轻松支持XKMS，反之亦然。
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.
服务器用一条InfoResponse消息进行响应，该消息包含服务器的身份验证机制参数和支持的ProcessInfo类型列表。对于DIGEST-MD5，这包括服务器支持的领域列表（每个领域都是一个名为“Realm”的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).
客户机必须能够从领域列表中选择一个，并且必须能够忽略存在的任何其他信息（允许扩展）。
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.
客户端向服务器发送上载请求消息，该消息必须包含一个凭据。
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).
如果对与帐户关联的存储凭据进行了任何更改，则服务器必须将相应的LastModified值（在DownloadResponse消息中返回）更新为当前时间（在服务器上）。
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中接收到的值。这意味着强烈建议客户端仅基于最近下载的凭据生成UploadRequest，否则LastModified值可能已过期。
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更新。服务器可以在第二次上载时检测到冲突。在这种情况下，服务器必须响应一个蜂鸣错误（应该是错误的）。
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!).
此操作的目的是允许客户端从服务器获取一个或多个凭据（整个协议的目的真的是！）。
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包含一个或多个凭据有效负载，包括LastModified time，它表示对与帐户关联的每个凭据进行最后更改的时间（在服务器上）（例如，在上传请求之后）。
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.
此操作的目的是允许客户端删除与帐户关联的一个或所有凭据。
The client sends a DeleteRequest message to the server which can contain either a CredentialSelector or an All element.
客户端向服务器发送DeleteRequest消息，该消息可以包含CredentialSelector或All元素。
If the DeleteRequest contains an All element, then all of the credentials associated with that account are deleted.
如果DeleteRequest包含All元素，则删除与该帐户关联的所有凭据。
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值。如果DeleteRequest中存在LastModified值，则该值必须是最近在该凭据的相应下载响应中接收到的值。如果该值不匹配，则服务器不得删除凭据。
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).
上面定义了六种神圣的行动。在本节中，我们将为每个操作（在支持的情况下）指定安全性要求。
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
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].
必须使用TLS_RSA_和_3DES-EDE_CBC_SHA实现神圣的TLS密码套件。实施还应支持TLS_RSA_和_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):
许多消息涉及凭证元素。它具有以下字段（除非另有说明，否则所有可选字段可能出现零次或一次）：
- 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包含一个字符串，通过该字符串可以识别此特定凭证（用于此帐户）。-有效负载包含ds:KeyInfo或其他形式的凭证。实现必须支持下面定义的PKCS#15形式的ds:KeyInfo（SacredPKCS15元素）LastModified是一个字符串，包含上次修改此凭据的时间（在服务器上）。-TimeToLive（可选）是客户端应遵守的提示，它指定下载的凭据可用的秒数。-ProcessInfo（可选）可以包含服务器要处理的任何（键入的）信息。如果服务器不支持任何ProcessInfo数据，它可能会忽略该数据。-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.
未来的备忘录可能会为您定义BEEP配置文件的替代版本。当一个BEEP peer发送问候语时，它表示它愿意支持哪些配置文件。因此，当BEEP客户端请求启动频道时，它会指示它支持的版本，以及BEEP服务器是否可以接受这些版本；后者指定要启动的配置文件。
Profile Identification: http://iana.org/beep/sacred
Profile Identification: 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
下载响应，错误，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
一对多更改中的消息：无
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
由于神圣配置文件的所有操作（除一个操作外）都有安全要求（参见第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 followed by
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对等方发出一个新的问候语。请参阅[BEEP]第3节，了解BEEP对等方如何根据是否使用保密性选择发出不同问候语的示例。
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>
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: <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]):
所有消息交换为“应用程序/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
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)
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参数中的语法错误（例如，无效的XML）504参数未实现530身份验证需要534身份验证机制不足（例如，太弱、序列用尽等）535身份验证失败537未授权用户的操作538身份验证机制要求加密550未采取请求的操作（例如，不接受任何请求的配置文件）553参数无效554事务失败（例如，策略冲突）
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.)
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授权标识的使用是特定于实现的。如果使用，授权标识不能替代凭证选择器字段，但可用于影响对凭证访问的授权。
The IANA has registered the BEEP profile specified in Section 4.
IANA已注册第4节规定的BEEP配置文件。
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。攻击者可以尝试让客户端解密选定的“密文”，并让客户端使用生成的明文-然后攻击者可以执行字典攻击（例如，如果随机字符串“解密”生成的明文用作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。攻击者可能会尝试各种拒绝服务攻击。-没有提出针对拒绝服务的具体对策。
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.
神圣协议中的各种操作取决于服务器认证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值”，在神圣的情况下，它将是“神圣的/<serverName>”。在MITM攻击中，这些值将是其他值。因此，如上所述的MITM攻击被阻止，因为摘要uri值与服务器期望的值不匹配。
[BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[BEEP]Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[DIGEST-MD5]Leach，P.和C.Newman，“使用摘要认证作为SASL机制”，RFC 28312000年5月。
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax Standard," RSA Laboratories, June 2000.
[PKCS15]“PKCS#15 v1.1：加密令牌信息语法标准”，RSA实验室，2000年6月。
[REQS] Arsenault, A. and S. Farrell, "Securely Available Credentials - Requirements", RFC 3157, August 2001.
[REQS]Arsenault，A.和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]迈尔斯，J.，“简单认证和安全层（SASL）”，RFC22221997年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）密码套件”，RFC 32682002年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.和D.Solo，“（可扩展标记语言）XML签名语法和处理”，RFC3275，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 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/
[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] "Recommendations for the Protection against Distributed
Denial-of-Service Attacks in the Internet",
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”，RFC2818，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.和M.Nystrom，“安全可用凭证-凭证服务器框架”，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:
拉迪娅·帕尔曼（拉迪娅。perlman@sun.com)还有查理·考夫曼(charliek@microsoft.com)本文件早期版本的合著者。迈克尔·佐洛塔列夫(mzolotar@tpg.com.au)做了大量的初始工作，修改了早期版本以适应SRP的使用（尽管SRP后来被放弃，但大部分框架仍然存在）。马歇尔玫瑰(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)
大卫·奇兹马迪亚，戴夫·克罗克(dcrocker@brandenburg.com)，劳伦斯·格林菲尔德（leg+@andrew.cmu.edu），戴尔·古斯塔夫森(degustafson@comcast.net)，迈克只是。mike@tbs-约翰·林恩（sct.gc.ca）(jlinn@rsasecurity.com)尼尔·麦克伯内特(neal@bcn.boulder.co.us)，基思摩尔(moore@cs.utk.edu)，RL“鲍勃”摩根(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 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 -->
</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">
<!-- 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>
<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：使用BEEP进行调谐的示例
Here is what tuning BEEP for authentication and confidentiality looks like using TLS and SASL's DIGEST-MD5:
下面是使用TLS和SASL的DIGEST-MD5为身份验证和机密性调优BEEP的样子：
L: <wait for incoming connection>
I: <open connection>
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
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: 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
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
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)
... 发送新的问候语（参见RFC3080的第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: 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 ...
... 启动器为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: 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
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
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
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
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: 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
I:结束
... 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
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.
神圣可在非BEEP环境中实施，前提是在发送任何神圣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的应用程序协议的有效负载，则在交换神圣PDU之前，必须成功进行适当的SASL和/或TLS协商。
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，则定义一个或多个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电子邮件：斯蒂芬。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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。