Network Working Group A. Arsenault
Request for Comments: 3157 Diversinet
Category: Informational S. Farrell
Baltimore Technologies
August 2001
Network Working Group A. Arsenault
Request for Comments: 3157 Diversinet
Category: Informational S. Farrell
Baltimore Technologies
August 2001
Securely Available Credentials - Requirements
安全可用凭证-要求
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
This document describes requirements to be placed on Securely Available Credentials (SACRED) protocols.
本文件描述了安全可用凭证（神圣）协议的要求。
Table Of Contents
目录
1. Introduction.................................................1
2. Framework Requirements.......................................4
3. Protocol Requirements........................................7
4. Security Considerations.....................................10
References.....................................................12
Acknowledgements...............................................12
Authors' Addresses.............................................13
Appendix A: A note on SACRED vs. hardware support..............14
Appendix B: Additional Use Cases...............................14
Full Copyright Statement.......................................20
1. Introduction.................................................1
2. Framework Requirements.......................................4
3. Protocol Requirements........................................7
4. Security Considerations.....................................10
References.....................................................12
Acknowledgements...............................................12
Authors' Addresses.............................................13
Appendix A: A note on SACRED vs. hardware support..............14
Appendix B: Additional Use Cases...............................14
Full Copyright Statement.......................................20
"Credentials" are information that can be used to establish the identity of an entity, or help that entity communicate securely. Credentials include such things as private keys, trusted roots, tickets, or the private part of a Personal Security Environment (PSE) [RFC2510] - that is, information used in secure communication on the Internet. Credentials are used to support various Internet protocols, e.g., S/MIME, IPSec and TLS.
“凭证”是可用于确定实体身份或帮助该实体安全通信的信息。凭证包括私钥、可信根、票证或个人安全环境（PSE）[RFC2510]的私有部分，即在Internet上的安全通信中使用的信息。凭据用于支持各种Internet协议，例如S/MIME、IPSec和TLS。
In simple models, users and other entities (e.g., computers like routers) are provided with credentials, and these credentials stay in one place. However, the number, and more importantly the number of different types, of devices that can be used to access the Internet is increasing. It is now possible to access Internet services and accounts using desktop computers, laptop computers, wireless phones, pagers, personal digital assistants (PDAs) and other types of devices. Further, many users want to access private information and secure services from a number of different devices, and want access to the same information from any device. Similarly credentials may have to be moved between routers when they are upgraded.
在简单的模型中，向用户和其他实体（例如路由器等计算机）提供凭据，并且这些凭据保留在一个位置。然而，可用于访问互联网的设备的数量，更重要的是不同类型的设备的数量正在增加。现在可以使用台式电脑、笔记本电脑、无线电话、寻呼机、个人数字助理（PDA）和其他类型的设备访问互联网服务和帐户。此外，许多用户希望从许多不同的设备访问私有信息和安全服务，并希望从任何设备访问相同的信息。同样，当路由器升级时，可能必须在路由器之间移动凭据。
This document identifies a set of requirements for credential mobility. The Working Group will also produce companion documents, which describe a framework for secure credential mobility, and a set of protocols for accomplishing this goal.
本文件确定了凭证移动的一系列要求。工作组还将编制配套文件，其中描述了安全凭证移动的框架，以及实现这一目标的一组协议。
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“要求”、“应该”、“建议”和“可能”应按照[RFC2119]中的说明进行解释。
In simple models of Internet use, users and other entities are provided with credentials, and these credentials stay in one place. For example, Mimi generates a public and private key on her desktop computer, provides the public key to a Certification Authority (CA) to be included in a certificate, and keeps the private key on her computer. It never has to be moved.
在互联网使用的简单模型中，向用户和其他实体提供凭证，这些凭证保存在一个地方。例如，Mimi在其桌面计算机上生成公钥和私钥，将公钥提供给证书颁发机构（CA）以包含在证书中，并将私钥保留在其计算机上。它永远不需要移动。
However, Mimi may want to able to send signed e-mail messages from her desktop computer when she is in the office, and from her laptop computer when she is on the road, and she does not want message recipients to know the difference. In order to do this, she must somehow make her private key available on both devices - that is, that credential must be moved.
但是，咪咪可能希望在办公室时能从台式电脑发送签名电子邮件，在路上时能从笔记本电脑发送签名电子邮件，她不想让邮件收件人知道两者的区别。为了做到这一点，她必须以某种方式使她的私钥在两台设备上都可用——也就是说，必须移动凭证。
Similarly, Will may want to retrieve and read encrypted e-mail from either his wireless phone or from his two-way pager. He wants to use whichever device he has with him at the moment, and does not want to be denied access to his mail or to be unable to decrypt important messages simply because he has the wrong device. Thus, he must be able to have the same private key available on both devices.
类似地，威尔可能想从他的无线电话或双向寻呼机中检索和读取加密电子邮件。他想使用目前随身携带的任何一种设备，不想因为设备不正确而被拒绝访问邮件或无法解密重要邮件。因此，他必须能够在两台设备上使用相同的私钥。
The following scenario relating to routers has also been offered: "Once upon a time, a router generated a keypair. The administrators transferred the public key of that router to a lot of other (peer) routers and used that router to encrypt traffic to the other routers. And this was good for many years. Then one day, the network
还提供了以下与路由器相关的场景：“从前，一个路由器生成了一个密钥对。管理员将该路由器的公钥传输给许多其他（对等）路由器，并使用该路由器对其他路由器的流量进行加密。这种情况持续了很多年。然后有一天，网络
administrators found that this particular little router couldn't handle an OC-192. So they trashed it and replaced it with a really big router. While they were there, the craft workers inserted a smart card into the router and logged into the router. They gave the appropriate commands and entered the correct answers and so the credentials (keypair) were transferred to the new, big router. Alternatively, the craft people could have logged into the router, given it a minimal configuration and transferred the credentials from a credential server to the router. They had to perform the correct incantations and authentications for the transfer to be successful. In this way, the identity of the router was moved from an old router to a new one. The administrators were glad that they didn't have to edit the configurations of all of the peer routers as well."
管理员发现这个特殊的小路由器无法处理OC-192。所以他们把它扔掉，换成一个很大的路由器。在那里，工艺工人将智能卡插入路由器并登录路由器。他们发出适当的命令并输入正确的答案，因此凭证（密钥对）被传输到新的大型路由器。或者，工艺人员可以登录路由器，给它一个最小的配置，并将凭证从凭证服务器传输到路由器。他们必须执行正确的咒语和认证才能成功转移。通过这种方式，路由器的身份从旧路由器移动到新路由器。管理员很高兴他们不必编辑所有对等路由器的配置。”
It is generally accepted that the private key in these examples must be transferred securely. In the first example, the private key should not be exposed to anyone other than Mimi herself (and ideally, it would not be directly exposed to her). Furthermore, it must be transferred correctly. It must be transferred to the proper device, and it must not be corrupted - improperly modified - during transfer.
一般认为，这些示例中的私钥必须安全地传输。在第一个示例中，私钥不应该暴露给咪咪本人以外的任何人（理想情况下，它不会直接暴露给咪咪本人）。此外，它必须正确传输。必须将其传输到适当的设备，并且在传输过程中不得损坏-不正确地修改。
Making credentials securely available (in an interoperable fashion) will provide substantial value to network owners, administrators, and end users. The intent is that this value be provided largely independent of the hardware device used to access the secure credential and the type of storage medium to which the secure credential is written. Different credential storage devices, (e.g., desktop or laptop PC computer memory, a 3.5 inch flexible diskette, a hard disk file, a cell phone, a smart card, etc.) will have very different security characteristics and, often very different protocol handling capabilities. Using SACRED protocols, users will be able to securely move their credentials between different locations, different Internet devices, and different storage media as needed.
安全地提供凭据（以可互操作的方式）将为网络所有者、管理员和最终用户提供巨大的价值。其目的是，该值的提供在很大程度上独立于用于访问安全凭证的硬件设备和安全凭证写入的存储介质的类型。不同的凭证存储设备（例如，台式机或笔记本电脑内存、3.5英寸软磁盘、硬盘文件、手机、智能卡等）将具有非常不同的安全特性，并且通常具有非常不同的协议处理能力。使用神圣协议，用户将能够根据需要在不同的位置、不同的互联网设备和不同的存储介质之间安全地移动其凭证。
In the remainder of this document we present a set of requirements for the secure transfer of software-based credentials.
在本文档的其余部分中，我们将介绍一组安全传输基于软件的凭据的要求。
The SACRED Working Group is working on the standardization of a set of protocols for securely transferring credentials among devices. A general framework is being developed that will give an abstract definition of protocols which can meet the credential-transfer requirements. This framework will allow for the development of a set of protocols, which may vary from one another in some respects. Specific protocols that conform to the framework can then be developed.
神圣工作组正致力于一组协议的标准化，用于在设备之间安全地传输凭证。目前正在开发一个通用框架，该框架将给出满足凭证传输要求的协议的抽象定义。该框架将允许开发一组协议，这些协议可能在某些方面有所不同。然后可以开发符合该框架的特定协议。
Work is being done on a number of documents. This document identifies the requirements for the general framework, as well as the requirements for specific protocols. Another document will describe the protocol framework. Still others will define the protocols themselves.
目前正在就一些文件开展工作。本文件确定了通用框架的要求以及特定协议的要求。另一份文件将描述协议框架。还有一些人将自己定义协议。
Section 1 of this document provides an introduction to the problem being solved by this working group. Section 2 describes requirements on the framework. Section 3 identifies the overall requirements for secure credential-transfer protocols, and separate requirements for two different classes of solutions. Section 4 identifies Security Considerations. Appendix A describes the relationship of the SACRED solutions and credential-mobility solutions involving hardware components such as smart cards. Appendix B contains some additional scenarios which were considered when developing the requirements.
本文件第1节介绍了本工作组正在解决的问题。第2节描述了对框架的需求。第3节确定了安全凭证传输协议的总体要求，以及两类不同解决方案的单独要求。第4节确定了安全注意事项。附录A描述了神圣解决方案与涉及智能卡等硬件组件的凭证移动解决方案之间的关系。附录B包含了在开发需求时考虑的一些附加场景。
This section describes requirements that the SACRED framework has to meet, as opposed to requirements that are to be met by a specific protocol that uses the framework.
本节描述了神圣框架必须满足的要求，而不是使用该框架的特定协议必须满足的要求。
There are at least two different ways to solve the problem of secure credential transfer between devices. One class of solutions uses a "credential server" as an intermediate node, and the other class provides direct transfer between devices.
至少有两种不同的方法可以解决设备之间安全凭证传输的问题。一类解决方案使用“凭证服务器”作为中间节点，另一类提供设备之间的直接传输。
A "credential server" can be likened to a server that sits in front of a repository where credentials can be securely stored for later retrieval. The credential server is active in the protocol, that is, it implements security enforcing functionality.
“凭证服务器”可以比作位于存储库前面的服务器，凭证可以安全地存储在存储库中以供以后检索。凭证服务器在协议中处于活动状态，即，它实现安全强制功能。
To transfer credentials securely from one end device to another is a straightforward two-step process. Users can have their credentials securely "uploaded" from one device, e.g., a wireless phone, to the credential server. They can be stored on the credential server, and "downloaded" when needed using another device; e.g., a two-way pager.
将凭证从一个终端设备安全地传输到另一个终端设备是一个简单的两步过程。用户可以将其凭据安全地从一个设备（例如，无线电话）“上载”到凭据服务器。它们可以存储在凭证服务器上，并在需要时使用其他设备“下载”；e、 一个双向传呼机。
Some advantages of a credential server approach compared to credential transfer are:
与凭证传输相比，凭证服务器方法的一些优点是：
1. It provides a conceptually clean and straightforward approach. For all end devices, there is one protocol, with a set of actions defined to transfer credentials from the device to the server, and another set of actions defined to transfer credentials from the server to the device. Furthermore, this protocol involves clients (the devices) and a server (the credential server), like many other Internet protocols; thus, the design of this protocol is likely to be familiar to most people familiar with most other Internet protocols.
1. 它提供了一种概念上清晰而直接的方法。对于所有终端设备，都有一个协议，其中定义了一组操作以将凭据从设备传输到服务器，并定义了另一组操作以将凭据从服务器传输到设备。此外，与许多其他互联网协议一样，该协议涉及客户端（设备）和服务器（凭证服务器）；因此，熟悉大多数其他互联网协议的大多数人可能都熟悉该协议的设计。
2. It provides for a place where credentials can be securely stored for arbitrary lengths of time. Given a reasonable-quality server operating under generally accepted practices, it is unlikely the credentials will be permanently lost due to a hardware failure. This contrasts with systems where credentials are only stored on end devices, in which a failure of or the loss of the device could mean that the credentials are lost forever.
2. 它提供了一个可以安全地存储任意时间长度的凭证的位置。如果服务器在公认的实践下运行，质量合理，则不太可能由于硬件故障而永久丢失凭据。这与凭证仅存储在终端设备上的系统形成对比，在终端设备上，设备故障或丢失可能意味着凭证将永远丢失。
3. The credential server may be able to enforce a uniform security policy regarding credential handling. This is particularly the case where credentials are issued by an organization for its own purposes, and are not "created" by the end user, and so must be governed by the policies of the issuer, not the user.
3. 凭证服务器可能能够实施关于凭证处理的统一安全策略。尤其是在以下情况下，凭证由组织为其自身目的颁发，并且不是由最终用户“创建”的，因此必须由颁发者而不是用户的策略管理。
However, the credential server approach has some potential disadvantages, too:
但是，凭据服务器方法也有一些潜在的缺点：
1. It might be somewhat expensive to maintain and run the credential server, particularly if there are stringent requirements on availability and reliability of the server. This is particularly true for servers which are used for a large community of users. When the credential server is intended for a small community, the complexity and cost would be much less.
1. 维护和运行凭证服务器可能会有点昂贵，特别是在对服务器的可用性和可靠性有严格要求的情况下。对于用于大型用户社区的服务器来说尤其如此。当凭证服务器用于小型社区时，复杂性和成本将大大降低。
2. The credential server may have to be "trusted" in some sense and also introduces a point of potential vulnerability. (See the Security Considerations section for some of the issues.) Good protocol and system design will limit the vulnerability that exists at the credential server, but at a minimum, someone with access to the credential server will be able to delete credentials and thus deny the SACRED service to system users.
2. 在某种意义上，凭据服务器可能必须是“受信任的”，并且还引入了一个潜在的漏洞点。（有关某些问题，请参阅安全注意事项部分。）良好的协议和系统设计将限制凭据服务器上存在的漏洞，但至少，有权访问凭据服务器的人将能够删除凭据，从而拒绝向系统用户提供神圣服务。
Thus, some users may prefer a different class of solution, in which credentials are transferred directly from one device to another (i.e., having no intermediary element that processes or has any understanding of the credentials).
因此，一些用户可能更喜欢不同类别的解决方案，其中凭证直接从一个设备传输到另一个设备（即，没有处理凭证或对凭证有任何理解的中间元素）。
For example, consider the case where Mimi sends a message from her wireless phone containing the credentials in question, and retrieves it using her two-way pager. In getting from one place to another, the bits of the message cross the wireless phone network to a base station. These bits are likely transferred over the wired phone network to a message server run by the wireless phone operator, and are transferred from there over the Internet to a message server run by the paging operator. From the paging operator they are transferred to a base station and then finally to Mimi's pager. Certainly, there are devices other than the original wireless phone and ultimate pager that are involved in the credential transfer, in the sense that they transmit bits from one place to another. However, to all devices except the pager and the wireless phone, what is being transferred is an un-interpreted and unprocessed set of bits. No security-related decisions are made, and no actions are taken based on the fact that this message contains credentials, at any of the intermediate nodes. They exist simply to forward bits. Thus, we consider this to be a "direct" transfer of credentials.
例如，考虑Mimi从她的无线电话发送包含所述证书的消息的情况，并使用她的双向寻呼机检索该消息。在从一个地方到另一个地方的过程中，信息的比特通过无线电话网络到达基站。这些比特可能通过有线电话网络传输到无线电话运营商运行的消息服务器，并通过互联网从那里传输到寻呼运营商运行的消息服务器。从寻呼运营商，他们被转移到基站，然后最终到咪咪的寻呼机。当然，除了原始的无线电话和终极寻呼机之外，还有一些设备参与了凭证传输，也就是说，它们将比特从一个地方传输到另一个地方。但是，对于除寻呼机和无线电话以外的所有设备，正在传输的是一组未解释且未经处理的位。在任何中间节点上，都不会做出与安全相关的决策，也不会根据此消息包含凭据这一事实采取任何操作。它们的存在只是为了转发比特。因此，我们认为这是凭证的“直接”转移。
Solutions involving the direct transfer of credentials from one device to another are potentially somewhat more complex than the credential-server approach, owing to the large number of different devices and formats that may have to be supported. Complexity is also added due to the fact that each device may in turn have to exhibit the behavior of both a client and a server.
由于可能需要支持大量不同的设备和格式，涉及将凭据从一个设备直接传输到另一个设备的解决方案可能比凭据服务器方法更复杂。由于每个设备可能必须同时显示客户机和服务器的行为，这也增加了复杂性。
We believe that both classes of solutions are useful in certain environments, and thus that the SACRED framework will have to define solutions for both. The extent to which elements of the above solutions overlap remains to be determined.
我们相信，这两类解决方案在某些环境中都是有用的，因此，神圣的框架必须为这两类解决方案定义解决方案。上述解决方案的要素重叠程度有待确定。
This all leads to our first set of requirements:
这就引出了我们的第一组要求：
F1. The framework MUST support both "credential server" and "direct" solutions. F2. The "credential server" and "direct" solutions SHOULD use the same technology as far as possible.
F1。该框架必须同时支持“凭证服务器”和“直接”解决方案。F2。“凭证服务器”和“直接”解决方案应尽可能使用相同的技术。
There is a wide range of deployment options for credential mobility solutions. In many of these cases, it is useful to be able to re-use an existing user authentication scheme, for example where passwords have previously been established, it may be more secure to re-use these than try to manage a whole new set of passwords. Different devices may also limit the types of user authentication scheme that are possible, e.g., not all mobile devices are practically capable of carrying out asymmetric cryptography.
凭证移动解决方案有多种部署选项。在许多情况下，能够重用现有的用户身份验证方案是很有用的，例如，在以前已建立密码的情况下，重用这些方案可能比尝试管理一组全新的密码更安全。不同设备还可以限制可能的用户认证方案的类型，例如，并非所有移动设备实际上都能够执行非对称加密。
F3. The framework MUST allow for protocols which support different user authentication schemes
F3。该框架必须允许支持不同用户身份验证方案的协议
Today there is no single standard format for credentials and this is not likely to change in the near future. There are a number of fairly widely deployed formats, e.g., [PGP], [PKCS#12] that have to be supported. This means that the framework has to allow for protocols supporting any credential format.
如今，没有单一的凭证标准格式，在不久的将来，这一点不太可能改变。有许多广泛部署的格式，例如[PGP]、[PKCS#12]必须得到支持。这意味着框架必须允许支持任何凭证格式的协议。
F4. The details of the actual credential type or format MUST be opaque to the protocol, though not to processing within the protocol's peers. The protocol MUST NOT depend on the internal structure of any credential type or format.
F4。实际凭证类型或格式的详细信息对协议来说必须是不透明的，但对协议对等方内的处理来说则不然。协议不得依赖于任何凭证类型或格式的内部结构。
Different devices allow for different transport layer possibilities, e.g., current WAP 1.x devices do not support TCP. For this reason the framework has to be transport "agnostic".
不同的设备允许不同的传输层可能性，例如，当前的WAP 1.x设备不支持TCP。因此，该框架必须是运输“不可知论”的。
F5. The framework MUST allow use of different transports.
F5。框架必须允许使用不同的传输。
In this section, we identify the requirements for secure credential-transfer solutions. We will begin by listing a set of relevant vulnerabilities and the requirements that must be met by all solutions. Then we identify additional requirements that must be met by solutions involving a credential server, followed by additional requirements that must be met by solutions involving direct transfer of credentials.
在本节中，我们将确定安全凭证传输解决方案的要求。我们将首先列出一组相关的漏洞和所有解决方案必须满足的要求。然后，我们确定涉及凭证服务器的解决方案必须满足的附加要求，然后是涉及凭证直接传输的解决方案必须满足的附加要求。
This section lists the vulnerabilities against which a SACRED protocol SHOULD offer protection. Any protocol claiming to meet the requirements listed in this document MUST explicitly indicate how (or whether) it offers protection for each of these vulnerabilities.
本节列出了神圣协议应提供保护的漏洞。任何声称满足本文件所列要求的协议必须明确说明其如何（或是否）为每个漏洞提供保护。
V1. A passive attacker can watch all packets on the network and later carry out a dictionary attack. V2. An attacker can attempt to masquerade as a credential server in an attempt to get a client to reveal information on line that allows for a later dictionary attack.
V1。被动攻击者可以监视网络上的所有数据包，然后执行字典攻击。V2。攻击者可以尝试伪装成凭据服务器，试图让客户端在线泄漏信息，从而允许以后的字典攻击。
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). 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). V5. An attacker can copy a credential server's repository and carry out a dictionary attack. 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. V7. An attacker can persuade a server that a successful login has occurred, even if it hasn't. V8. (Upload) An attacker can overwrite someone else's credentials on the server. V9. (When using password-based authentication) An attacker can force a password change to a known (or "weak") password. V10. An attacker can attempt a man-in-the-middle attack for lots V11. User enters password instead of name. V12. An attacker could attempt various denial-of-service attacks.
V3。攻击者可以尝试让客户端解密选定的“密文”，并让客户端使用生成的明文-然后攻击者可以执行字典攻击（例如，如果随机字符串“解密”生成的明文用作DSA私钥）。V4。攻击者可以覆盖存储库条目，这样当用户随后使用他们认为是好的凭证时，他们就会暴露有关其密码的信息（从而暴露“真实”凭证）。V5。攻击者可以复制凭据服务器的存储库并执行字典攻击。V6。攻击者可以试图伪装成客户机，试图让服务器泄露信息，以便稍后进行字典攻击。V7。攻击者可以说服服务器成功登录，即使服务器没有成功登录。V8。（上传）攻击者可以覆盖服务器上其他人的凭据。V9。（使用基于密码的身份验证时）攻击者可以强制将密码更改为已知（或“弱”）密码。V10。攻击者可以尝试中间人攻击第11批。用户输入密码而不是名称。V12。攻击者可能会尝试各种拒绝服务攻击。
Looking again at the examples described in Section 1.1, we can readily see that there are a number of requirements that must apply to the transfer of credentials if the ultimate goal of supporting the Internet security protocols (e.g., TLS, IPSec, S/MIME) is to be met. For example, the credentials must remain confidential at all times; it is unacceptable for nodes other than the end-user's device(s) to see the credentials in any readable, cleartext form.
再次查看第1.1节中描述的示例，我们可以很容易地看到，如果要满足支持Internet安全协议（例如TLS、IPSec、S/MIME）的最终目标，则必须对凭证的传输应用许多要求。例如，证书必须始终保密；对于终端用户设备以外的节点，以任何可读、明文形式查看凭据是不可接受的。
These, then, are the requirements that apply to all secure credential-transfer solutions:
因此，这些要求适用于所有安全凭证传输解决方案：
G1. Credential transfer both to and from a device MUST be supported. G2. Credentials MUST NOT be forced by the protocol to be present in cleartext at any device other than the end user's. G3. The protocol SHOULD ensure that all transferred credentials be authenticated in some way (e.g., digitally signed or MAC-ed). G4. The protocol MUST support a range of cryptographic algorithms, including symmetric and asymmetric algorithms, hash algorithms, and MAC algorithms.
G1。必须支持与设备之间的凭据传输。G2。协议不得强制凭据以明文形式出现在终端用户以外的任何设备上。G3。协议应确保所有传输的凭据都以某种方式进行身份验证（例如，数字签名或MAC加密）。G4。协议必须支持一系列加密算法，包括对称和非对称算法、哈希算法和MAC算法。
G5. The protocol MUST allow the use of various credential types and formats (e.g., X.509, PGP, PKCS12, ...). G6. One mandatory to support credential format MUST be defined. G7. One mandatory to support user authentication scheme MUST be defined. G8. The protocol MAY allow credentials to be labeled with a text handle, (outside the credential), to allow the end user to select amongst a set of credentials or to name a particular credential. G9. Full I18N support is REQUIRED (via UTF8 support) [RFC2277]. G10. It is desirable that the protocol be able to support privacy, that is, anonymity for the client. G11. Transferred credentials MAY incorporate timing information, for example a "time to live" value determining the maximum time for which the credential is to be usable following transfer/download.
G5。协议必须允许使用各种凭证类型和格式（如X.509、PGP、PKCS12等）。G6。必须定义一个支持凭证格式的必填项。七国集团。必须定义一个支持用户身份验证方案的必填项。八国集团。协议可允许使用文本句柄（在凭证外部）标记凭证，以允许最终用户在一组凭证中进行选择或命名特定凭证。G9。需要完全的I18N支持（通过UTF8支持）[RFC2277]。G10。希望该协议能够支持隐私，即客户端的匿名性。G11。传输的凭证可以包括定时信息，例如“生存时间”值，该值确定凭证在传输/下载之后可用的最长时间。
The following requirements assume that there is a credential server from which credentials are downloaded to the end user device, and to which credentials are uploaded from an end user device.
以下要求假设存在凭证服务器，凭证从该服务器下载到最终用户设备，凭证从最终用户设备上载到该服务器。
S1. Credential downloads (to an end user) and upload (to the credential server) MUST be supported. S2. Credentials MUST only be downloadable following user authentication or else only downloaded in a format that requires completion of user authentication for deciphering. S3. It MUST be possible to ensure the authenticity of a credential during upload. S4. Different end user devices MAY be used to download/upload/manage the same set of credentials. S5. Credential servers SHOULD be authenticated to the user for all operations except download. Note: This requirement can be ignored if the credential format itself is strongly protected, as there is no risk (other than user confusion) from an unauthenticated credential server. S6. It SHOULD be possible to authenticate the credential server to the user as part of a download operation. S7. The user SHOULD only have to enter a single secret value in order to download and use a credential. S8. Sharing of secrets across multiple servers MAY be possible, so that penetration of some servers does not expose the private parts of a credential ("m-from-n" operation). S9. The protocol MAY support "away-from-home" operation, where the user enters both a name and a domain (e.g. RoamingStephen@baltimore.ie) and the domain can be used in order to locate the user's credential server.
S1。必须支持凭据下载（到最终用户）和上载（到凭据服务器）。S2。凭据只能在用户身份验证后下载，或者只能以需要完成用户身份验证才能解密的格式下载。S3。上传过程中必须能够确保凭证的真实性。S4。不同的最终用户设备可用于下载/上传/管理同一组凭证。S5。对于除下载之外的所有操作，应向用户验证凭据服务器。注意：如果凭证格式本身受到严格保护，则可以忽略此要求，因为未经验证的凭证服务器没有风险（用户混淆除外）。中六。作为下载操作的一部分，应该可以向用户验证凭据服务器。S7。用户只需输入一个密钥值即可下载和使用凭证。S8。跨多个服务器共享机密是可能的，因此某些服务器的渗透不会暴露凭证的私有部分（“m-from-n”操作）。S9。协议可能支持“离家”操作，其中用户输入名称和域（例如。RoamingStephen@baltimore.ie)并且可以使用域来定位用户的凭据服务器。
S10. The protocol MUST provide operations allowing users to manage their credentials stored on the credential server, e.g., to retrieve a list of their credentials stored on a server; add credentials to the server; delete credentials from the server. S11. Client-initiated authentication information (e.g., password) change MUST be supported. S12. The user SHOULD be able to retrieve a list of accesses/changes to their credentials. S13. The protocol MUST support user self-enrollment. One scenario calling for this is where a previously unknown user uploads his credential without requiring manual operator intervention. S14. The protocol MUST NOT prevent bulk initializing of a credential server's repository. S15. The protocol SHOULD require minimal client configuration.
S10。协议必须提供允许用户管理存储在凭证服务器上的凭证的操作，例如，检索存储在服务器上的凭证列表；向服务器添加凭据；从服务器上删除凭据。S11。必须支持客户端发起的身份验证信息（如密码）更改。S12。用户应该能够检索对其凭据的访问/更改列表。S13。协议必须支持用户自注册。其中一种情况是以前未知的用户在不需要操作员手动干预的情况下上传其凭证。S14。协议不得阻止凭据服务器存储库的批量初始化。S15。协议应要求最少的客户端配置。
The full set of requirements for this case has not been elucidated, and this list is therefore provisional. An additional requirements document (or a modification of this one) will be required prior to progression of a direct-transfer protocol.
本案例的全部要求尚未阐明，因此本清单为暂定清单。在制定直接传输协议之前，需要一份附加要求文件（或对该文件的修改）。
The following requirements apply to solutions supporting the "direct" transfer of credentials from one device to another. (See Section 2 for the note on the meaning of "direct" in this case.)
以下要求适用于支持凭证从一个设备“直接”传输到另一个设备的解决方案。（关于本例中“直接”含义的注释，请参见第2节。）
D1. It SHOULD be possible for the receiving device to authenticate that the credential package indeed came from the purported sending device. D2. In order for a sender to know that a credential has been received by a recipient, it SHOULD be possible for the receiving device to send an acknowledgment of credential receipt back to the sending device, and for the sending device to authenticate this acknowledgment.
D1。接收设备应该能够验证凭证包是否确实来自声称的发送设备。D2。为了让发送方知道接收方已接收到凭证，接收设备应该可以将凭证接收确认发送回发送设备，并且发送设备可以验证该确认。
Mobile credentials will never be as secure as a "pure" hardware-based solution, because of potential attacks through the operating system of the end-user device. However, an acceptable level of security may be accomplished through some simple means. In fact the level of security may be improved (compared to password encrypted files) through the use of SACRED protocols.
由于最终用户设备的操作系统存在潜在的攻击，移动凭据永远不会像“纯”基于硬件的解决方案那样安全。但是，可以通过一些简单的方法实现可接受的安全级别。事实上，通过使用神圣协议，可以提高安全级别（与密码加密文件相比）。
The platforms to which credentials are downloaded usually cannot be regarded as tamper-resistant, and it therefore is not too hard to analyze contents of their memories. Further, storage of private keys, even if they are encrypted, on a credential server, will be unacceptable in some environments. Lastly, replacement of installed or downloaded SACRED client software with a Trojan horse program will always be possible, such a program could email the username and password to the program's author.
下载凭证的平台通常不能被认为是防篡改的，因此分析其存储器的内容并不太困难。此外，在某些环境中，在凭证服务器上存储私钥（即使已加密）是不可接受的。最后，用特洛伊木马程序替换已安装或下载的神圣客户端软件始终是可能的，这样的程序可以通过电子邮件将用户名和密码发送给程序的作者。
Although out of scope of the SACRED protocol development work, implementations should carefully audit events that may be security relevant. In particular credential server implementations should audit all operations and should include information about the time and source (e.g., IP address) of the operation, the claimed identity of the client (possibly masked - see below), the type and result of the operation and possibly other operation specific information. Implementations should also take care not to include security sensitive information in the audit trail, especially not sensitive authentication information.
虽然超出了神圣协议开发工作的范围，但实现应该仔细审核可能与安全相关的事件。特别是，凭据服务器实施应审核所有操作，并应包括有关操作的时间和来源（例如，IP地址）、客户机的声明身份（可能被屏蔽-见下文）、操作的类型和结果以及可能的其他操作特定信息的信息。实现还应注意不要在审计跟踪中包含安全敏感信息，尤其是不敏感的身份验证信息。
It may be sensible to mask the claimed identity in some way in order to ensure that even if a user enters her password in a "username" field, that that information is not in clear in the audit trail, regardless of whether or not it was received in clear.
为了确保即使用户在“用户名”字段中输入密码，该信息在审计跟踪中也不是清晰的，无论是否以清晰的方式接收，以某种方式屏蔽声明的身份可能是明智的。
Similar mechanisms which should be supported, but which are out of scope of protocol development include alerts and account locking, in particular following repeated authentication failures.
应该支持但不在协议开发范围内的类似机制包括警报和帐户锁定，特别是在多次身份验证失败之后。
Credential servers are major targets. Someone who can successfully attack a credential server might be able to gain access to the credentials of a number of users, unless those credentials are sufficiently protected (e.g., encrypted sufficiently that they cannot be read or used by someone who gains access to them). Attackers might also be able to substitute credentials of users, to carry out other system attacks (e.g., an attacker could provide a user with a "trusted root" credential that the attacker controls, which would later allow the attacker to have some other certificate accepted by the user counter to policy).
凭证服务器是主要目标。能够成功攻击凭据服务器的人可能能够访问多个用户的凭据，除非这些凭据得到充分保护（例如，充分加密，使获得访问权限的人无法读取或使用）。攻击者还可以替换用户的凭据，以执行其他系统攻击（例如，攻击者可以向用户提供由攻击者控制的“受信任的根”凭据，这将允许攻击者获得用户接受的其他证书以对抗策略）。
In addition, a credential server is a major target for denial of service attacks. Ensuring that a credential server is unavailable to legitimate users can be of great assistance to attackers. Users who were not able to retrieve needed credentials might be forced to
此外，凭据服务器是拒绝服务攻击的主要目标。确保合法用户无法使用凭据服务器对攻击者有很大帮助。无法检索所需凭据的用户可能会被迫
operate insecurely, or not operate at all. Credential servers are especially vulnerable to denial of service attacks if they do lots of expensive cryptographic operations - it might not take very many operations for the attacker to bring service to an unacceptable level.
操作不安全，或根本不操作。如果凭据服务器执行大量昂贵的加密操作，则它们尤其容易受到拒绝服务攻击—攻击者可能不需要很多操作就能将服务提升到不可接受的水平。
Thus, great care should be taken in designing systems that use credential servers to protect against these attacks.
因此，在设计使用凭证服务器来抵御这些攻击的系统时，应该非常小心。
References
工具书类
[PGP] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[PGP]Callas，J.，Donnerhacke，L.，Finney，H.和R.Thayer，“OpenPGP消息格式”，RFC 24401998年11月。
[PKCS12] "PKCS #12 v1.0: Personal Information Exchange Syntax Standard", RSA Laboratories, June 24, 1999.
[PKCS12]“PKCS#12 v1.0：个人信息交换语法标准”，RSA实验室，1999年6月24日。
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS]Housley，R.，“加密消息语法”，RFC 2630，1999年6月。
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax Standard," RSA Laboratories, June 2000.
[PKCS15]“PKCS#15 v1.1：加密令牌信息语法标准”，RSA实验室，2000年6月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[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月。
[RFC2277] Alvestrand, H., " IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277]Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure Certificate Management Protocols", RFC 2510, March 1999.
[RFC2510]Adams，C.和S.Farrell，“互联网X.509公钥基础设施证书管理协议”，RFC25101999年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱西克，H.，马斯特，L.，利奇，P.和T.伯纳斯李，“超文本传输协议-HTTP/1.1”，RFC 2616，1999年6月。
Acknowledgements
致谢
The authors gratefully acknowledge the text containing additional use cases in Appendix B that was supplied by Neal Mc Burnett (nealmcb@avaya.com).
作者感谢Neal Mc Burnett提供的附录B中包含额外用例的文本(nealmcb@avaya.com).
Authors' Addresses
作者地址
Alfred Arsenault Diversinet Corp. P.O. Box 6530 Ellicott City, MD 21042 USA
美国马里兰州埃利科特市艾尔弗雷德·阿塞诺·迪维斯内特公司邮政信箱6530号，邮编21042
Phone: +1 410-480-2052
EMail: aarsenault@dvnet.com
Phone: +1 410-480-2052
EMail: aarsenault@dvnet.com
Stephen Farrell, Baltimore Technologies, 39 Parkgate Street, Dublin 8, IRELAND
斯蒂芬·法雷尔，爱尔兰都柏林8号帕克盖特街39号巴尔的摩科技公司
Phone: +353-1-881-6000
EMail: stephen.farrell@baltimore.ie
Phone: +353-1-881-6000
EMail: stephen.farrell@baltimore.ie
Appendix A: A note on SACRED vs. hardware support.
附录A：关于神圣与硬件支持的说明。
One way of accomplishing many of the goals of the SACRED WG is to put the credentials on hardware tokens - e.g., smart cards, PCMCIA cards, or other devices. There are a number of types of hardware tokens today that provide secure storage for sensitive information, some degree of authentication, and interfaces to a number of types of wireless and other devices. Thus, in the second example from section 1.1, Will could simply put his private key on a smart card, always take the smart card with him, and be assured that whichever device he uses to retrieve his e-mail, he will have all of the information necessary to decrypt and read messages.
实现神圣工作组许多目标的一种方法是将凭证放在硬件令牌上，例如智能卡、PCMCIA卡或其他设备。目前有多种类型的硬件令牌，可为敏感信息提供安全存储、某种程度的身份验证以及与多种类型的无线和其他设备的接口。因此，在第1.1节的第二个示例中，威尔可以简单地将他的私钥放在智能卡上，始终随身携带智能卡，并确保无论他使用哪种设备检索他的电子邮件，他都将拥有解密和阅读邮件所需的所有信息。
However, hardware tokens are not appropriate for every environment. They cost more than software-only solutions, and the additional security they provide may or may not be worth the incremental cost. Not all devices have interfaces for the same hardware tokens. And hardware tokens are subject to different failure modes than typical computers - it is not at all unusual for a smart card to be lost or stolen; or for a PCMCIA card to physically break.
但是，硬件令牌并不适用于所有环境。它们的成本高于纯软件解决方案，它们提供的额外安全性可能值得，也可能不值得增加成本。并非所有设备都具有相同硬件令牌的接口。硬件代币的故障模式与典型计算机不同——智能卡丢失或被盗并不罕见；或PCMCIA卡发生物理损坏。
Thus, it is appropriate to develop complementary software-based solution that allows credentials to be moved from one device to another, and provides a level of security sufficient for its environments. While we recognize that the level of security provided by a software solution may not be as high as that provided by the hardware solutions discussed above, and some organizations may not consider it sufficient at all, we believe that a worthwhile solution can be developed.
因此，开发基于软件的补充解决方案是合适的，该解决方案允许凭证从一个设备移动到另一个设备，并为其环境提供足够的安全级别。虽然我们认识到，软件解决方案提供的安全级别可能没有上面讨论的硬件解决方案所提供的那么高，但是一些组织可能根本不认为它是足够的，我们相信可以开发出一个有价值的解决方案。
Finally, SACRED protocols can also complement hardware credential solutions by providing standard mechanisms for the update of credentials which are stored on the hardware device. Today, this often requires returning (with) the device to an administrative centre, which is often inconvenient and may be costly. SACRED protocols provide a way to update and manage credentials stored on hardware devices without requiring such physical presence.
最后，神圣协议还可以通过提供用于更新存储在硬件设备上的凭据的标准机制来补充硬件凭据解决方案。如今，这通常需要将设备返回管理中心，这通常不方便，而且可能成本高昂。神圣协议提供了一种更新和管理存储在硬件设备上的凭据的方法，而不需要这种物理存在。
Appendix B: Additional Use Cases
附录B：附加用例
This appendix describes some additional use cases for SACRED protocols. SACRED protocols are NOT REQUIRED to support all these use cases, that is, this text is purely informative.
本附录描述了神圣协议的一些附加用例。神圣的协议不需要支持所有这些用例，也就是说，本文仅提供信息。
Scenario Overview
情景概述
A university utilizing a PKI for various applications and services on-campus is likely to find that many of its users would like to make use of the same PKI-enabled services and applications on computers located in their residence. These home computers may be owned either by the university or by the individual but are permanently located at the residence as opposed to laptop systems that may be taken home. The usage depicted in this scenario may be motivated by formal telecommuting arrangements or simply by the need to catch up on work from home in the evenings. The basic scenario should apply equally well to the commercial, health care, and higher education environments.
将PKI用于校园内各种应用程序和服务的大学可能会发现，其许多用户希望在其住所的计算机上使用相同的PKI支持的服务和应用程序。这些家庭电脑可能由大学或个人所有，但与可带回家的笔记本电脑系统不同，它们永久位于住所。本场景中描述的使用可能是由于正式的远程办公安排，或者仅仅是因为晚上需要在家赶时间。基本情景应该同样适用于商业、医疗和高等教育环境。
Assumptions
假设
This scenario assumes that the institution has not implemented a hardware token-based PKI mobility solution
该场景假设该机构尚未实施基于硬件令牌的PKI移动解决方案
The home computer has a dial-up as opposed to a permanent network connection.
家庭计算机具有拨号连接，而不是永久性网络连接。
The PKI applications, whenever practical, should be functional in both on-line and off-line modes. For example, the home user signing an email message to be queued for later bulk sending and the reading of a received encrypted message may be supported off-line while composing and queuing of an encrypted message might not be supported in off-line mode.
只要可行，PKI应用程序应能在在线和离线模式下运行。例如，在离线模式下可能不支持撰写和排队加密消息，而在离线模式下可能不支持对电子邮件消息进行签名以排队等待稍后的批量发送和读取接收到的加密消息。
Applications using digital signatures may require "non-repudiation".
使用数字签名的应用程序可能需要“不可否认性”。
The institution prefers that the user be identified via a single certificate / key-pair from all computers used by the individual.
该机构倾向于通过个人使用的所有计算机的单一证书/密钥对来识别用户。
The home computer system can not be directly supported by the institution's IT staff. Hardware, operating system versions, and operating system configurations will vary widely. Significant software installation or specialized configurations will be difficult to implement.
家庭计算机系统不能直接由该机构的IT人员支持。硬件、操作系统版本和操作系统配置将大不相同。重要的软件安装或专用配置将难以实施。
Uniqueness of Scenario
情景的唯一性
vThe PKI mobility support needed for this scenario is, in general, similar to the other mobility scenarios. However, it does have several unique aspects:
v该场景所需的PKI移动支持通常与其他移动场景类似。然而，它确实有几个独特的方面：
1. The home-user scenario differs from the general public workstation case in that it provides the opportunity to permanently store the user's certificate and key-pair on the workstation.
1. 家庭用户场景不同于一般的公共工作站场景，因为它提供了在工作站上永久存储用户证书和密钥对的机会。
2. Likewise the appropriate CA certificates and even certificates for other users can be permanently stored or cached on the home workstation.
2. 同样，适当的CA证书甚至其他用户的证书也可以永久存储或缓存在家庭工作站上。
3. Another key difference is the need to support off-line use of the PKI credentials given the assumed dial-up network connection.
3. 另一个关键区别是，在假定拨号网络连接的情况下，需要支持离线使用PKI凭据。
4. The level of hardware and software platform consistency (operating system versions and configurations) will vary widely.
4. 硬件和软件平台的一致性水平（操作系统版本和配置）将大不相同。
5. Finally, the level of available technical support is significantly less for home systems than for equivalent systems managed by the IT staff at the office location.
5. 最后，家庭系统的可用技术支持水平明显低于办公室IT人员管理的同等系统。
Scenario Overview
情景概述
Many colleges and universities operate labs full of computer systems that are available for use by the general student population. These computers are typically configured with identical hardware and an operating system build that is replicated to all of the systems in the lab. Many typical configurations provide no permanent storage of any type while others may offer individual disk space for personal files on a central server. Some scheme is generally used to ensure that the configuration of the operating system is preserved across users and that temporary files created by one user are removed before the next user logs in. Students generally sit down at the next available workstation without any clear pattern of usage.
许多学院和大学的实验室里都有供普通学生使用的计算机系统。这些计算机通常配置相同的硬件和复制到实验室所有系统的操作系统版本。许多典型配置不提供任何类型的永久存储，而其他配置可能为中央服务器上的个人文件提供单独的磁盘空间。某些方案通常用于确保跨用户保留操作系统的配置，并确保在下一个用户登录之前删除一个用户创建的临时文件。学生通常坐在下一个可用的工作站上，没有任何明确的使用模式。
The same basic technical solutions used to operate public labs are often also used in general environments where several people share a single workstation. This is often found in locations with shift work such as medical facilities and service bureaus that provide services to multiple time zones.
用于操作公共实验室的基本技术解决方案也经常用于多人共享一个工作站的一般环境。这种情况经常出现在轮班工作的地方，如医疗设施和服务局，它们向多个时区提供服务。
Assumptions
假设
1. This scenario assumes that the institution has not implemented a hardware token-based PKI mobility solution.
1. 该场景假设该机构尚未实施基于硬件令牌的PKI移动解决方案。
2. The computer systems are permanently networked with LAN connections.
2. 计算机系统通过局域网连接永久联网。
3. The configuration of the computer system is centrally maintained and customizations are relatively easy to implement. For example it would be easy to load enterprise root certificates, LDAP server configurations, specialized software, and any other needed components of the PKI on to the workstations.
3. 计算机系统的配置集中维护，定制相对容易实现。例如，将企业根证书、LDAP服务器配置、专用软件和任何其他需要的PKI组件加载到工作站上是很容易的。
4. Applications using digital signatures may require "non-repudiation" in some of the anticipated environments. Examples of this might include homework submission in a public lab environment or medical records in a health care environment.
4. 在某些预期环境中，使用数字签名的应用程序可能需要“不可否认性”。这方面的例子可能包括在公共实验室环境中提交家庭作业或在医疗保健环境中提交医疗记录。
5. The institution prefers that the user be identified via a single certificate / key-pair from all computers used by the individual.
5. 该机构倾向于通过个人使用的所有计算机的单一证书/密钥对来识别用户。
6. Many anticipated implementations of this scenario will not implement any user authentication at the desktop operating system level. Instead, user authentication will occur at during the startup of networked applications such as email, web-based services, etc. Login at the desktop level may be with generic user names that are more targeted at matching printouts to machines than identifying users.
6. 此场景的许多预期实现不会在桌面操作系统级别实现任何用户身份验证。相反，用户身份验证将在网络应用程序（如电子邮件、基于web的服务等）启动期间进行。桌面级别的登录可能使用通用用户名，该用户名更倾向于将打印输出与计算机匹配，而不是识别用户。
7. Users, with almost ridiculous frequency, will walk away from a system forgetting to first logout from running authenticated applications.
7. 用户会以近乎荒谬的频率离开系统，忘记在运行经过身份验证的应用程序时首先注销。
Uniqueness of Scenario
情景的唯一性
The PKI mobility support needed for this scenario is, in general, similar to the other mobility scenarios. However, it does have several unique aspects:
该场景所需的PKI移动支持通常与其他移动场景类似。然而，它确实有几个独特的方面：
1. Unlike situations with personal workstations, there is no permanent storage available to hold user key pairs and certificates.
1. 与个人工作站的情况不同，没有可用于保存用户密钥对和证书的永久存储。
2. Appropriate CA certificates and custom software are easily added and maintained for these types of shared systems.
2. 对于这些类型的共享系统，可以轻松添加和维护适当的CA证书和自定义软件。
3. The workstations are installed in public locations and users will frequently forget to close applications before permanently walking away from the workstation.
3. 工作站安装在公共场所，用户经常会忘记关闭应用程序，然后永久离开工作站。
Overview
概述
This scenario describes the needs of the traveler or the shopper. This person is traveling light (no computer) or is burdened with everything but a computer. It recognizes the increasing availability of Internet access points in public spaces, such as libraries, airports, shopping malls, and "cyber cafes".
此场景描述了旅行者或购物者的需求。这个人是轻装旅行（没有电脑），或者除了电脑之外什么都有。它认识到，图书馆、机场、购物中心和“网吧”等公共场所的互联网接入点越来越多。
The Need
需要
In our increasingly mobile society, the chances of needing information when away from the normal computing place are great. One may need to look up a telephone number. Have you tried to find a phone book at a public phone lately? It may become necessary to use a data device to find the next place to rush to. With the proliferation of wireless devices (electronic leashes), others have the ability to create a need for quick access to electronic information. A pager can generate a need to check the email inbox or address book. A cell phone can drive you to your database to answer a pressing question.
在我们日益移动的社会中，离开正常的计算场所需要信息的机会很大。你可能需要查一个电话号码。你最近有没有试过在公用电话上找电话簿？可能需要使用数据设备来找到下一个要赶往的地方。随着无线设备（电子皮带）的普及，其他设备也有能力快速获取电子信息。寻呼机可以产生查看电子邮件收件箱或通讯簿的需求。手机可以驱动你去数据库回答一个紧迫的问题。
The ability to quickly access sensitive or protected information or services from publicly available devices will only become more necessary as we become more and more "connected".
随着我们越来越“联网”，从公共可用设备快速访问敏感或受保护的信息或服务的能力只会变得越来越必要。
The Device
装置
The access device is more a function of the best discount or marketing effort than of design. Any number of hardware platforms will be encountered.
接入设备与其说是设计的功能，不如说是最佳折扣或营销的功能。将遇到任意数量的硬件平台。
Since these devices are open to the public I/O ports are not likely to be. In order to protect the device and its immediate network environment, most devices will be in some sort of protective container. Access to serial, parallel, USB, firewire, SCSI, or PCMCIA connections will not be possible. Likewise floppy, zip, or CD drives. Therefore, any software "token" must be obtained from the network itself.
由于这些设备对公共开放，因此不太可能使用I/O端口。为了保护设备及其直接的网络环境，大多数设备将放在某种保护容器中。无法访问串行、并行、USB、firewire、SCSI或PCMCIA连接。同样，软盘、zip或CD驱动器也是如此。因此，任何软件“令牌”都必须从网络本身获得。
The Concerns
关注点
1. Getting the "token". Since it will be necessary to obtain the token (key, certificate, credential) from across the network. How can it be protected during transit?
1. 获取“令牌”。因为需要通过网络获取令牌（密钥、证书、凭证）。如何在运输过程中对其进行保护？
2. Where did you get it? One of the primary controls in PKI is protection of the private key. Placing the key on a host that is accessible from a public network means that there is an inherent exposure from that network. The access controls and other security measures on the host machine are an area of concern.
2. 你从哪儿弄来的？PKI中的主要控制之一是保护私钥。将密钥放置在可从公共网络访问的主机上意味着存在来自该网络的固有暴露。主机上的访问控制和其他安全措施是一个值得关注的领域。
3. How did you get it? When you obtained the token from the server, how did it know that you are you? Authentication becomes critical.
3. 你是怎么得到的？当您从服务器获得令牌时，它如何知道您是您？身份验证变得至关重要。
4. What happens to the token when you leave? You've checked your mail, downloaded a recipe from that super-secure recipe server, found out how to get to the adult beverage store for the... uh... accessories... for the meal, and you're off! Is your token? Or is it still sitting there on the public kiosk waiting for those youngsters coming out of the music store to notice and cruise the information highway on your ticket?
4. 当你离开时，代币会发生什么变化？你已经检查了你的邮件，从超级安全的配方服务器下载了一份配方，找到了如何去成人饮料店购买。。。UH配件。。。去吃饭，你就走了！这是你的代币吗？或者它仍然坐在公共信息亭上，等待那些从音乐商店出来的年轻人注意到并用你的票在信息高速公路上巡游？
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。