Network Working Group D. Gustafson
Request for Comments: 3760 Future Foundation
Category: Informational M. Just
Treasury Board of Canada
M. Nystrom
RSA Security
April 2004
Network Working Group D. Gustafson
Request for Comments: 3760 Future Foundation
Category: Informational M. Just
Treasury Board of Canada
M. Nystrom
RSA Security
April 2004
Securely Available Credentials (SACRED) - Credential Server Framework
安全可用凭据（神圣）-凭据服务器框架
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004). All Rights Reserved.
版权所有（C）互联网协会（2004年）。版权所有。
Abstract
摘要
As the number, and more particularly the number of different types, of devices connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This document responds to the requirements on protocols for secure exchange of credentials listed in RFC 3157, by presenting an abstract protocol framework.
随着连接到互联网的设备数量的增加，尤其是不同类型设备的数量的增加，凭证移动成为IETF标准化的一个问题。本文件通过提供抽象协议框架，响应RFC 3157中列出的安全凭证交换协议要求。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Functional Overview. . . . . . . . . . . . . . . . . . . . . . 2
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Credentials. . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Network Architecture . . . . . . . . . . . . . . . . . . 5
3. Protocol Framework . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Credential Upload. . . . . . . . . . . . . . . . . . . . 8
3.2. Credential Download. . . . . . . . . . . . . . . . . . . 10
3.3. Credential Removal . . . . . . . . . . . . . . . . . . . 11
3.4. Credential Management. . . . . . . . . . . . . . . . . . 12
4. Protocol Considerations. . . . . . . . . . . . . . . . . . . . 12
4.1. Secure Credential Formats. . . . . . . . . . . . . . . . 12
4.2. Authentication Methods . . . . . . . . . . . . . . . . . 13
4.3. Transport Protocol Suites. . . . . . . . . . . . . . . . 16
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
5.1. Communications Security. . . . . . . . . . . . . . . . . 17
5.2. Systems Security . . . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Functional Overview. . . . . . . . . . . . . . . . . . . . . . 2
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Credentials. . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Network Architecture . . . . . . . . . . . . . . . . . . 5
3. Protocol Framework . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Credential Upload. . . . . . . . . . . . . . . . . . . . 8
3.2. Credential Download. . . . . . . . . . . . . . . . . . . 10
3.3. Credential Removal . . . . . . . . . . . . . . . . . . . 11
3.4. Credential Management. . . . . . . . . . . . . . . . . . 12
4. Protocol Considerations. . . . . . . . . . . . . . . . . . . . 12
4.1. Secure Credential Formats. . . . . . . . . . . . . . . . 12
4.2. Authentication Methods . . . . . . . . . . . . . . . . . 13
4.3. Transport Protocol Suites. . . . . . . . . . . . . . . . 16
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
5.1. Communications Security. . . . . . . . . . . . . . . . . 17
5.2. Systems Security . . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . 20
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . 20
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
1 Introduction
1导言
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 proposes a general framework for secure exchange of such credentials and provides a high level outline that will help guide the development of one or more securely available credentials (SACRED) credential exchange protocols.
本文件为此类凭证的安全交换提出了一个通用框架，并提供了一个高层次的概要，将有助于指导一个或多个安全可用凭证（神圣）凭证交换协议的开发。
Requirements for SACRED are fully described in [RFC3157]. These requirements assume that two distinctly different network architectures will be created to support credential exchange for roaming users:
[RFC3157]中详细描述了神圣的要求。这些要求假设将创建两种截然不同的网络体系结构，以支持漫游用户的凭据交换：
a) Client/Server Credential Exchange b) Peer-to-Peer Credential Exchange
a) 客户端/服务器凭据交换b）对等凭据交换
This document describes the framework for one or more client/server credential exchange protocols.
本文档描述了一个或多个客户端/服务器凭据交换协议的框架。
In all cases, adequate user authentication methods will be used to ensure credentials are not divulged to unauthorized parties. As well, adequate server authentication methods will be used to ensure that each client's authentication information (see Section 2.1) is not compromised, and to ensure that roaming users interact with intended/authorized credential servers.
在所有情况下，都将使用适当的用户身份验证方法，以确保凭据不会泄露给未经授权的方。此外，还将使用适当的服务器身份验证方法，以确保每个客户端的身份验证信息（见第2.1节）不受损害，并确保漫游用户与预期/授权的凭据服务器进行交互。
This section provides definitions for several terms or phrases used throughout this document.
本节提供了本文档中使用的几个术语或短语的定义。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“应该”、“不应该”、“建议”和“可能”应按照[RFC2119]中的说明进行解释。
client authentication information: information that is presented by the client to a server to authenticate the client. This may include a password token, a registration string that may have been received out-of-band (and possibly used for initially registering a roaming user) or data signed with a signature key belonging to the client (e.g., as part of TLS [RFC2246] client authentication).
客户端身份验证信息：客户端向服务器提供的用于对客户端进行身份验证的信息。这可能包括密码令牌、可能已在带外接收的注册字符串（并且可能用于最初注册漫游用户）或使用属于客户端的签名密钥签名的数据（例如，作为TLS[RFC2246]客户端认证的一部分）。
credentials: cryptographic objects and related data used to support secure communications over the Internet. Credentials may consist of public/private key pairs, symmetric keys, X.509 public key certificates, attribute certificates, and/or application data. Several standardized formats for the representation of credentials exist, e.g., [PKCS12], [PKCS15] (see "secured credentials" below).
凭据：用于支持Internet上安全通信的加密对象和相关数据。凭据可能包括公钥/私钥对、对称密钥、X.509公钥证书、属性证书和/或应用程序数据。有几种标准化的凭证表示格式，例如[PKCS12]、[PKCS15]（请参阅下面的“安全凭证”）。
passkey: a symmetric key, derived from a password.
密钥：从密码派生的对称密钥。
password: a string of characters known only to a client and used for the purposes of authenticating to a server and/or securing credentials. A user may be required to remember more than one password.
密码：只有客户端才知道的字符串，用于向服务器进行身份验证和/或保护凭据。用户可能需要记住多个密码。
password token: a value derived from a password using a one-way function that may be used by a client to authenticate to a server. A password token may be derived from a password using a one-way hash function, for example.
密码令牌：使用单向函数从密码中派生的值，客户端可使用该函数向服务器进行身份验证。例如，可以使用单向散列函数从密码派生密码令牌。
secured credentials: a set of one or more credentials that have been cryptographically secured, e.g., encrypted/MACed with a passkey. Secured credentials may be protected using more than one layer of encryption, e.g., the credential is secured with a passkey corresponding to a user's password and also by a key known only to the server (the credential's stored form). During network transfer, the passkey-protected credential may be protected with an additional encryption layer using a symmetric key chosen by the Credential Server (e.g., the transmitted form).
安全凭证：一组一个或多个已通过加密方式进行安全保护的凭证，例如，使用密钥进行加密/加密。可使用不止一层的加密来保护安全凭证，例如，凭证由对应于用户密码的密钥以及仅服务器已知的密钥（凭证的存储形式）来保护。在网络传输期间，受密钥保护的凭证可以使用凭证服务器选择的对称密钥（例如，传输的形式）使用附加加密层进行保护。
strong password protocol: a protocol that authenticates clients to servers securely (see e.g., [SPEKE] for a more detailed definition of this), where the client need only memorize a small secret (a password) and carries no other secret information, and where the server carries a verifier
强密码协议：一种安全地向服务器验证客户端的协议（参见[SPEKE]了解更详细的定义），其中客户端只需记住一个小秘密（密码），不携带任何其他秘密信息，服务器携带验证器
(password token) which allows it to authenticate the client. A shared secret is negotiated between client and server and is used to protect data subsequently exchanged.
（密码令牌），它允许对客户端进行身份验证。客户机和服务器之间协商共享秘密，用于保护随后交换的数据。
Note the distinction between an "account password" and a "credential password." An account password (and corresponding password token) is used to authenticate to a Credential Server and to negotiate a key that provides session level encryption between client and server.
请注意“帐户密码”和“凭据密码”之间的区别。帐户密码（以及相应的密码令牌）用于对凭据服务器进行身份验证，并协商在客户端和服务器之间提供会话级加密的密钥。
A credential password is used to derive a passkey that's used to provide persistent encryption and authentication for a stored credential. Applicable secured credential standards documents (e.g., [PKCS15]) describe the technical details of specific password-based-encryption (pbe) techniques that are used to protect credentials from unauthorized use.
凭证密码用于派生用于为存储的凭证提供持久加密和身份验证的密钥。适用的安全凭证标准文档（例如[PKCS15]）描述了用于保护凭证不被未授权使用的特定基于密码的加密（pbe）技术的技术细节。
Although the same password value may be used to provide both services, it is likely that different, algorithm specific passkeys would be generated from this password (i.e., because of different salt values, etc.).
虽然可以使用相同的密码值来提供这两种服务，但很可能会从该密码生成不同的特定于算法的密钥（即，由于不同的salt值等）。
In addition, although it may be more convenient for a user to remember only a single password, differing security policies (e.g., password rules) between the credential server and the credential issuers may result in a user having to remember multiple passwords.
此外，尽管用户仅记住单个密码可能更方便，但凭证服务器和凭证颁发者之间不同的安全策略（例如，密码规则）可能导致用户必须记住多个密码。
This document is concerned with the secure exchange and online management of credentials in a roaming or mobile environment. Credentials MAY be usable with any end user device that can connect to the Internet, such as:
本文档涉及漫游或移动环境中凭据的安全交换和在线管理。凭据可用于可连接到Internet的任何最终用户设备，例如：
- desktop or laptop PC - mobile phone - personal digital assistant (PDA) - etc.
- 台式或笔记本电脑-移动电话-个人数字助理（PDA）-等。
The end user system may, optionally, store its credential information on special hardware devices that provide enhanced portability and protection for user credentials.
最终用户系统可以可选地将其凭证信息存储在为用户凭证提供增强的可移植性和保护的特殊硬件设备上。
Since the credential usually contains sensitive information that is known only to the credential holder, credentials MUST NOT be sent in the clear during network transmission and SHOULD NOT be in the clear when stored on an end user device such as a diskette or hard drive. For this reason, a secured credential is defined. Throughout this document we assume that, at least from the point of view of the
由于凭证通常包含仅凭证持有人知道的敏感信息，因此在网络传输期间，凭证不得以明文形式发送，并且在最终用户设备（如软盘或硬盘驱动器）上存储时，凭证也不应以明文形式发送。因此，定义了安全凭据。在本文件中，我们假设，至少从
protocol, a secured credential is an opaque (and at least partially privacy and integrity protected) data object that can be used by a network connected device. Once downloaded, clients must be able to recover their credentials from this opaque format.
协议中，安全凭据是一种不透明（至少部分受隐私和完整性保护）数据对象，可由网络连接设备使用。下载后，客户端必须能够从此不透明格式恢复其凭据。
At a minimum, all supported credential formats SHOULD provide privacy and integrity protection for private keys, secret keys, and any other data objects that must be protected from disclosure or modification. Typically, these security capabilities are part of the basic credential format such that the credential (e.g., a data file) is protected when stored on hard drives, flexible diskettes, etc.
至少，所有受支持的凭据格式都应为私钥、密钥和任何其他必须保护不被泄露或修改的数据对象提供隐私和完整性保护。通常，这些安全功能是基本凭证格式的一部分，因此凭证（例如，数据文件）在存储在硬盘驱动器、软磁盘等上时受到保护。
During network transmission, the secured credential is protected with a second (outer) encryption layer. The outer encryption layer is created using a session-level encryption key that was derived during the mutual authentication process. Effectively, secured credentials traverse an "encrypted tunnel" that provides an additional layer of privacy protection for credentials (and any other) information exchanged.
在网络传输期间，安全凭证由第二（外部）加密层保护。外部加密层是使用在相互身份验证过程中派生的会话级加密密钥创建的。有效地，安全凭证通过“加密隧道”，为凭证（和任何其他）交换信息提供额外的隐私保护层。
The network diagram below shows the components involved in the SACRED client/server framework.
下面的网络图显示了神圣客户机/服务器框架中涉及的组件。
+--------+ +------------+
| Client +-----------| Credential |
+--------+ 1 | Server |
\ +-----+------+
\ |
\ | 2
\ |
\ 3 +-----+------+
-----------| Credential |
| Store(s) |
+------------+
+--------+ +------------+
| Client +-----------| Credential |
+--------+ 1 | Server |
\ +-----+------+
\ |
\ | 2
\ |
\ 3 +-----+------+
-----------| Credential |
| Store(s) |
+------------+
Client - The entity that wants to retrieve their credentials from a credential server.
客户端-希望从凭据服务器检索其凭据的实体。
Credential Server - The server that downloads secure credentials to and uploads them from the client. The server is responsible for authenticating the client to ensure that the secured credentials are exchanged only with an appropriate end user. The credential server is authenticated to the client to ensure that the client's authentication information is not compromised and so that the user can trust the credentials retrieved.
凭据服务器—将安全凭据下载到客户端并从客户端上载的服务器。服务器负责对客户端进行身份验证，以确保仅与适当的最终用户交换安全凭据。凭据服务器向客户端进行身份验证，以确保客户端的身份验证信息不受损害，从而用户可以信任检索到的凭据。
Credential Store - The repository for secured credentials. There might be access control features but those generally aren't sufficient in themselves for securing credentials. The credential server may be capable of splitting credentials across multiple credential stores for redundancy or to provide additional levels of protection for user credentials.
凭据存储-安全凭据的存储库。可能有访问控制功能，但这些功能本身通常不足以保护凭据。凭证服务器可以跨多个凭证存储区拆分凭证以实现冗余，或者为用户凭证提供额外级别的保护。
Protocol 1 - The protocol used to authenticate the client and credential server, and download and upload user credentials from a credential server.
协议1-用于验证客户端和凭据服务器以及从凭据服务器下载和上载用户凭据的协议。
Protocol 2 - The protocol used by the Credential Server to store and retrieve user credentials (LDAP, LDAP/SSL, or other).
协议2—凭据服务器用于存储和检索用户凭据（LDAP、LDAP/SSL或其他）的协议。
Protocol 3 - The protocol used by the client to store and retrieve user credentials from the credential store (LDAP, LDAP/SSL, or other).
协议3—客户端用于从凭据存储（LDAP、LDAP/SSL或其他）存储和检索用户凭据的协议。
This framework describes the high level design for protocol 1. Protocols 2 and 3 are closely related (but out of scope for this document) and could be implemented using standard protocols, such as LDAP or secure LDAP, or other standard or proprietary protocols. Note also that any administrator-credential server protocols are assumed to be server vendor specific and are not the subject of SACRED standardization efforts at this time.
该框架描述了协议1的高级设计。协议2和3密切相关（但不在本文档的范围内），可以使用标准协议（如LDAP或安全LDAP）或其他标准或专有协议来实现。还请注意，任何管理员凭据服务器协议都假定为特定于服务器供应商的协议，目前不是神圣的标准化工作的主题。
Clients are not precluded from exchanging credentials directly with a credential store (or any other server of it's choosing). However, mutual authentication with roaming users and a consistent level of protection for credential data while stored on network servers and while in transit is provided by SACRED protocols exchanged with the credential server. Depending on credential server design, user credentials may flow through the credential server to the credential store or directly between the client and the credential store.
客户端不排除直接与凭证存储（或其选择的任何其他服务器）交换凭证。但是，与漫游用户的相互身份验证以及存储在网络服务器上和传输过程中的凭证数据的一致保护级别由与凭证服务器交换的神圣协议提供。根据凭据服务器的设计，用户凭据可以通过凭据服务器流向凭据存储，或者直接在客户端和凭据存储之间流动。
Also, users may upload their credentials to several credential servers to obtain enhanced levels of availability. Coordination (automatic replication) of user information or credential data among several credential servers is currently beyond the scope of this document.
此外，用户还可以将其凭据上载到多个凭据服务器，以获得更高级别的可用性。多个凭证服务器之间的用户信息或凭证数据的协调（自动复制）目前超出了本文档的范围。
This section provides a high level description of client/server protocols that can be used to exchange and manage SACRED credentials.
本节提供可用于交换和管理凭证的客户端/服务器协议的高级描述。
The client/server credential exchange protocol is based on three basic and abstract operations; "GET", "PUT", and "DELETE". The secured credential exchange protocol is accomplished as follows:
客户机/服务器凭证交换协议基于三种基本抽象操作；“获取”、“放置”和“删除”。安全凭证交换协议的实现如下：
connect - the client initiates a connection to a credential server for the purpose of secure credential exchange.
连接-客户端启动与凭据服务器的连接，以实现安全凭据交换。
mutual authentication/key negotiation - using a strong password protocol (or equivalent) the client authenticates to the server, the server authenticates to the client, and a session level encryption key is negotiated. The details of the mutual authentication protocol exchange are dependent upon the particular authentication method used. In all cases, the end result is to authenticate the client to the server and server to the client, and establish a strong, shared secret between the two parties.
相互身份验证/密钥协商-使用强密码协议（或等效协议），客户端向服务器进行身份验证，服务器向客户端进行身份验证，并协商会话级加密密钥。相互认证协议交换的详细信息取决于所使用的特定认证方法。在所有情况下，最终结果都是将客户机验证给服务器，将服务器验证给客户机，并在双方之间建立一个强大的共享秘密。
client request(s) - the SACRED client issues one or more high level credential exchange requests (e.g., GET, PUT, or DELETE).
客户端请求-客户端发出一个或多个高级凭证交换请求（例如，获取、放置或删除）。
server response(s) - the SACRED credential server responds to each request, either performing the operation successfully or indicating an appropriate error.
服务器响应-凭证服务器响应每个请求，要么成功执行操作，要么指示适当的错误。
close - the client indicates it has no more requests for the server at this time. The security context between client and server is no longer needed. Close is a logical, session management operation.
关闭-客户端表示此时没有对服务器的更多请求。不再需要客户端和服务器之间的安全上下文。关闭是一种逻辑、会话管理操作。
disconnect - the parties disconnect the transport level connection between client and server. Note that "connect" and "disconnect" are logical, transport-layer dependent operations that enclose the protocol exchange between the two communicating processes.
断开连接-双方断开客户端和服务器之间的传输级连接。请注意，“连接”和“断开连接”是逻辑的、依赖于传输层的操作，包含两个通信进程之间的协议交换。
Each high-level credential exchange operation is made up of a series of request-response pairs. The client initiates each request, which the server processes before returning an appropriate response. Each request must complete (server reports success or failure) before the client issues the next request. The server SHOULD be willing to service at least one upload or download request following successful mutual authentication but either party can terminate the logical connection at any time.
每个高级凭证交换操作都由一系列请求-响应对组成。客户机启动每个请求，服务器在返回适当的响应之前处理这些请求。在客户端发出下一个请求之前，每个请求都必须完成（服务器报告成功或失败）。在成功的相互身份验证之后，服务器应该愿意为至少一个上传或下载请求提供服务，但任何一方都可以随时终止逻辑连接。
In the following sections, secured credentials and related values are represented using the following notation:
在以下部分中，使用以下符号表示安全凭据和相关值：
SC-x is the secured credential file, which includes a format identifier field and credential data. The credential data is an opaque, encrypted data object (e.g., PKCS#15 or PKCS#12 file). The format identifier is needed to correctly parse the credential data.
SC-x是安全凭证文件，包括格式标识符字段和凭证数据。凭证数据是不透明的加密数据对象（例如PKCS 15或PKCS 12文件）。正确解析凭证数据需要格式标识符。
Name-x is an account-defined selector or locator (a user friendly name) that is used to indicate a specific secured credential. The name of each credential stored under a given user account MUST be unique e.g., there may be one credential called "financial" and another called "healthcare", etc. At a minimum, credential names MUST be unique across a given account/user name. When no name is supplied for a GET operation, all credentials stored for the given username will be returned.
Name-x是一个帐户定义的选择器或定位器（用户友好的名称），用于指示特定的安全凭据。存储在给定用户帐户下的每个凭证的名称必须是唯一的，例如，可能有一个凭证称为“金融”和另一个凭证称为“医疗保健”，等等。至少，凭证名称在给定帐户/用户名中必须是唯一的。当没有为GET操作提供名称时，将返回为给定用户名存储的所有凭据。
ID-x is a distinct credential version indicator that MAY be used to request a conditional GET/PUT/DELETE operation. This credential-ID value SHOULD contain the server's "last-modified" date and time (e.g., the time that this particular credential version was stored on the server) and MAY contain additional information such as a sequence number or a (complete or partial) credential fingerprint that is used to ensure the credential-ID is unique from other credential versions stored under the same user account and credential name.
ID-x是一个不同的凭证版本指示符，可用于请求有条件的获取/放置/删除操作。此凭证ID值应包含服务器的“上次修改”日期和时间（例如，此特定凭证版本存储在服务器上的时间），并可能包含其他信息，如序列号或（完整或部分）凭证指纹，用于确保凭证ID与存储在同一用户帐户和凭证名称下的其他凭证版本唯一。
All named credentials may be accessed by authenticating under a single username. If a user needs or prefers to use more than one distinct authentication password (and/or authentication method) to protect access to several secured credentials, he/she SHOULD register those credentials under distinct user/account names, one for each different authentication method used.
可以通过使用单个用户名进行身份验证来访问所有命名凭据。如果用户需要或更愿意使用多个不同的身份验证密码（和/或身份验证方法）来保护对多个安全凭据的访问，则他/她应在不同的用户名/帐户名下注册这些凭据，每个用户名/帐户名对应使用的不同身份验证方法。
The purpose of a credential upload operation is to allow a client to register new credentials, or replace currently stored credentials (e.g., credentials that may have been updated by the client using appropriate key management software).
凭证上载操作的目的是允许客户端注册新凭证，或替换当前存储的凭证（例如，可能已由客户端使用适当的密钥管理软件更新的凭证）。
The framework for the credential upload, as implemented using the PUT operation, is:
使用PUT操作实现的凭证上载框架为：
- The client and server establish a mutually authenticated session and negotiate a shared secret.
- 客户端和服务器建立相互验证的会话并协商共享秘密。
- The client will then issue a PUT message that contains the upload credential and related data fields.
- 然后，客户端将发出包含上载凭据和相关数据字段的PUT消息。
- The server will respond to the PUT, indicating the credential was successfully stored on the server or that an error occurred.
- 服务器将响应PUT，指示凭据已成功存储在服务器上或发生错误。
The client's PUT request MAY contain an optional identifier (credential-ID) field. If present, the new credential will only be stored if a credential with the same name and credential-ID is currently stored on the server (e.g., a logical REPLACE operation is performed). The server MUST return an error if a client attempts to replace a credential that does not exist on the server.
客户端的PUT请求可能包含可选标识符（凭证ID）字段。如果存在，则仅当服务器上当前存储了具有相同名称和凭据ID的凭据（例如，执行了逻辑替换操作）时，才会存储新凭据。如果客户端试图替换服务器上不存在的凭据，服务器必须返回错误。
The credential server's response to a PUT request MUST contain a credential version identifier (credential-ID) for the newly stored credential that MAY be used by clients to optimize subsequent download operations and avoid credential version mismatches.
凭证服务器对PUT请求的响应必须包含新存储凭证的凭证版本标识符（凭证ID），客户端可以使用该标识符优化后续下载操作并避免凭证版本不匹配。
The following gives an example of a "credential upload" protocol sequence:
下面给出了“凭证上载”协议序列的示例：
client server
------- -------
client server
------- -------
< connect > -->
< connect > -->
<--- mutual authentication --->
<--- mutual authentication --->
< PUT SC-1, Name-1, [ID-1] > -->
<-- < Name-1, new-ID-1 >
< PUT SC-2, Name-2, [ID-2] > -->
<-- < Name-2, new-ID-2 >
< PUT SC-1, Name-1, [ID-1] > -->
<-- < Name-1, new-ID-1 >
< PUT SC-2, Name-2, [ID-2] > -->
<-- < Name-2, new-ID-2 >
...
...
< close > -->
<-- OK (+ disconnect)
< close > -->
<-- OK (+ disconnect)
new-ID-x is the credential-ID of the newly stored credential.
new-ID-x是新存储凭证的凭证ID。
Roaming clients can download their credentials at any time after they have been uploaded to the server.
漫游客户端可以在上传到服务器后随时下载其凭据。
The framework for a credential download, as implemented using the GET operation, is:
使用GET操作实现的凭证下载框架是：
- The client SHOULD authenticate the server.
- 客户端应该对服务器进行身份验证。
- The user MUST be authenticated (by the server).
- 必须（通过服务器）对用户进行身份验证。
- A GET request for the credential download is issued.
- 发出凭证下载的GET请求。
- The response contains the credential and format identifier.
- 响应包含凭证和格式标识符。
The specific user credential being requested may be identified by name in the message sent to the credential server. If successful, the response MUST contain the requested credential data element (format ID and data) as defined above.
被请求的特定用户凭据可以通过发送到凭据服务器的消息中的名称来标识。如果成功，响应必须包含上面定义的请求凭证数据元素（格式ID和数据）。
If the user issues a GET request with a NULL credential name field, the server SHOULD return all credentials stored under the current user account.
如果用户发出带有空凭据名称字段的GET请求，服务器应返回当前用户帐户下存储的所有凭据。
Optionally, the client MAY include a credential-ID to indicate a conditional download request. In this case, the server will return the requested credential if and only if the ID of the credential currently stored on the server does NOT match the ID specified.
可选地，客户端可以包括凭证ID以指示有条件下载请求。在这种情况下，当且仅当当前存储在服务器上的凭据ID与指定的ID不匹配时，服务器才会返回请求的凭据。
The server should return either the requested credential or a distinct response indicating that the conditional download was not performed (e.g., the client already has a copy of this exact credential).
服务器应返回请求的凭据或明确的响应，指示未执行有条件下载（例如，客户端已拥有该凭据的副本）。
The following gives an example of a "credential download" protocol sequence:
以下给出了“凭证下载”协议序列的示例：
client server
------- --------
client server
------- --------
< connect > -->
< connect > -->
<--- mutual authentication -->
<--- mutual authentication -->
< GET Name-1, [ID-1] > -->
<-- < SC-1, ID-1' >
< GET Name-2, [ID-2] > -->
<-- < GET response >
< GET Name-1, [ID-1] > -->
<-- < SC-1, ID-1' >
< GET Name-2, [ID-2] > -->
<-- < GET response >
...
...
< close > -->
<-- OK (+ disconnect)
< close > -->
<-- OK (+ disconnect)
Notice that for the second request, no credential has been returned since ID-2, as included in the client's request, matched the identifier for the Name-2 credential.
请注意，对于第二个请求，由于客户端请求中包含的ID-2与Name-2凭据的标识符匹配，因此没有返回任何凭据。
The framework for the credential removal, as implemented with the DELETE operation, is:
通过删除操作实现的凭据删除框架是：
- The credential server MUST be authenticated (by the client) using a method-dependent protocol sequence.
- 凭据服务器必须（由客户端）使用依赖于方法的协议序列进行身份验证。
- The user MUST be authenticated (by the server) using a method-dependent protocol sequence.
- 必须使用依赖于方法的协议序列（由服务器）对用户进行身份验证。
- The user then sends a DELETE request message that contains the credential name indicating which credential to remove.
- 然后，用户发送一条删除请求消息，其中包含凭证名称，指示要删除的凭证。
- Optionally, the client may include a credential-ID in the DELETE request. In this case, the credential will be deleted if the request ID matches the ID of the credential currently stored on the server. This may be done to ensure that a client intending to delete their stored credential does not mistakenly delete a different version of the credential.
- 可选地，客户端可以在删除请求中包括凭证ID。在这种情况下，如果请求ID与当前存储在服务器上的凭据ID匹配，则将删除凭据。这样做可以确保打算删除其存储凭据的客户端不会错误地删除不同版本的凭据。
The following gives an example of a "credential removal" protocol sequence:
下面给出了“凭证删除”协议序列的示例：
client server
------- --------
client server
------- --------
< connect > -->
< connect > -->
<-------- mutual authentication -------->
<-------- mutual authentication -------->
< DEL Name-1, [ID1] > -->
<-- < Name-1 deleted >
< DEL Name-2, [ID2] > -->
<-- < Name-2 deleted >
< DEL Name-1, [ID1] > -->
<-- < Name-1 deleted >
< DEL Name-2, [ID2] > -->
<-- < Name-2 deleted >
...
...
< close > -->
<-- OK (+ disconnect)
< close > -->
<-- OK (+ disconnect)
Note that the three operations defined above (GET, PUT, DELETE) can be used to perform the basic credential management operations:
请注意，上面定义的三个操作（GET、PUT、DELETE）可用于执行基本凭证管理操作：
- add a new credential on the server, - update (replace) an existing credential, and - delete an existing credential.
- 在服务器上添加新凭据，-更新（替换）现有凭据，-删除现有凭据。
The information provided for these basic operations might be used to help guide the design of more complex operations such as user registration (add account), user deregistration (remove account), change account password, or list all credentials.
为这些基本操作提供的信息可用于帮助指导更复杂操作的设计，如用户注册（添加帐户）、用户注销（删除帐户）、更改帐户密码或列出所有凭据。
Note that, in the case where a credential with the same name exists on the server, uploading a NULL credential is logically equivalent to removing a previously stored credential.
请注意，在服务器上存在同名凭据的情况下，上载空凭据在逻辑上等同于删除以前存储的凭据。
To ensure that credentials created on, and uploaded from, one device can be downloaded and used on any other device, there is a need to define a single "mandatory to implement" credential format that must be supported by all conforming client implementations.
为了确保在一台设备上创建和上载的凭据可以下载并在任何其他设备上使用，需要定义一个单一的“强制实现”凭据格式，所有符合要求的客户端实现都必须支持该格式。
At least two well-defined credential formats are available today: [PKCS12] and [PKCS15].
目前至少有两种定义良好的凭证格式可用：[PKCS12]和[PKCS15]。
Other optional credential formats may also be supported if necessary. For example, additional credential formats might be defined for use with specific (compatible) client devices. Each credential format MUST provide adequate privacy protection for user credentials when they are stored on flexible diskettes, hard disks, etc.
如有必要，还可以支持其他可选凭证格式。例如，可以定义附加的凭证格式以用于特定（兼容）客户端设备。当用户凭证存储在软磁盘、硬盘等上时，每种凭证格式都必须为用户凭证提供足够的隐私保护。
Throughout this document, the credential is treated as an opaque (encrypted) data object and, as such, the credential format does not affect the basic credential exchange protocol.
在本文档中，凭证被视为不透明（加密）数据对象，因此凭证格式不影响基本凭证交换协议。
Authentication is vitally important to ensure that credentials are accepted from and delivered to the authorized end user only. If an unsecured credential is delivered to some other party, the credential may be more easily compromised. If a credential is accepted from an unauthorized party, the user might be tricked into using a credential that has been substituted by an attacker (e.g., an attacker might replace a newer credential with an older credential belonging to the same user).
身份验证对于确保仅接受授权最终用户的凭据并将其交付给授权最终用户至关重要。如果将不安全的凭据传递给其他方，则该凭据可能更容易受到攻击。如果接受来自未经授权方的凭据，则用户可能会被骗使用已被攻击者替换的凭据（例如，攻击者可能会用属于同一用户的旧凭据替换较新的凭据）。
Ideally, the list of authentication methods should be open ended, allowing new methods to be added as needs are identified and as they become available. For all credentials, the user authentication method and data is defined when a user is first registered with the credential server and may be updated from time to time thereafter by the authorized user.
理想情况下，身份验证方法的列表应该是开放式的，允许在确定需求和可用时添加新方法。对于所有凭证，用户认证方法和数据在用户首次向凭证服务器注册时定义，并且可在此后由授权用户不时更新。
To adequately protect user credentials from unauthorized disclosure or modification in a roaming environment, all SACRED authentication methods MUST provide protection for user credentials in network environments where attackers might attempt to exploit potential security vulnerabilities. See SACRED Requirements [RFC3157], Section 3.1, Vulnerabilities.
为了在漫游环境中充分保护用户凭据不受未经授权的泄露或修改，所有神圣的身份验证方法必须在攻击者可能试图利用潜在安全漏洞的网络环境中为用户凭据提供保护。见神圣要求[RFC3157]，第3.1节，漏洞。
At a minimum, each SACRED authentication method SHOULD ensure that:
每种认证方法至少应确保：
- The server authenticates the client - The client authenticates the server - The client and server securely negotiate (or derive) a cryptographically strong, secret key (e.g., a session key). - The exchange of one or more user credentials is protected using this session key.
- 服务器对客户端进行身份验证-客户端对服务器进行身份验证-客户端和服务器安全地协商（或派生）加密强的密钥（例如，会话密钥）。-使用此会话密钥保护一个或多个用户凭据的交换。
It is expected that all SACRED client/server protocols will provide each of these basic security functions. Some existing authentication protocols that might be used for this purpose include:
所有神圣的客户机/服务器协议都将提供这些基本的安全功能。可能用于此目的的一些现有身份验证协议包括：
- Strong password protocols - TLS
- 强密码协议-TLS
Sections 4.2.1 and 4.2.2 provide some guidance about when to use these authentication methods based on the generic security capabilities they provide and the security elements (passwords, key pairs, user certificates, CA certificates) that must be available to the SACRED client.
第4.2.1节和第4.2.2节根据这些认证方法提供的通用安全功能以及客户端必须使用的安全元素（密码、密钥对、用户证书、CA证书），提供了有关何时使用这些认证方法的一些指导。
Strong password protocols such as those described in [RFC2945], [BM92], [BM94], and [SPEKE] MAY be used to provide mutual authentication and privacy for SACRED protocols.
强密码协议，如[RFC2945]、[BM92]、[BM94]和[SPEKE]中所述，可用于为神圣协议提供相互认证和隐私。
All strong password protocols require that user-specific values (i.e., a passtoken and related values) be configured within the server. Only a party who knows the password can calculate the verifier value. It must be securely delivered to the server at a time when the client establishes a relationship with the server. At connect time, messages are exchanged between the two parties and complementary algorithms are used to compute a shared common value known only to the legitimate user and the server. Both parties derive a strong (symmetric) key that may be used to secure communications between the two parties.
所有强密码协议都要求在服务器中配置特定于用户的值（即，passtoken和相关值）。只有知道密码的一方才能计算验证器值。它必须在客户端与服务器建立关系时安全地传递到服务器。在连接时，双方之间交换消息，并使用互补算法计算只有合法用户和服务器才知道的共享公共值。双方都派生一个强（对称）密钥，该密钥可用于保护双方之间的通信。
TLS authentication may either be mutual between the client and server or unilateral where only the server is authenticated to the client. These options are described in the next two subsections.
TLS身份验证可以是客户机和服务器之间的相互身份验证，也可以是单向身份验证，其中只有服务器通过了客户机的身份验证。下面两小节将介绍这些选项。
In both cases, TLS can be used to authenticate the server whenever the TLS client has been pre-configured with the necessary certificates needed to validate the server's certificate chain (including revocation status checking).
在这两种情况下，只要TLS客户端预先配置了验证服务器证书链所需的必要证书（包括吊销状态检查），就可以使用TLS对服务器进行身份验证。
TLS Server Authentication (sTLS)
TLS服务器身份验证（sTLS）
TLS provides a basic secure session capability (sometimes called server-side TLS) whereby the client authenticates the server and a pair of session level encryption keys is securely exchanged between
TLS提供了一种基本的安全会话功能（有时称为服务器端TLS），客户机通过该功能对服务器进行身份验证，并在服务器之间安全地交换一对会话级加密密钥
client and server. Following server authentication and security context setup, all client requests and server responses exchanged are integrity and privacy protected.
客户端和服务器。在服务器身份验证和安全上下文设置之后，交换的所有客户端请求和服务器响应都受到完整性和隐私保护。
Protocol designers and implementors should be aware that the flexibility of the certificate-based TLS server authentication method creates security risks that need to be mitigated. Specifically, the need to ensure the user is connected to the intended credential server (secure site), and no other. The TLS v1.0 standard [RFC2246] identifies the basis for managing this risk in section F.3 (see also Section 5.2 in this document):
协议设计者和实现者应该意识到，基于证书的TLS服务器身份验证方法的灵活性产生了需要缓解的安全风险。具体而言，需要确保用户连接到预期的凭据服务器（安全站点），而不是其他。TLS v1.0标准[RFC2246]在第F.3节中确定了管理该风险的依据（另见本文件第5.2节）：
"Implementations and users must be careful when deciding which certificates and certificate authorities are acceptable; a dishonest certificate authority can do tremendous damage."
“在决定哪些证书和证书颁发机构是可接受的时，实现和用户必须小心；不诚实的证书颁发机构可能会造成巨大的损害。”
Note also that a faulty implementation of (increasingly complex) TLS server certificate chain processing, by the SACRED client, could lead to similar compromise, allowing successful credential server masquerade or man-in-the-middle attacks.
还请注意，神圣客户端错误地实现（日益复杂的）TLS服务器证书链处理可能会导致类似的危害，从而导致成功的凭证服务器伪装或中间人攻击。
An engineering approach that provides an enhanced or augmented server authentication method may be warranted for SACRED protocol designs. It is also important to understand that simple layering of independently developed security protocols (e.g., using BEEP or similar layering techniques) produces a complex, multilayer security protocol that might be easily defeated by a combination-specific attack that is able to expose and exploit known weaknesses of the individual protocol(s).
提供增强或增强服务器身份验证方法的工程方法可用于协议设计。了解独立开发的安全协议的简单分层（例如，使用BEEP或类似分层技术）会产生一个复杂的多层安全协议，该协议可能很容易被特定组合攻击击败，该攻击能够暴露和利用单个协议的已知弱点。
When necessary, and after a TLS session has been established between the two parties, the credential server can request that the client provide her user id and password information to authenticate the remote user. Preferably, client and server can cooperate to perform an authentication operation that allows the server to authenticate the client (and perhaps vice-versa) in a "zero knowledge manner". In such cases, the client need not have a security credential.
必要时，在双方之间建立TLS会话后，凭证服务器可以请求客户端提供其用户id和密码信息，以验证远程用户。优选地，客户机和服务器可以合作执行认证操作，该认证操作允许服务器以“零知识方式”认证客户机（或者反之亦然）。在这种情况下，客户端不需要具有安全凭据。
TLS with Client Authentication (cTLS)
具有客户端身份验证（cTLS）的TLS
TLS provides an optional, secure session capability (sometimes called client-side TLS) whereby the TLS server can request client authentication by verifying the client's digital signature.
TLS提供可选的安全会话功能（有时称为客户端TLS），TLS服务器可以通过验证客户端的数字签名来请求客户端身份验证。
In order to use cTLS to provide mutual authentication, the client must also be configured with at least one security credential that is acceptable to the TLS server for remote client authentication purposes.
为了使用CTL提供相互身份验证，客户机还必须配置至少一个TLS服务器可接受的安全凭据，用于远程客户机身份验证。
Other authentication methods that provide the necessary security capabilities MAY also be suitable for use with SACRED credential exchange protocols.
提供必要安全功能的其他身份验证方法也适用于神圣凭证交换协议。
It is intended that one or more underlying protocol stacks may carry the SACRED credential exchange protocols. It is recognized at the outset that the use of several underlying protocol suites, although not ideal from an interoperability standpoint, may well be required to support the wide variety of needs anticipated.
一个或多个底层协议栈可以承载神圣的凭证交换协议。从一开始就认识到，虽然从互操作性的角度来看并不理想，但可能需要使用几个底层协议套件来支持各种各样的预期需求。
The SACRED list members have discussed several protocol suites that have been considered on their technical merits, each with distinct benefits and protocol design/implementation costs. Among these protocols are:
神圣列表成员讨论了几个协议套件，这些套件都是根据其技术优点考虑的，每个套件都有不同的优点和协议设计/实施成本。这些协议包括：
- TCP - BEEP - HTTP
- TCP-BEEP-HTTP
All protocol suites listed here depend on TCP to provide a reliable, end-to-end transport layer protocol. Each of these building block approaches provides a different way of handling the remaining application layer issues (basic session management, session level security, presentation/formatting, application functionality).
这里列出的所有协议套件都依赖于TCP来提供可靠的端到端传输层协议。这些构建块方法中的每一种都提供了处理其余应用程序层问题的不同方法（基本会话管理、会话级别安全性、表示/格式、应用程序功能）。
This approach (layering a SACRED credential exchange protocol directly on top of a TCP connection) requires the development of a custom credential exchange messaging protocol that interfaces to a TCP connection/socket. The primary benefit of this approach is the ability to provide exactly the protocol functionality needed and no more. Most server and client development environments already provide the socket level API needed.
这种方法（将神圣的凭证交换协议直接分层到TCP连接之上）需要开发与TCP连接/套接字接口的自定义凭证交换消息传递协议。这种方法的主要好处是能够准确地提供所需的协议功能。大多数服务器和客户端开发环境已经提供了所需的套接字级API。
This approach builds on the Blocks Extensible Exchange Protocol (BEEP) described in [RFC3080]. BEEP provides general purpose, peer-to-peer message exchange over any of several transport mechanisms where the necessary transport layer mappings have been defined for operation over TCP, TLS, etc. See also [RFC3081].
这种方法建立在[RFC3080]中描述的块可扩展交换协议（BEEP）的基础上。BEEP通过几种传输机制中的任何一种提供通用的对等消息交换，其中定义了必要的传输层映射，以便通过TCP、TLS等进行操作。另请参见[RFC3081]。
BEEP provides the necessary user authentication/session security and session management capabilities needed to support SACRED credential exchange operations.
BEEP提供必要的用户身份验证/会话安全性和会话管理功能，以支持神圣凭证交换操作。
This approach builds on the Hypertext Transport Protocol (HTTP) described in [RFC1945] and [RFC2616]. HTTP provides general purpose typing and negotiation of data representation, allowing systems to be built independently of the data objects being transferred. HTTP support is available in a wide variety of server and client platforms, including portable devices that apply to roaming environments (laptop PCs, PDAs, mobile phones, etc.).
这种方法建立在[RFC1945]和[RFC2616]中描述的超文本传输协议（HTTP）的基础上。HTTP提供数据表示的通用类型和协商，允许独立于传输的数据对象构建系统。HTTP支持可用于多种服务器和客户端平台，包括适用于漫游环境的便携式设备（笔记本电脑、PDA、移动电话等）。
HTTP is layered over TCP and can be used, optionally, with TLS to provide authenticated, session level security. Either or both TLS authentication options, sTLS or cTLS, may be used whenever TLS is supported.
HTTP是在TCP上分层的，可以选择与TLS一起使用，以提供经过身份验证的会话级安全性。只要支持TLS，就可以使用一个或两个TLS身份验证选项STL或CTL。
The following security considerations identify general observations and precautions to be considered for a framework supporting credential mobility. When designing or implementing a protocol to support this framework, one should recognize these security considerations, and furthermore consult the SACRED Requirements document [RFC3157] Security Considerations.
以下安全注意事项确定了支持凭证移动的框架需要考虑的一般观察和预防措施。在设计或实施支持此框架的协议时，应认识到这些安全注意事项，并进一步参考神圣需求文件[RFC3157]安全注意事项。
A SACRED PDU will contain information pertaining to client or server authentication, or communication of credentials. This information is subject to the traditional security concerns identified below.
神圣的PDU将包含与客户端或服务器身份验证或凭据通信有关的信息。此信息受到以下传统安全问题的影响。
The password or password verifier should be protected when communicated from the client to credential server. The communicated value should be resistant to a dictionary attack.
当从客户端向凭据服务器通信时，应保护密码或密码验证器。传递的值应能抵抗字典攻击。
Similarly, the entity credentials must be confidentiality protected, when communicated from the client to the server and vice-versa. The communicated value should also resist a dictionary attack.
同样，当从客户端到服务器进行通信时，实体凭据必须受到保密保护，反之亦然。传递的值还应抵抗字典攻击。
Communication integrity between the client and the credential server is required. In this way, intended client operations may not be altered (e.g., from an update to a deletion of credentials), nor may clients be maliciously given "old" credentials (e.g., possibly by an attacker replaying a previous credential download).
客户端和凭据服务器之间需要通信完整性。通过这种方式，可能不会更改预期的客户端操作（例如，从更新到删除凭据），也可能不会恶意向客户端提供“旧”凭据（例如，攻击者可能会重播以前的凭据下载）。
Proper authentication of the client and server is required to achieve communication confidentiality and integrity.
为了实现通信的机密性和完整性，需要对客户端和服务器进行适当的身份验证。
The server must properly authenticate the client, so that credentials are not mistakenly revealed to an attacker. The client must ensure the proper identification of the credential server so as to prevent revealing their password to an attacker. These goals may be achieved implicitly with a strong password-based protocol or explicitly. If the server is identified explicitly, the user or client must ensure that the user password is conveyed to a trusted server. This might be achieved by installing appropriate trusted key(s) in the client.
服务器必须正确地对客户端进行身份验证，以便不会将凭据错误地透露给攻击者。客户端必须确保正确识别凭据服务器，以防止向攻击者泄露其密码。这些目标可以通过基于密码的协议隐式实现，也可以显式实现。如果明确标识了服务器，则用户或客户端必须确保将用户密码传送到受信任的服务器。这可以通过在客户端中安装适当的受信任密钥来实现。
There are no requirements upon the SACRED protocol itself to support non-repudiation, although the context in which the credentials are being used may have such requirements.
对神圣协议本身没有支持不可否认性的要求，尽管使用凭证的上下文可能有这样的要求。
Systems security is concerned with protection of the protocol endpoints (i.e., the client and server) and information stored at the server in support of the SACRED protocol.
系统安全性涉及保护协议端点（即客户端和服务器）以及存储在服务器上的支持协议的信息。
As with most security protocols, secure use of the client often relies, in part, upon secure behavior by the user. In the case of a password-based SACRED protocol, users should be educated, or enforced through policy, to choose passwords with a reasonable amount of entropy. Additionally, users should be made aware of the importance of protecting the confidentiality of their account password.
与大多数安全协议一样，客户端的安全使用通常部分依赖于用户的安全行为。在基于密码的神圣协议的情况下，应该教育用户或通过策略强制用户选择具有合理熵的密码。此外，应让用户意识到保护其帐户密码机密性的重要性。
In addition, the client interface should be designed to thwart "shoulder surfing" where an attacker can observe the password as entered by a user. This is often achieved by not echoing the exact characters of the password when entered.
此外，客户端界面的设计应该能够阻止“肩上冲浪”，攻击者可以观察用户输入的密码。这通常是通过在输入密码时不回显密码的确切字符来实现的。
As well, the interface should encourage the entering of the password in the appropriate interface field so that protections can be properly enforced. For example, a user should be guided to not mistakenly enter their password in the "username" field (since their password would likely be echoed to the screen in this case, and might not be encrypted when communicated to the server). This might be accomplished via the automatic insertion of the user name or several user name choices in the appropriate on-screen dialog field, for example.
此外，接口应鼓励在适当的接口字段中输入密码，以便正确实施保护。例如，应引导用户不要在“用户名”字段中错误输入密码（因为在这种情况下，他们的密码可能会回显到屏幕上，并且在与服务器通信时可能不会加密）。例如，这可以通过在适当的屏幕对话框字段中自动插入用户名或几个用户名选项来实现。
When TLS is used as the SACRED transport protocol, the client interface should be designed to allow the user to verify that she is connected to the intended credential server. For example, client software should allow for the visual display of identifying components from the TLS server's X.509 certificate, like the server's name, the certificate fingerprint, etc.
当TLS用作神圣的传输协议时，客户端接口的设计应允许用户验证是否已连接到预期的凭据服务器。例如，客户端软件应允许从TLS服务器的X.509证书中可视化显示标识组件，如服务器名称、证书指纹等。
Users should be guided to verify this information regularly, allowing ready recognition of trusted credential servers. In addition, users should be made aware of the importance of verifying their credential server's identity before initiating any credential exchange operations.
应引导用户定期验证此信息，以便随时识别受信任的凭据服务器。此外，在启动任何凭证交换操作之前，应让用户了解验证其凭证服务器身份的重要性。
A SACRED client SHOULD only be configured with those SACRED trust anchors that are to be used by the client. Re-use of trust anchors from other applications, e.g., Internet browsers is NOT RECOMMENDED.
神圣客户端应该只配置那些将由客户端使用的神圣信任锚。不建议重复使用来自其他应用程序（例如Internet浏览器）的信任锚。
Password verifiers and user credentials must be afforded a high level of protection at the credential server. In addition to salting and super-encrypting each (to ensure resistance to offline dictionary attacks), a system should ensure that credential server keys are protected using sufficient procedural and physical access controls.
密码验证器和用户凭据必须在凭据服务器上提供高级别的保护。除了对每个密钥进行加密和超级加密（以确保抵抗脱机字典攻击），系统还应确保使用足够的过程和物理访问控制来保护凭据服务器密钥。
The login to the credential server should be resistant to replay attacks.
登录到凭据服务器应能抵抗重播攻击。
Online attempts to access a particular user account should be controlled, or at least monitored. Control might be enforced by incorporating a time delay after a number of unsuccessful logins to a particular account, or possibly the locking of the account altogether. Alternatively, one might simply log unsuccessful attempts where an administrative notice is produced once a threshold of unsuccessful credential access attempts is reached.
应控制或至少监控访问特定用户帐户的在线尝试。可以通过在多次登录到特定帐户失败后加入时间延迟来实施控制，也可以完全锁定该帐户。或者，您可以简单地记录不成功的尝试，其中一旦达到不成功的凭据访问尝试的阈值，就会生成管理通知。
As with most protocols, Denial of Service (DoS) issues must also be considered. In the case of SACRED, most DoS issues are a concern for the underlying transport protocol. However, some concerns may still be mitigated.
与大多数协议一样，还必须考虑拒绝服务（DoS）问题。在神圣的情况下，大多数DoS问题都与底层传输协议有关。然而，一些担忧仍可能得到缓解。
Service to a user might be denied in case their account is locked after numerous unsuccessful login attempts. Consideration of protection against online attacks must therefore be considered (as described above). Proper user authentication should ensure that an attacker does not maliciously overwrite a user's credentials. Credential servers should be wary of repeated logins to a particular account (which also identifies a possible security breach, as described above) or abnormal volumes of requests to a number of accounts (possibly identifying a DoS attack).
如果用户的帐户在多次登录尝试失败后被锁定，则向用户提供的服务可能会被拒绝。因此，必须考虑防止在线攻击（如上所述）。正确的用户身份验证应确保攻击者不会恶意覆盖用户的凭据。凭据服务器应警惕重复登录特定帐户（如上所述，这也可识别可能的安全漏洞）或对多个帐户的异常请求量（可能识别DoS攻击）。
[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月。
[RFC3157] Arsenault, A. and S. Farrell, "Securely Available Credentials - Requirements", RFC 3157, August 2001.
[RFC3157]Arsenault，A.和S.Farrell，“安全可用凭证-要求”，RFC 3157，2001年8月。
[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange: Password-based protocols secure against dictionary attacks", Proceedings of the IEEE Symposium on Research in Security and Privacy, May 1992.
[BM92]Bellovin，S.和M.Merritt，“加密密钥交换：基于密码的协议防止字典攻击”，IEEE安全和隐私研究研讨会论文集，1992年5月。
[BM94] Bellovin, S. and M. Merritt, "Augmented Encrypted Key Exchange: a Password-Based Protocol Secure Against Dictionary Attacks and Password File Compromise, ATT Labs Technical Report, 1994.
[BM94]Bellovin，S.和M.Merritt，“增强加密密钥交换：一种防止字典攻击和密码文件泄露的基于密码的协议”，ATT实验室技术报告，1994年。
[PKCS12] "PKCS 12 v1.0: Personal Information Exchange Syntax", RSA Laboratories, June 24, 1999.
[PKCS12]“PKCS12V1.0：个人信息交换语法”，RSA实验室，1999年6月24日。
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax Standard", RSA Laboratories, June 2000.
[PKCS15]“PKCS#15 v1.1：加密令牌信息语法标准”，RSA实验室，2000年6月。
[RFC1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol-- HTTP/1.0", RFC 1945, May 1996.
[RFC1945]Berners Lee，T.，Fielding，R.和H.Frystyk，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, L., Leach, M. and T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫格尔，J.，弗莱西克，H.，马斯特，L.，利奇，M.和T.伯纳斯李，“超文本传输协议-HTTP/1.1”，RFC 2616，1999年6月。
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000.
[RFC2945]Wu，T.，“SRP认证和密钥交换系统”，RFC 29452000年9月。
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[RFC3080]Rose，M.，“块可扩展交换协议核心”，RFC 30802001年3月。
[RFC3081] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 2001.
[RFC3081]Rose，M.，“将BEEP核心映射到TCP”，RFC 3081，2001年3月。
[SPEKE] Jablon, D., "Strong Password-Only Authenticated Key Exchange", September 1996.
[SPEKE]Jablon，D.，“仅强密码认证密钥交换”，1996年9月。
Dale Gustafson Future Foundation Inc.
戴尔古斯塔夫森未来基金会
EMail: degustafson@comcast.net
EMail: degustafson@comcast.net
Mike Just Treasury Board of Canada, Secretariat
Mike Just加拿大财政委员会秘书处
EMail: Just.Mike@tbs-sct.gc.ca
EMail: Just.Mike@tbs-sct.gc.ca
Magnus Nystrom RSA Security Inc.
Magnus Nystrom RSA安全公司。
EMail: magnus@rsasecurity.com
EMail: magnus@rsasecurity.com
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编辑功能的资金目前由互联网协会提供。