Network Working Group M. Eisler
Request for Comments: 2847 Zambeel
Category: Standards Track June 2000
Network Working Group M. Eisler
Request for Comments: 2847 Zambeel
Category: Standards Track June 2000
LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM
LIPKEY-一种使用SPKM的低基础设施公钥机制
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This memorandum describes a method whereby one can use GSS-API [RFC2078] to supply a secure channel between a client and server, authenticating the client with a password, and a server with a public key certificate. As such, it is analogous to the common low infrastructure usage of the Transport Layer Security (TLS) protocol [RFC2246].
本备忘录描述了一种方法，使用GSS-API[RFC2078]在客户机和服务器之间提供安全通道，使用密码验证客户机，使用公钥证书验证服务器。因此，它类似于传输层安全（TLS）协议[RFC2246]的常见低基础设施使用率。
The method leverages the existing Simple Public Key Mechanism (SPKM) [RFC2025], and is specified as a separate GSS-API mechanism (LIPKEY) layered above SPKM.
该方法利用了现有的简单公钥机制（SPKM）[RFC2025]，并指定为SPKM之上分层的单独GSS-API机制（LIPKEY）。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. LIPKEY's Requirements of SPKM . . . . . . . . . . . . . . . . 4
2.1. Mechanism Type . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Name Type . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. MANDATORY Algorithms . . . . . . . . . . . . . . . . . . . 5
2.3.2. RECOMMENDED Integrity Algorithms (I-ALG) . . . . . . . . . 7
2.4. Context Establishment Tokens . . . . . . . . . . . . . . . . 8
2.4.1. REQ-TOKEN Content Requirements . . . . . . . . . . . . . . 8
2.4.1.1. algId and req-integrity . . . . . . . . . . . . . . . . 8
2.4.1.2. Req-contents . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1.2.1. Options . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1.2.2. Conf-Algs . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1.2.3. Intg-Algs . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. LIPKEY's Requirements of SPKM . . . . . . . . . . . . . . . . 4
2.1. Mechanism Type . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Name Type . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3.1. MANDATORY Algorithms . . . . . . . . . . . . . . . . . . . 5
2.3.2. RECOMMENDED Integrity Algorithms (I-ALG) . . . . . . . . . 7
2.4. Context Establishment Tokens . . . . . . . . . . . . . . . . 8
2.4.1. REQ-TOKEN Content Requirements . . . . . . . . . . . . . . 8
2.4.1.1. algId and req-integrity . . . . . . . . . . . . . . . . 8
2.4.1.2. Req-contents . . . . . . . . . . . . . . . . . . . . . . 8
2.4.1.2.1. Options . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1.2.2. Conf-Algs . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1.2.3. Intg-Algs . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2. REP-TI-TOKEN Content Requirements . . . . . . . . . . . . 9
2.4.2.1. algId . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2.2. rep-ti-integ . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Quality of Protection (QOP) . . . . . . . . . . . . . . . .10
3. How LIPKEY Uses SPKM . . . . . . . . . . . . . . . . . . . . 11
3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Initiator . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. GSS_Import_name . . . . . . . . . . . . . . . . . . . . 11
3.2.2. GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . . 11
3.2.3. GSS_Init_sec_context . . . . . . . . . . . . . . . . . . 12
3.2.3.1. LIPKEY Caller Specified anon_req_flag as TRUE . . . . 12
3.2.3.2. LIPKEY Caller Specified anon_req_flag as FALSE . . . . 13
3.2.4. Other operations . . . . . . . . . . . . . . . . . . . . 14
3.3. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. GSS_Import_name . . . . . . . . . . . . . . . . . . . . 14
3.3.2. GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . . 14
3.3.3. GSS_Accept_sec_context . . . . . . . . . . . . . . . . . 15
4. LIPKEY Description . . . . . . . . . . . . . . . . . . . . . 15
4.1. Mechanism Type . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Name Types . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Token Formats . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. Context Tokens . . . . . . . . . . . . . . . . . . . . . 16
4.3.1.1. Context Tokens Prior to SPKM-3 Context Establishment . 16
4.3.1.2. Post-SPKM-3 Context Establishment Tokens . . . . . . . 16
4.3.1.2.1. From LIPKEY Initiator . . . . . . . . . . . . . . . 17
4.3.1.2.2. From LIPKEY Target . . . . . . . . . . . . . . . . . 17
4.3.2. Tokens from GSS_GetMIC and GSS_Wrap . . . . . . . . . . 17
4.4. Quality of Protection . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . 18
5.1. Password Management . . . . . . . . . . . . . . . . . . . 18
5.2. Certification Authorities . . . . . . . . . . . . . . . . 18
5.3. HMAC-MD5 and MD5 Weaknesses . . . . . . . . . . . . . . . 18
5.4. Security of cast5CBC . . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 22
2.4.2. REP-TI-TOKEN Content Requirements . . . . . . . . . . . . 9
2.4.2.1. algId . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.2.2. rep-ti-integ . . . . . . . . . . . . . . . . . . . . . . 9
2.5. Quality of Protection (QOP) . . . . . . . . . . . . . . . .10
3. How LIPKEY Uses SPKM . . . . . . . . . . . . . . . . . . . . 11
3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Initiator . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. GSS_Import_name . . . . . . . . . . . . . . . . . . . . 11
3.2.2. GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . . 11
3.2.3. GSS_Init_sec_context . . . . . . . . . . . . . . . . . . 12
3.2.3.1. LIPKEY Caller Specified anon_req_flag as TRUE . . . . 12
3.2.3.2. LIPKEY Caller Specified anon_req_flag as FALSE . . . . 13
3.2.4. Other operations . . . . . . . . . . . . . . . . . . . . 14
3.3. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1. GSS_Import_name . . . . . . . . . . . . . . . . . . . . 14
3.3.2. GSS_Acquire_cred . . . . . . . . . . . . . . . . . . . . 14
3.3.3. GSS_Accept_sec_context . . . . . . . . . . . . . . . . . 15
4. LIPKEY Description . . . . . . . . . . . . . . . . . . . . . 15
4.1. Mechanism Type . . . . . . . . . . . . . . . . . . . . . . 15
4.2. Name Types . . . . . . . . . . . . . . . . . . . . . . . . 15
4.3. Token Formats . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. Context Tokens . . . . . . . . . . . . . . . . . . . . . 16
4.3.1.1. Context Tokens Prior to SPKM-3 Context Establishment . 16
4.3.1.2. Post-SPKM-3 Context Establishment Tokens . . . . . . . 16
4.3.1.2.1. From LIPKEY Initiator . . . . . . . . . . . . . . . 17
4.3.1.2.2. From LIPKEY Target . . . . . . . . . . . . . . . . . 17
4.3.2. Tokens from GSS_GetMIC and GSS_Wrap . . . . . . . . . . 17
4.4. Quality of Protection . . . . . . . . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . 18
5.1. Password Management . . . . . . . . . . . . . . . . . . . 18
5.2. Certification Authorities . . . . . . . . . . . . . . . . 18
5.3. HMAC-MD5 and MD5 Weaknesses . . . . . . . . . . . . . . . 18
5.4. Security of cast5CBC . . . . . . . . . . . . . . . . . . . 18
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 22
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This memorandum describes a new security mechanism under the GSS-API called the Low Infrastructure Public Key Mechanism (LIPKEY). GSS-API provides a way for an application protocol to implement authentication, integrity, and privacy. TLS is another way. While TLS
本备忘录描述了GSS-API下的一种新安全机制，称为低基础设施公钥机制（LIPKEY）。GSS-API为应用程序协议提供了实现身份验证、完整性和隐私的方法。TLS是另一种方式。而TLS
is in many ways simpler for an application to incorporate than GSS-API, there are situations where GSS-API might be more suitable. Certainly this is the case with application protocols that run over connectionless protocols. It is also the case with application protocols such as ONC RPC [RFC1831] [RFC2203], which have their own security architecture, and so do not easily mesh with a protocol like TLS that is implemented as a layer that encapsulates the upper layer application protocol. GSS-API allows the application protocol to encapsulate as much of the application protocol as necessary.
在许多方面，应用程序比GSS-API更容易合并，在某些情况下，GSS-API可能更合适。当然，在无连接协议上运行的应用程序协议就是这种情况。诸如ONC-RPC[RFC1831][RFC2203]之类的应用程序协议也是如此，它们有自己的安全体系结构，因此不容易与像TLS这样的协议啮合，TLS被实现为封装上层应用程序协议的层。GSS-API允许应用程序协议根据需要封装尽可能多的应用程序协议。
Despite the flexibility of GSS-API, it compares unfavorably with TLS with respect to the perception of the amount of infrastructure required to deploy it. The better known GSS-API mechanisms, Kerberos V5 [RFC1964] and SPKM require a great deal of infrastructure to set up. Compare this to the typical TLS deployment scenario, which consists of a client with no public key certificate accessing a server with a public key certificate. The client:
尽管GSS-API具有灵活性，但在部署它所需的基础设施数量方面，它与TLS相比并不理想。众所周知的GSS-API机制，Kerberos V5[RFC1964]和SPKM需要大量的基础设施来设置。将此与典型的TLS部署场景进行比较，典型的TLS部署场景包括没有公钥证书的客户端使用公钥证书访问服务器。客户：
* obtains the server's certificate,
* 获取服务器的证书，
* verifies that it was signed by a trusted Certification Authority (CA),
* 验证它是否由受信任的证书颁发机构（CA）签名，
* generates a random session symmetric key,
* 生成随机会话对称密钥，
* encrypts the session key with the server's public key, and
* 使用服务器的公钥加密会话密钥，以及
* sends the encrypted session key to the server.
* 将加密的会话密钥发送到服务器。
At this point, the client and server have a secure channel. The client can then provide a user name and password to the server to authenticate the client. For example, when TLS is being used with the http protocol, once there is a secure channel, the http server will present the client with an html page that prompts for a user name and password. This information is then encrypted with the session key and sent to the server. The server then authenticates the client.
此时，客户机和服务器拥有一个安全通道。然后，客户机可以向服务器提供用户名和密码，以对客户机进行身份验证。例如，当TLS与http协议一起使用时，一旦存在安全通道，http服务器将向客户端提供一个html页面，提示输入用户名和密码。然后使用会话密钥对该信息进行加密并发送到服务器。然后服务器对客户端进行身份验证。
Note that the client is not required to have a certificate for itself to identify and authenticate it to the server. In addition to a TLS implementation, the required security infrastructure includes a public key certificate and password database on the server, and a list of trusted CAs and their public keys on the client. Most operating systems that the http server would run on already have a native password database, so the net additional infrastructure is a server certificate and CA list. Hence the term "low infrastructure security model" to identify this typical TLS deployment scenario.
请注意，客户机本身不需要有证书，就可以向服务器标识和验证它。除了TLS实现之外，所需的安全基础设施还包括服务器上的公钥证书和密码数据库，以及客户端上的受信任CA及其公钥列表。运行http服务器的大多数操作系统都已经有了本机密码数据库，因此网络附加基础设施是服务器证书和CA列表。因此，术语“低基础设施安全模型”用于识别这种典型的TLS部署场景。
By using unilateral authentication, and using a mechanism resembling the SPKM-1 mechanism type, SPKM can offer many aspects of the previously described low infrastructure security model. An application that uses GSS-API is certainly free to use GSS-API's GSS_Wrap() routine to encrypt a user name and password and send them to the server, for it to decrypt and verify.
通过使用单边身份验证，并使用类似于SPKM-1机制类型的机制，SPKM可以提供前面描述的低基础设施安全模型的许多方面。使用GSS-API的应用程序当然可以自由地使用GSS-API的GSS_Wrap（）例程加密用户名和密码并将其发送到服务器，以便服务器解密和验证。
Applications often have application protocols associated with them, and there might not be any provision in the protocol to specify a password. Layering a thin GSS-API mechanism over a mechanism resembling SPKM-1 can mitigate this problem. This can be a useful approach to avoid modifying applications that have already bound to GSS-API, assuming the applications are not statically bound to specific GSS-API mechanisms. The remainder of this memorandum defines the thin mechanism: the Low Infrastructure Public Key Mechanism (LIPKEY).
应用程序通常有与之关联的应用程序协议，协议中可能没有任何指定密码的规定。在类似SPKM-1的机制上分层一个精简的GSS-API机制可以缓解此问题。假设应用程序未静态绑定到特定的GSS-API机制，这是避免修改已绑定到GSS-API的应用程序的一种有用方法。本备忘录的其余部分定义了精简机制：低基础设施公钥机制（LIPKEY）。
SPKM-1 with unilateral authentication is close to the desired low infrastructure model described earlier. This section describes some additional changes to how SPKM-1 operates in order to realize the low infrastructure model. These changes include some minor changes in semantics. While it would be possible to implement these semantic changes within an SPKM-1 implementation (including using the same mechanism type Object Identifier (OID) as SPKM-1), the set of changes stretch the interpretation of RFC 2025 to the point where compatibility would be in danger. A new mechanism type, called SPKM-3, is warranted. LIPKEY requires that the SPKM implementation support SPKM-3. SPKM-3 is equivalent to SPKM-1, except as described in the remainder of this section.
具有单边身份验证的SPKM-1接近前面描述的理想低基础设施模型。本节描述了SPKM-1如何运行的一些附加更改，以实现低基础设施模型。这些变化包括语义上的一些小变化。虽然可以在SPKM-1实现中实现这些语义更改（包括使用与SPKM-1相同的机制类型对象标识符（OID）），但这组更改将RFC 2025的解释延伸到兼容性面临危险的程度。一种新的机构类型，称为SPKM-3，是有保证的。LIPKEY要求SPKM实施支持SPKM-3。SPKM-3等同于SPKM-1，但本节其余部分所述情况除外。
SPKM-3 has a different mechanism type OID from SPKM-1.
SPKM-3具有与SPKM-1不同的机构类型OID。
spkm-3 OBJECT IDENTIFIER ::=
{iso(1)identified-organization(3)dod(6)internet(1)security(5)
mechanisms(5)spkm(1)spkm-3(3)}
spkm-3 OBJECT IDENTIFIER ::=
{iso(1)identified-organization(3)dod(6)internet(1)security(5)
mechanisms(5)spkm(1)spkm-3(3)}
RFC 2025 defines no required name types of SPKM. LIPKEY requires that the SPKM-3 implementation support all the mechanism independent name types in RFC 2078.
RFC 2025未定义SPKM所需的名称类型。LIPKEY要求SPKM-3实现支持RFC2078中所有与机制无关的名称类型。
RFC 2025 defines various algorithms for integrity, confidentiality, key establishment, and subkey derivation. Except for md5WithRSAEncryption, the REQUIRED Key Establishment (K-ALG), Integrity (I-ALG) and One-Way Functions for Subkey Derivation (O-ALG) algorithms listed in RFC 2025 continue to be REQUIRED.
RFC 2025定义了完整性、机密性、密钥建立和子密钥派生的各种算法。除MD5WithRSA加密外，RFC 2025中列出的子密钥导出（O-ALG）算法仍然需要所需的密钥建立（K-ALG）、完整性（I-ALG）和单向函数。
SPKM is designed to be extensible with regard to new algorithms. In order for LIPKEY to work correctly and securely, the following algorithms MUST be implemented in SPKM-3:
SPKM的设计是为了在新算法方面具有可扩展性。为了使LIPKEY能够正确、安全地工作，必须在SPKM-3中实现以下算法：
* Integrity algorithms (I-ALG)
* 完整性算法（I-ALG）
NULL-MAC Because the initiator may not have a certificate for itself, nor for the target, it is not possible for it to calculate an Integrity value in the initiator's REQ-TOKEN that is sent to the target. So we define, in ASN.1 [CCITT] syntax, a null I-ALG that returns a zero length bit string regardless of the input passed to it:
NULL-MAC由于启动器本身或目标可能没有证书，因此无法计算发送到目标的启动器REQ-TOKEN中的完整性值。因此，我们在ASN.1[CCITT]语法中定义了一个null I-ALG，它返回一个零长度的位字符串，而不管传递给它的输入是什么：
NULL-MAC OBJECT IDENTIFIER ::=
{iso(1)identified-organization(3)dod(6)internet(1)security(5)
integrity(3)NULL-MAC(3)}
NULL-MAC OBJECT IDENTIFIER ::=
{iso(1)identified-organization(3)dod(6)internet(1)security(5)
integrity(3)NULL-MAC(3)}
id-dsa-with-sha1 This is the signature algorithm as defined in Section 7.2.2 of [RFC2459]. As noted in RFC 2459, the ASN.1 OID used to identify this signature algorithm is:
id-dsa-with-sha1这是[RFC2459]第7.2.2节中定义的签名算法。如RFC 2459所述，用于识别此签名算法的ASN.1 OID为：
id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040)
x9cm(4) 3
}
id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040)
x9cm(4) 3
}
Note that there is a work-in-progress [PKIX] to obsolete RFC 2459. However that work-in-progress does not change the definition of id-dsa-with-sha1.
请注意，对于过时的RFC 2459，有一项工作正在进行[PKIX]。但是，正在进行的工作不会更改id-dsa-with-sha1的定义。
HMAC-MD5 A consequence of the SPKM-3 initiator not having a certificate is that it cannot use a digital signature algorithm like md5WithRSAEncryption, id-dsa-with-sha1, or sha1WithRSAEncryption once the context is established. Instead, a message authentication code (MAC) algorithm is
HMAC-MD5 SPKM-3启动器没有证书的后果是，一旦建立上下文，它就不能使用MD5WithRSA加密、id-dsa-with-sha1或sha1 WithRSA加密等数字签名算法。相反，需要使用消息身份验证码（MAC）算法
required. DES-MAC is specified as recommended in [RFC2025]. Since the security of 56 bit DES has been shown to be inadequate [EFF], SPKM-3 needs a stronger MAC. Thus, SPKM-3 MUST support the HMAC-MD5 algorithm [RFC2104], with this OID:
必修的。DES-MAC按照[RFC2025]中的建议进行指定。由于56位DES的安全性已被证明不充分[EFF]，SPKM-3需要更强的MAC。因此，SPKM-3必须支持HMAC-MD5算法[RFC2104]，具有以下OID：
HMAC-MD5 OBJECT IDENTIFIER ::= {
iso(1) org(3) dod(6) internet(1) security(5)
mechanisms(5) ipsec(8) isakmpOakley(1)
1
}
HMAC-MD5 OBJECT IDENTIFIER ::= {
iso(1) org(3) dod(6) internet(1) security(5)
mechanisms(5) ipsec(8) isakmpOakley(1)
1
}
The reference for the algorithm OID of HMAC-MD5 is [IANA]. The reference for the HMAC-MD5 algorithm is [RFC2104].
HMAC-MD5算法OID的参考文献为[IANA]。HMAC-MD5算法的参考文献为[RFC2104]。
The HMAC-SHA1 algorithm is not a mandatory SPKM-3 I-ALG MAC because SHA-1 is about half the speed of MD5 [Young]. A MAC based on an encryption algorithm like cast5CBC, DES EDE3, or RC4 is not mandatory because MD5 is 31 percent faster than the fastest of the three encryption algorithms [Young].
HMAC-SHA1算法不是强制性的SPKM-3 I-ALG MAC，因为SHA-1的速度大约是MD5[Young]的一半。基于cast5CBC、DES EDE3或RC4等加密算法的MAC不是强制性的，因为MD5比三种加密算法中最快的算法快31%[Young]。
* Confidentiality algorithm (C-ALG).
* 保密算法（C-ALG）。
RFC 2025 does not have a MANDATORY confidentiality algorithm, and instead has RECOMMENDED a 56 bit DES algorithm. Since the LIPKEY initiator needs to send a password to the target, and since 56 bit DES has been demonstrated as inadequate [EFF], LIPKEY needs stronger encryption. Thus, SPKM-3 MUST support this algorithm:
RFC 2025没有强制的保密算法，而是建议使用56位DES算法。由于LIPKEY启动器需要向目标发送密码，并且56位DES已被证明不充分[EFF]，因此LIPKEY需要更强的加密。因此，SPKM-3必须支持该算法：
cast5CBC OBJECT IDENTIFIER ::= {
iso(1) memberBody(2) usa(840) nt(113533) nsn(7)
algorithms(66) 10
}
cast5CBC OBJECT IDENTIFIER ::= {
iso(1) memberBody(2) usa(840) nt(113533) nsn(7)
algorithms(66) 10
}
Parameters ::= SEQUENCE {
iv OCTET STRING DEFAULT 0, -- Initialization vector
keyLength INTEGER -- Key length, in bits
}
Parameters ::= SEQUENCE {
iv OCTET STRING DEFAULT 0, -- Initialization vector
keyLength INTEGER -- Key length, in bits
}
The reference for the OID and description of the cast5CBC algorithm is [RFC2144]. The keyLength in the Parameters MUST be set to 128 bits.
cast5CBC算法的OID和描述参考文献为[RFC2144]。参数中的keyLength必须设置为128位。
A triple DES (DES EDE3) algorithm is not a mandatory SPKM-3 C-ALG because it is much slower than cast5CBC. One set of measurements [Young] on a Pentium Pro 200 megahertz processor using the SSLeay code, showed that DES EDE3 performed as high as 1,646,210 bytes per second, using 1024 byte blocks. The same
三重DES（DES EDE3）算法不是强制性的SPKM-3 C-ALG，因为它比cast5CBC慢得多。在使用SSLeay代码的奔腾Pro 200兆赫处理器上进行的一组测量[Young]表明，DES EDE3使用1024字节块执行的速度高达每秒1646210字节。相同的
test bed yielded performance of 7,147,760 bytes per second for cast5CBC, and 22,419,840 bytes per second for RC4. Most TLS sessions negotiate the RC4 cipher. Given that LIPKEY is targeted at environments similar to that where TLS is deployed, selecting a cipher that is over 13 times slower (and over 13 times more CPU intensive) than RC4 would severely impede the usefulness of LIPKEY. For performance reasons, RC4 would be the preferred mandatory algorithm for SPKM-3. Due to intellectual property considerations with RC4 [Schneier], the combination of cast5CBC's reasonable performance, and its royalty-free licensing terms [RFC2144] make cast5CBC the optimal choice among DES EDE3, RC4, and cast5CBC.
测试台为cast5CBC提供了每秒7147760字节的性能，为RC4提供了每秒22419840字节的性能。大多数TLS会话协商RC4密码。由于LIPKEY的目标环境与部署TLS的环境类似，因此选择比RC4慢13倍（CPU密集度高13倍）的密码将严重阻碍LIPKEY的使用。出于性能原因，RC4将是SPKM-3的首选强制算法。鉴于RC4[Schneier]的知识产权考虑，cast5CBC的合理性能及其免版税许可条款[RFC2144]的结合使cast5CBC成为DES EDE3、RC4和cast5CBC的最佳选择。
* Key Establishment Algorithm (K-ALG)
* 密钥建立算法（K-ALG）
RFC 2025 lists dhKeyAgreement [PKCS-3] as an apparently optional algorithm. As will be described later, the RSAEncryption key establishment algorithm is of no use for a low infrastructure security mechanism as defined by this memorandum. Hence, in SPKM-3, dhKeyAgreement is a REQUIRED key establishment algorithm:
RFC 2025将dhKeyAgreement[PKCS-3]列为一种显然可选的算法。如下文所述，RSA加密密钥建立算法对于本备忘录定义的低基础设施安全机制没有用处。因此，在SPKM-3中，dhKeyAgreement是一种必需的密钥建立算法：
dhKeyAgreement OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-3(3) 1
}
dhKeyAgreement OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-3(3) 1
}
* One-Way Function for Subkey Derivation Algorithm (O-ALG)
* 子密钥导出算法的单向函数（O-ALG）
RFC 2025 lists MD5 as a mandatory algorithm. Since MD5 has been found to have weaknesses when used as a hash [Dobbertin], id-sha1 is a MANDATORY O-ALG in SPKM-3:
RFC 2025将MD5列为强制算法。由于MD5在用作哈希[Dobbertin]时存在弱点，id-sha1在SPKM-3中是一个强制性的O-ALG：
id-sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14)
secsig(3) algorithms(2) 26
}
id-sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14)
secsig(3) algorithms(2) 26
}
The reference for the algorithm OID of id-sha1 is [RFC2437]. The reference for SHA-1 algorithm corresponding to id-sha1 is [FIPS].
id-sha1算法OID的参考文献为[RFC2437]。对应于id-sha1的SHA-1算法的参考文献为[FIPS]。
md5WithRSAEncryption The md5WithRSAEncryption integrity algorithm is listed in [RFC2025] as mandatory. Due to intellectual property considerations [RSA-IP], SPKM-3 implementations cannot be
MD5WithRSA加密[RFC2025]中列出的MD5WithRSA加密完整性算法是强制性的。由于知识产权方面的考虑[RSA-IP]，SPKM-3的实施无法
required to implement it. However, given the proliferation of certificates using RSA public keys, md5WithRSAEncryption is strongly RECOMMENDED. Otherwise, the opportunities for LIPKEY to leverage existing public key infrastructure will be limited.
需要执行它。但是，鉴于使用RSA公钥的证书数量激增，强烈建议使用MD5WithRSA加密。否则，LIPKEY利用现有公钥基础设施的机会将受到限制。
sha1WithRSAEncryption For reasons similar to that for md5WithRSAEncryption, sha1WithRSAEncryption is a RECOMMENDED algorithm. The sha1WithRSAEncryption algorithm is listed in addition to md5WithRSAEncryption due to weaknesses in the MD5 hash algorithm [Dobbertin]. The OID for sha1WithRSAEncryption is:
SHA1 WithRSA加密与MD5 WithRSA加密的原因类似，建议使用SHA1 WithRSA加密算法。由于MD5哈希算法[Dobbertin]的弱点，除MD5 WithRSA加密外，还列出了SHA1 WithRSA加密算法。使用RSA加密的SHA1的OID为：
sha1WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 5
}
sha1WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1)
pkcs-1(1) 5
}
The reference for the algorithm OID and description of sha1WithRSAEncryption is [RFC2437].
使用RSA加密的SHA1算法OID和描述的参考文献为[RFC2437]。
RFC 2025 sets up a context with an initiator first token (REQ-TOKEN), a target reply (REP-TI-TOKEN), and finally an initiator second token (REP-IT-TOKEN) to reply to the target's reply. Since LIPKEY uses SPKM-3 with unilateral authentication, the REP-IT-TOKEN is not used. LIPKEY has certain requirements on the contents of the REQ-TOKEN and REP-TI-TOKEN, but the syntax of the SPKM-3 tokens is not different from RFC 2025's SPKM-1 tokens.
RFC 2025使用启动器第一令牌（REQ-token）、目标应答（REP-TI-token）和最后一个启动器第二令牌（REP-IT-token）建立上下文，以应答目标的应答。由于LIPKEY使用带有单边身份验证的SPKM-3，因此不使用REP-IT-TOKEN。LIPKEY对REQ-TOKEN和REP-TI-TOKEN的内容有一定要求，但SPKM-3令牌的语法与RFC 2025的SPKM-1令牌并无不同。
If the SPKM-3 initiator cannot calculate a req-integrity field due to the lack of a target certificate, it MUST use the NULL-MAC I-ALG described earlier in this memorandum. This will produce a zero length bit string in the Integrity field.
如果SPKM-3启动器由于缺少目标证书而无法计算req完整性字段，则必须使用本备忘录前面描述的NULL-MAC I-ALG。这将在完整性字段中生成零长度的位字符串。
Because RFC 2025 requires that the RSAEncryption K-ALG be present, SPKM-1 must be able to map the target (targ-name) to its public key certificate, and thus SPKM can use the RSAEncryption algorithm to fill in the key-estb-req field. Because LIPKEY assumes a low infrastructure deployment, SPKM-3 MUST be prepared to be unable to map the targ-name field of the Req-contents field. This is a contradiction which is resolved by requiring SPKM-3 to support the
由于RFC 2025要求存在RSAK-ALG加密，SPKM-1必须能够将目标（targ名称）映射到其公钥证书，因此SPKM可以使用RSAKEncryption算法填充密钥estb req字段。由于LIPKEY假设基础设施部署较低，因此SPKM-3必须准备好无法映射Req内容字段的targ name字段。这是一个矛盾，通过要求SPKM-3支持
dhKeyAgreement algorithm. Note that if an SPKM-3 implementation tries to map the target to a certificate, and succeeds, it is free to use the RSAEncryption K-ALG algorithm. It is also free to use an algID other than NULL-MAC in the REQ-TOKEN type.
dhKeyAgreement算法。请注意，如果SPKM-3实现尝试将目标映射到证书并成功，则可以自由使用RSAK-ALG加密算法。在REQ-TOKEN类型中，也可以自由使用除NULL-MAC之外的algID。
SPKM-3 implementations MUST set the target-certif-data-required bit to 1 if the only K-ALG in the key-estb-set field of Req-contents is dhKeyAgreement. This would normally occur if the SPKM-3 implementation cannot resolve the target name to a certificate.
如果Req内容的key estb set字段中的唯一K-ALG是DHKEYAGREENT，则SPKM-3实现必须将目标certif data required位设置为1。如果SPKM-3实现无法将目标名称解析为证书，则通常会发生这种情况。
If the SPKM-3 implementation supports an algorithm weaker than cast5CBC, cast5CBC MUST be listed before the weaker algorithm to encourage the target to negotiate the stronger algorithm.
如果SPKM-3实现支持比cast5CBC弱的算法，则cast5CBC必须列在较弱算法之前，以鼓励目标协商较强算法。
Because the initiator will be anonymous (at the SPKM-3 level) and will not have a certificate for itself, the initiator cannot use an integrity algorithm that supports non-repudiation; it must use a MAC algorithm. If the SPKM-3 implementation supports an algorithm weaker than HMAC-MD5, HMAC-MD5 MUST be listed before the weaker algorithm to encourage the target to negotiate the stronger algorithm.
由于启动器将是匿名的（在SPKM-3级别），并且自身没有证书，因此启动器不能使用支持不可否认性的完整性算法；它必须使用MAC算法。如果SPKM-3实现支持的算法弱于HMAC-MD5，则必须在弱算法之前列出HMAC-MD5，以鼓励目标协商强算法。
With the previously described requirements on REQ-TOKEN, the contents of SPKM-3's REP-TI-TOKEN can for the most part be derived from the specification in RFC 2025. The exceptions are the algId and rep-ti-integ fields.
根据前面描述的REQ-TOKEN要求，SPKM-3的REP-TI-TOKEN的内容大部分可以从RFC 2025中的规范中派生出来。例外情况是algId和rep ti integ字段。
The SPKM-3 target MUST NOT use a NULL-MAC I-ALG; it MUST use a signature algorithm like id-dsa-with-sha1, md5WithRSAEncryption, or sha1WithRSAEncryption.
SPKM-3目标不得使用空MAC I-ALG；它必须使用id-dsa-with-sha1、MD5 WITHRSA加密或sha1 WITHRSA加密等签名算法。
If the req-token has an algId of NULL-MAC, then the target MUST compute the rep-ti-integ on the concatenation of the req-contents and rep-ti-contents.
如果req令牌的algId为NULL-MAC，则目标必须在req内容和rep ti内容的串联上计算rep ti整数。
The SPKM-3 initiator and target negotiate the set of algorithms they mutually support, using the procedure defined in Section 5.2 of RFC 2025. If a QOP of zero is specified, then the initiator and target will use the first C-ALG (privacy), and I-ALG (integrity) algorithms negotiated.
SPKM-3发起者和目标使用RFC 2025第5.2节中定义的程序协商他们相互支持的算法集。如果指定QOP为零，则发起方和目标方将使用协商的第一个C-ALG（隐私）和I-ALG（完整性）算法。
SPKM breaks the QOP into several fields, as reproduced here from Section 5.2 of RFC 2025:
SPKM将QOP分为几个字段，如RFC 2025第5.2节所述：
Confidentiality Integrity
31 (MSB) 16 15 (LSB) 0
-------------------------------|-------------------------------
| TS(5) | U(3) | IA(4) | MA(4) | TS(5) | U(3) | IA(4) | MA(4) |
-------------------------------|-------------------------------
Confidentiality Integrity
31 (MSB) 16 15 (LSB) 0
-------------------------------|-------------------------------
| TS(5) | U(3) | IA(4) | MA(4) | TS(5) | U(3) | IA(4) | MA(4) |
-------------------------------|-------------------------------
The MA subfields enumerate mechanism-defined algorithms. Since this memorandum introduces a new mechanism, SPKM-3, within the SPKM family, it is appropriate to add algorithms to the MA subfields of the respective Confidentiality and Integrity fields.
MA子字段枚举机制定义的算法。由于本备忘录在SPKM系列中引入了一种新的机制，即SPKM-3，因此将算法添加到相应机密性和完整性字段的MA子字段是合适的。
The complete set of Confidentiality MA algorithms is thus:
因此，完整的保密MA算法集为：
0001 (1) = DES-CBC 0010 (2) = cast5CBC
0001（1）=DES-CBC 0010（2）=cast5CBC
Where "0001" and "0010" are in base 2. An SPKM peer that negotiates a confidentiality MA algorithm value of "0010" MUST use a 128 bit key, i.e. set the keyLength values in the cast5CBC Parameters to 128 bits.
其中“0001”和“0010”位于基数2中。协商保密性MA算法值“0010”的SPKM对等方必须使用128位密钥，即将cast5CBC参数中的keyLength值设置为128位。
The complete set of Integrity MA algorithms is thus:
因此，完整的MA算法集为：
0001 (1) = md5WithRSAEncryption 0010 (2) = DES-MAC 0011 (3) = id-dsa-with-sha1 0100 (4) = HMAC-MD5 0101 (5) = sha1WithRSAEncryption
0001（1）=MD5带RSA加密0010（2）=DES-MAC 0011（3）=id-dsa-with-sha1 0100（4）=HMAC-MD5 0101（5）=sha1带RSA加密
Where "0001" through "0101" are in base 2.
其中“0001”至“0101”位于基数2中。
Adding support for cast5CBC, id-dsa-with-sha1, HMAC-MD5, and sha1WithRSAEncryption in the above manner to SPKM-1 and SPKM-2 does not impair SPKM-1 and SPKM-2 backward compatibility because, as noted previously, SPKM negotiates algorithms. An older SPKM-1 or SPKM-2 that does not recognize MA values for cast5CBC, id-dsa-with-sha1, HMAC-MD5, or sha1WithRSAEncryption will not select them.
以上述方式向SPKM-1和SPKM-2添加对cast5CBC、id-dsa-with-sha1、HMAC-MD5和sha1 WITHRSA加密的支持不会损害SPKM-1和SPKM-2的向后兼容性，因为如前所述，SPKM协商算法。如果旧版SPKM-1或SPKM-2无法识别cast5CBC、id-dsa-with-sha1、HMAC-MD5或sha1 WITHRSANCRYPTION的MA值，则不会选择它们。
LIPKEY will invoke SPKM-3 to produce SPKM tokens. Since the mechanism that the application uses is LIPKEY, LIPKEY will wrap some of the SPKM-3 tokens with LIPKEY prefixes. The exact definition of the tokens is described later in this memorandum.
LIPKEY将调用SPKM-3来生成SPKM令牌。由于应用程序使用的机制是LIPKEY，因此LIPKEY将用LIPKEY前缀包装一些SPKM-3令牌。代币的确切定义将在本备忘录后面部分进行说明。
The initiator uses GSS_Import_name to import the target's name, typically, but not necessarily, using the GSS_C_NT_HOSTBASED_SERVICE name type. Ultimately, the output of GSS_Import_name will apply to an SPKM-3 mechanism type because a LIPKEY target is an SPKM-3 target.
启动器使用GSS_导入_名称导入目标的名称，通常（但不一定）使用GSS_C_NT_基于主机的_服务名称类型。最终，GSS_Import_name的输出将应用于SPKM-3机制类型，因为LIPKEY目标是SPKM-3目标。
The initiator calls GSS_Acquire_cred. The credentials that are acquired are LIPKEY credentials, a user name and password. How the user name and password is acquired is dependent upon the operating environment. A application that invokes GSS_Acquire_cred() while the application's user has a graphical user interface running might trigger the appearance of a pop up window that prompts for the information. A application embedded into the operating system, such as an NFS [Sandberg] client implemented as a native file system might broadcast a message to the user's terminals telling him to invoke a command that prompts for the information.
发起者调用GSS\u Acquire\u cred。获取的凭据包括LIPKEY凭据、用户名和密码。用户名和密码的获取方式取决于操作环境。当应用程序的用户运行图形用户界面时调用GSS_Acquire_cred（）的应用程序可能会触发弹出窗口的出现，提示输入信息。嵌入到操作系统中的应用程序，例如作为本机文件系统实现的NFS[Sandberg]客户机，可能会向用户终端广播一条消息，告诉用户调用一个命令来提示输入信息。
Because the credentials will not be used until GSS_Init_sec_context is called, the LIPKEY implementation will need to safeguard the credentials. If this is a problem, the implementation may instead defer actual acquisition of the user name and password until GSS_init_sec_context is ready to send the user name and password to the target. In that event, the output_cred_handle argument of GSS_Acquire_cred would simply be a reference that mapped to the principal corresponding to the desired_name argument. A subsequent GSS_Init_sec_context call would consider the mapping of claimant_cred_handle to principal when it acquires the user name and password. For example, the aforementioned pop up window might fill in the user name portion of the dialog with a default value that maps to the principal referred to in claimant_cred_handle.
因为在调用GSS_Init_sec_上下文之前不会使用凭据，所以LIPKEY实现需要保护凭据。如果这是一个问题，则实现可能会推迟用户名和密码的实际获取，直到GSS_init_sec_上下文准备好将用户名和密码发送到目标。在这种情况下，GSS_Acquire_cred的output_cred_handle参数将只是一个映射到与所需的_name参数对应的主体的引用。后续的GSSY-IITY-SeCixCurrar调用将考虑在获取用户名和密码时将CalimaTyCuffl句柄映射到主体的映射。例如，前面提到的弹出窗口可能会在对话框的用户名部分填充一个默认值，该值映射到索赔人cred\u handle中提到的主体。
When a program invokes GSS_Init_sec_context on the LIPKEY mechanism type, if the context handle is NULL, the LIPKEY mechanism will in turn invoke GSS_Init_sec_context on an SPKM-3 mechanism implemented according to the requirements described previously. This call to SPKM-3 MUST have the following attributes:
当程序调用LIPKEY机制类型上的GSS_Init_sec_上下文时，如果上下文句柄为NULL，LIPKEY机制将依次调用根据前面描述的要求实现的SPKM-3机制上的GSS_Init_sec_上下文。此对SPKM-3的调用必须具有以下属性：
* claimant_cred_handle is NULL
* 索赔人凭证句柄为空
* mutual_req_flag is FALSE
* 相互请求标志为FALSE
* anon_req_flag is TRUE
* anon_req_标志为真
* input_token is NULL
* 输入\u令牌为空
* mech_type is the OID of the SPKM-3 mechanism
* mech_类型是SPKM-3机构的OID
Keep in mind the above attributes are in the GSS_Init_sec_context call from the LIPKEY mechanism down to the SPKM-3 mechanism. There are no special restrictions placed on the application invoking LIPKEY's GSS_Init_sec_context routine. All other arguments are derived from the LIPKEY GSS_Init_sec_context arguments.
请记住，上述属性位于从LIPKEY机制到SPKM-3机制的GSS_Init_sec_上下文调用中。对调用LIPKEY的GSS_Init_sec_上下文例程的应用程序没有特殊限制。所有其他参数均源自LIPKEY GSS_Init_sec_上下文参数。
The call to the SPKM-3 GSS_Init_sec_context will create an SPKM-3 context handle. The remainder of the description of the LIPKEY GSS_Init_sec_context call depends on whether the caller of the LIPKEY GSS_Init_sec_context sets anon_req_flag to TRUE or FALSE.
对SPKM-3 GSS_Init_sec_上下文的调用将创建SPKM-3上下文句柄。LIPKEY GSS_Init_sec_上下文调用的其余描述取决于LIPKEY GSS_Init_sec_上下文的调用方是否将anon_req_标志设置为TRUE或FALSE。
If the caller of LIPKEY's GSS_Init_sec_context sets anon_req_flag to TRUE, it MUST return to the LIPKEY caller all the outputs from the SPKM-3 GSS_Init_sec_context call, including the output_context_handle, output_token, and mech_type. In this way, LIPKEY now "gets out of the way" of GSS-API processing between the application and SPKM-3, because nothing in the returned outputs relates to LIPKEY. This is necessary, because LIPKEY context tokens do not have provision for specifying anonymous initiators. This is because SPKM-3 is sufficient for purpose of supporting anonymous initiators in a low infrastructure environment.
如果LIPKEY的GSS_Init_sec_上下文调用方将anon_req_标志设置为TRUE，则必须将SPKM-3 GSS_Init_sec_上下文调用的所有输出返回给LIPKEY调用方，包括输出上下文_句柄、输出令牌和机械类型。通过这种方式，LIPKEY现在“避开”了应用程序和SPKM-3之间的GSS-API处理，因为返回的输出中没有任何内容与LIPKEY相关。这是必要的，因为LIPKEY上下文令牌没有指定匿名启动器的规定。这是因为SPKM-3足以在低基础设施环境中支持匿名启动器。
Clearly, when the LIPKEY caller desires anonymous authentication, LIPKEY does not add any value, but it is simpler to support the feature, than to insist the caller directly use SPKM-3.
显然，当LIPKEY调用者需要匿名身份验证时，LIPKEY不会增加任何值，但支持该功能比坚持调用者直接使用SPKM-3更简单。
If all goes well, the caller of LIPKEY will be returned a major_status of GSS_S_CONTINUE_NEEDED via SPKM-3, and so the caller of LIPKEY will send the output_token to the target. The caller of LIPKEY then receives the response token from the target, and directly invokes the SPKM-3 GSS_Init_sec_context. Upon return, the major_status should be GSS_S_COMPLETE.
如果一切顺利，LIPKEY的调用者将通过SPKM-3返回所需的GSS_S_CONTINUE_的主要_状态，因此LIPKEY的调用者将向目标发送输出_令牌。然后，LIPKEY的调用者从目标接收响应令牌，并直接调用SPKM-3 GSS_Init_sec_上下文。返回后，主要_状态应为GSS_S_COMPLETE。
The LIPKEY mechanism will need to allocate a context handle for itself, and record in the LIPKEY context handle the SPKM-3 context handle that was returned in the output_context_handle parameter from the call to the SPKM-3 GSS_Init_sec_context routine. The LIPKEY GSS_Init_sec_context routine will return in output_context_handle the LIPKEY context handle, and in mech_type, the LIPKEY mechanism type. The output_token is as defined later in this memorandum, in the subsection entitled "Context Tokens Prior to SPKM-3 Context Establishment." All the other returned outputs will be those that the SPKM-3 GSS_Init_sec_context routine returned to LIPKEY. If all went well, the SPKM-3 mechanism will have returned a major_status of GSS_S_CONTINUE_NEEDED.
LIPKEY机制需要为自己分配一个上下文句柄，并在LIPKEY上下文句柄中记录从SPKM-3 GSS_Init_sec_上下文例程调用的输出_context_handle参数中返回的SPKM-3上下文句柄。LIPKEY GSS_Init_sec_上下文例程将在输出_context_handle中返回LIPKEY上下文句柄，在mech_类型中返回LIPKEY机制类型。输出令牌在本备忘录后面的“SPKM-3上下文建立之前的上下文令牌”小节中定义。所有其他返回的输出将是SPKM-3 GSS_Init_sec_上下文例程返回给LIPKEY的输出。如果一切顺利，SPKM-3机制将返回所需GSS的主要状态。
The caller of the LIPKEY GSS_Init_sec_context routine will see a major_status of GSS_S_CONTINUE_NEEDED, and so the caller of LIPKEY will send the output_token to the target. The caller of LIPKEY then receives the target's response token, and invokes the LIPKEY GSS_Init_sec_context routine for a second time. LIPKEY then invokes the SPKM-3 GSS_Init_sec_context for a second time and upon return, the major_status should be GSS_S_COMPLETE.
LIPKEY GSS_Init_sec_上下文例程的调用者将看到所需GSS_S_CONTINUE_的主要_状态，因此LIPKEY的调用者将向目标发送输出_令牌。然后，LIPKEY的调用者接收目标的响应令牌，并再次调用LIPKEY GSS_Init_sec_上下文例程。LIPKEY然后第二次调用SPKM-3 GSS_Init_sec_上下文，返回后，主_状态应为GSS_S_COMPLETE。
While SPKM-3's context establishment is now complete, LIPKEY's context establishment is not yet complete, because the initiator must send to the target the user name and password that were passed to it via the claimant_cred_handle on the first call to the LIPKEY GSS_Init_sec_context routine. LIPKEY uses the established SPKM-3 context handle as the input to GSS_Wrap (with conf_req_flag set to TRUE) to encrypt what the claimant_cred_handle refers to (user name and password), and returns that as the output_token to the caller of LIPKEY (provided the conf_state output from the call to SPKM-3's GSS_Wrap is TRUE), along with a major_status of GSS_S_CONTINUE_NEEDED.
虽然SPKM-3的上下文建立现已完成，但LIPKEY的上下文建立尚未完成，因为发起方必须向目标方发送用户名和密码，在第一次调用LIPKEY GSS_Init_sec_上下文例程时，该用户名和密码通过Claimer_cred_句柄传递给目标方。LIPKEY使用已建立的SPKM-3上下文句柄作为GSS_Wrap的输入（conf_req_标志设置为TRUE），以加密索赔人的cred_句柄引用的内容（用户名和密码），并将其作为输出_令牌返回给LIPKEY的调用者（前提是对SPKM-3的GSS_Wrap的调用的conf_状态输出为TRUE），随着GSS的重要地位，继续需要。
The caller of LIPKEY sends its second context establishment token to the target, and waits for a token provided by the target's GSS_Accept_sec_context routine. The target's LIPKEY GSS_Accept_sec_context routine invokes the SPKM-3 GSS_Unwrap routine on the token, and validates the user name and password. The target then invokes SPKM-3's GSS_Wrap routine on a boolean indicating
LIPKEY的调用者向目标发送其第二个上下文建立令牌，并等待目标的GSS_Accept_sec_上下文例程提供的令牌。目标的LIPKEY GSS_Accept_sec_上下文例程调用令牌上的SPKM-3 GSS_展开例程，并验证用户名和密码。然后，目标在一个布尔值上调用SPKM-3的GSS_Wrap例程
whether or not the user name and password were accepted, and returns the output_message result from GSS_Wrap as the output_token result for GSS_Accept_sec_context.
是否接受用户名和密码，并将GSS_Wrap的输出_消息结果作为GSS_Accept_sec_上下文的输出_令牌结果返回。
The caller of LIPKEY receives the target's response token, and passes this via the input_token parameter to the LIPKEY GSS_Init_sec_context routine. LIPKEY then invokes GSS_Unwrap to get the boolean acceptance indication, and maps this to a major_status of either GSS_S_COMPLETE indicating successful (the boolean was TRUE) and completed LIPKEY context establishment, or GSS_S_FAILURE, indicating that context establishment failed. GSS_S_CONTINUE_NEEDED will not be returned.
LIPKEY的调用者接收目标的响应令牌，并通过input_token参数将其传递给LIPKEY GSS_Init_sec_上下文例程。LIPKEY然后调用GSS_Unwrap以获取布尔接受指示，并将其映射到GSS_S_COMPLETE表示成功（布尔值为TRUE）并完成LIPKEY上下文建立或GSS_S_FAILURE表示上下文建立失败的主要状态。所需的GSS_S_CONTINUE_将不会返回。
Note that the mutual_req_flag parameter is ignored because unilateral authentication is impossible. The initiator must authenticate the target via SPKM-3 in order to create a secure channel to transmit the user name and password. The target must authenticate the initiator when it receives the user name and password.
请注意，由于无法进行单边身份验证，因此会忽略mutual_req_flag参数。发起者必须通过SPKM-3对目标进行身份验证，以便创建安全通道来传输用户名和密码。目标必须在收到用户名和密码时对启动器进行身份验证。
The SPKM-3 context remains established while the LIPKEY context is established. If the SPKM-3 context expires before the LIPKEY context is destroyed, the LIPKEY implementation should expire the LIPKEY context and return the appropriate error on the next GSS-API operation.
SPKM-3上下文保持建立，而LIPKEY上下文保持建立。如果SPKM-3上下文在LIPKEY上下文被销毁之前过期，LIPKEY实现应该使LIPKEY上下文过期，并在下一个GSS-API操作中返回相应的错误。
For other operations, the LIPKEY context acts as a pass through to the SPKM-3 context. Operations that affect or inquire context state, such as GSS_Delete_sec_context, GSS_Export_sec_context, GSS_Import_sec_context, and GSS_Inquire_context will require a pass through to the SPKM-3 context and a state modification of the LIPKEY context.
对于其他操作，LIPKEY上下文充当到SPKM-3上下文的传递。影响或查询上下文状态的操作，如GSS_Delete_secu_context、GSS_Export_secu_context、GSS_Import_secu_context和GSS_inquire_context，将需要传递到SPKM-3上下文并修改LIPKEY上下文的状态。
As with the initiator, the imported name will be that of the target.
与启动器一样，导入的名称将是目标的名称。
The target calls the LIPKEY GSS_Acquire_cred routine to get a credential for an SPKM-3 target, via the SPKM-3 GSS_Acquire_cred routine. The desired_name is the output_name from GSS_Import_name.
目标调用LIPKEY GSS_Acquire_cred例程，通过SPKM-3 GSS_Acquire_cred例程获取SPKM-3目标的凭证。所需的_名称是GSS_导入_名称的输出_名称。
When a program invokes GSS_Accept_sec_context on the LIPKEY mechanism type, if the context handle is NULL, the LIPKEY mechanism will in turn invoke GSS_Accept_sec_context on an SPKM-3 mechanism implemented according the requirements described previously. This call to SPKM-3 is no different than what one would expect for a layered call to GSS_Accept_sec_context.
当程序调用LIPKEY机制类型上的GSS_Accept_sec_上下文时，如果上下文句柄为NULL，LIPKEY机制将依次调用根据前面描述的要求实现的SPKM-3机制上的GSS_Accept_sec_上下文。对SPKM-3的调用与对GSS_Accept_sec_context的分层调用没有什么不同。
If all goes well, the SPKM-3 GSS_Accept_sec_context call succeeds with GSS_S_COMPLETE, and the LIPKEY GSS_Accept_sec_context call returns the output_token to the caller, but with a major_status of GSS_S_CONTINUE_NEEDED because the LIPKEY initiator is still expected to send the user name and password.
如果一切顺利，SPKM-3 GSS_Accept_sec_上下文调用将在GSS_sec_完成的情况下成功，LIPKEY GSS_Accept_sec_上下文调用将输出_令牌返回给调用者，但主要_状态为GSS_S_CONTINUE_，因为LIPKEY启动器仍需要发送用户名和密码。
Once the SPKM-3 context is in a GSS_S_COMPLETE state, the next token the target receives will contain the user name and password, wrapped by the output of an SPKM-3 GSS_Wrap call. The target invokes the LIPKEY GSS_Accept_sec_context, which in turn invokes the SPKM-3 GSS_Unwrap routine. The LIPKEY GSS_Accept_sec_context routine then compares the user name and password with its user name name and password database. If the initiator's user name and password are valid, GSS_S_COMPLETE is returned to the caller. Otherwise GSS_S_FAILURE is returned. In either case, an output_token - equal to the output_message result from an SPKM-3 GSS_Wrap call on a boolean value - is returned to the caller. The boolean value is set to TRUE if the the user name and password were valid, FALSE otherwise. The target expects no more context establishment tokens from caller.
一旦SPKM-3上下文处于GSS_S_完成状态，目标接收的下一个令牌将包含用户名和密码，并由SPKM-3 GSS_Wrap调用的输出包装。目标调用LIPKEY GSS_Accept_sec_上下文，该上下文反过来调用SPKM-3 GSS_展开例程。LIPKEY GSS_Accept_sec_上下文例程然后将用户名和密码与其用户名和密码数据库进行比较。如果启动器的用户名和密码有效，则会将GSS_s_COMPLETE返回给调用方。否则返回GSS_故障。在任何一种情况下，都会向调用者返回一个output_令牌（等于对布尔值进行SPKM-3 GSS_Wrap调用的output_消息结果）。如果用户名和密码有效，则布尔值设置为TRUE，否则为FALSE。目标不需要调用方提供更多的上下文建立令牌。
lipkey OBJECT IDENTIFIER ::=
{iso(1)identified-organization(3)dod(6)internet(1)security(5)
mechanisms(5)lipkey(9)}
lipkey OBJECT IDENTIFIER ::=
{iso(1)identified-organization(3)dod(6)internet(1)security(5)
mechanisms(5)lipkey(9)}
LIPKEY uses only the mechanism independent name types defined in RFC 2078. All the name types defined in RFC 2078 are REQUIRED.
LIPKEY仅使用RFC 2078中定义的与机制无关的名称类型。RFC 2078中定义的所有名称类型都是必需的。
GSS-API defines the context tokens as:
GSS-API将上下文标记定义为：
InitialContextToken ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
InitialContextToken ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
SubsequentContextToken ::= innerContextToken ANY
-- interpretation based on predecessor InitialContextToken
-- ASN.1 structure not required
SubsequentContextToken ::= innerContextToken ANY
-- interpretation based on predecessor InitialContextToken
-- ASN.1 structure not required
The contents of the innerContextToken depend on whether the SPKM-3 context is established or not.
innerContextToken的内容取决于是否建立SPKM-3上下文。
In a LIPKEY InitialContextToken, thisMech will be the Object identifier for LIPKEY. However, as long as LIPKEY has not established the SPKM-3 mechanism, the innerContextToken for both the InitialContextToken and the SubsequentContextToken will be the output of an SPKM-3 GSS_Init_sec_context or GSS_Accept_sec_context. So the LIPKEY innerContextToken would be either:
在LIPKEY InitialContextToken中，thisMech将是LIPKEY的对象标识符。但是，只要LIPKEY没有建立SPKM-3机制，InitialContextToken和SubsequentContextToken的innerContextToken都将是SPKM-3 GSS_Init_sec_上下文或GSS_Accept_sec_上下文的输出。因此LIPKEY innerContextToken可以是：
* An InitialContextToken, with thisMech set to the object identifier for SPKM-3, with innerContextToken defined to be an SPKMInnerContextToken, as defined in RFC 2025.
* InitialContextToken，thisMech设置为SPKM-3的对象标识符，innerContextToken定义为SPKMInnerContextToken，如RFC 2025中所定义。
* A SubsequentContextToken, with innerContextToken defined to be SPKMInnerContextToken
* 随后的ContextToken，其innerContextToken定义为SPKminerContextToken
Once the SPKM-3 context is established, there is just one token sent from the initiator to the target, and one token returned to initiator.
一旦建立了SPKM-3上下文，只有一个令牌从启动器发送到目标，一个令牌返回到启动器。
The LIPKEY initiator generates a token that is the the result of a GSS_Wrap (conf_req is set to TRUE) of a user name and password by the SPKM-3 context. The input_message argument of GSS_Wrap refers to an instance of the UserName-Password type defined below:
LIPKEY启动器生成一个令牌，该令牌是SPKM-3上下文对用户名和密码进行GSS_包装（conf_req设置为TRUE）的结果。GSS_Wrap的input_message参数引用下面定义的用户名密码类型的实例：
UserName-Password ::= SEQUENCE {
user-name OCTET STRING,
-- each octet is an octet of a
-- UTF-8 [RFC2279] string
password OCTET STRING
-- each octet is an octet of a
-- UTF-8 [RFC2279] string
}
UserName-Password ::= SEQUENCE {
user-name OCTET STRING,
-- each octet is an octet of a
-- UTF-8 [RFC2279] string
password OCTET STRING
-- each octet is an octet of a
-- UTF-8 [RFC2279] string
}
The target validates the user name and password token from the initiator, and generates a response token that is the output_message result of an SPKM-3 GSS_Wrap (conf_req may or may not be set to TRUE) call on an indication of validation success. The input_message argument of GSS_Wrap refers to an instance of the Valid-UNP type defined below:
目标验证来自启动器的用户名和密码令牌，并生成响应令牌，该令牌是SPKM-3 GSS_Wrap（conf_req可以设置为TRUE，也可以不设置为TRUE）调用的输出消息结果，指示验证成功。GSS_Wrap的输入_消息参数引用了下面定义的有效UNP类型的实例：
Valid-UNP ::= BOOLEAN
-- If TRUE, user name/password pair was valid.
Valid-UNP ::= BOOLEAN
-- If TRUE, user name/password pair was valid.
RFC 2078 defines the token emitted by GSS_GetMIC and GSS_Wrap as:
PerMsgToken ::=
-- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
-- ASN.1 structure not required
innerMsgToken ANY
RFC 2078 defines the token emitted by GSS_GetMIC and GSS_Wrap as:
PerMsgToken ::=
-- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
-- ASN.1 structure not required
innerMsgToken ANY
SealedMessage ::=
-- as emitted by GSS_Wrap and processed by GSS_Unwrap
-- includes internal, mechanism-defined indicator
-- of whether or not encrypted
-- ASN.1 structure not required
sealedUserData ANY
SealedMessage ::=
-- as emitted by GSS_Wrap and processed by GSS_Unwrap
-- includes internal, mechanism-defined indicator
-- of whether or not encrypted
-- ASN.1 structure not required
sealedUserData ANY
As one can see, there are no mechanism independent prefixes in PerMSGToken or SealedMessage, and no explicit mechanism specific information. Since LIPKEY does not add any value to GSS_GetMIC and
可以看到，PerMSGToken或SealedMessage中没有独立于机制的前缀，也没有明确的特定于机制的信息。因为LIPKEY不会给GSS_GetMIC和
GSS_Wrap other than passing the message to the SPKM-3 GSS_GetMIC and GSS_Wrap, LIPKEY's PerMsgToken and SealedMessage tokens are exactly what SPKM-3's GSS_GetMIC and GSS_Wrap routines produce.
GSS_Wrap除了将消息传递给SPKM-3 GSS_GetMIC和GSS_Wrap之外，LIPKEY的PerMsgToken和Sealed消息令牌正是SPKM-3的GSS_GetMIC和GSS_Wrap例程产生的。
LIPKEY, being a pass through for GSS_Wrap and GSS_GetMIC to SPKM-3, does not interpret or alter the QOPs passed to the aforementioned routines or received from their complements, GSS_Unwrap, and GSS_VerifyMIC. Thus, LIPKEY supports the same set of QOPs as SPKM-3.
LIPKEY作为GSS_Wrap和GSS_GetMIC到SPKM-3的传递，不解释或改变传递到上述例程或从补充、GSS_Unwrap和GSS_VerifyMIC接收到的QOP。因此，LIPKEY支持与SPKM-3相同的QOP集。
LIPKEY sends the clear text password encrypted by 128 bit cast5CBC so the risk in this approach is in how the target manages the password after it is done with it. The approach should be safe, provided the target clears the memory (primary and secondary, such as disk) buffers that contained the password, and any hash of the password immediately after it has validated the user's password.
LIPKEY发送由128位cast5CBC加密的明文密码，因此这种方法的风险在于目标在使用完密码后如何管理密码。该方法应该是安全的，前提是目标在验证用户密码后立即清除包含密码的内存（主要和次要，如磁盘）缓冲区以及密码的任何哈希。
The initiator must have a list of trusted Certification Authorities in order to verify the checksum (rep-ti-integ) on the SPKM-3 target's context reply token. If it encounters a certificate signed by an unknown and/or untrusted certificate authority, the initiator MUST NOT silently accept the certificate. If it does wish to accept the certificate, it MUST get confirmation from the user running the application that is using GSS-API.
发起方必须拥有受信任的证书颁发机构列表，以便验证SPKM-3目标的上下文应答令牌上的校验和（rep ti integ）。如果遇到由未知和/或不受信任的证书颁发机构签名的证书，则启动器不得静默接受该证书。如果它确实希望接受证书，则必须获得运行使用GSS-API的应用程序的用户的确认。
While the MD5 hash algorithm has been found to have weaknesses [Dobbertin], the weaknesses do not impact the security of HMAC-MD5 [Dobbertin].
虽然发现MD5哈希算法存在弱点[Dobbertin]，但这些弱点并不影响HMAC-MD5[Dobbertin]的安全性。
The cast5CBC encryption algorithm is relatively new compared to established algorithms like triple DES, and RC4. Nonetheless, the choice of cast5CBC as the MANDATORY C-ALG for SPKM-3 is advisable. The cast5CBC algorithm is a 128 bit algorithm that the 256 bit cast6CBC [RFC2612] algorithm is based upon. The cast6CBC algorithm was judged by the U.S. National Institute of Standards and Technology (NIST) to have no known major or minor "security gaps," and to have a "high security margin" [AES]. NIST did note some vulnerabilities
与triple DES和RC4等现有算法相比，cast5CBC加密算法相对较新。尽管如此，建议选择cast5CBC作为SPKM-3的强制性C-ALG。cast5CBC算法是256位cast6CBC[RFC2612]算法所基于的128位算法。美国国家标准与技术研究所（NIST）判定cast6CBC算法没有已知的主要或次要“安全漏洞”，并且具有“高安全边际”[AES]。NIST确实注意到了一些漏洞
related to smart card implementations, but many other algorithms NIST analyzed shared the vulnerabilities, and in any case, LIPKEY is by definition not aimed at smart cards.
与智能卡实现相关，但NIST分析的许多其他算法都存在漏洞，而且无论如何，LIPKEY的定义并不针对智能卡。
References
工具书类
[AES] Nechvatal, J., Barker, E., Dodson, D., Dworkin, M., Foti,
J., Roback, E. (Undated, but no later than 1999). "Status
Report on the First Round of the Development of the
Advanced Encryption Standard."
http://csrc.nist.gov/encryption/aes/round1/r1report.htm
[AES] Nechvatal, J., Barker, E., Dodson, D., Dworkin, M., Foti,
J., Roback, E. (Undated, but no later than 1999). "Status
Report on the First Round of the Development of the
Advanced Encryption Standard."
http://csrc.nist.gov/encryption/aes/round1/r1report.htm
[CCITT] CCITT (1988). "Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1)."
[CCITT]CCITT（1988年）。“建议X.208：抽象语法符号1（ASN.1）的规范。”
[Dobbertin] Dobbertin, H. (1996). "The Status of Md5 After a Recent
Attack," RSA Laboratories' CryptoBytes, Volume 2, Number
2.
ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf
[Dobbertin] Dobbertin, H. (1996). "The Status of Md5 After a Recent
Attack," RSA Laboratories' CryptoBytes, Volume 2, Number
2.
ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto2n2.pdf
[EFF] Electronic Frontier Foundation, John Gilmore (Editor) (1998). "Cracking Des: Secrets of Encryption Research, Wiretap Politics & Chip Design," O'Reilly & Associates, ISBN 1565925203.
电子前沿基金会，John Gilmore（编辑）（1998）。“破解Des：加密研究、窃听政治和芯片设计的秘密”，O'Reilly&Associates，ISBN 1565925203。
[FIPS] National Institute of Standards and Technology (1995).
"Secure Hash Standard" (SHA-1).
http://www.itl.nist.gov/fipspubs/fip180-1.htm
[FIPS] National Institute of Standards and Technology (1995).
"Secure Hash Standard" (SHA-1).
http://www.itl.nist.gov/fipspubs/fip180-1.htm
[IANA] Internet Assigned Numbers Authority (1999). "Network
Management Parameters." http://www.isi.edu/in-
notes/iana/assignments/smi-numbers
[IANA] Internet Assigned Numbers Authority (1999). "Network
Management Parameters." http://www.isi.edu/in-
notes/iana/assignments/smi-numbers
[PKCS-3] RSA Laboratories (1993). "PKCS #3: Diffie-Hellman Key-
Agreement Standard, Version 1.4."
ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-3.asc
[PKCS-3] RSA Laboratories (1993). "PKCS #3: Diffie-Hellman Key-
Agreement Standard, Version 1.4."
ftp://ftp.rsa.com/pub/pkcs/ascii/pkcs-3.asc
[PKIX] Housley, R., Ford, W., Polk, W., Solo, D., "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", Work in Progress.
[PKIX]Housley，R.，Ford，W.，Polk，W.，Solo，D.，“Internet X.509公钥基础设施证书和CRL配置文件”，正在进行的工作。
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 1831, August 1995.
[RFC1831]Srinivasan，R.，“RPC：远程过程调用协议规范版本2”，RFC18311995年8月。
[RFC1832] Srinivasan, R., "XDR: External Data Representation Standard", RFC 1832, August 1995.
[RFC1832]Srinivasan，R.，“XDR：外部数据表示标准”，RFC 1832，1995年8月。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]Linn，J.，“Kerberos版本5 GSS-API机制”，RFC19641996年6月。
[RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[RFC2203]Eisler，M.，Chiu，A.和L.Ling，“RPCSEC_GSS协议规范”，RFC 2203，1997年9月。
[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[RFC2025]Adams，C.，“简单公钥GSS-API机制（SPKM）”，RFC 20252996年10月。
[RFC2078] Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[RFC2078]Linn，J.，“通用安全服务应用程序接口，第2版”，RFC 2078，1997年1月。
[RFC2104] Krawczyk, H, Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H，Bellare，M.和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144, May 1997.
[RFC2144]Adams，C.，“CAST-128加密算法”，RFC2144，1997年5月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[RFC2279]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998.
[RFC2437]Kaliski，B.和J.Staddon，“PKCS#1:RSA加密规范2.0版”，RFC 2437，1998年10月。
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999.
[RFC2459]Housley，R.，Ford，W.，Polk，W.和D.Solo，“互联网X.509公钥基础设施证书和CRL配置文件”，RFC 2459，1999年1月。
[RFC2612] Adams, C. and J. Gilchrist, "The CAST-256 Encryption Algorithm", RFC 2612, June 1999.
[RFC2612]Adams，C.和J.Gilcrist，“CAST-256加密算法”，RFC2612，1999年6月。
[RSA-IP] All statements received by the IETF Secretariat are places on-line in http://www.ietf.org/ipr.html. Please check this web page to see any IPR information received about this and other technology.
[RSA-IP]IETF秘书处收到的所有声明都是在线的http://www.ietf.org/ipr.html. 请查看此网页以查看收到的有关此技术和其他技术的任何知识产权信息。
[Sandberg] Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon, B. (1985). "Design and Implementation of the Sun Network Filesystem," Proceedings of the 1985 Summer USENIX Technical Conference.
[桑德伯格]桑德伯格，R.，戈德伯格，D.，克莱曼，S.，沃尔什，D.，里昂，B.（1985）。“Sun网络文件系统的设计和实现”，1985年夏季USENIX技术会议论文集。
[Schneier] Schneier, B. (1996). "Applied Cryptography," John Wiley & Sons, Inc., ISBN 0-471-11709-9.
[Schneier]Schneier，B.（1996年）。“应用密码学”，约翰·威利父子公司，ISBN 0-471-11709-9。
[Young] Young, E.A. (1997). Collected timing results from the SSLeay source code distribution.
[杨]杨，E.A.（1997年）。从SSLeay源代码发行版收集计时结果。
Acknowledgments
致谢
The author thanks and acknowledges:
作者感谢并承认：
* Jack Kabat for his patient explanation of the intricacies of SPKM, excellent suggestions, and review comments.
* Jack Kabat感谢他耐心地解释了SPKM的复杂性、出色的建议和评论。
* Denis Pinkas for his review comments.
* 丹尼斯·平卡斯感谢他的评论。
* Carlisle Adams for his review comments.
* 卡莱尔·亚当斯的评论。
* John Linn for his review comments.
* 约翰·林恩的评论。
* Martin Rex for his review comments.
* Martin Rex感谢他的评论。
* This memorandum includes ASN.1 definitions for GSS-API tokens from RFC 2078, which was authored by John Linn.
* 本备忘录包括来自RFC 2078的GSS-API令牌的ASN.1定义，该定义由John Linn编写。
* This memorandum includes ASN.1 definitions and other text from the SPKM definition in RFC 2025, which was authored by Carlisle Adams.
* 本备忘录包括ASN.1定义和RFC 2025中SPKM定义的其他文本，该定义由Carlisle Adams编写。
Author's Address
作者地址
Address comments related to this memorandum to:
将与本备忘录相关的意见发送至：
ietf-cat-wg@lists.Stanford.EDU
ietf猫-wg@lists.Stanford.EDU
Mike Eisler Zambeel 5565 Wilson Road Colorado Springs, CO 80919
科罗拉多州科罗拉多斯普林斯威尔逊路5565号迈克·艾斯勒·赞比尔，邮编：80919
Phone: 1-719-599-9026 EMail: mike@eisler.com
电话：1-719-599-9026电子邮件：mike@eisler.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。