Network Working Group M. Nystroem
Request for Comments: 4758 RSA Security
Category: Informational November 2006
Network Working Group M. Nystroem
Request for Comments: 4758 RSA Security
Category: Informational November 2006
Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 Revision 1
加密令牌密钥初始化协议（CT-KIP）1.0版第1版
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 IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
This document constitutes Revision 1 of Cryptographic Token Key Initialization Protocol (CT-KIP) Version 1.0 from RSA Laboratories' One-Time Password Specifications (OTPS) series. The body of this document, except for the intellectual property considerations section, is taken from the CT-KIP Version 1.0 document, but comments received during the IETF review are reflected; hence, the status of a revised version. As no "bits-on-the-wire" have changed, the protocol specified herein is compatible with CT-KIP Version 1.0.
本文档构成RSA Laboratories一次性密码规范（OTPS）系列的加密令牌密钥初始化协议（CT-KIP）1.0版的第1版。除知识产权考虑部分外，本文件正文摘自CT-KIP 1.0版文件，但反映了IETF审查期间收到的意见；因此，修订版本的状态为。由于“线路上的位”没有改变，因此本文规定的协议与CT-KIP版本1.0兼容。
CT-KIP is a client-server protocol for initialization (and configuration) of cryptographic tokens. The protocol requires neither private-key capabilities in the cryptographic tokens, nor an established public-key infrastructure. Provisioned (or generated) secrets will only be available to the server and the cryptographic token itself.
CT-KIP是用于加密令牌初始化（和配置）的客户机-服务器协议。该协议既不需要加密令牌中的私钥功能，也不需要已建立的公钥基础设施。提供的（或生成的）机密将仅对服务器和加密令牌本身可用。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Background .................................................4
1.3. Document Organization ......................................5
2. Acronyms and Notation ...........................................5
2.1. Acronyms ...................................................5
2.2. Notation ...................................................5
3. CT-KIP ..........................................................6
3.1. Overview ...................................................6
3.2. Entities ...................................................7
3.3. Principles of Operation ....................................7
3.4. The CT-KIP One-Way Pseudorandom Function, CT-KIP-PRF ......10
3.4.1. Introduction .......................................10
3.4.2. Declaration ........................................11
3.5. Generation of Cryptographic Keys for Tokens ...............11
3.6. Encryption of Pseudorandom Nonces Sent from the
CT-KIP Client .............................................12
3.7. CT-KIP Schema Basics ......................................13
3.7.1. Introduction .......................................13
3.7.2. General XML Schema Requirements ....................13
3.7.3. The AbstractRequestType Type .......................13
3.7.4. The AbstractResponseType type ......................14
3.7.5. The StatusCode Type ................................14
3.7.6. The IdentifierType Type ............................16
3.7.7. The NonceType Type .................................16
3.7.8. The ExtensionsType and the
AbstractExtensionType Types ........................17
3.8. CT-KIP Messages ...........................................17
3.8.1. Introduction .......................................17
3.8.2. CT-KIP Initialization ..............................17
3.8.3. The CT-KIP Client's Initial PDU ....................18
3.8.4. The CT-KIP server's initial PDU ....................20
3.8.5. The CT-KIP Client's Second PDU .....................23
3.8.6. The CT-KIP Server's Final PDU ......................24
3.9. Protocol Extensions .......................................27
3.9.1. The ClientInfoType Type ............................27
3.9.2. The ServerInfoType Type ............................28
3.9.3. The OTPKeyConfigurationDataType Type ...............28
4. Protocol Bindings ..............................................29
4.1. General Requirement .......................................29
4.2. HTTP/1.1 binding for CT-KIP ...............................29
4.2.1. Introduction .......................................29
4.2.2. Identification of CT-KIP Messages ..................29
4.2.3. HTTP Headers .......................................29
4.2.4. HTTP Operations ....................................30
4.2.5. HTTP Status Codes ..................................30
1. Introduction ....................................................4
1.1. Scope ......................................................4
1.2. Background .................................................4
1.3. Document Organization ......................................5
2. Acronyms and Notation ...........................................5
2.1. Acronyms ...................................................5
2.2. Notation ...................................................5
3. CT-KIP ..........................................................6
3.1. Overview ...................................................6
3.2. Entities ...................................................7
3.3. Principles of Operation ....................................7
3.4. The CT-KIP One-Way Pseudorandom Function, CT-KIP-PRF ......10
3.4.1. Introduction .......................................10
3.4.2. Declaration ........................................11
3.5. Generation of Cryptographic Keys for Tokens ...............11
3.6. Encryption of Pseudorandom Nonces Sent from the
CT-KIP Client .............................................12
3.7. CT-KIP Schema Basics ......................................13
3.7.1. Introduction .......................................13
3.7.2. General XML Schema Requirements ....................13
3.7.3. The AbstractRequestType Type .......................13
3.7.4. The AbstractResponseType type ......................14
3.7.5. The StatusCode Type ................................14
3.7.6. The IdentifierType Type ............................16
3.7.7. The NonceType Type .................................16
3.7.8. The ExtensionsType and the
AbstractExtensionType Types ........................17
3.8. CT-KIP Messages ...........................................17
3.8.1. Introduction .......................................17
3.8.2. CT-KIP Initialization ..............................17
3.8.3. The CT-KIP Client's Initial PDU ....................18
3.8.4. The CT-KIP server's initial PDU ....................20
3.8.5. The CT-KIP Client's Second PDU .....................23
3.8.6. The CT-KIP Server's Final PDU ......................24
3.9. Protocol Extensions .......................................27
3.9.1. The ClientInfoType Type ............................27
3.9.2. The ServerInfoType Type ............................28
3.9.3. The OTPKeyConfigurationDataType Type ...............28
4. Protocol Bindings ..............................................29
4.1. General Requirement .......................................29
4.2. HTTP/1.1 binding for CT-KIP ...............................29
4.2.1. Introduction .......................................29
4.2.2. Identification of CT-KIP Messages ..................29
4.2.3. HTTP Headers .......................................29
4.2.4. HTTP Operations ....................................30
4.2.5. HTTP Status Codes ..................................30
4.2.6. HTTP Authentication ................................31
4.2.7. Initialization of CT-KIP ...........................31
4.2.8. Example Messages ...................................31
5. Security considerations ........................................32
5.1. General ...................................................32
5.2. Active Attacks ............................................32
5.2.1. Introduction .......................................32
5.2.2. Message Modifications ..............................32
5.2.3. Message Deletion ...................................34
5.2.4. Message Insertion ..................................34
5.2.5. Message Replay .....................................34
5.2.6. Message Reordering .................................35
5.2.7. Man in the Middle ..................................35
5.3. Passive Attacks ...........................................35
5.4. Cryptographic Attacks .....................................35
5.5. Attacks on the Interaction between CT-KIP and User
Authentication ............................................36
6. Intellectual Property Considerations ...........................36
7. References .....................................................37
7.1. Normative References ......................................37
7.2. Informative References ....................................37
Appendix A. CT-KIP Schema .........................................39
Appendix B. Examples of CT-KIP Messages ...........................46
B.1. Introduction ..............................................46
B.2. Example of a CT-KIP Initialization (Trigger) Message ......46
B.3. Example of a <ClientHello> Message ........................46
B.4. Example of a <ServerHello> Message ........................47
B.5. Example of a <ClientNonce> Message ........................47
B.6. Example of a <ServerFinished> Message .....................48
Appendix C. Integration with PKCS #11 .............................48
Appendix D. Example CT-KIP-PRF Realizations .......................48
D.1. Introduction ..............................................48
D.2. CT-KIP-PRF-AES ............................................48
D.2.1. Identification .....................................48
D.2.2. Definition .........................................49
D.2.3. Example ............................................50
D.3. CT-KIP-PRF-SHA256 .........................................50
D.3.1. Identification .....................................50
D.3.2. Definition .........................................51
D.3.3. Example ............................................52
Appendix E. About OTPS ............................................53
4.2.6. HTTP Authentication ................................31
4.2.7. Initialization of CT-KIP ...........................31
4.2.8. Example Messages ...................................31
5. Security considerations ........................................32
5.1. General ...................................................32
5.2. Active Attacks ............................................32
5.2.1. Introduction .......................................32
5.2.2. Message Modifications ..............................32
5.2.3. Message Deletion ...................................34
5.2.4. Message Insertion ..................................34
5.2.5. Message Replay .....................................34
5.2.6. Message Reordering .................................35
5.2.7. Man in the Middle ..................................35
5.3. Passive Attacks ...........................................35
5.4. Cryptographic Attacks .....................................35
5.5. Attacks on the Interaction between CT-KIP and User
Authentication ............................................36
6. Intellectual Property Considerations ...........................36
7. References .....................................................37
7.1. Normative References ......................................37
7.2. Informative References ....................................37
Appendix A. CT-KIP Schema .........................................39
Appendix B. Examples of CT-KIP Messages ...........................46
B.1. Introduction ..............................................46
B.2. Example of a CT-KIP Initialization (Trigger) Message ......46
B.3. Example of a <ClientHello> Message ........................46
B.4. Example of a <ServerHello> Message ........................47
B.5. Example of a <ClientNonce> Message ........................47
B.6. Example of a <ServerFinished> Message .....................48
Appendix C. Integration with PKCS #11 .............................48
Appendix D. Example CT-KIP-PRF Realizations .......................48
D.1. Introduction ..............................................48
D.2. CT-KIP-PRF-AES ............................................48
D.2.1. Identification .....................................48
D.2.2. Definition .........................................49
D.2.3. Example ............................................50
D.3. CT-KIP-PRF-SHA256 .........................................50
D.3.1. Identification .....................................50
D.3.2. Definition .........................................51
D.3.3. Example ............................................52
Appendix E. About OTPS ............................................53
Note: This document is Revision 1 of CT-KIP Version 1.0 [12] from RSA Laboratories' OTPS series.
注：本文件是RSA Laboratories OTPS系列CT-KIP版本1.0[12]的第1版。
This document describes a client-server protocol for initialization (and configuration) of cryptographic tokens. The protocol requires neither private-key capabilities in the cryptographic tokens, nor an established public-key infrastructure.
本文档描述了用于加密令牌初始化（和配置）的客户机-服务器协议。该协议既不需要加密令牌中的私钥功能，也不需要已建立的公钥基础设施。
The objectives of this protocol are:
本议定书的目标是：
o To provide a secure method of initializing cryptographic tokens with secret keys without exposing generated, secret material to any other entities than the server and the cryptographic token itself,
o 提供一种使用密钥初始化加密令牌的安全方法，无需将生成的机密材料暴露给服务器和加密令牌本身以外的任何其他实体，
o To avoid, as much as possible, any impact on existing cryptographic token manufacturing processes,
o 为了尽可能避免对现有加密令牌制造过程造成任何影响，
o To provide a solution that is easy to administer and scales well.
o 提供一个易于管理和良好扩展的解决方案。
The mechanism is intended for general use within computer and communications systems employing connected cryptographic tokens (or software emulations thereof).
该机制用于使用连接的加密令牌（或其软件仿真）的计算机和通信系统中的一般用途。
A cryptographic token may be a handheld hardware device, a hardware device connected to a personal computer through an electronic interface such as USB, or a software module resident on a personal computer, which offers cryptographic functionality that may be used, e.g., to authenticate a user towards some service. Increasingly, these tokens work in a connected fashion, enabling their programmatic initialization as well as programmatic retrieval of their output values. This document intends to meet the need for an open and interoperable mechanism to programmatically initialize and configure connected cryptographic tokens. A companion document entitled "A PKCS #11 Mechanism for the Cryptographic Token Key Initialization Protocol" [2] describes an application-programming interface suitable for use with this mechanism.
密码令牌可以是手持硬件设备、通过诸如USB之类的电子接口连接到个人计算机的硬件设备，或者驻留在个人计算机上的软件模块，其提供可用于（例如）向某个服务认证用户的密码功能。这些令牌越来越多地以连接的方式工作，支持其编程初始化以及对其输出值的编程检索。本文档旨在满足以编程方式初始化和配置连接的加密令牌的开放和可互操作机制的需要。标题为“加密令牌密钥初始化协议的PKCS#11机制”[2]的配套文件描述了适用于该机制的应用程序编程接口。
The organization of this document is as follows:
本文件的组织结构如下：
o Section 1 is an introduction.
o 第一节是导言。
o Section 2 defines some notation used in this document.
o 第2节定义了本文件中使用的一些符号。
o Section 3 defines the protocol mechanism in detail.
o 第3节详细定义了协议机制。
o Section 4 defines a binding of the protocol to transports.
o 第4节定义了协议与传输的绑定。
o Section 5 provides security considerations.
o 第5节提供了安全注意事项。
o Appendix A defines the XML schema for the protocol mechanism, Appendix B gives example messages, and Appendix C discusses integration with PKCS #11 [3].
o 附录A定义了协议机制的XML模式，附录B给出了示例消息，附录C讨论了与PKCS 11的集成[3]。
o Appendix D provides example realizations of an abstract pseudorandom function defined in Section 3.
o 附录D提供了第3节中定义的抽象伪随机函数的示例实现。
o Appendix E provides general information about the One-Time Password Specifications.
o 附录E提供了一次性密码规范的一般信息。
MAC Message Authentication Code
MAC消息认证码
PDU Protocol Data Unit
协议数据单元
PRF Pseudo-Random Function
伪随机函数
CT-KIP Cryptographic Token Key Initialization Protocol (the protocol mechanism described herein)
CT-KIP加密令牌密钥初始化协议（本文描述的协议机制）
|| String concatenation
||字符串串联
[x] Optional element x
[x] 可选元素x
A ^ B Exclusive-or operation on strings A and B (A and B of equal length)
A^B对字符串A和B（长度相等的A和B）的异或运算
K_AUTH Secret key used for authentication purposes
用于身份验证目的的K_身份验证密钥
K_TOKEN Secret key used for token computations, generated in CT-KIP
用于令牌计算的K_令牌密钥，在CT-KIP中生成
K_SERVER Public key of CT-KIP server
CT-KIP服务器的K_服务器公钥
K_SHARED Secret key shared between the cryptographic token and the CT-KIP server
加密令牌和CT-KIP服务器之间共享的K_共享密钥
K Key used to encrypt R_C (either K_SERVER or K_SHARED)
用于加密R_C的K密钥（K_服务器或K_共享）
R Pseudorandom value chosen by the cryptographic token and used for MAC computations
R由加密令牌选择并用于MAC计算的伪随机值
R_C Pseudorandom value chosen by the cryptographic token
由加密令牌选择的R_C伪随机值
R_S Pseudorandom value chosen by the CT-KIP server
CT-KIP服务器选择的R_S伪随机值
The following typographical convention is used in the body of the text: <XMLElement>.
正文中使用了以下印刷惯例：<xmlement>。
The CT-KIP is a client-server protocol for the secure initialization of cryptographic tokens. The protocol is meant to provide high assurance for both the server and the client (cryptographic token) that generated keys have been correctly and randomly generated and not exposed to other entities. The protocol does not require the existence of a public-key infrastructure.
CT-KIP是用于加密令牌安全初始化的客户机-服务器协议。该协议旨在为服务器和客户端（加密令牌）提供高保证，确保生成的密钥已正确、随机生成，且未暴露给其他实体。该协议不要求存在公钥基础设施。
+---------------+ +---------------+
| | | |
| CT-KIP client | | CT-KIP server |
| | | |
+---------------+ +---------------+
| |
| [ <---- CT-KIP trigger ---- ] |
| |
| ------- Client Hello -------> |
| |
| <------ Server Hello -------- |
| |
| ------- Client Nonce -------> |
| |
| <----- Server Finished ------ |
+---------------+ +---------------+
| | | |
| CT-KIP client | | CT-KIP server |
| | | |
+---------------+ +---------------+
| |
| [ <---- CT-KIP trigger ---- ] |
| |
| ------- Client Hello -------> |
| |
| <------ Server Hello -------- |
| |
| ------- Client Nonce -------> |
| |
| <----- Server Finished ------ |
Figure 1: The 4-pass CT-KIP protocol (with optional preceding trigger)
图1：4通道CT-KIP协议（带可选前置触发器）
In principle, the protocol involves a CT-KIP client and a CT-KIP server.
原则上，该协议涉及一个CT-KIP客户端和一个CT-KIP服务器。
It is assumed that a desktop/laptop or a wireless device (e.g., a mobile phone or a PDA) will host an application communicating with the CT-KIP server as well as the cryptographic token, and collectively, the cryptographic token and the communicating application form the CT-KIP client. When there is a need to point out if an action is to be performed by the communicating application or by the token the text will make this explicit.
假设台式机/膝上型计算机或无线设备（例如，移动电话或PDA）将承载与CT-KIP服务器以及加密令牌通信的应用程序，并且加密令牌和通信应用程序共同构成CT-KIP客户端。当需要指出某个操作是由通信应用程序执行还是由令牌执行时，文本将对此进行明确说明。
The manner in which the communicating application will transfer CT-KIP protocol elements to and from the cryptographic token is transparent to the CT-KIP server. One method for this transfer is described in [2].
通信应用程序将CT-KIP协议元素传输到加密令牌和从加密令牌传输CT-KIP协议元素的方式对CT-KIP服务器是透明的。[2]中描述了此传输的一种方法。
To initiate a CT-KIP session, a user may use a browser to connect to a web server running on some host. The user may then identify (and authenticate) herself (through some means that essentially are out of scope for this document) and possibly indicate how the CT-KIP client shall contact the CT-KIP server. There are also other alternatives for CT-KIP session initiation, such as the CT-KIP client being pre-configured to contact a certain CT-KIP server, or the user being informed out-of-band about the location of the CT-KIP server. In any event, once the location of the CT-KIP server is known, the CT-KIP client and the CT-KIP server engage in a 4-pass protocol in which:
要启动CT-KIP会话，用户可以使用浏览器连接到某台主机上运行的web服务器。然后，用户可以识别（和验证）自己（通过一些基本上不在本文件范围内的方式），并可能指示CT-KIP客户端应如何联系CT-KIP服务器。CT-KIP会话启动还有其他替代方案，例如，CT-KIP客户端被预先配置为联系某个CT-KIP服务器，或者用户在带外被告知CT-KIP服务器的位置。在任何情况下，一旦知道CT-KIP服务器的位置，CT-KIP客户端和CT-KIP服务器将采用4通道协议，其中：
a. The CT-KIP client provides information to the CT-KIP server about the cryptographic token's identity, supported CT-KIP versions, cryptographic algorithms supported by the token and for which keys may be generated using this protocol, and encryption and MAC algorithms supported by the cryptographic token for the purposes of this protocol.
a. CT-KIP客户端向CT-KIP服务器提供有关加密令牌的身份、支持的CT-KIP版本、令牌支持的加密算法（可使用此协议生成密钥）以及加密令牌为此协议支持的加密和MAC算法的信息。
b. Based on this information, the CT-KIP server provides a random nonce, R_S, to the CT-KIP client, along with information about the type of key to generate, the encryption algorithm chosen to protect sensitive data sent in the protocol. In addition, it provides either information about a shared secret key to use for encrypting the cryptographic token's random nonce (see below), or its own public key. The length of the nonce R_S may depend on the selected key type.
b. 基于此信息，CT-KIP服务器向CT-KIP客户端提供随机的nonce rs，以及有关要生成的密钥类型的信息，以及选择用于保护协议中发送的敏感数据的加密算法。此外，它还提供有关用于加密加密令牌的随机nonce（见下文）的共享密钥的信息，或者提供其自己的公钥。nonce R_的长度可能取决于所选的键类型。
c. The cryptographic token generates a random nonce R_C and encrypts it using the selected encryption algorithm and with a key K that is either the CT-KIP server's public key K_SERVER, or a shared secret key K_SHARED as indicated by the CT-KIP server. The length of the nonce R_C may depend on the selected key type. The CT-KIP client then sends the encrypted random nonce to the CT-KIP server. The token also calculates a cryptographic key K_TOKEN of the selected type from the combination of the two random nonces R_S and R_C, the encryption key K, and possibly some other data, using the CT-KIP-PRF function defined herein.
c. 加密令牌生成一个随机的nonce R_C，并使用所选的加密算法和密钥K（即CT-KIP服务器的公钥K_服务器）或CT-KIP服务器所指示的共享密钥K_共享）对其进行加密。nonce rc的长度可能取决于所选的键类型。然后，CT-KIP客户端将加密的随机nonce发送到CT-KIP服务器。令牌还使用本文定义的CT-KIP-PRF函数，从两个随机非数R_S和R_C、加密密钥K和可能的一些其他数据的组合计算所选类型的加密密钥K_令牌。
d. The CT-KIP server decrypts R_C, calculates K_TOKEN from the combination of the two random nonces R_S and R_C, the encryption key K, and possibly some other data, using the CT-KIP-PRF function defined herein. The server then associates K_TOKEN with the cryptographic token in a server-side data store. The intent is that the data store later on will be used by some service that needs to verify or decrypt data produced by the cryptographic token and the key.
d. CT-KIP服务器使用本文定义的CT-KIP-PRF函数，解密R_C，根据两个随机时值R_S和R_C、加密密钥K以及可能的一些其他数据的组合计算K_令牌。然后，服务器将K_令牌与服务器端数据存储中的加密令牌相关联。其目的是稍后数据存储将由需要验证或解密加密令牌和密钥生成的数据的某些服务使用。
e. Once the association has been made, the CT-KIP server sends a confirmation message to the CT-KIP client. The confirmation message includes an identifier for the generated key and may also contain additional configuration information, e.g., the identity of the CT-KIP server.
e. 关联完成后，CT-KIP服务器向CT-KIP客户端发送确认消息。确认消息包括所生成密钥的标识符，并且还可以包含附加配置信息，例如CT-KIP服务器的标识。
f. Upon receipt of the CT-KIP server's confirmation message, the cryptographic token associates the provided key identifier with the generated key K_TOKEN, and stores the provided configuration data, if any.
f. 在接收到CT-KIP服务器的确认消息后，加密令牌将提供的密钥标识符与生成的密钥K_令牌相关联，并存储提供的配置数据（如果有）。
Note: Conceptually, although R_C is one pseudorandom string, it may be viewed as consisting of two components, R_C1 and R_C2, where R_C1 is generated during the protocol run, and R_C2 can be generated at the cryptographic token manufacturing time and stored in the cryptographic token. In that case, the latter string, R_C2, should be unique for each cryptographic token for a given manufacturer.
注：从概念上讲，尽管R_C是一个伪随机字符串，但它可以被视为由两个组件组成，R_C1和R_C2，其中R_C1在协议运行期间生成，R_C2可以在加密令牌制造时生成并存储在加密令牌中。在这种情况下，后一个字符串R_C2对于给定制造商的每个加密令牌都应该是唯一的。
+----------------------+ +-------+ +----------------------+
| +------------+ | | | | |
| | Server key | | | | | |
| +<-| Public |------>------------->-------------+---------+ |
| | | Private | | | | | | | |
| | +------------+ | | | | | | |
| | | | | | | | | |
| V V | | | | V V |
| | +---------+ | | | | +---------+ | |
| | | Decrypt |<-------<-------------<-----------| Encrypt | | |
| | +---------+ | | | | +---------+ | |
| | | +--------+ | | | | ^ | |
| | | | Server | | | | | | | |
| | | | Random |--->------------->------+ +----------+ | |
| | | +--------+ | | | | | | Client | | |
| | | | | | | | | | Random | | |
| | | | | | | | | +----------+ | |
| | | | | | | | | | | |
| | V V | | | | V V | |
| | +------------+ | | | | +------------+ | |
| +-->| CT-KIP PRF | | | | | | CT-KIP PRF |<----+ |
| +------------+ | | | | +------------+ |
| | | | | | | |
| V | | | | V |
| +-------+ | | | | +-------+ |
| | Key | | | | | | Key | |
| +-------+ | | | | +-------+ |
| +-------+ | | | | +-------+ |
| |Key Id |-------->------------->------|Key Id | |
| +-------+ | | | | +-------+ |
+----------------------+ +-------+ +----------------------+
CT-KIP Server CT-KIP Client CT-KIP Client (Token)
(PC Host)
+----------------------+ +-------+ +----------------------+
| +------------+ | | | | |
| | Server key | | | | | |
| +<-| Public |------>------------->-------------+---------+ |
| | | Private | | | | | | | |
| | +------------+ | | | | | | |
| | | | | | | | | |
| V V | | | | V V |
| | +---------+ | | | | +---------+ | |
| | | Decrypt |<-------<-------------<-----------| Encrypt | | |
| | +---------+ | | | | +---------+ | |
| | | +--------+ | | | | ^ | |
| | | | Server | | | | | | | |
| | | | Random |--->------------->------+ +----------+ | |
| | | +--------+ | | | | | | Client | | |
| | | | | | | | | | Random | | |
| | | | | | | | | +----------+ | |
| | | | | | | | | | | |
| | V V | | | | V V | |
| | +------------+ | | | | +------------+ | |
| +-->| CT-KIP PRF | | | | | | CT-KIP PRF |<----+ |
| +------------+ | | | | +------------+ |
| | | | | | | |
| V | | | | V |
| +-------+ | | | | +-------+ |
| | Key | | | | | | Key | |
| +-------+ | | | | +-------+ |
| +-------+ | | | | +-------+ |
| |Key Id |-------->------------->------|Key Id | |
| +-------+ | | | | +-------+ |
+----------------------+ +-------+ +----------------------+
CT-KIP Server CT-KIP Client CT-KIP Client (Token)
(PC Host)
Figure 2: Principal data flow for CT-KIP key generation - using public server key
图2:CT-KIP密钥生成的主要数据流-使用公共服务器密钥
The inclusion of the two random nonces R_S and R_C in the key generation provides assurance to both sides (the token and the CT-KIP server) that they have contributed to the key's randomness and that the key is unique. The inclusion of the encryption key K ensures that no man-in-the-middle may be present, or else the cryptographic token will end up with a key different from the one stored by the legitimate CT-KIP server.
密钥生成中包含的两个随机非随机数R_S和R_C向双方（令牌和CT-KIP服务器）提供了保证，即它们导致了密钥的随机性，并且密钥是唯一的。包含加密密钥K可确保中间不存在任何人，否则加密令牌最终将使用与合法CT-KIP服务器存储的密钥不同的密钥。
Note: A man-in-the middle (in the form of corrupt client software or a mistakenly contacted server) may present his own public key to the token. This will enable the attacker to learn the client's version
注意：中间人（以损坏的客户端软件或错误联系的服务器的形式）可能会向令牌提供自己的公钥。这将使攻击者能够了解客户端的版本
of K_TOKEN. However, the attacker is not able to persuade the legitimate server to derive the same value for K_TOKEN, since K_TOKEN is a function of the public key involved, and the attacker's public key must be different than the correct server's (or else the attacker would not be able to decrypt the information received from the client). Therefore, once the attacker is no longer "in the middle", the client and server will detect that they are "out of synch" when they try to use their keys. Therefore, in the case of encrypting R_C with K_SERVER, it is important to verify that K_SERVER really is the legitimate server's key. One way to do this is to independently validate a newly generated K_TOKEN against some validation service at the server (e.g., by using a connection independent from the one used for the key generation).
K_代币。但是，攻击者无法说服合法服务器为K_令牌派生相同的值，因为K_令牌是相关公钥的函数，并且攻击者的公钥必须不同于正确的服务器（否则攻击者将无法解密从客户端接收的信息）。因此，一旦攻击者不再处于“中间”，客户端和服务器将在尝试使用密钥时检测到它们“不同步”。因此，在使用K_服务器加密R_C的情况下，验证K_服务器是否真的是合法服务器的密钥非常重要。一种方法是根据服务器上的验证服务独立验证新生成的K_令牌（例如，通过使用独立于密钥生成所用连接的连接）。
The CT-KIP server may couple an initial user authentication to the CT-KIP execution in several ways to ensure that a generated K_TOKEN ends up associated with the correct token and user. One way is to provide a one-time value to the user or CT-KIP client after successful user authentication and require this value to be used when contacting the CT-KIP service (in effect coupling the user authentication with the subsequent CT-KIP protocol run). This value could, for example, be placed in a <TriggerNonce> element of the CT-KIP initialization trigger (if triggers are used; see Section 4.2.7). Another way is for the user to provide a token identifier which will later be used in the CT-KIP protocol to the server during the authentication phase. The server may then include this token identifier in the CT-KIP initialization trigger. It is also legitimate for a CT-KIP client to initiate a CT-KIP protocol run without having received an initialization message from a server, but in this case any provided token identifier shall not be accepted by the server unless the server has access to a unique token key for the identified token and that key will be used in the protocol. Whatever the method, the CT-KIP server must ensure that a generated key is associated with the correct token and, if applicable, the correct user. For a further discussion of this and threats related to man-in-the-middle attacks in this context, see Section 5.5.
CT-KIP服务器可以几种方式将初始用户认证与CT-KIP执行耦合，以确保生成的K_令牌最终与正确的令牌和用户关联。一种方法是在成功的用户身份验证后向用户或CT-KIP客户端提供一次性值，并要求在联系CT-KIP服务时使用该值（实际上是将用户身份验证与后续的CT-KIP协议运行耦合）。例如，该值可以放置在CT-KIP初始化触发器的<Triggernance>元素中（如果使用了触发器；请参见第4.2.7节）。另一种方法是用户提供令牌标识符，该标识符稍后将在认证阶段在CT-KIP协议中用于服务器。然后，服务器可以在CT-KIP初始化触发器中包括该令牌标识符。CT-KIP客户端在未收到来自服务器的初始化消息的情况下启动CT-KIP协议运行也是合法的，但在这种情况下，任何提供的令牌标识符都不会被服务器接受，除非服务器可以访问标识令牌的唯一令牌密钥，并且该密钥将用于协议中。无论采用何种方法，CT-KIP服务器都必须确保生成的密钥与正确的令牌以及正确的用户（如果适用）相关联。有关这方面的进一步讨论以及与中间人攻击相关的威胁，请参见第5.5节。
The general requirements on CT-KIP-PRF are the same as on keyed hash functions: It shall take an arbitrary length input, and be one-way and collision-free (for a definition of these terms, see, e.g., [4]). Further, the CT-KIP-PRF function shall be capable of generating a variable-length output, and its output shall be unpredictable even if other outputs for the same key are known.
CT-KIP-PRF的一般要求与键控哈希函数的一般要求相同：它应采用任意长度的输入，并且是单向和无冲突的（有关这些术语的定义，请参见，例如[4]）。此外，CT-KIP-PRF功能应能产生可变长度输出，即使已知同一钥匙的其他输出，其输出也应不可预测。
It is assumed that any realization of CT-KIP-PRF takes three input parameters: A secret key k, some combination of variable data, and the desired length of the output. Examples of the variable data include, but are not limited to, a current token counter value, the current token time, and a challenge. The combination of variable data can, without loss of generalization, be considered as a salt value (see PKCS #5 Version 2.0 [5], Section 4), and this characterization of CT-KIP-PRF should fit all actual PRF algorithms implemented by tokens. From the point of view of this specification, CT-KIP-PRF is a "black-box" function that, given the inputs, generates a pseudorandom value.
假设CT-KIP-PRF的任何实现都需要三个输入参数：密钥k、一些可变数据的组合以及所需的输出长度。变量数据的示例包括但不限于当前令牌计数器值、当前令牌时间和质询。变量数据的组合可以在不失去泛化的情况下被视为salt值（见PKCS#5版本2.0[5]，第4节），CT-KIP-PRF的这种特征应该适合由令牌实现的所有实际PRF算法。从本规范的角度来看，CT-KIP-PRF是一个“黑箱”函数，给定输入，该函数生成伪随机值。
Separate specifications may define the implementation of CT-KIP-PRF for various types of cryptographic tokens. Appendix D contains two example realizations of CT-KIP-PRF.
单独的规范可以定义各种类型的加密令牌的CT-KIP-PRF的实现。附录D包含CT-KIP-PRF的两个示例实现。
CT-KIP-PRF (k, s, dsLen)
CT-KIP-PRF（k、s、dsLen）
Input:
输入：
k secret key in octet string format
八位字节字符串格式的k密钥
s octet string of varying length consisting of variable data distinguishing the particular string being derived
s长度可变的八位字节字符串，由变量数据组成，用于区分所导出的特定字符串
dsLen desired length of the output
dsLen输出的所需长度
Output:
输出：
DS pseudorandom string, dsLen-octets long
DS伪随机字符串，dsLen八位字节长
For the purposes of this document, the secret key k shall be 16 octets long.
在本文件中，密钥k的长度应为16个八位字节。
In CT-KIP, keys are generated using the CT-KIP-PRF function, a secret random value R_C chosen by the CT-KIP client, a random value R_S chosen by the CT-KIP server, and the key k used to encrypt R_C. The input parameter s of CT-KIP-PRF is set to the concatenation of the (ASCII) string "Key generation", k, and R_S, and the input parameter dsLen is set to the desired length of the key, K_TOKEN (the length of K_TOKEN is given by the key's type):
在CT-KIP中，使用CT-KIP-PRF函数、CT-KIP客户端选择的秘密随机值R_C、CT-KIP服务器选择的随机值R_S以及用于加密R_C的密钥k生成密钥。CT-KIP-PRF的输入参数S设置为（ASCII）字符串“密钥生成”、k和R_S的串联，并且输入参数dsLen被设置为所需的密钥长度K_令牌（K_令牌的长度由密钥的类型给出）：
dsLen = (desired length of K_TOKEN)
dsLen = (desired length of K_TOKEN)
K_TOKEN = CT-KIP-PRF (R_C, "Key generation" || k || R_S, dsLen)
K|u令牌=CT-KIP-PRF（R|C，“密钥生成”| K|R|S，dsLen）
When computing K_TOKEN above, the output of CT-KIP-PRF may be subject to an algorithm-dependent transform before being adopted as a key of the selected type. One example of this is the need for parity in DES keys.
当计算上述K_令牌时，CT-KIP-PRF的输出在被采用为所选类型的密钥之前，可经受依赖于算法的变换。其中一个例子是DES密钥中需要奇偶校验。
CT-KIP client random nonce(s) are either encrypted with the public key provided by the CT-KIP server or by a shared secret key. For example, in the case of a public RSA key, an RSA encryption scheme from PKCS #1 [6] may be used.
使用CT-KIP服务器提供的公钥或共享密钥对CT-KIP客户机随机nonce进行加密。例如，在公开RSA密钥的情况下，可以使用PKCS#1[6]的RSA加密方案。
In the case of a shared secret key, to avoid dependence on other algorithms, the CT-KIP client may use the CT-KIP-PRF function described herein with the shared secret key K_SHARED as input parameter k (in this case, K_SHARED should be used solely for this purpose), the concatenation of the (ASCII) string "Encryption" and the server's nonce R_S as input parameter s, and dsLen set to the length of R_C:
在共享密钥的情况下，为了避免对其他算法的依赖，CT-KIP客户机可以使用本文描述的CT-KIP-PRF函数，其中共享密钥K_shared作为输入参数K（在这种情况下，K_shared应仅用于此目的）、串接（ASCII）字符串“加密”服务器的nonce R_s作为输入参数s，dsLen设置为R_C的长度：
dsLen = len(R_C)
dsLen=len（R_C）
DS = CT-KIP-PRF(K_SHARED, "Encryption" || R_S, dsLen)
DS=CT-KIP-PRF（K|U共享，“加密”| R|S，dsLen）
This will produce a pseudorandom string DS of length equal to R_C. Encryption of R_C may then be achieved by XOR-ing DS with R_C:
这将产生一个长度等于R_C的伪随机字符串DS。然后可以通过将DS与R_C异或来实现R_C的加密：
Enc-R_C = DS ^ R_C
Enc-R\u C=DS^R\u C
The CT-KIP server will then perform the reverse operation to extract R_C from Enc-R_C.
然后，CT-KIP服务器将执行反向操作，从Enc-R_C中提取R_C。
Note: It may appear that an attacker, who learns a previous value of R_C, may be able to replay the corresponding R_S and, hence, learn a new R_C as well. However, this attack is mitigated by the requirement for a server to show knowledge of K_AUTH (see below) in order to successfully complete a key re-generation.
注意：可能会出现这样的情况：学习了以前的R_C值的攻击者可能能够重播相应的R_S，因此也可以学习新的R_C。但是，为了成功地完成密钥的重新生成，服务器需要显示K_AUTH的知识（见下文），从而减轻了这种攻击。
Core parts of the XML schema for CT-KIP, found in Appendix A, are explained in this section. Specific protocol message elements are defined in Section 3.8. Examples can be found in Appendix B.
本节解释了CT-KIP XML模式的核心部分（见附录A）。第3.8节定义了特定的协议消息元素。示例见附录B。
The XML format for CT-KIP messages have been designed to be extensible. However, it is possible that the use of extensions will harm interoperability; therefore, any use of extensions should be carefully considered. For example, if a particular implementation relies on the presence of a proprietary extension, then it may not be able to interoperate with independent implementations that have no knowledge of this extension.
CT-KIP消息的XML格式被设计为可扩展的。然而，使用扩展可能会损害互操作性；因此，任何扩展的使用都应该仔细考虑。例如，如果特定实现依赖于专有扩展的存在，那么它可能无法与不了解此扩展的独立实现进行互操作。
XML types defined in this sub-section are not CT-KIP messages; rather they provide building blocks that are used by CT-KIP messages.
本小节中定义的XML类型不是CT-KIP消息；相反，它们提供CT-KIP消息使用的构建块。
Some CT-KIP elements rely on the parties being able to compare received values with stored values. Unless otherwise noted, all elements in this document that have the XML Schema "xs:string" type, or a type derived from it, must be compared using an exact binary comparison. In particular, CT-KIP implementations must not depend on case-insensitive string comparisons, normalization or trimming of white space, or conversion of locale-specific formats such as numbers.
一些CT-KIP元件依赖于各方能够将接收值与存储值进行比较。除非另有说明，否则必须使用精确的二进制比较来比较本文档中具有XML模式“xs:string”类型或从中派生的类型的所有元素。特别是，CT-KIP实现不能依赖于不区分大小写的字符串比较、空白的规范化或修剪，或者特定于语言环境的格式（如数字）的转换。
Implementations that compare values that are represented using different character encodings must use a comparison method that returns the same result as converting both values to the Unicode character encoding, Normalization Form C [1], and then performing an exact binary comparison.
比较使用不同字符编码表示的值的实现必须使用一种比较方法，该方法返回的结果与将两个值转换为Unicode字符编码（规范化形式C[1]），然后执行精确的二进制比较相同。
No collation or sorting order for attributes or element values is defined. Therefore, CT-KIP implementations must not depend on specific sorting orders for values.
未定义属性或元素值的排序规则或排序顺序。因此，CT-KIP实现不能依赖于值的特定排序顺序。
All CT-KIP requests are defined as extensions to the abstract AbstractRequestType type. The elements of the AbstractRequestType, therefore, apply to all CT-KIP requests. All CT-KIP requests must contain a Version attribute. For this version of this specification, Version shall be set to "1.0".
所有CT-KIP请求都定义为抽象AbstractRequestType类型的扩展。因此，AbstractRequestType的元素适用于所有CT-KIP请求。所有CT-KIP请求必须包含版本属性。对于本规范的本版本，版本应设置为“1.0”。
<xs:complexType name="AbstractRequestType" abstract="true">
<xs:attribute name="Version" type="VersionType"
use="required"/>
</xs:complexType>
<xs:complexType name="AbstractRequestType" abstract="true">
<xs:attribute name="Version" type="VersionType"
use="required"/>
</xs:complexType>
All CT-KIP responses are defined as extensions to the abstract AbstractResponseType type. The elements of the AbstractResponseType, therefore, apply to all CT-KIP responses. All CT-KIP responses contain a Version attribute indicating the version that was used. A Status attribute, which indicates whether the preceding request was successful or not must also be present. Finally, all responses may contain a SessionID attribute identifying the particular CT-KIP session. The SessionID attribute needs only be present if more than one roundtrip is required for a successful protocol run (this is the case with the protocol version described herein).
所有CT-KIP响应都定义为抽象AbstractResponseType类型的扩展。因此，AbstractResponseType的元素适用于所有CT-KIP响应。所有CT-KIP响应都包含一个Version属性，指示使用的版本。还必须存在一个状态属性，该属性指示前面的请求是否成功。最后，所有响应可能包含识别特定CT-KIP会话的SessionID属性。只有当成功运行协议需要多次往返时，才需要存在SessionID属性（本文所述的协议版本就是这种情况）。
<xs:complexType name="AbstractResponseType" abstract="true">
<xs:attribute name="Version" type="VersionType" use="required"/>
<xs:attribute name="SessionID" type="IdentifierType"/>
<xs:attribute name="Status" type="StatusCode" use="required"/>
</xs:complexType>
<xs:complexType name="AbstractResponseType" abstract="true">
<xs:attribute name="Version" type="VersionType" use="required"/>
<xs:attribute name="SessionID" type="IdentifierType"/>
<xs:attribute name="Status" type="StatusCode" use="required"/>
</xs:complexType>
The StatusCode type enumerates all possible return codes:
StatusCode类型枚举所有可能的返回代码：
<xs:simpleType name="StatusCode">
<xs:restriction base="xs:string">
<xs:enumeration value="Continue"/>
<xs:enumeration value="Success"/>
<xs:enumeration value="Abort"/>
<xs:enumeration value="AccessDenied"/>
<xs:enumeration value="MalformedRequest"/>
<xs:enumeration value="UnknownRequest"/>
<xs:enumeration value="UnknownCriticalExtension"/>
<xs:enumeration value="UnsupportedVersion"/>
<xs:enumeration value="NoSupportedKeyTypes"/>
<xs:enumeration value="NoSupportedEncryptionAlgorithms"/>
<xs:enumeration value="NoSupportedMACAlgorithms"/>
<xs:enumeration value="InitializationFailed"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="StatusCode">
<xs:restriction base="xs:string">
<xs:enumeration value="Continue"/>
<xs:enumeration value="Success"/>
<xs:enumeration value="Abort"/>
<xs:enumeration value="AccessDenied"/>
<xs:enumeration value="MalformedRequest"/>
<xs:enumeration value="UnknownRequest"/>
<xs:enumeration value="UnknownCriticalExtension"/>
<xs:enumeration value="UnsupportedVersion"/>
<xs:enumeration value="NoSupportedKeyTypes"/>
<xs:enumeration value="NoSupportedEncryptionAlgorithms"/>
<xs:enumeration value="NoSupportedMACAlgorithms"/>
<xs:enumeration value="InitializationFailed"/>
</xs:restriction>
</xs:simpleType>
Upon transmission or receipt of a message for which the Status attribute's value is not "Success" or "Continue", the default behavior, unless explicitly stated otherwise below, is that both the
在传输或接收状态属性值不是“成功”或“继续”的消息时，除非下面另有明确说明，否则默认行为是
CT-KIP server and the CT-KIP client shall immediately terminate the CT-KIP session. CT-KIP servers and CT-KIP clients must delete any secret values generated as a result of failed runs of the CT-KIP protocol. Session identifiers may be retained from successful or failed protocol runs for replay detection purposes, but such retained identifiers shall not be reused for subsequent runs of the protocol.
CT-KIP服务器和CT-KIP客户端应立即终止CT-KIP会话。CT-KIP服务器和CT-KIP客户端必须删除因CT-KIP协议运行失败而生成的任何机密值。会话标识符可以从成功或失败的协议运行中保留，以用于重播检测，但此类保留的标识符不得用于协议的后续运行。
When possible, the CT-KIP client should present an appropriate error message to the user.
如果可能，CT-KIP客户端应向用户提供适当的错误消息。
These status codes are valid in all CT-KIP-Response messages unless explicitly stated otherwise.
除非另有明确说明，否则这些状态代码在所有CT KIP响应消息中均有效。
o "Continue" indicates that the CT-KIP server is ready for a subsequent request from the CT-KIP client. It cannot be sent in the server's final message.
o “继续”表示CT-KIP服务器已准备好接收来自CT-KIP客户端的后续请求。无法在服务器的最终消息中发送。
o "Success" indicates successful completion of the CT-KIP session. It can only be sent in the server's final message.
o “成功”表示CT-KIP课程成功完成。它只能在服务器的最终消息中发送。
o "Abort" indicates that the CT-KIP server rejected the CT-KIP client's request for unspecified reasons.
o “中止”表示CT-KIP服务器因未指明的原因拒绝了CT-KIP客户端的请求。
o "AccessDenied" indicates that the CT-KIP client is not authorized to contact this CT-KIP server.
o “AccessDenied”表示CT-KIP客户端无权联系此CT-KIP服务器。
o "MalformedRequest" indicates that the CT-KIP server failed to parse the CT-KIP client's request.
o “MalformedRequest”表示CT-KIP服务器无法解析CT-KIP客户端的请求。
o "UnknownRequest" indicates that the CT-KIP client made a request that is unknown to the CT-KIP server.
o “UnknownRequest”表示CT-KIP客户端发出了CT-KIP服务器未知的请求。
o "UnknownCriticalExtension" indicates that a critical CT-KIP extension (see below) used by the CT-KIP client was not supported or recognized by the CT-KIP server.
o “UnknownCriticalExtension”表示CT-KIP客户端使用的关键CT-KIP扩展（见下文）不受CT-KIP服务器支持或识别。
o "UnsupportedVersion" indicates that the CT-KIP client used a CT-KIP protocol version not supported by the CT-KIP server. This error is only valid in the CT-KIP server's first response message.
o “UnsupportedVersion”表示CT-KIP客户端使用了CT-KIP服务器不支持的CT-KIP协议版本。此错误仅在CT-KIP服务器的第一条响应消息中有效。
o "NoSupportedKeyTypes" indicates that the CT-KIP client only suggested key types that are not supported by the CT-KIP server. This error is only valid in the CT-KIP server's first response message. Note that the error will only occur if the CT-KIP server does not support any of the CT-KIP client's suggested key types.
o “NoSupportedKeyTypes”表示CT-KIP客户端仅建议CT-KIP服务器不支持的密钥类型。此错误仅在CT-KIP服务器的第一条响应消息中有效。请注意，只有当CT-KIP服务器不支持CT-KIP客户端建议的任何密钥类型时，才会发生此错误。
o "NoSupportedEncryptionAlgorithms" indicates that the CT-KIP client only suggested encryption algorithms that are not supported by the CT-KIP server. This error is only valid in the CT-KIP server's first response message. Note that the error will only occur if the CT-KIP server does not support any of the CT-KIP client's suggested encryption algorithms.
o “NoSupportedEncryptionAlgorithms”表示CT-KIP客户端仅建议CT-KIP服务器不支持的加密算法。此错误仅在CT-KIP服务器的第一条响应消息中有效。请注意，只有当CT-KIP服务器不支持CT-KIP客户端建议的任何加密算法时，才会发生错误。
o "NoSupportedMACAlgorithms" indicates that the CT-KIP client only suggested MAC algorithms that are not supported by the CT-KIP server. This error is only valid in the CT-KIP server's first response message. Note that the error will only occur if the CT-KIP server does not support any of the CT-KIP client's suggested MAC algorithms.
o “NoSupportedMACAlgorithms”表示CT-KIP客户端仅建议CT-KIP服务器不支持的MAC算法。此错误仅在CT-KIP服务器的第一条响应消息中有效。请注意，只有当CT-KIP服务器不支持CT-KIP客户端建议的任何MAC算法时，才会发生错误。
o "InitializationFailed" indicates that the CT-KIP server could not generate a valid key given the provided data. When this status code is received, the CT-KIP client should try to restart CT-KIP, as it is possible that a new run will succeed.
o “InitializationFailed”表示CT-KIP服务器在提供数据的情况下无法生成有效密钥。收到此状态代码后，CT-KIP客户端应尝试重新启动CT-KIP，因为新的运行可能会成功。
The IdentifierType type is used to identify various CT-KIP elements, such as sessions, users, and services. Identifiers must not be longer than 128 octets.
IdentifierType类型用于标识各种CT-KIP元素，如会话、用户和服务。标识符的长度不得超过128个八位字节。
<xs:simpleType name="IdentifierType">
<xs:restriction base="xs:string">
<xs:maxLength value="128"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="IdentifierType">
<xs:restriction base="xs:string">
<xs:maxLength value="128"/>
</xs:restriction>
</xs:simpleType>
The NonceType type is used to carry pseudorandom values in CT-KIP messages. A nonce, as the name implies, must be used only once. For each CT-KIP message that requires a nonce element to be sent, a fresh nonce shall be generated each time. Nonce values must be at least 16 octets long.
非类型类型用于在CT-KIP消息中携带伪随机值。顾名思义，nonce只能使用一次。对于需要发送nonce元素的每个CT-KIP消息，每次都应生成一个新的nonce。Nonce值的长度必须至少为16个八位字节。
<xs:simpleType name="NonceType">
<xs:restriction base="xs:base64Binary">
<xs:minLength value="16"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="NonceType">
<xs:restriction base="xs:base64Binary">
<xs:minLength value="16"/>
</xs:restriction>
</xs:simpleType>
The ExtensionsType type is a list of type-value pairs that define optional CT-KIP features supported by a CT-KIP client or server. Extensions may be sent with any CT-KIP message. Please see the description of individual CT-KIP messages in Section 3.8 of this document for applicable extensions. Unless an extension is marked as Critical, a receiving party need not be able to interpret it. A receiving party is always free to disregard any (non-critical) extensions.
ExtensionsType类型是定义CT-KIP客户端或服务器支持的可选CT-KIP功能的类型-值对列表。扩展可以与任何CT-KIP消息一起发送。有关适用的扩展，请参见本文件第3.8节中的单个CT-KIP消息说明。除非扩展被标记为关键，否则接收方不需要解释它。接收方始终可以自由忽略任何（非关键）扩展。
<xs:complexType name="AbstractExtensionsType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="Extension" type="AbstractExtensionType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AbstractExtensionsType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="Extension" type="AbstractExtensionType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AbstractExtensionType" abstract="true">
<xs:attribute name="Critical" type="xs:boolean"/>
</xs:complexType>
<xs:complexType name="AbstractExtensionType" abstract="true">
<xs:attribute name="Critical" type="xs:boolean"/>
</xs:complexType>
In this section, CT-KIP messages, including their parameters, encodings and semantics are defined.
在本节中，定义了CT-KIP消息，包括它们的参数、编码和语义。
The CT-KIP server may initialize the CT-KIP protocol by sending a <CT-KIPTrigger> message. This message may, e.g., be sent in response to a user requesting token initialization in a browsing session.
CT-KIP服务器可以通过发送<CT KIPTrigger>消息来初始化CT-KIP协议。例如，可以发送该消息以响应在浏览会话中请求令牌初始化的用户。
<xs:complexType name="InitializationTriggerType">
<xs:sequence>
<xs:element name="TokenID" type="xs:base64Binary" minOccurs="0"/>
<xs:element name="KeyID" type="xs:base64Binary" minOccurs="0"/>
<xs:element name="TokenPlatformInfo"
type="TokenPlatformInfoType" minOccurs="0"/>
<xs:element name="TriggerNonce" type="NonceType"/>
<xs:element name="CT-KIPURL" type="xs:anyURI" minOccurs="0"/>
<xs:any namespace="##other" processContents="strict"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
<xs:complexType name="InitializationTriggerType">
<xs:sequence>
<xs:element name="TokenID" type="xs:base64Binary" minOccurs="0"/>
<xs:element name="KeyID" type="xs:base64Binary" minOccurs="0"/>
<xs:element name="TokenPlatformInfo"
type="TokenPlatformInfoType" minOccurs="0"/>
<xs:element name="TriggerNonce" type="NonceType"/>
<xs:element name="CT-KIPURL" type="xs:anyURI" minOccurs="0"/>
<xs:any namespace="##other" processContents="strict"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID"/>
</xs:complexType>
<xs:element name="CT-KIPTrigger" type="CT-KIPTriggerType"/>
<xs:element name="CT-KIPTrigger" type="CT-KIPTriggerType"/>
<xs:complexType name="CT-KIPTriggerType">
<xs:annotation>
<xs:documentation xml:lang="en">
Message used to trigger the device to initiate a
CT-KIP run.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:choice>
<xs:element name="InitializationTrigger"
type="InitializationTriggerType"/>
<xs:any nameSpace="##other" processContents="strict"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="Version" type="ct-kip:VersionType"/>
</xs:complexType>
<xs:complexType name="CT-KIPTriggerType">
<xs:annotation>
<xs:documentation xml:lang="en">
Message used to trigger the device to initiate a
CT-KIP run.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:choice>
<xs:element name="InitializationTrigger"
type="InitializationTriggerType"/>
<xs:any nameSpace="##other" processContents="strict"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="Version" type="ct-kip:VersionType"/>
</xs:complexType>
The <CT-KIPTrigger> element is intended for the CT-KIP client and may inform the CT-KIP client about the identifier for the token that is to be initialized, and, optionally, of the identifier for the key on that token. The latter would apply when re-seeding. The trigger always contains a nonce to allow the server to couple the trigger with a later CT-KIP <ClientHello> request. Finally, the trigger may contain a URL to use when contacting the CT-KIP server. The <xs:any> elements are for future extensibility. Any provided <TokenID> or <KeyID> values shall be used by the CT-KIP client in the subsequent <ClientHello> request. The optional <TokenPlatformInfo> element informs the CT-KIP client about the characteristics of the intended token platform, and applies in the public-key variant of CT-KIP in situations when the client potentially needs to decide which one of several tokens to initialize.
<CT KIPTrigger>元素用于CT-KIP客户机，可以通知CT-KIP客户机要初始化的令牌的标识符，以及该令牌上的密钥的标识符（可选）。后者将在重新播种时适用。触发器始终包含一个nonce，以允许服务器将触发器与稍后的CT-KIP<ClientHello>请求耦合。最后，触发器可能包含联系CT-KIP服务器时使用的URL。<xs:any>元素用于将来的扩展性。CT-KIP客户端应在随后的<ClientHello>请求中使用任何提供的<TokenID>或<KeyID>值。可选的<TokenPlatformInfo>元素通知CT-KIP客户机预期令牌平台的特征，并在客户机可能需要决定初始化几个令牌中的哪一个时应用于CT-KIP的公钥变体。
The Version attribute shall be set to "1.0" for this version of CT-KIP.
对于本版本的CT-KIP，版本属性应设置为“1.0”。
This message is the initial message sent from the CT-KIP client to the CT-KIP server.
此消息是从CT-KIP客户端发送到CT-KIP服务器的初始消息。
<xs:element name="ClientHello" type="ClientHelloPDU"/>
<xs:element name="ClientHello" type="ClientHelloPDU"/>
<xs:complexType name="ClientHelloPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Message sent from CT-KIP client to CT-KIP server to
<xs:complexType name="ClientHelloPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Message sent from CT-KIP client to CT-KIP server to
initiate a CT-KIP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractRequestType">
<xs:sequence>
<xs:element name="TokenID"
type="xs:base64Binary" minOccurs="0"/>
<xs:element name="KeyID"
type="xs:base64Binary" minOccurs="0"/>
<xs:element name="ClientNonce"
type="NonceType" minOccurs="0"/>
<xs:element name= "TriggerNonce"
type="NonceType" minOccurs="0"/>
<xs:element name="SupportedKeyTypes"
type="AlgorithmsType"/>
<xs:element name="SupportedEncryptionAlgorithms"
type="AlgorithmsType"/>
<xs:element name="SupportedMACAlgorithms"
type="AlgorithmsType"/>
<xs:element name="Extensions"
type="ExtensionsType" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
initiate a CT-KIP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractRequestType">
<xs:sequence>
<xs:element name="TokenID"
type="xs:base64Binary" minOccurs="0"/>
<xs:element name="KeyID"
type="xs:base64Binary" minOccurs="0"/>
<xs:element name="ClientNonce"
type="NonceType" minOccurs="0"/>
<xs:element name= "TriggerNonce"
type="NonceType" minOccurs="0"/>
<xs:element name="SupportedKeyTypes"
type="AlgorithmsType"/>
<xs:element name="SupportedEncryptionAlgorithms"
type="AlgorithmsType"/>
<xs:element name="SupportedMACAlgorithms"
type="AlgorithmsType"/>
<xs:element name="Extensions"
type="ExtensionsType" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
The components of this message have the following meaning:
此消息的组件具有以下含义：
o Version: (attribute inherited from the AbstractRequestType type) The highest version of this protocol the client supports. Only version one ("1.0") is currently specified.
o Version：（从AbstractRequestType类型继承的属性）客户端支持的此协议的最高版本。目前只指定了版本1（“1.0”）。
o <TokenID>: An identifier for the cryptographic token (allows the server to find, e.g., a correct shared secret for MACing purposes). The identifier shall only be present if such shared secrets exist or if the identifier was provided by the server in a <CT-KIPTrigger> element (see Section 4.2.7 below). In the latter case, it must have the same value as the identifier provided in that element.
o <TokenID>：加密令牌的标识符（允许服务器查找，例如，用于MACing目的的正确共享密钥）。只有在存在此类共享机密或服务器在<CT KIPTrigger>元素中提供标识符时，标识符才应存在（见下文第4.2.7节）。在后一种情况下，它必须具有与该元素中提供的标识符相同的值。
o <KeyID>: An identifier for the key that will be overwritten if the protocol run is successful. The identifier shall only be present if the key exists or was provided by the server in a <CT-KIPTrigger> element (see Section 4.2.7 below). In the latter case, it must have the same value as the identifier provided in that element.
o <KeyID>：如果协议运行成功，将覆盖的密钥标识符。只有当密钥存在或由服务器在<CT KIPTrigger>元素中提供时，标识符才应存在（见下文第4.2.7节）。在后一种情况下，它必须具有与该元素中提供的标识符相同的值。
o <ClientNonce>: This is the nonce R, which, when present, shall be used by the server when calculating MAC values (see below). It is recommended that clients include this element whenever the <KeyID> element is present.
o <ClientNonce>：这是nonce R，当存在时，服务器应在计算MAC值时使用它（见下文）。建议客户机在出现<KeyID>元素时包含此元素。
o <TriggerNonce>: This optional element shall be present if and only if the CT-KIP run was initialized with a <CT-KIPTrigger> message (see Section 4.2.7 below), and shall, in that case, have the same value as the <TriggerNonce> child of that message. A server using nonces in this way must verify that the nonce is valid and that any token or key identifier values provided in the <CT-KIPTrigger> message match the corresponding identifier values in the <ClientHello> message.
o <Triggernance>：当且仅当CT-KIP运行使用<CT KIPTrigger>消息初始化时（见下文第4.2.7节），该可选元素应存在，并且在这种情况下，该可选元素的值应与该消息的<Triggernance>子元素的值相同。以这种方式使用nonce的服务器必须验证nonce是否有效，以及<CT KIPTrigger>消息中提供的任何令牌或密钥标识符值是否与<ClientHello>消息中的相应标识符值匹配。
o <SupportedKeyTypes>: A sequence of URIs indicating the key types for which the token is willing to generate keys through CT-KIP.
o <SupportedKeyTypes>：一系列URI，指示令牌愿意通过CT-KIP为其生成密钥的密钥类型。
o <SupportedEncryptionAlgorithms>: A sequence of URIs indicating the encryption algorithms supported by the cryptographic token for the purposes of CT-KIP. The CT-KIP client may indicate the same algorithm both as a supported key type and as an encryption algorithm.
o <SupportedEncryptionAlgorithms>：一系列URI，指示加密令牌为CT-KIP目的支持的加密算法。CT-KIP客户端可以将相同的算法指示为受支持的密钥类型和加密算法。
o <SupportedMACAlgorithms>: A sequence of URIs indicating the MAC
algorithms supported by the cryptographic token for the purposes
of CT-KIP. The CT-KIP client may indicate the same algorithm both
as an encryption algorithm and as a MAC algorithm (e.g., http://
www.rsasecurity.com/rsalabs/otps/schemas/2005/12/
ct-kip#ct-kip-prf-aes defined in Appendix D)
o <SupportedMACAlgorithms>: A sequence of URIs indicating the MAC
algorithms supported by the cryptographic token for the purposes
of CT-KIP. The CT-KIP client may indicate the same algorithm both
as an encryption algorithm and as a MAC algorithm (e.g., http://
www.rsasecurity.com/rsalabs/otps/schemas/2005/12/
ct-kip#ct-kip-prf-aes defined in Appendix D)
o <Extensions>: A sequence of extensions. One extension is defined for this message in this version of CT-KIP: the ClientInfoType (see Section 3.9.1).
o <Extensions>：一系列扩展。在此版本的CT-KIP中为该消息定义了一个扩展名：ClientInfo类型（见第3.9.1节）。
This message is the first message sent from the CT-KIP server to the CT-KIP client (assuming a trigger message has not been sent to initiate the protocol, in which case, this message is the second message sent from the CT-KIP server to the CT-KIP client). It is sent upon reception of a <ClientHello> message.
此消息是从CT-KIP服务器发送到CT-KIP客户端的第一条消息（假设尚未发送触发消息来启动协议，在这种情况下，此消息是从CT-KIP服务器发送到CT-KIP客户端的第二条消息）。它在收到<ClientHello>消息时发送。
<xs:element name="ServerHello" type="ServerHelloPDU"/>
<xs:element name="ServerHello" type="ServerHelloPDU"/>
<xs:complexType name="ServerHelloPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Message sent from CT-KIP server to CT-KIP
<xs:complexType name="ServerHelloPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Message sent from CT-KIP server to CT-KIP
client in response to a received ClientHello
PDU.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="KeyType"
type="AlgorithmType"/>
<xs:element name="EncryptionAlgorithm"
type="AlgorithmType"/>
<xs:element name="MacAlgorithm"
type="AlgorithmType"/>
<xs:element name="EncryptionKey"
type="ds:KeyInfoType"/>
<xs:element name="Payload"
type="PayloadType"/>
<xs:element name="Extensions"
type="ExtensionsType" minOccurs="0"/>
<xs:element name="Mac" type="MacType"
minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
client in response to a received ClientHello
PDU.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="KeyType"
type="AlgorithmType"/>
<xs:element name="EncryptionAlgorithm"
type="AlgorithmType"/>
<xs:element name="MacAlgorithm"
type="AlgorithmType"/>
<xs:element name="EncryptionKey"
type="ds:KeyInfoType"/>
<xs:element name="Payload"
type="PayloadType"/>
<xs:element name="Extensions"
type="ExtensionsType" minOccurs="0"/>
<xs:element name="Mac" type="MacType"
minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="PayloadType">
<xs:annotation>
<xs:documentation xml:lang="en">
Currently, only the nonce is defined. In future versions,
other payloads may be defined, e.g., for one-roundtrip
initialization protocols.
</xs:documentation>
</xs:annotation>
<xs:choice>
<xs:element name="Nonce" type="NonceType"/>
<any namespace="##other" processContents="strict"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="PayloadType">
<xs:annotation>
<xs:documentation xml:lang="en">
Currently, only the nonce is defined. In future versions,
other payloads may be defined, e.g., for one-roundtrip
initialization protocols.
</xs:documentation>
</xs:annotation>
<xs:choice>
<xs:element name="Nonce" type="NonceType"/>
<any namespace="##other" processContents="strict"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="MacType">
<xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="MacAlgorithm" type="xs:anyURI"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="MacType">
<xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="MacAlgorithm" type="xs:anyURI"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
The components of this message have the following meaning:
此消息的组件具有以下含义：
o Version: (attribute inherited from the AbstractResponseType type) The version selected by the CT-KIP server. May be lower than the version indicated by the CT-KIP client, in which case, local policy at the client will determine whether or not to continue the session.
o Version：（从AbstractResponseType继承的属性）CT-KIP服务器选择的版本。可能低于CT-KIP客户端指示的版本，在这种情况下，客户端的本地策略将决定是否继续会话。
o SessionID: (attribute inherited from the AbstractResponseType type) An identifier for this session.
o SessionID：（从AbstractResponseType类型继承的属性）此会话的标识符。
o Status: (attribute inherited from the abstract AbstractResponseType type) Return code for the <ClientHello>. If Status is not "Continue", only the Status and Version attributes will be present; otherwise, all the other elements must be present as well.
o 状态：（从抽象AbstractResponseType类型继承的属性）返回<ClientHello>的代码。如果状态不是“继续”，则只显示状态和版本属性；否则，所有其他元素也必须存在。
o <KeyType>: The type of the key to be generated.
o <KeyType>：要生成的密钥的类型。
o <EncryptionAlgorithm>: The encryption algorithm to use when protecting R_C.
o <EncryptionAlgorithm>：保护R\u C时使用的加密算法。
o <MacAlgorithm>: The MAC algorithm to be used by the CT-KIP server.
o <MacAlgorithm>：CT-KIP服务器使用的MAC算法。
o <EncryptionKey>: Information about the key to use when encrypting R_C. It will either be the server's public key (the <ds:KeyValue> alternative of ds:KeyInfoType) or an identifier for a shared secret key (the <ds:KeyName> alternative of ds:KeyInfoType).
o <EncryptionKey>：有关加密R_C时要使用的密钥的信息。它将是服务器的公钥（ds:KeyValue>ds:KeyInfoType的替代项）或共享密钥的标识符（ds:KeyName>ds:KeyInfoType的替代项）。
o <Payload>: The actual payload. For this version of the protocol, only one payload is defined: the pseudorandom string R_S.
o <Payload>：实际有效负载。对于这个版本的协议，只定义了一个有效负载：伪随机字符串R_S。
o <Extensions>: A list of server extensions. Two extensions are defined for this message in this version of CT-KIP: the ClientInfoType and the ServerInfoType (see Section 3.9).
o <Extensions>：服务器扩展的列表。在此版本的CT-KIP中为此消息定义了两个扩展：ClientInfo类型和ServerInfoType（请参见第3.9节）。
o <Mac>: The MAC must be present if the CT-KIP run will result in the replacement of an existing token key with a new one (i.e., if the <KeyID> element was present in the <ClientHello> message). In this case, the CT-KIP server must prove to the cryptographic token that it is authorized to replace it. The MAC value shall be computed on the (ASCII) string "MAC 1 computation", the client's nonce R (if sent), and the server's nonce R_S using an authentication key K_AUTH that should be a special authentication key used only for this purpose but may be the current K_TOKEN.
o <Mac>：如果CT-KIP运行将导致用新令牌密钥替换现有令牌密钥（即，如果<ClientHello>消息中存在<KeyID>元素），则Mac必须存在。在这种情况下，CT-KIP服务器必须向加密令牌证明它有权替换它。MAC值应使用身份验证密钥K_AUTH在（ASCII）字符串“MAC 1计算”、客户端的nonce R（如果已发送）和服务器的nonce R_上计算，该身份验证密钥K_AUTH应为仅用于此目的的特殊身份验证密钥，但可以是当前K_令牌。
The MAC value may be computed by using the CT-KIP-PRF function of Section 3.4, in which case the input parameter s shall be set to the concatenation of the (ASCII) string "MAC 1 computation", R (if sent by the client), and R_S, and k shall be set to K_AUTH. The input parameter dsLen shall be set to the length of R_S:
可使用第3.4节的CT-KIP-PRF函数计算MAC值，在这种情况下，输入参数s应设置为（ASCII）字符串“MAC 1计算”、R（如果由客户端发送）和R_s的串联，k应设置为k_AUTH。输入参数dsLen应设置为R_S的长度：
dsLen = len(R_S)
dsLen=len（R_S）
MAC = CT-KIP-PRF (K_AUTH, "MAC 1 computation" || [R ||] R_S, dsLen)
MAC=CT-KIP-PRF（K_AUTH，“mac1计算”|[R| |]R|S，dsLen）
The CT-KIP client must verify the MAC if the successful execution of the protocol will result in the replacement of an existing token key with a newly generated one. The CT-KIP client must terminate the CT-KIP session if the MAC does not verify, and must delete any nonces, keys, and/or secrets associated with the failed run of the CT-KIP protocol.
如果协议的成功执行将导致用新生成的令牌密钥替换现有令牌密钥，则CT-KIP客户端必须验证MAC。如果MAC未验证，CT-KIP客户端必须终止CT-KIP会话，并且必须删除与CT-KIP协议失败运行相关的任何nonce、密钥和/或机密。
The MacType's MacAlgorithm attribute shall, when present, identify the negotiated MAC algorithm.
MacType的MacAlgorithm属性在出现时应标识协商的MAC算法。
This message contains the nonce chosen by the cryptographic token, R_C, encrypted by the specified encryption key and encryption algorithm.
此消息包含由加密令牌R_C选择的nonce，该令牌由指定的加密密钥和加密算法加密。
<xs:element name="ClientNonce" type="ClientNoncePDU"/>
<xs:element name="ClientNonce" type="ClientNoncePDU"/>
<xs:complexType name="ClientNoncePDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Second message sent from CT-KIP client to
CT-KIP server in a CT-KIP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractRequestType">
<xs:sequence>
<xs:element name="EncryptedNonce"
type="xs:base64Binary"/>
<xs:element name="Extensions"
type="ExtensionsType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="SessionID" type="IdentifierType"
use="required"/>
</xs:extension>
</xs:complexContent>
<xs:complexType name="ClientNoncePDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Second message sent from CT-KIP client to
CT-KIP server in a CT-KIP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractRequestType">
<xs:sequence>
<xs:element name="EncryptedNonce"
type="xs:base64Binary"/>
<xs:element name="Extensions"
type="ExtensionsType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="SessionID" type="IdentifierType"
use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:complexType>
The components of this message have the following meaning:
此消息的组件具有以下含义：
o Version: (inherited from the AbstractRequestType type) Shall be the same version as in the <ServerHello> message.
o 版本：（继承自AbstractRequestType类型）应与<ServerHello>消息中的版本相同。
o SessionID: Shall have the same value as the SessionID attribute in the received <ServerHello> message.
o SessionID：应与收到的<ServerHello>消息中的SessionID属性具有相同的值。
o <EncryptedNonce>: The nonce generated and encrypted by the token. The encryption shall be made using the selected encryption algorithm and identified key, and as specified in Section 3.4.
o <EncryptedNonce>：由令牌生成并加密的nonce。应按照第3.4节的规定，使用选定的加密算法和识别密钥进行加密。
o <Extensions>: A list of extensions. Two extensions are defined for this message in this version of CT-KIP: the ClientInfoType and the ServerInfoType (see Section 3.9).
o <Extensions>：扩展列表。在此版本的CT-KIP中为此消息定义了两个扩展：ClientInfo类型和ServerInfoType（请参见第3.9节）。
This message is the last message of a two roundtrip CT-KIP exchange. The CT-KIP server sends this message to the CT-KIP client in response to the <ClientNonce> message.
此消息是两次往返CT-KIP交换的最后一条消息。CT-KIP服务器将此消息发送到CT-KIP客户端，以响应<ClientNonce>消息。
<xs:element name="ServerFinished" type="ServerFinishedPDU"/>
<xs:element name="ServerFinished" type="ServerFinishedPDU"/>
<xs:complexType name="ServerFinishedPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Final message sent from CT-KIP server to
CT-KIP client in a CT-KIP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="TokenID"
type="xs:base64Binary"/>
<xs:element name="KeyID"
type="xs:base64Binary"/>
<xs:element name="KeyExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="ServiceID"
type="IdentifierType" minOccurs="0"/>
<xs:element name="ServiceLogo"
type="LogoType" minOccurs="0"/>
<xs:element name="UserID"
type="IdentifierType" minOccurs="0"/>
<xs:complexType name="ServerFinishedPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Final message sent from CT-KIP server to
CT-KIP client in a CT-KIP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="TokenID"
type="xs:base64Binary"/>
<xs:element name="KeyID"
type="xs:base64Binary"/>
<xs:element name="KeyExpiryDate"
type="xs:dateTime" minOccurs="0"/>
<xs:element name="ServiceID"
type="IdentifierType" minOccurs="0"/>
<xs:element name="ServiceLogo"
type="LogoType" minOccurs="0"/>
<xs:element name="UserID"
type="IdentifierType" minOccurs="0"/>
<xs:element name="Extensions"
type="ExtensionsType" minOccurs="0"/>
<xs:element name="Mac"
type="MacType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="Extensions"
type="ExtensionsType" minOccurs="0"/>
<xs:element name="Mac"
type="MacType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
The components of this message have the following meaning:
此消息的组件具有以下含义：
o Version: (inherited from the AbstractResponseType type) The CT-KIP version used in this session.
o 版本：（继承自AbstractResponseType）此会话中使用的CT-KIP版本。
o SessionID: (inherited from the AbstractResponseType type) The previously established identifier for this session.
o SessionID：（继承自AbstractResponseType）先前为此会话建立的标识符。
o Status: (inherited from the AbstractResponseType type) Return code for the <ServerFinished> message. If Status is not "Success", only the Status, SessionID, and Version attributes will be present (the presence of the SessionID attribute is dependent on the type of reported error); otherwise, all the other elements must be present as well. In this latter case, the <ServerFinished> message can be seen as a "Commit" message, instructing the cryptographic token to store the generated key and associate the given key identifier with this key.
o 状态：（继承自AbstractResponseType类型）返回<ServerFinished>消息的代码。如果Status不是“Success”，则只显示Status、SessionID和Version属性（SessionID属性的存在取决于报告的错误类型）；否则，所有其他元素也必须存在。在后一种情况下，<ServerFinished>消息可以被视为“提交”消息，指示加密令牌存储生成的密钥并将给定的密钥标识符与该密钥关联。
o <TokenID>: An identifier for the token carrying the generated key. Must have the same value as the <TokenID> element of the <ClientHello> message, if one was provided. When assigned by the CT-KIP server, the <TokenID> element shall be unique within the domain of the CT-KIP server.
o <TokenID>：携带生成密钥的令牌的标识符。必须具有与<ClientHello>消息的<TokenID>元素相同的值（如果提供）。当由CT-KIP服务器分配时，<TokenID>元素在CT-KIP服务器域内应是唯一的。
o <KeyID>: An identifier for the newly generated key. The identifier shall be globally unique. Must have the same value as any key identifier provided by the CT-KIP client in the <ClientHello> message.
o <KeyID>：新生成的密钥的标识符。标识符应具有全局唯一性。必须具有与CT-KIP客户端在<ClientHello>消息中提供的任何密钥标识符相同的值。
The reason for requiring globally unique key identifiers is that it avoids potential conflicts when associating key holders with key identifiers. One way of achieving global uniqueness with reasonable certainty is to hash the combination of the issuer's fully qualified domain name with an (issuer-specific) serial number, assuming that each issuer makes sure their serial numbers never repeat.
要求全局唯一密钥标识符的原因是，在将密钥持有者与密钥标识符关联时，可以避免潜在的冲突。合理确定地实现全局唯一性的一种方法是将发行人的完全限定域名与（发行人特定的）序列号的组合散列，假设每个发行人确保其序列号永不重复。
CT-KIP clients must support key identifiers at least 64 octets long. CT-KIP servers should not generate key identifiers longer than 64 octets.
CT-KIP客户端必须支持至少64个八位字节长的密钥标识符。CT-KIP服务器生成的密钥标识符不应超过64个八位字节。
o <KeyExpiryDate>: This optional element provides the date and time after which the generated key should be treated as expired and invalid.
o <KeyExpiryDate>：此可选元素提供日期和时间，在此日期和时间之后，生成的密钥应被视为过期和无效。
o <ServiceID>: An optional identifier for the service that has stored the generated key. The cryptographic token may store this identifier associated with the key in order to simplify later lookups. The identifier shall be a printable string.
o <ServiceID>：存储生成密钥的服务的可选标识符。加密令牌可以存储与密钥相关联的该标识符，以便简化以后的查找。标识符应为可打印字符串。
o <ServiceLogo>: This optional element provides a graphical logo image for the service that can be displayed in user interfaces, e.g., to help a user select a certain key. The logo should contain an image within the size range of 60 pixels wide by 45 pixels high, and 200 pixels wide by 150 pixels high. The required MimeType attribute of this type provides information about the MIME type of the image. This specification supports both the JPEG and GIF image formats (with MIME types of "image/jpeg" and "image/ gif").
o <ServiceLogo>：此可选元素为服务提供可在用户界面中显示的图形徽标图像，例如，帮助用户选择某个键。徽标应包含大小范围为60像素宽45像素高和200像素宽150像素高的图像。此类型所需的MimeType属性提供有关映像的MIME类型的信息。此规范支持JPEG和GIF图像格式（MIME类型为“image/JPEG”和“image/GIF”）。
o <UserID>: An optional identifier for the user associated with the generated key in the authentication service. The cryptographic token may store this identifier associated with the generated key in order to enhance later user experiences. The identifier shall be a printable string.
o <UserID>：与身份验证服务中生成的密钥关联的用户的可选标识符。加密令牌可以存储与生成的密钥相关联的该标识符，以便增强以后的用户体验。标识符应为可打印字符串。
o <Extensions>: A list of extensions chosen by the CT-KIP server. For this message, this version of CT-KIP defines two extensions, the OTPKeyConfigurationDataType and the ClientInfoType (see Section 3.9).
o <Extensions>：CT-KIP服务器选择的扩展列表。对于此消息，此版本的CT-KIP定义了两个扩展，OTPKeyConfigurationDataType和ClientInfo类型（请参见第3.9节）。
o <Mac>: To avoid a false "Commit" message causing the token to end up in an initialized state for which the server does not know the stored key, <ServerFinished> messages must always be authenticated with a MAC. The MAC shall be made using the already established MAC algorithm. The MAC value shall be computed on the (ASCII) string "MAC 2 computation" and R_C using an authentication key K_AUTH. Again, this should be a special authentication key used only for this purpose, but may also be an existing K_TOKEN. (In this case, implementations must protect against attacks where K_TOKEN is used to pre-compute MAC values.) If no authentication key is present in the token, and no K_TOKEN existed before the CT-KIP run, K_AUTH shall be the newly generated K_TOKEN.
o <Mac>：为了避免错误的“提交”消息导致令牌最终处于初始化状态，而服务器不知道存储的密钥，<ServerFinished>消息必须始终使用Mac进行身份验证。应使用已建立的MAC算法进行MAC。应使用认证密钥K_AUTH在（ASCII）字符串“MAC 2计算”和R_C上计算MAC值。同样，这应该是仅用于此目的的特殊身份验证密钥，但也可以是现有的K_令牌。（在这种情况下，实现必须防止K_令牌用于预计算MAC值的攻击。）如果令牌中不存在身份验证密钥，并且在CT-KIP运行之前不存在K_令牌，K_AUTH应为新生成的K_令牌。
If CT-KIP-PRF is used as the MAC algorithm, then the input parameter s shall consist of the concatenation of the (ASCII) string "MAC 2 computation" and R_C, and the parameter dsLen shall be set to the length of R_C:
如果使用CT-KIP-PRF作为MAC算法，则输入参数s应包括（ASCII）字符串“MAC 2计算”和R_C的串联，并且参数dsLen应设置为R_C的长度：
dsLen = len(R_C)
dsLen=len（R_C）
MAC = CT-KIP-PRF (K_AUTH, "MAC 2 computation" || R_C, dsLen)
MAC=CT-KIP-PRF（K|u AUTH，“MAC 2计算”| R|C，dsLen）
When receiving a <ServerFinished> message with Status = "Success" for which the MAC verifies, the CT-KIP client shall associate the generated key K_TOKEN with the provided key identifier and store this data permanently. After this operation, it shall not be possible to overwrite the key unless knowledge of an authorizing key is proven through a MAC on a later <ServerHello> (and <ServerFinished>) message.
当收到MAC验证的带有Status=“Success”的<ServerFinished>消息时，CT-KIP客户端应将生成的密钥K_令牌与提供的密钥标识符相关联，并永久存储该数据。此操作后，除非通过稍后的<ServerHello>（和<ServerFinished>）消息上的MAC证明知道授权密钥，否则不可能覆盖密钥。
The CT-KIP client must verify the MAC. The CT-KIP client must terminate the CT-KIP session if the MAC does not verify, and must, in this case, also delete any nonces, keys, and/or secrets associated with the failed run of the CT-KIP protocol.
CT-KIP客户端必须验证MAC。如果MAC未验证，CT-KIP客户端必须终止CT-KIP会话，并且在这种情况下，还必须删除与CT-KIP协议失败运行相关的任何nonce、密钥和/或机密。
The MacType's MacAlgorithm attribute shall, when present, identify the negotiated MAC algorithm.
MacType的MacAlgorithm属性在出现时应标识协商的MAC算法。
When present in a <ClientHello> or a <ClientNonce> message, the optional ClientInfoType extension contains CT-KIP client-specific information. CT-KIP servers must support this extension. CT-KIP servers must not attempt to interpret the data it carries and, if received, must include it unmodified in the current protocol run's next server response. Servers need not retain the ClientInfoType's data after that response has been generated.
当出现在<ClientHello>或<ClientNonce>消息中时，可选的ClientInfo扩展包含CT-KIP客户端特定信息。CT-KIP服务器必须支持此扩展。CT-KIP服务器不得试图解释其携带的数据，如果收到，必须在当前协议运行的下一个服务器响应中包含未修改的数据。在生成响应后，服务器不需要保留ClientInfo类型的数据。
<xs:complexType name="ClientInfoType">
<xs:complexContent>
<xs:extension base="AbstractExtensionType">
<xs:sequence>
<xs:element name="Data"
type="xs:base64Binary"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="ClientInfoType">
<xs:complexContent>
<xs:extension base="AbstractExtensionType">
<xs:sequence>
<xs:element name="Data"
type="xs:base64Binary"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
When present, the optional ServerInfoType extension contains CT-KIP server-specific information. This extension is only valid in <ServerHello> messages for which Status = "Continue". CT-KIP clients must support this extension. CT-KIP clients must not attempt to interpret the data it carries and, if received, must include it unmodified in the current protocol run's next client request (i.e., the <ClientNonce> message). CT-KIP clients need not retain the ServerInfoType's data after that request has been generated. This extension may be used, e.g., for state management in the CT-KIP server.
如果存在，可选的ServerInfoType扩展包含CT-KIP服务器特定的信息。此扩展仅在Status=“Continue”的<ServerHello>消息中有效。CT-KIP客户端必须支持此扩展。CT-KIP客户端不得试图解释其携带的数据，如果收到，必须在当前协议运行的下一个客户端请求（即<ClientNonce>消息）中包含未经修改的数据。生成请求后，CT-KIP客户端无需保留ServerInfoType的数据。此扩展可用于CT-KIP服务器中的状态管理。
<xs:complexType name="ServerInfoType">
<xs:complexContent>
<xs:extension base="AbstractExtensionType">
<xs:sequence>
<xs:element name="Data"
type="xs:base64Binary"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="ServerInfoType">
<xs:complexContent>
<xs:extension base="AbstractExtensionType">
<xs:sequence>
<xs:element name="Data"
type="xs:base64Binary"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
The optional OTPKeyConfigurationDataType extension contains additional key configuration data for OTP keys:
可选的OTPKeyConfigurationDataType扩展包含OTP密钥的其他密钥配置数据：
<xs:complexType name="OTPKeyConfigurationDataType">
<xs:annotation>
<xs:documentation xml:lang="en">
This extension is only valid in ServerFinished
PDUs. It carries additional configuration data
that an OTP token should use (subject to local
policy) when generating OTP values with a newly
generated OTP key.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="ExtensionType">
<xs:sequence>
<xs:element name="OTPFormat"
type="OTPFormatType"/>
<xs:element name="OTPLength"
type="xs:positiveInteger"/>
<xs:element name="OTPMode"
type="OTPModeType" minOccurs="0"/>
<xs:complexType name="OTPKeyConfigurationDataType">
<xs:annotation>
<xs:documentation xml:lang="en">
This extension is only valid in ServerFinished
PDUs. It carries additional configuration data
that an OTP token should use (subject to local
policy) when generating OTP values with a newly
generated OTP key.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="ExtensionType">
<xs:sequence>
<xs:element name="OTPFormat"
type="OTPFormatType"/>
<xs:element name="OTPLength"
type="xs:positiveInteger"/>
<xs:element name="OTPMode"
type="OTPModeType" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
This extension is only valid in <ServerFinished> messages. It carries additional configuration data that the cryptographic token should use (subject to local policy) when generating OTP values from the newly generated OTP key. The components of this extension have the following meaning:
此扩展仅在<ServerFinished>消息中有效。它携带加密令牌在从新生成的OTP密钥生成OTP值时应使用的额外配置数据（根据本地策略）。本扩展的组成部分具有以下含义：
o OTPFormat: The default format of OTPs produced with this key.
o OTP格式：使用此键生成的OTP的默认格式。
o OTPLength: The default length of OTPs produced with this key.
o OTPLength：使用此密钥生成的OTP的默认长度。
o OTPMode: The default mode of operation when producing OTPs with this key.
o OTP模式：使用此键生成OTP时的默认操作模式。
CT-KIP assumes a reliable transport.
CT-KIP假设传输可靠。
This section presents a binding of the previous messages to HTTP/1.1 [7]. Note that the HTTP client normally will be different from the CT-KIP client, i.e., the HTTP client will only exist to "proxy" CT-KIP messages from the CT-KIP client to the CT-KIP server. Likewise, on the HTTP server side, the CT-KIP server may receive CT-KIP PDUs from a "front-end" HTTP server.
本节介绍以前的消息到HTTP/1.1[7]的绑定。请注意，HTTP客户端通常与CT-KIP客户端不同，即HTTP客户端的存在只是为了将CT-KIP客户端的CT-KIP消息“代理”到CT-KIP服务器。同样，在HTTP服务器端，CT-KIP服务器可以从“前端”HTTP服务器接收CT-KIP PDU。
The MIME-type for all CT-KIP messages shall be
所有CT-KIP消息的MIME类型应为
application/vnd.otps.ct-kip+xml
application/vnd.otps.ct kip+xml
HTTP proxies must not cache responses carrying CT-KIP messages. For this reason, the following holds:
HTTP代理不能缓存承载CT-KIP消息的响应。因此，以下情况适用：
o When using HTTP/1.1, requesters should:
o 使用HTTP/1.1时，请求者应：
* Include a Cache-Control header field set to "no-cache, no-store".
* 包括设置为“无缓存，无存储”的缓存控制标头字段。
* Include a Pragma header field set to "no-cache".
* 包括设置为“无缓存”的杂注标题字段。
o When using HTTP/1.1, responders should:
o 使用HTTP/1.1时，响应者应：
* Include a Cache-Control header field set to "no-cache, no-must-revalidate, private".
* 包括设置为“无缓存，无需重新验证，专用”的缓存控制标头字段。
* Include a Pragma header field set to "no-cache".
* 包括设置为“无缓存”的杂注标题字段。
* NOT include a Validator, such as a Last-Modified or ETag header.
* 不包括验证器，例如上次修改的或ETag头。
There are no other restrictions on HTTP headers, besides the requirement to set the Content-Type header value to application/ vnd.otps.ct-kip+xml.
除了将内容类型头值设置为application/vnd.otps.ct kip+xml之外，HTTP头没有其他限制。
Persistent connections as defined in HTTP/1.1 are assumed but not required. CT-KIP requests are mapped to HTTP POST operations. CT-KIP responses are mapped to HTTP responses.
HTTP/1.1中定义的持久连接是假定的，但不是必需的。CT-KIP请求映射到HTTP POST操作。CT-KIP响应映射到HTTP响应。
A CT-KIP HTTP responder that refuses to perform a message exchange with a CT-KIP HTTP requester should return a 403 (Forbidden) response. In this case, the content of the HTTP body is not significant. In the case of an HTTP error while processing a CT-KIP request, the HTTP server must return a 500 (Internal Server Error) response. This type of error should be returned for HTTP-related errors detected before control is passed to the CT-KIP processor, or when the CT-KIP processor reports an internal error (for example, the CT-KIP XML namespace is incorrect, or the CT-KIP schema cannot be located). If the type of a CT-KIP request cannot be determined, the CT-KIP responder must return a 400 (Bad request) response.
拒绝与CT-KIP HTTP请求程序执行消息交换的CT-KIP HTTP响应程序应返回403（禁止）响应。在这种情况下，HTTP正文的内容并不重要。如果在处理CT-KIP请求时出现HTTP错误，HTTP服务器必须返回500（内部服务器错误）响应。对于在将控制传递给CT-KIP处理器之前检测到的HTTP相关错误，或者当CT-KIP处理器报告内部错误时（例如，CT-KIP XML命名空间不正确，或者找不到CT-KIP架构），应返回此类错误。如果无法确定CT-KIP请求的类型，则CT-KIP响应程序必须返回400（错误请求）响应。
In these cases (i.e., when the HTTP response code is 4xx or 5xx), the content of the HTTP body is not significant.
在这些情况下（即，当HTTP响应代码为4xx或5xx时），HTTP正文的内容并不重要。
Redirection status codes (3xx) apply as usual.
重定向状态代码（3xx）照常适用。
Whenever the HTTP POST is successfully invoked, the CT-KIP HTTP responder must use the 200 status code and provide a suitable CT-KIP message (possibly with CT-KIP error information included) in the HTTP body.
每当成功调用HTTP POST时，CT-KIP HTTP响应程序必须使用200状态代码，并在HTTP正文中提供适当的CT-KIP消息（可能包含CT-KIP错误信息）。
No support for HTTP/1.1 authentication is assumed.
假定不支持HTTP/1.1身份验证。
The CT-KIP server may initialize the CT-KIP protocol by sending an HTTP response with Content-Type set to application/ vnd.otps.ct-kip+xml and response code set to 200 (OK). This message may, e.g., be sent in response to a user requesting token initialization in a browsing session. The initialization message may carry data in its body. If this is the case, the data shall be a valid instance of a <CT-KIPTrigger> element.
CT-KIP服务器可以通过发送内容类型设置为application/vnd.otps.CT KIP+xml且响应代码设置为200（OK）的HTTP响应来初始化CT-KIP协议。例如，可以发送该消息以响应在浏览会话中请求令牌初始化的用户。初始化消息的正文中可能包含数据。在这种情况下，数据应为<CT KIPTrigger>元素的有效实例。
a. Initialization from CT-KIP server:
a. 从CT-KIP服务器初始化：
HTTP/1.1 200 OK
Cache-Control: no-store
Content-Type: application/vnd.otps.ct-kip+xml
Content-Length: <some value>
HTTP/1.1 200 OK
Cache-Control: no-store
Content-Type: application/vnd.otps.ct-kip+xml
Content-Length: <some value>
CT-KIP initialization data in XML form...
XML格式的CT-KIP初始化数据。。。
b. Initial request from CT-KIP client:
b. CT-KIP客户的初始请求：
POST http://example.com/cgi-bin/CT-KIP-server HTTP/1.1
Cache-Control: no-store
Pragma: no-cache
Host: example.com
Content-Type: application/vnd.otps.ct-kip+xml
Content-Length: <some value>
POST http://example.com/cgi-bin/CT-KIP-server HTTP/1.1
Cache-Control: no-store
Pragma: no-cache
Host: example.com
Content-Type: application/vnd.otps.ct-kip+xml
Content-Length: <some value>
CT-KIP data in XML form (supported version, supported algorithms...)
XML格式的CT-KIP数据（支持的版本、支持的算法…）
c. Initial response from CT-KIP server:
c. CT-KIP服务器的初始响应：
HTTP/1.1 200 OK
Cache-Control: no-store
Content-Type: application/vnd.otps.ct-kip+xml
Content-Length: <some other value>
HTTP/1.1 200 OK
Cache-Control: no-store
Content-Type: application/vnd.otps.ct-kip+xml
Content-Length: <some other value>
CT-KIP data in XML form (server random nonce, server public key, ...)
XML格式的CT-KIP数据（服务器随机时值、服务器公钥等）
CT-KIP is designed to protect generated key material from exposure. No other entities than the CT-KIP server and the cryptographic token will have access to a generated K_TOKEN if the cryptographic algorithms used are of sufficient strength and, on the CT-KIP client side, generation and encryption of R_C and generation of K_TOKEN take place as specified and in the token. This applies even if malicious software is present in the CT-KIP client. However, as discussed in the following, CT-KIP does not protect against certain other threats resulting from man-in-the-middle attacks and other forms of attacks. CT-KIP should, therefore, be run over a transport providing privacy and integrity, such as HTTP over Transport Layer Security (TLS) with a suitable ciphersuite, when such threats are a concern. Note that TLS ciphersuites with anonymous key exchanges are not suitable in those situations.
CT-KIP旨在保护生成的关键材料不受暴露。如果所使用的加密算法具有足够的强度，并且在CT-KIP客户端上，R_C的生成和加密以及K_令牌的生成按照令牌中的规定进行，则CT-KIP服务器和加密令牌以外的任何其他实体都无权访问生成的K_令牌。即使CT-KIP客户端中存在恶意软件，这也适用。但是，如下文所述，CT-KIP无法抵御中间人攻击和其他形式的攻击造成的某些其他威胁。因此，CT-KIP应在提供隐私和完整性的传输上运行，如HTTP over transport Layer Security（TLS）和适当的密码套件（当此类威胁受到关注时）。请注意，具有匿名密钥交换的TLS密码套件不适用于这些情况。
An active attacker may attempt to modify, delete, insert, replay or reorder messages for a variety of purposes including service denial and compromise of generated key material. Sections 5.2.2 through 5.2.7 analyze these attack scenarios.
主动攻击者可能出于各种目的，包括拒绝服务和泄露生成的密钥材料，试图修改、删除、插入、重播或重新排序消息。第5.2.2至5.2.7节分析了这些攻击场景。
Modifications to a <CT-KIPTrigger> message will either cause denial-of-service (modifications of any of the identifiers or the nonce) or the CT-KIP client to contact the wrong CT-KIP server. The latter is in effect a man-in-the-middle attack and is discussed further in Section 5.2.7.
对<CT KIPTrigger>消息的修改将导致拒绝服务（修改任何标识符或nonce）或CT-KIP客户端联系错误的CT-KIP服务器。后者实际上是中间人攻击，第5.2.7节将进一步讨论。
An attacker may modify a <ClientHello> message. This means that the attacker could indicate a different key or token than the one intended by the CT-KIP client, and could also suggest other
攻击者可以修改<ClientHello>消息。这意味着攻击者可能会指示与CT-KIP客户端预期的密钥或令牌不同的密钥或令牌，也可能会建议其他密钥或令牌
cryptographic algorithms than the ones preferred by the CT-KIP client, e.g., cryptographically weaker ones. The attacker could also suggest earlier versions of the CT-KIP protocol, in case these versions have been shown to have vulnerabilities. These modifications could lead to an attacker succeeding in initializing or modifying another token than the one intended (i.e., the server assigning the generated key to the wrong token), or gaining access to a generated key through the use of weak cryptographic algorithms or protocol versions. CT-KIP implementations may protect against the latter by having strict policies about what versions and algorithms they support and accept. The former threat (assignment of a generated key to the wrong token) is not possible when the shared-key variant of CT-KIP is employed (assuming existing shared keys are unique per token) but is possible in the public-key variant. Therefore, CT-KIP servers must not accept unilaterally provided token identifiers in the public-key variant. This is also indicated in the protocol description. In the shared-key variant, however, an attacker may be able to provide the wrong identifier (possibly also leading to the incorrect user being associated with the generated key) if the attacker has real-time access to the token with the identified key. In other words, the generated key is associated with the correct token but the token is associated with the incorrect user. See further Section 5.5 for a discussion of this threat and possible countermeasures.
与CT-KIP客户端首选的加密算法相比，加密算法更弱。攻击者还可以建议CT-KIP协议的早期版本，以防这些版本存在漏洞。这些修改可能导致攻击者成功初始化或修改另一个令牌（即，服务器将生成的密钥分配给错误的令牌），或通过使用弱加密算法或协议版本访问生成的密钥。CT-KIP实现可以通过对其支持和接受的版本和算法制定严格的政策来防范后者。前一种威胁（将生成的密钥分配给错误的令牌）在使用CT-KIP的共享密钥变体时是不可能的（假设每个令牌的现有共享密钥是唯一的），但在公钥变体中是可能的。因此，CT-KIP服务器不得接受公钥变体中单方面提供的令牌标识符。协议说明中也指出了这一点。但是，在共享密钥变体中，如果攻击者能够使用已识别的密钥实时访问令牌，则攻击者可能会提供错误的标识符（也可能导致错误的用户与生成的密钥关联）。换句话说，生成的密钥与正确的令牌相关联，但令牌与错误的用户相关联。有关此威胁和可能的对策的讨论，请参见第5.5节。
An attacker may also modify a <ServerHello> message. This means that the attacker could indicate different key types, algorithms, or protocol versions than the legitimate server would, e.g., cryptographically weaker ones. The attacker could also provide a different nonce than the one sent by the legitimate server. Clients will protect against the former through strict adherence to policies regarding permissible algorithms and protocol versions. The latter (wrong nonce) will not constitute a security problem, as a generated key will not match the key generated on the legitimate server. Also, whenever the CT-KIP run would result in the replacement of an existing key, the <Mac> element protects against modifications of R_S.
攻击者还可以修改<ServerHello>消息。这意味着攻击者可以指示与合法服务器不同的密钥类型、算法或协议版本，例如加密较弱的密钥类型、算法或协议版本。攻击者还可以提供与合法服务器发送的nonce不同的nonce。客户将通过严格遵守有关允许的算法和协议版本的政策来防范前者。后者（错误的nonce）不会构成安全问题，因为生成的密钥与合法服务器上生成的密钥不匹配。此外，每当CT-KIP运行会导致替换现有密钥时，<Mac>元素可防止R_的修改。
Modifications of <ClientNonce> messages are also possible. If an attacker modifies the SessionID attribute, then, in effect, a switch to another session will occur at the server, assuming the new SessionID is valid at that time on the server. It still will not allow the attacker to learn a generated K_TOKEN since R_C has been wrapped for the legitimate server. Modifications of the <EncryptedNonce> element, e.g., replacing it with a value for which the attacker knows an underlying R'C, will not result in the client changing its pre-CT-KIP state, since the server will be unable to provide a valid MAC in its final message to the client. The server
也可以修改<ClientNonce>消息。如果攻击者修改SessionID属性，那么实际上，服务器上将切换到另一个会话，假设新SessionID当时在服务器上有效。它仍然不允许攻击者学习生成的K_令牌，因为R_C已为合法服务器包装。修改<EncryptedNonce>元素（例如，将其替换为攻击者知道基础R'C的值）不会导致客户端更改其CT前KIP状态，因为服务器将无法在其发送给客户端的最终消息中提供有效的MAC。服务器
may, however, end up storing K'TOKEN rather than K_TOKEN. If the token has been associated with a particular user, then this could constitute a security problem. For a further discussion about this threat, and a possible countermeasure, see Section 5.5 below. Note that use of Secure Socket Layer (SSL) or TLS does not protect against this attack if the attacker has access to the CT-KIP client (e.g., through malicious software, "trojans").
然而，最终可能会存储K'TOKEN而不是K_-TOKEN。如果令牌已与特定用户关联，则这可能构成安全问题。有关此威胁和可能对策的进一步讨论，请参见下文第5.5节。请注意，如果攻击者可以访问CT-KIP客户端（例如，通过恶意软件“特洛伊木马”），则使用安全套接字层（SSL）或TLS无法防止此攻击。
Finally, attackers may also modify the <ServerFinished> message. Replacing the <Mac> element will only result in denial-of-service. Replacement of any other element may cause the CT-KIP client to associate, e.g., the wrong service with the generated key. CT-KIP should be run over a transport providing privacy and integrity when this is a concern.
最后，攻击者还可以修改<ServerFinished>消息。替换<Mac>元素只会导致拒绝服务。替换任何其他元素可能会导致CT-KIP客户端将错误的服务与生成的密钥相关联。CT-KIP应在提供隐私和完整性的交通工具上运行。
Message deletion will not cause any other harm than denial-of-service, since a token shall not change its state (i.e., "commit" to a generated key) until it receives the final message from the CT-KIP server and successfully has processed that message, including validation of its MAC. A deleted <ServerFinished> message will not cause the server to end up in an inconsistent state vis-a-vis the token if the server implements the suggestions in Section 5.5.
消息删除不会造成拒绝服务以外的任何其他伤害，因为令牌在从CT-KIP服务器接收到最终消息并成功处理该消息（包括验证其MAC）之前，不得更改其状态（即，“提交”到生成的密钥）。如果服务器执行第5.5节中的建议，则删除的<ServerFinished>消息不会导致服务器与令牌处于不一致的状态。
An active attacker may initiate a CT-KIP run at any time, and suggest any token identifier. CT-KIP server implementations may receive some protection against inadvertently initializing a token or inadvertently replacing an existing key or assigning a key to a token by initializing the CT-KIP run by use of the <CT-KIPTrigger>. The <TriggerNonce> element allows the server to associate a CT-KIP protocol run with, e.g., an earlier user-authenticated session. The security of this method, therefore, depends on the ability to protect the <TriggerNonce> element in the CT-KIP initialization message. If an eavesdropper is able to capture this message, he may race the legitimate user for a key initialization. CT-KIP over a transport providing privacy and integrity, coupled with the recommendations in Section 5.5, is recommended when this is a concern.
主动攻击者可随时启动CT-KIP运行，并建议任何令牌标识符。CT-KIP服务器实现可以通过使用<CT KIPTrigger>初始化CT-KIP运行来获得一些保护，防止无意中初始化令牌或无意中替换现有密钥或将密钥分配给令牌。<TriggerNonce>元素允许服务器将运行的CT-KIP协议与早期用户验证会话相关联。因此，此方法的安全性取决于保护CT-KIP初始化消息中<Triggernance>元素的能力。如果窃听者能够捕获此消息，他可能会与合法用户竞争密钥初始化。当涉及此问题时，建议使用CT-KIP，该传输提供隐私和完整性，并结合第5.5节中的建议。
Insertion of other messages into an existing protocol run is seen as equivalent to modification of legitimately sent messages.
将其他消息插入现有协议运行被视为等同于修改合法发送的消息。
Attempts to replay a previously recorded CT-KIP message will be detected, as the use of nonces ensures that both parties are live.
将检测到试图重播先前录制的CT-KIP消息，因为使用nonce可确保双方都处于活动状态。
An attacker may attempt to re-order messages but this will be detected, as each message is of a unique type.
攻击者可能会尝试对邮件重新排序，但这会被检测到，因为每条邮件都具有唯一的类型。
In addition to other active attacks, an attacker posing as a man in the middle may be able to provide his own public key to the CT-KIP client. This threat and countermeasures to it are discussed in Section 3.3. An attacker posing as a man-in-the-middle may also be acting as a proxy and, hence, may not interfere with CT-KIP runs but still learn valuable information; see Section 5.3.
除了其他主动攻击，作为中间人的攻击者可能能够向CT-KIP客户端提供自己的公钥。第3.3节讨论了这种威胁及其对策。伪装成中间人的攻击者也可能充当代理，因此可能不会干扰CT-KIP的运行，但仍能获得有价值的信息；见第5.3节。
Passive attackers may eavesdrop on CT-KIP runs to learn information that later on may be used to impersonate users, mount active attacks, etc.
被动攻击者可能窃听CT-KIP运行，以了解稍后可能用于模拟用户、发起主动攻击等的信息。
If CT-KIP is not run over a transport providing privacy, a passive attacker may learn:
如果CT-KIP未在提供隐私的传输上运行，则被动攻击者可能会了解：
o What tokens a particular user is in possession of;
o 特定用户拥有什么令牌；
o The identifiers of keys on those tokens and other attributes pertaining to those keys, e.g., the lifetime of the keys; and
o 这些令牌上的密钥标识符以及与这些密钥相关的其他属性，例如密钥的生存期；和
o CT-KIP versions and cryptographic algorithms supported by a particular CT-KIP client or server.
o 特定CT-KIP客户端或服务器支持的CT-KIP版本和加密算法。
Whenever the above is a concern, CT-KIP should be run over a transport providing privacy. If man-in-the-middle attacks for the purposes described above are a concern, the transport should also offer server-side authentication.
只要存在上述问题，CT-KIP应在提供隐私的交通工具上运行。如果出于上述目的的中间人攻击是一个问题，那么传输还应该提供服务器端身份验证。
An attacker with unlimited access to an initialized token may use the token as an "oracle" to pre-compute values that later on may be used to impersonate the CT-KIP server. Sections 3.6 and 3.8 contain discussions of this threat and steps recommended to protect against it.
对已初始化令牌具有无限访问权限的攻击者可将该令牌用作“oracle”来预计算值，这些值稍后可用于模拟CT-KIP服务器。第3.6节和第3.8节讨论了这种威胁，并建议采取措施防止这种威胁。
If keys generated in CT-KIP will be associated with a particular user at the CT-KIP server (or a server trusted by, and communicating with the CT-KIP server), then in order to protect against threats where an attacker replaces a client-provided encrypted R_C with his own R'C (regardless of whether the public-key variant or the shared-secret variant of CT-KIP is employed to encrypt the client nonce), the server should not commit to associate a generated K_TOKEN with the given token (user) until the user simultaneously has proven both possession of a token containing K_TOKEN and some out-of-band provided authenticating information (e.g., a temporary password). For example, if the token is a one-time password token, the user could be required to authenticate with both a one-time password generated by the token and an out-of-band provided temporary PIN in order to have the server "commit" to the generated token value for the given user. Preferably, the user should perform this operation from another host than the one used to initialize the token, in order to minimize the risk of malicious software on the client interfering with the process.
如果在CT-KIP中生成的密钥将与CT-KIP服务器（或CT-KIP服务器信任并与之通信的服务器）上的特定用户相关联，则为了防止攻击者用自己的R'C替换客户端提供的加密R_C的威胁（无论是使用CT-KIP的公钥变量还是共享秘密变量加密客户端nonce），服务器都不应承诺将生成的K_令牌与给定令牌（用户）关联直到用户同时证明拥有包含K_令牌的令牌和一些带外提供的身份验证信息（例如，临时密码）。例如，如果令牌是一次性密码令牌，则可能要求用户使用令牌生成的一次性密码和带外提供的临时PIN进行身份验证，以便服务器“提交”为给定用户生成的令牌值。用户最好从用于初始化令牌的主机以外的另一台主机执行此操作，以便将客户端上恶意软件干扰进程的风险降至最低。
Another threat arises when an attacker is able to trick a user to authenticate to the attacker rather than to the legitimate service before the CT-KIP protocol run. If successful, the attacker will then be able to impersonate the user towards the legitimate service, and subsequently receive a valid CT-KIP trigger. If the public-key variant of CT-KIP is used, this may result in the attacker being able to (after a successful CT-KIP protocol run) impersonate the user. Ordinary precautions must, therefore, be in place to ensure that users authenticate only to legitimate services.
当攻击者能够欺骗用户在CT-KIP协议运行之前向攻击者而不是向合法服务进行身份验证时，就会产生另一种威胁。如果成功，攻击者将能够向合法服务模拟用户，并随后收到有效的CT-KIP触发器。如果使用了CT-KIP的公钥变体，这可能会导致攻击者（在成功运行CT-KIP协议后）模拟用户。因此，必须采取常规预防措施，以确保用户仅对合法服务进行身份验证。
RSA and SecurID are registered trademarks or trademarks of RSA Security Inc. in the United States and/or other countries. The names of other products and services mentioned may be the trademarks of their respective owners.
RSA和SecurID是RSA Security Inc.在美国和/或其他国家/地区的注册商标或商标。提及的其他产品和服务的名称可能是其各自所有者的商标。
[1] Davis, M. and M. Duerst, "Unicode Normalization Forms", March 2001, <http://www.unicode.org/unicode/reports/tr15/tr15-21.html>.
[1] Davis，M.和M.Duerst，“Unicode规范化表单”，2001年3月<http://www.unicode.org/unicode/reports/tr15/tr15-21.html>.
[2] RSA Laboratories, "PKCS #11 Mechanisms for the Cryptographic Token Key Initialization Protocol", PKCS #11 Version 2.20 Amendment 2, December 2005, <ftp://ftp.rsasecurity.com/pub/ pkcs/pkcs-11/v2-20/pkcs-11v2-20a2.pdf>.
[2] RSA实验室，“PKCS#11加密令牌密钥初始化协议的机制”，PKCS#11版本2.20修订版2，2005年12月<ftp://ftp.rsasecurity.com/pub/ pkcs/pkcs-11/v2-20/pkcs-11v2-20a2.pdf>。
[3] RSA Laboratories, "Cryptographic Token Interface Standard", PKCS #11 Version 2.20, June 2004, <ftp://ftp.rsasecurity.com/ pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf>.
[3] RSA实验室，“加密令牌接口标准”，PKCS#11版本2.20，2004年6月<ftp://ftp.rsasecurity.com/ pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf>。
[4] RSA Laboratories, "Frequently Asked Questions About Today's Cryptography. Version 4.1", 2000, <http://www.rsasecurity.com/ rsalabs/faq/files/rsalabs_faq41.pdf>.
[4] RSA Laboratories，“关于当今密码学的常见问题。版本4.1”，2000年<http://www.rsasecurity.com/ rsalabs/faq/files/rsalabs_faq41.pdf>。
[5] RSA Laboratories, "Password-Based Cryptography Standard", PKCS #5 Version 2.0, March 1999, <ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf>.
[5] RSA实验室，“基于密码的加密标准”，PKCS#5 2.0版，1999年3月<ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf>.
[6] RSA Laboratories, "RSA Cryptography Standard", PKCS #1 Version 2.1, June 2002, <ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf>.
[6] RSA实验室，“RSA加密标准”，PKCS#1版本2.1，2002年6月<ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf>.
[7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[7] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[8] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)", FIPS 197, November 2001, <http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.
[8] 国家标准与技术研究所，“高级加密标准（AES）规范”，FIPS 197，2001年11月<http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf>.
[9] Krawzcyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[9] Krawzcyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC2104，1997年2月。
[10] Iwata, T. and K. Kurosawa, "OMAC: One-Key CBC MAC. In Fast Software Encryption, FSE 2003, pages 129 - 153. Springer-Verlag", 2003, <http://crypt.cis.ibaraki.ac.jp/omac/docs/omac.pdf>.
[10] 岩田，T.和K.黑泽明，“OMAC:One Key CBC MAC.在快速软件加密中，FSE 2003，第129-153页，Springer Verlag”，2003<http://crypt.cis.ibaraki.ac.jp/omac/docs/omac.pdf>.
[11] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 197, February 2004, <http://csrc.nist.gov/ publications/fips/fips180-2/fips180-2withchangenotice.pdf>.
[11] 国家标准与技术研究所，“安全哈希标准”，FIPS 197，2004年2月<http://csrc.nist.gov/ 出版物/fips/fips180-2/fips180-2 WithChangeNotice.pdf>。
[12] RSA Laboratories, "Cryptographic Token Key Initialization Protocol", OTPS Version 1.0, December 2005, <ftp://ftp.rsasecurity.com/pub/otps/ct-kip/ct-kip-v1-0.pdf>.
[12] RSA实验室，“加密令牌密钥初始化协议”，OTPS版本1.0，2005年12月<ftp://ftp.rsasecurity.com/pub/otps/ct-kip/ct-kip-v1-0.pdf>.
<xs:schema
targetNamespace=
"http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns=
"http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#">
<xs:schema
targetNamespace=
"http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns=
"http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#">
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
xmldsig-core-schema.xsd"/>
<xs:import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation=
"http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/
xmldsig-core-schema.xsd"/>
<!-- Basic types -->
<!-- Basic types -->
<xs:complexType name="AbstractRequestType" abstract="true">
<xs:attribute name="Version" type="VersionType" use="required"/>
</xs:complexType>
<xs:complexType name="AbstractRequestType" abstract="true">
<xs:attribute name="Version" type="VersionType" use="required"/>
</xs:complexType>
<xs:complexType name="AbstractResponseType" abstract="true">
<xs:attribute name="Version" type="VersionType" use="required"/>
<xs:attribute name="SessionID" type="IdentifierType"/>
<xs:attribute name="Status" type="StatusCode" use="required"/>
</xs:complexType>
<xs:complexType name="AbstractResponseType" abstract="true">
<xs:attribute name="Version" type="VersionType" use="required"/>
<xs:attribute name="SessionID" type="IdentifierType"/>
<xs:attribute name="Status" type="StatusCode" use="required"/>
</xs:complexType>
<xs:simpleType name="StatusCode">
<xs:restriction base="xs:string">
<xs:enumeration value="Continue"/>
<xs:enumeration value="Success"/>
<xs:enumeration value="Abort"/>
<xs:enumeration value="AccessDenied"/>
<xs:enumeration value="MalformedRequest"/>
<xs:enumeration value="UnknownRequest"/>
<xs:enumeration value="UnknownCriticalExtension"/>
<xs:enumeration value="UnsupportedVersion"/>
<xs:enumeration value="NoSupportedKeyTypes"/>
<xs:enumeration value="NoSupportedEncryptionAlgorithms"/>
<xs:enumeration value="NoSupportedMACAlgorithms"/>
<xs:enumeration value="InitializationFailed"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="StatusCode">
<xs:restriction base="xs:string">
<xs:enumeration value="Continue"/>
<xs:enumeration value="Success"/>
<xs:enumeration value="Abort"/>
<xs:enumeration value="AccessDenied"/>
<xs:enumeration value="MalformedRequest"/>
<xs:enumeration value="UnknownRequest"/>
<xs:enumeration value="UnknownCriticalExtension"/>
<xs:enumeration value="UnsupportedVersion"/>
<xs:enumeration value="NoSupportedKeyTypes"/>
<xs:enumeration value="NoSupportedEncryptionAlgorithms"/>
<xs:enumeration value="NoSupportedMACAlgorithms"/>
<xs:enumeration value="InitializationFailed"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="VersionType">
<xs:restriction base="xs:string">
<xs:pattern value="\d{1,2}\.\d{1,3}"/>
</xs:restriction>
<xs:simpleType name="VersionType">
<xs:restriction base="xs:string">
<xs:pattern value="\d{1,2}\.\d{1,3}"/>
</xs:restriction>
</xs:simpleType>
</xs:simpleType>
<xs:simpleType name="IdentifierType">
<xs:restriction base="xs:string">
<xs:maxLength value="128"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="IdentifierType">
<xs:restriction base="xs:string">
<xs:maxLength value="128"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="NonceType">
<xs:restriction base="xs:base64Binary">
<xs:length value="16"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="NonceType">
<xs:restriction base="xs:base64Binary">
<xs:length value="16"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="LogoType">
<xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="MimeType" type="MimeTypeType"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="LogoType">
<xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="MimeType" type="MimeTypeType"
use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="MimeTypeType">
<xs:restriction base="xs:string">
<xs:enumeration value="image/jpeg"/>
<xs:enumeration value="image/gif"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="MimeTypeType">
<xs:restriction base="xs:string">
<xs:enumeration value="image/jpeg"/>
<xs:enumeration value="image/gif"/>
</xs:restriction>
</xs:simpleType>
<!-- Algorithms are identified through URIs -->
<xs:complexType name="AlgorithmsType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="Algorithm" type="AlgorithmType"/>
</xs:sequence>
</xs:complexType>
<!-- Algorithms are identified through URIs -->
<xs:complexType name="AlgorithmsType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="Algorithm" type="AlgorithmType"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="AlgorithmType">
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:simpleType name="AlgorithmType">
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:complexType name="MacType">
<xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="MacAlgorithm"
type="xs:anyURI"/>
</xs:extension>
</xs:simpleContent>
<xs:complexType name="MacType">
<xs:simpleContent>
<xs:extension base="xs:base64Binary">
<xs:attribute name="MacAlgorithm"
type="xs:anyURI"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:complexType>
<!-- CT-KIP extensions (for future use) -->
<xs:complexType name="ExtensionsType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="Extension" type="AbstractExtensionType"/>
</xs:sequence>
</xs:complexType>
<!-- CT-KIP extensions (for future use) -->
<xs:complexType name="ExtensionsType">
<xs:sequence maxOccurs="unbounded">
<xs:element name="Extension" type="AbstractExtensionType"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="AbstractExtensionType" abstract="true">
<xs:attribute name="Critical" type="xs:boolean"/>
</xs:complexType>
<xs:complexType name="AbstractExtensionType" abstract="true">
<xs:attribute name="Critical" type="xs:boolean"/>
</xs:complexType>
<xs:complexType name="ClientInfoType">
<xs:complexContent>
<xs:extension base="AbstractExtensionType">
<xs:sequence>
<xs:element name="Data" type="xs:base64Binary"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="ClientInfoType">
<xs:complexContent>
<xs:extension base="AbstractExtensionType">
<xs:sequence>
<xs:element name="Data" type="xs:base64Binary"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="ServerInfoType">
<xs:complexContent>
<xs:extension base="AbstractExtensionType">
<xs:sequence>
<xs:element name="Data" type="xs:base64Binary"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="ServerInfoType">
<xs:complexContent>
<xs:extension base="AbstractExtensionType">
<xs:sequence>
<xs:element name="Data" type="xs:base64Binary"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="OTPKeyConfigurationDataType">
<xs:annotation>
<xs:documentation xml:lang="en">
This extension is only valid in ServerFinished PDUs. It
carries additional configuration data that an OTP token should
use (subject to local policy) when generating OTP values from a
newly generated OTP key.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractExtensionType">
<xs:sequence>
<xs:element name="OTPFormat" type="OTPFormatType"/>
<xs:element name="OTPLength" type="xs:positiveInteger"/>
<xs:element name="OTPMode" type="OTPModeType" minOccurs="0"/>
<xs:complexType name="OTPKeyConfigurationDataType">
<xs:annotation>
<xs:documentation xml:lang="en">
This extension is only valid in ServerFinished PDUs. It
carries additional configuration data that an OTP token should
use (subject to local policy) when generating OTP values from a
newly generated OTP key.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractExtensionType">
<xs:sequence>
<xs:element name="OTPFormat" type="OTPFormatType"/>
<xs:element name="OTPLength" type="xs:positiveInteger"/>
<xs:element name="OTPMode" type="OTPModeType" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:simpleType name="OTPFormatType">
<xs:restriction base="xs:string">
<xs:enumeration value="Decimal"/>
<xs:enumeration value="Hexadecimal"/>
<xs:enumeration value="Alphanumeric"/>
<xs:enumeration value="Binary"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="OTPFormatType">
<xs:restriction base="xs:string">
<xs:enumeration value="Decimal"/>
<xs:enumeration value="Hexadecimal"/>
<xs:enumeration value="Alphanumeric"/>
<xs:enumeration value="Binary"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="OTPModeType">
<xs:choice maxOccurs="unbounded">
<xs:element name="Time" type="TimeType"/>
<xs:element name="Counter"/>
<xs:element name="Challenge"/>
<xs:any namespace="##other" processContents="strict"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="OTPModeType">
<xs:choice maxOccurs="unbounded">
<xs:element name="Time" type="TimeType"/>
<xs:element name="Counter"/>
<xs:element name="Challenge"/>
<xs:any namespace="##other" processContents="strict"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="TimeType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:attribute name="TimeInterval" type="xs:positiveInteger"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="TimeType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:attribute name="TimeInterval" type="xs:positiveInteger"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="PayloadType">
<xs:annotation>
<xs:documentation xml:lang="en">
</xs:documentation>
</xs:annotation>
<xs:choice>
<xs:element name="Nonce" type="NonceType"/>
<xs:any namespace="##other" processContents="strict"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="PayloadType">
<xs:annotation>
<xs:documentation xml:lang="en">
</xs:documentation>
</xs:annotation>
<xs:choice>
<xs:element name="Nonce" type="NonceType"/>
<xs:any namespace="##other" processContents="strict"/>
</xs:choice>
</xs:complexType>
<xs:simpleType name="PlatformType">
<xs:restriction base="xs:string">
<xs:enumeration value="Hardware"/>
<xs:enumeration value="Software"/>
<xs:enumeration value="Unspecified"/>
</xs:restriction>
<xs:simpleType name="PlatformType">
<xs:restriction base="xs:string">
<xs:enumeration value="Hardware"/>
<xs:enumeration value="Software"/>
<xs:enumeration value="Unspecified"/>
</xs:restriction>
</xs:simpleType>
</xs:simpleType>
<xs:complexType name="TokenPlatformInfoType">
<xs:annotation>
<xs:documentation xml:lang="en">
Carries token platform information helping the client to select
a suitable token.
</xs:documentation>
</xs:annotation>
<xs:attribute name="KeyLocation" type="PlatformType"/>
<xs:attribute name="AlgorithmLocation" type="PlatformType"/>
</xs:complexType>
<xs:complexType name="TokenPlatformInfoType">
<xs:annotation>
<xs:documentation xml:lang="en">
Carries token platform information helping the client to select
a suitable token.
</xs:documentation>
</xs:annotation>
<xs:attribute name="KeyLocation" type="PlatformType"/>
<xs:attribute name="AlgorithmLocation" type="PlatformType"/>
</xs:complexType>
<xs:complexType name="InitializationTriggerType">
<xs:sequence>
<xs:element name="TokenID" type="xs:base64Binary" minOccurs="0"/>
<xs:element name="KeyID" type="xs:base64Binary" minOccurs="0"/>
<xs:element name="TokenPlatformInfo" type="TokenPlatformInfoType"
minOccurs="0"/>
<xs:element name="TriggerNonce" type="NonceType"/>
<xs:element name="CT-KIPURL" type="xs:anyURI" minOccurs="0"/>
<xs:any namespace="##other" processContents="strict"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="InitializationTriggerType">
<xs:sequence>
<xs:element name="TokenID" type="xs:base64Binary" minOccurs="0"/>
<xs:element name="KeyID" type="xs:base64Binary" minOccurs="0"/>
<xs:element name="TokenPlatformInfo" type="TokenPlatformInfoType"
minOccurs="0"/>
<xs:element name="TriggerNonce" type="NonceType"/>
<xs:element name="CT-KIPURL" type="xs:anyURI" minOccurs="0"/>
<xs:any namespace="##other" processContents="strict"
minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<!-- CT-KIP PDUs -->
<!-- CT-KIP PDUs -->
<!-- CT-KIP trigger -->
<xs:element name="CT-KIPTrigger" type="CT-KIPTriggerType"/>
<!-- CT-KIP trigger -->
<xs:element name="CT-KIPTrigger" type="CT-KIPTriggerType"/>
<xs:complexType name="CT-KIPTriggerType">
<xs:annotation>
<xs:documentation xml:lang="en">
Message used to trigger the device to initiate a CT-KIP run.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:choice>
<xs:element name="InitializationTrigger"
type="InitializationTriggerType"/>
<xs:any namespace="##other" processContents="strict"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="Version" type="VersionType"/>
</xs:complexType>
<xs:complexType name="CT-KIPTriggerType">
<xs:annotation>
<xs:documentation xml:lang="en">
Message used to trigger the device to initiate a CT-KIP run.
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:choice>
<xs:element name="InitializationTrigger"
type="InitializationTriggerType"/>
<xs:any namespace="##other" processContents="strict"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="Version" type="VersionType"/>
</xs:complexType>
<!-- ClientHello PDU -->
<!-- ClientHello PDU -->
<xs:element name="ClientHello" type="ClientHelloPDU"/>
<xs:element name="ClientHello" type="ClientHelloPDU"/>
<xs:complexType name="ClientHelloPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Message sent from CT-KIP client to CT-KIP server to initiate an
CT-KIP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractRequestType">
<xs:sequence>
<xs:element name="TokenID" type="xs:base64Binary"
minOccurs="0"/>
<xs:element name="KeyID" type="xs:base64Binary"
minOccurs="0"/>
<xs:element name="ClientNonce" type="NonceType"
minOccurs="0"/>
<xs:element name="TriggerNonce" type="NonceType"
minOccurs="0"/>
<xs:element name="SupportedKeyTypes" type="AlgorithmsType"/>
<xs:element name="SupportedEncryptionAlgorithms"
type="AlgorithmsType"/>
<xs:element name="SupportedMACAlgorithms"
type="AlgorithmsType"/>
<xs:element name="Extensions" type="ExtensionsType"
minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="ClientHelloPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Message sent from CT-KIP client to CT-KIP server to initiate an
CT-KIP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractRequestType">
<xs:sequence>
<xs:element name="TokenID" type="xs:base64Binary"
minOccurs="0"/>
<xs:element name="KeyID" type="xs:base64Binary"
minOccurs="0"/>
<xs:element name="ClientNonce" type="NonceType"
minOccurs="0"/>
<xs:element name="TriggerNonce" type="NonceType"
minOccurs="0"/>
<xs:element name="SupportedKeyTypes" type="AlgorithmsType"/>
<xs:element name="SupportedEncryptionAlgorithms"
type="AlgorithmsType"/>
<xs:element name="SupportedMACAlgorithms"
type="AlgorithmsType"/>
<xs:element name="Extensions" type="ExtensionsType"
minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- ServerHello PDU -->
<xs:element name="ServerHello" type="ServerHelloPDU"/>
<!-- ServerHello PDU -->
<xs:element name="ServerHello" type="ServerHelloPDU"/>
<xs:complexType name="ServerHelloPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Message sent from CT-KIP server to CT-KIP client in response to
a received ClientHello PDU.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="KeyType" type="AlgorithmType"/>
<xs:element name="EncryptionAlgorithm" type="AlgorithmType"/>
<xs:element name="MacAlgorithm" type="AlgorithmType"/>
<xs:complexType name="ServerHelloPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Message sent from CT-KIP server to CT-KIP client in response to
a received ClientHello PDU.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="KeyType" type="AlgorithmType"/>
<xs:element name="EncryptionAlgorithm" type="AlgorithmType"/>
<xs:element name="MacAlgorithm" type="AlgorithmType"/>
<xs:element name="EncryptionKey" type="ds:KeyInfoType"/>
<xs:element name="Payload" type="PayloadType"/>
<xs:element name="Extensions" type="ExtensionsType"
minOccurs="0"/>
<xs:element name="Mac" type="MacType" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="EncryptionKey" type="ds:KeyInfoType"/>
<xs:element name="Payload" type="PayloadType"/>
<xs:element name="Extensions" type="ExtensionsType"
minOccurs="0"/>
<xs:element name="Mac" type="MacType" minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- ClientNonce PDU -->
<xs:element name="ClientNonce" type="ClientNoncePDU"/>
<!-- ClientNonce PDU -->
<xs:element name="ClientNonce" type="ClientNoncePDU"/>
<xs:complexType name="ClientNoncePDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Second message sent from CT-KIP client to CT-KIP server to
convey the client's chosen secret.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractRequestType">
<xs:sequence>
<xs:element name="EncryptedNonce" type="xs:base64Binary"/>
<xs:element name="Extensions" type="ExtensionsType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="SessionID" type="IdentifierType"
use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="ClientNoncePDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Second message sent from CT-KIP client to CT-KIP server to
convey the client's chosen secret.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractRequestType">
<xs:sequence>
<xs:element name="EncryptedNonce" type="xs:base64Binary"/>
<xs:element name="Extensions" type="ExtensionsType"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="SessionID" type="IdentifierType"
use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<!-- ServerFinished PDU -->
<xs:element name="ServerFinished" type="ServerFinishedPDU"/>
<xs:complexType name="ServerFinishedPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Final message sent from CT-KIP server to CT-KIP client in an
CT-KIP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="TokenID" type="xs:base64Binary"/>
<xs:element name="KeyID" type="xs:base64Binary"/>
<xs:element name="KeyExpiryDate" type="xs:dateTime"
<!-- ServerFinished PDU -->
<xs:element name="ServerFinished" type="ServerFinishedPDU"/>
<xs:complexType name="ServerFinishedPDU">
<xs:annotation>
<xs:documentation xml:lang="en">
Final message sent from CT-KIP server to CT-KIP client in an
CT-KIP session.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="AbstractResponseType">
<xs:sequence minOccurs="0">
<xs:element name="TokenID" type="xs:base64Binary"/>
<xs:element name="KeyID" type="xs:base64Binary"/>
<xs:element name="KeyExpiryDate" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="ServiceID" type="IdentifierType"
minOccurs="0"/>
<xs:element name="ServiceLogo" type="LogoType"
minOccurs="0"/>
<xs:element name="UserID" type="IdentifierType"
minOccurs="0"/>
<xs:element name="Extensions" type="ExtensionsType"
minOccurs="0"/>
<xs:element name="Mac" type="MacType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
minOccurs="0"/>
<xs:element name="ServiceID" type="IdentifierType"
minOccurs="0"/>
<xs:element name="ServiceLogo" type="LogoType"
minOccurs="0"/>
<xs:element name="UserID" type="IdentifierType"
minOccurs="0"/>
<xs:element name="Extensions" type="ExtensionsType"
minOccurs="0"/>
<xs:element name="Mac" type="MacType"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:schema>
</xs:schema>
All examples are syntactically correct. MAC and cipher values are fictitious, however. The examples illustrate a complete CT-KIP exchange, starting with an initialization (trigger) message from the server.
所有示例在语法上都是正确的。然而，MAC和密码值是虚构的。这些示例演示了一个完整的CT-KIP交换，从服务器发出的初始化（触发器）消息开始。
<CT-KIPTrigger
xmlns=
"http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Version="1.0">
<InitializationTrigger>
<TokenID>12345678</TokenID>
<TriggerNonce>112dsdfwf312asder394jw==</TriggerNonce>
</InitializationTrigger>
</CT-KIPTrigger>
<CT-KIPTrigger
xmlns=
"http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Version="1.0">
<InitializationTrigger>
<TokenID>12345678</TokenID>
<TriggerNonce>112dsdfwf312asder394jw==</TriggerNonce>
</InitializationTrigger>
</CT-KIPTrigger>
<?xml version="1.0" encoding="UTF-8"?>
<ClientHello
xmlns=
"http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Version="1.0">
<TokenID>12345678</TokenID>
<?xml version="1.0" encoding="UTF-8"?>
<ClientHello
xmlns=
"http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Version="1.0">
<TokenID>12345678</TokenID>
<TriggerNonce>112dsdfwf312asder394jw==</TriggerNonce>
<SupportedKeyTypes>
<Algorithm>http://www.rsasecurity.com/rsalabs/otps/schemas
/2005/09/otps-wst#SecurID-AES</Algorithm>
</SupportedKeyTypes>
<SupportedEncryptionAlgorithms>
<Algorithm>http://www.w3.org/2001/04/xmlenc#rsa-1_5</Algorithm>
<Algorithm>http://www.rsasecurity.com/rsalabs/otps/schemas/
2005/12/ct-kip#ct-kip-prf-aes</Algorithm>
</SupportedEncryptionAlgorithms>
<SupportedMACAlgorithms>
<Algorithm>http://www.rsasecurity.com/rsalabs/otps/schemas/
2005/12/ct-kip#ct-kip-prf-aes</Algorithm>
</SupportedMACAlgorithms>
</ClientHello>
<TriggerNonce>112dsdfwf312asder394jw==</TriggerNonce>
<SupportedKeyTypes>
<Algorithm>http://www.rsasecurity.com/rsalabs/otps/schemas
/2005/09/otps-wst#SecurID-AES</Algorithm>
</SupportedKeyTypes>
<SupportedEncryptionAlgorithms>
<Algorithm>http://www.w3.org/2001/04/xmlenc#rsa-1_5</Algorithm>
<Algorithm>http://www.rsasecurity.com/rsalabs/otps/schemas/
2005/12/ct-kip#ct-kip-prf-aes</Algorithm>
</SupportedEncryptionAlgorithms>
<SupportedMACAlgorithms>
<Algorithm>http://www.rsasecurity.com/rsalabs/otps/schemas/
2005/12/ct-kip#ct-kip-prf-aes</Algorithm>
</SupportedMACAlgorithms>
</ClientHello>
<?xml version="1.0" encoding="UTF-8"?>
<ServerHello
xmlns=
"http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Version="1.0" SessionID="4114" Status="Success">
<KeyType>http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
otps-wst#SecurID-AES</KeyType>
<EncryptionAlgorithm>http://www.rsasecurity.com/rsalabs/otps/
schemas/2005/12/ct-kip#ct-kip-prf-aes</EncryptionAlgorithm>
<MacAlgorithm>http://www.rsasecurity.com/rsalabs/otps/schemas/
2005/12/ct-kip#ct-kip-prf-aes</MacAlgorithm>
<EncryptionKey>
<ds:KeyName>KEY-1</ds:KeyName>
</EncryptionKey>
<Payload>
<Nonce>qw2ewasde312asder394jw==</Nonce>
</Payload>
</ServerHello>
<?xml version="1.0" encoding="UTF-8"?>
<ServerHello
xmlns=
"http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/ct-kip#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Version="1.0" SessionID="4114" Status="Success">
<KeyType>http://www.rsasecurity.com/rsalabs/otps/schemas/2005/09/
otps-wst#SecurID-AES</KeyType>
<EncryptionAlgorithm>http://www.rsasecurity.com/rsalabs/otps/
schemas/2005/12/ct-kip#ct-kip-prf-aes</EncryptionAlgorithm>
<MacAlgorithm>http://www.rsasecurity.com/rsalabs/otps/schemas/
2005/12/ct-kip#ct-kip-prf-aes</MacAlgorithm>
<EncryptionKey>
<ds:KeyName>KEY-1</ds:KeyName>
</EncryptionKey>
<Payload>
<Nonce>qw2ewasde312asder394jw==</Nonce>
</Payload>
</ServerHello>
<?xml version="1.0" encoding="UTF-8"?>
<ClientNonce
xmlns="http://www.rsasecurity.com/rsalabs/otps/schemas/
2005/12/ct-kip#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Version="1.0" SessionID="4114">
<EncryptedNonce>vXENc+Um/9/NvmYKiHDLaErK0gk=</EncryptedNonce>
<?xml version="1.0" encoding="UTF-8"?>
<ClientNonce
xmlns="http://www.rsasecurity.com/rsalabs/otps/schemas/
2005/12/ct-kip#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Version="1.0" SessionID="4114">
<EncryptedNonce>vXENc+Um/9/NvmYKiHDLaErK0gk=</EncryptedNonce>
</ClientNonce>
</ClientNonce>
<?xml version="1.0" encoding="UTF-8"?>
<ServerFinished
xmlns="http://www.rsasecurity.com/rsalabs/otps/schemas/
2005/12/ct-kip#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Version="1.0" SessionID="4114" Status="Success">
<TokenID>12345678</TokenID>
<KeyExpiryDate>2009-09-16T03:02:00Z</KeyExpiryDate>
<KeyID>43212093</KeyID>
<ServiceID>Example Enterprise Name</ServiceID>
<UserID>exampleLoginName</UserID>
<Extensions>
<Extension xsi:type="OTPKeyConfigurationDataType">
<OTPFormat>Decimal</OTPFormat>
<OTPLength>6</OTPLength>
<OTPMode><Time/></OTPMode>
</Extension>
</Extensions>
<Mac>miidfasde312asder394jw==</Mac>
</ServerFinished>
<?xml version="1.0" encoding="UTF-8"?>
<ServerFinished
xmlns="http://www.rsasecurity.com/rsalabs/otps/schemas/
2005/12/ct-kip#"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
Version="1.0" SessionID="4114" Status="Success">
<TokenID>12345678</TokenID>
<KeyExpiryDate>2009-09-16T03:02:00Z</KeyExpiryDate>
<KeyID>43212093</KeyID>
<ServiceID>Example Enterprise Name</ServiceID>
<UserID>exampleLoginName</UserID>
<Extensions>
<Extension xsi:type="OTPKeyConfigurationDataType">
<OTPFormat>Decimal</OTPFormat>
<OTPLength>6</OTPLength>
<OTPMode><Time/></OTPMode>
</Extension>
</Extensions>
<Mac>miidfasde312asder394jw==</Mac>
</ServerFinished>
Appendix C. Integration with PKCS #11
附录C.与PKCS的整合#11
A CT-KIP client that needs to communicate with a connected cryptographic token to perform a CT-KIP exchange may use PKCS #11 [3] as a programming interface. When performing CT-KIP with a cryptographic token using the PKCS #11 programming interface, the procedure described in [2], Appendix B, is recommended.
需要与连接的加密令牌通信以执行CT-KIP交换的CT-KIP客户端可以使用PKCS#11[3]作为编程接口。当使用PKCS#11编程接口使用加密令牌执行CT-KIP时，建议采用附录B中[2]所述的程序。
This example appendix defines CT-KIP-PRF in terms of AES [8] and HMAC [9].
本示例附录根据AES[8]和HMAC[9]定义了CT-KIP-PRF。
For tokens supporting this realization of CT-KIP-PRF, the following URI may be used to identify this algorithm in CT-KIP:
对于支持此CT-KIP-PRF实现的令牌，以下URI可用于识别CT-KIP中的此算法：
http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/
http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/
ct-kip#ct-kip-prf-aes
ct kip#ct kip prf aes
When this URI is used to identify the encryption algorithm to use, the method for encryption of R_C values described in Section 3.6 shall be used.
当此URI用于识别要使用的加密算法时，应使用第3.6节中描述的R_C值加密方法。
CT-KIP-PRF-AES (k, s, dsLen)
CT-KIP-PRF-AES（k、s、dsLen）
Input:
输入：
k encryption key to use
要使用的k加密密钥
s octet string consisting of randomizing material. The length of the string s is sLen.
由随机化材料组成的八进制字符串。字符串s的长度为sLen。
dsLen desired length of the output
dsLen输出的所需长度
Output:
输出：
DS a pseudorandom string, dsLen-octets long
DS是一个伪随机字符串，dsLen八位字节长
Steps:
步骤：
1. Let bLen be the output block size of AES in octets:
1. 设bLen为AES的输出块大小（以八位字节为单位）：
bLen = (AES output block length in octets)
bLen = (AES output block length in octets)
(normally, bLen = 16)
（正常情况下，bLen=16）
2. If dsLen > (2**32 - 1) * bLen, output "derived data too long" and stop
2. 如果dsLen>（2**32-1）*bLen，则输出“派生数据太长”并停止
3. Let n be the number of bLen-octet blocks in the output data, rounding up, and let j be the number of octets in the last block:
3. 设n为输出数据中的bLen八位字节块数，向上取整，设j为最后一个块中的八位字节数：
n = ROUND( dsLen / bLen )
n = ROUND( dsLen / bLen )
j = dsLen - (n - 1) * bLen
j = dsLen - (n - 1) * bLen
4. For each block of the pseudorandom string DS, apply the function F defined below to the key k, the string s and the block index to compute the block:
4. 对于伪随机字符串DS的每个块，将下面定义的函数F应用于键k、字符串s和块索引以计算块：
B1 = F (k, s, 1) ,
B1=F（k，s，1），
B2 = F (k, s, 2) ,
B2=F（k，s，2），
...
...
Bn = F (k, s, n)
Bn=F（k，s，n）
The function F is defined in terms of the OMAC1 construction from [10], using AES as the block cipher:
函数F根据[10]中的OMAC1构造定义，使用AES作为分组密码：
F (k, s, i) = OMAC1-AES (k, INT (i) || s)
F（k，s，i）=OMAC1-AES（k，INT（i）| s）
where INT (i) is a four-octet encoding of the integer i, most significant octet first, and the output length of OMAC1 is set to bLen.
其中INT（i）是整数i的四个八位编码，最重要的八位先，OMAC1的输出长度设置为bLen。
Concatenate the blocks and extract the first dsLen octets to produce the desired data string DS:
连接块并提取第一个dsLen八位字节，以生成所需的数据字符串DS：
DS = B1 || B2 || ... || Bn<0..j-1>
DS = B1 || B2 || ... || Bn<0..j-1>
Output the derived data DS.
将导出的数据输出到DS。
If we assume that dsLen = 16, then:
如果我们假设dsLen=16，那么：
n = 16 / 16 = 1
n = 16 / 16 = 1
j = 16 - (1 - 1) * 16 = 16
j = 16 - (1 - 1) * 16 = 16
DS = B1 = F (k, s, 1) = OMAC1-AES (k, INT (1) || S)
DS = B1 = F (k, s, 1) = OMAC1-AES (k, INT (1) || S)
For tokens supporting this realization of CT-KIP-PRF, the following URI may be used to identify this algorithm in CT-KIP:
对于支持此CT-KIP-PRF实现的令牌，以下URI可用于识别CT-KIP中的此算法：
http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/
ct-kip#ct-kip-prf-sha256
http://www.rsasecurity.com/rsalabs/otps/schemas/2005/12/
ct-kip#ct-kip-prf-sha256
When this URI is used to identify the encryption algorithm to use, the method for encryption of R_C values described in Section 3.6 shall be used.
当此URI用于识别要使用的加密算法时，应使用第3.6节中描述的R_C值加密方法。
CT-KIP-PRF-SHA256 (k, s, dsLen)
CT-KIP-PRF-SHA256（k、s、dsLen）
Input:
输入：
k encryption key to use
要使用的k加密密钥
s octet string consisting of randomizing material. The length of the string s is sLen
由随机化材料组成的八进制字符串。字符串s的长度为sLen
dsLen desired length of the output
dsLen输出的所需长度
Output:
输出：
DS a pseudorandom string, dsLen-octets long
DS是一个伪随机字符串，dsLen八位字节长
Steps:
步骤：
1. Let bLen be the output size in octets of SHA-256 [11] (no truncation is done on the HMAC output):
1. 设bLen为SHA-256[11]的输出大小（以八位字节为单位）（HMAC输出上未进行截断）：
bLen = 32
bLen = 32
2. If dsLen > (2**32 - 1) bLen, output "derived data too long" and stop
2. 如果dsLen>（2**32-1）bLen，则输出“派生数据太长”并停止
3. Let n be the number of bLen-octet blocks in the output data, rounding up, and let j be the number of octets in the last block:
3. 设n为输出数据中的bLen八位字节块数，向上取整，设j为最后一个块中的八位字节数：
n = ROUND ( dsLen / bLen )
n=圆形（dsLen/bLen）
j = dsLen - (n - 1) * bLen
j = dsLen - (n - 1) * bLen
4. For each block of the pseudorandom string DS, apply the function F defined below to the key k, the string s and the block index to compute the block:
4. 对于伪随机字符串DS的每个块，将下面定义的函数F应用于键k、字符串s和块索引以计算块：
B1 = F (k, s, 1) ,
B1=F（k，s，1），
B2 = F (k, s, 2) ,
B2=F（k，s，2），
...
...
Bn = F (k, s, n)
Bn=F（k，s，n）
The function F is defined in terms of the HMAC construction from [9], using SHA-256 as the digest algorithm:
函数F根据[9]中的HMAC构造定义，使用SHA-256作为摘要算法：
F (k, s, i) = HMAC-SHA256 (k, INT (i) || s)
F（k，s，i）=HMAC-SHA256（k，INT（i）| s）
where INT (i) is a four-octet encoding of the integer i, most significant octet first, and the output length of HMAC is set to bLen.
其中INT（i）是整数i的四个八位组编码，最重要的八位组在前，HMAC的输出长度设置为bLen。
Concatenate the blocks and extract the first dsLen octets to produce the desired data string DS:
连接块并提取第一个dsLen八位字节，以生成所需的数据字符串DS：
DS = B1 || B2 || ... || Bn<0..j-1>
DS = B1 || B2 || ... || Bn<0..j-1>
Output the derived data DS.
将导出的数据输出到DS。
If we assume that sLen = 256 (two 128-octet long values) and dsLen = 16, then:
如果我们假设sLen=256（两个128八位字节长的值）和dsLen=16，那么：
n = ROUND ( 16 / 32 ) = 1
n = ROUND ( 16 / 32 ) = 1
j = 16 - (1 - 1) * 32 = 16
j = 16 - (1 - 1) * 32 = 16
B1 = F (k, s, 1) = HMAC-SHA256 (k, INT (1) || s )
B1=F（k，s，1）=HMAC-SHA256（k，INT（1）| s）
DS = B1<0 ... 15>
DS = B1<0 ... 15>
That is, the result will be the first 16 octets of the HMAC output.
也就是说，结果将是HMAC输出的前16个八位字节。
The One-Time Password Specifications are documents produced by RSA Laboratories in cooperation with secure systems developers for the purpose of simplifying integration and management of strong authentication technology into secure applications, and to enhance the user experience of this technology.
一次性密码规范是RSA实验室与安全系统开发人员合作编制的文档，旨在简化强身份验证技术在安全应用程序中的集成和管理，并增强此技术的用户体验。
Further development of the OTPS series will occur through mailing list discussions and occasional workshops, and suggestions for improvement are welcome. As for our PKCS documents, results may also be submitted to standards forums. For more information, contact:
OTPS系列的进一步开发将通过邮件列表讨论和偶尔的研讨会进行，欢迎提出改进建议。至于我们的PKCS文件，结果也可以提交给标准论坛。有关详细信息，请联系：
OTPS Editor RSA Laboratories 174 Middlesex Turnpike Bedford, MA 01730 USA otps-editor@rsasecurity.com http://www.rsasecurity.com/rsalabs/
OTPS编辑RSA实验室174美国马萨诸塞州米德尔塞克斯收费公路贝德福德01730 OTPS-editor@rsasecurity.com http://www.rsasecurity.com/rsalabs/
Author's Address
作者地址
Magnus Nystroem RSA Security
Magnus Nystroem RSA安全
EMail: magnus@rsasecurity.com
EMail: magnus@rsasecurity.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
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.
本文件受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, THE IETF TRUST, 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。