Network Working Group R. Zuccherato
Request for Comments: 3163 Entrust Technologies
Category: Experimental M. Nystrom
RSA Security
August 2001
Network Working Group R. Zuccherato
Request for Comments: 3163 Entrust Technologies
Category: Experimental M. Nystrom
RSA Security
August 2001
ISO/IEC 9798-3 Authentication SASL Mechanism
ISO/IEC 9798-3认证SASL机制
Status of this Memo
本备忘录的状况
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
IESG Note
IESG注释
It is the opinion of the Security Area Directors that this document defines a mechanism to use a complex system (namely PKI certificates) for authentication, but then intentionally discards the key benefits (namely integrity on each transmission). Put another way, it has all of the pain of implementing a PKI and none of the benefits. We should not support it in use in Internet protocols.
安全区域主管认为，本文件定义了一种机制，使用复杂系统（即PKI证书）进行身份验证，但随后故意放弃了关键好处（即每次传输的完整性）。换句话说，它有实施PKI的所有痛苦，但没有任何好处。我们不应该在互联网协议中使用它。
The same effect, with the benefits of PKI, can be had by using TLS/SSL, an existing already standards track protocol.
使用TLS/SSL（一种已经存在的标准跟踪协议）也可以达到同样的效果，并具有PKI的优点。
Abstract
摘要
This document defines a SASL (Simple Authentication and Security Layer) authentication mechanism based on ISO/IEC 9798-3 and FIPS PUB 196 entity authentication.
本文档定义了基于ISO/IEC 9798-3和FIPS PUB 196实体认证的SASL（简单认证和安全层）认证机制。
This document defines a SASL [RFC2222] authentication mechanism based on ISO/IEC 9798-3 [ISO3] and FIPS PUB 196 [FIPS] entity authentication.
本文件定义了基于ISO/IEC 9798-3[ISO3]和FIPS PUB 196[FIPS]实体认证的SASL[RFC2222]认证机制。
This mechanism only provides authentication using X.509 certificates [X509]. It has no effect on the protocol encodings and does not provide integrity or confidentiality services.
此机制仅使用X.509证书[X509]提供身份验证。它对协议编码没有影响，也不提供完整性或保密性服务。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The key benefit of asymmetric (public key) security, is that the secret (private key) only needs to be placed with the entity that is being authenticated. Thus, a private key can be issued to a client, which can then be authenticated by ANY server based on a token generated by the client and the generally available public key. Symmetric authentication mechanisms (password mechanisms such as CRAM-MD5 [RFC2195]) require a shared secret, and the need to maintain it at both endpoints. This means that a secret key for the client needs to be maintained at every server that may need to authenticate the client.
非对称（公钥）安全性的关键好处是，秘密（私钥）只需要与正在进行身份验证的实体放在一起。因此，可以向客户机颁发私钥，然后可以由任何服务器基于客户机生成的令牌和通常可用的公钥对其进行身份验证。对称身份验证机制（密码机制，如CRAM-MD5[RFC2195]）需要共享秘密，并且需要在两个端点上维护它。这意味着需要在每个可能需要对客户端进行身份验证的服务器上维护客户端的密钥。
The service described in this memo provides authentication only. There are a number of places where an authentication only service is useful, e.g., where confidentiality and integrity are provided by lower layers, or where confidentiality or integrity services are provided by the application.
本备忘录中描述的服务仅提供身份验证。在许多地方，仅认证服务是有用的，例如，较低层提供机密性和完整性，或者应用程序提供机密性或完整性服务。
The functionality defined here can be provided by TLS, and it is important to consider why it is useful to have it in both places. There are several reasons for this, e.g.:
这里定义的功能可以由TLS提供，并且重要的是考虑为什么在两个地方都有它。这有几个原因，例如：
- Simplicity. This mechanism is simpler than TLS. If there is only a requirement for this functionality (as distinct from all of TLS), this simplicity will facilitate deployment.
- 简单这种机制比TLS更简单。如果只需要此功能（与所有TL不同），这种简单性将有助于部署。
- Layering. The SASL mechanism to establish authentication works cleanly with most protocols. This mechanism can fit more cleanly than TLS for some protocols.
- 分层。用于建立身份验证的SASL机制在大多数协议中都能正常工作。对于某些协议，这种机制比TLS更适合。
- Proxies. In some architectures the endpoint of the TLS session may not be the application endpoint. In these situations, this mechanism can be used to obtain end-to-end authentication.
- 代理。在某些体系结构中，TLS会话的端点可能不是应用程序端点。在这些情况下，可以使用此机制获得端到端身份验证。
- Upgrade of authentication. In some applications it may not be clear at the time of TLS session negotiation what type of authentication may be required (e.g., anonymous, server, client-server). This mechanism allows the negotiation of an anonymous or server authenticated TLS session which can, at a later time, be upgraded to provide the desired level of authentication.
- 升级身份验证。在某些应用程序中，在TLS会话协商时可能不清楚可能需要什么类型的身份验证（例如，匿名、服务器、客户端-服务器）。此机制允许协商匿名或服务器身份验证的TLS会话，该会话可在以后升级以提供所需的身份验证级别。
The mechanism described in this memo provides either mutual or unilateral entity authentication as defined in ISO/IEC 9798-1 [ISO1] using an asymmetric (public-key) digital signature mechanism.
本备忘录中描述的机制使用非对称（公钥）数字签名机制提供ISO/IEC 9798-1[ISO1]中定义的相互或单边实体认证。
This SASL mechanism contains two authentication modes:
此SASL机制包含两种身份验证模式：
- Unilateral client authentication: The client digitally signs a challenge from the server, thus authenticating itself to the server.
- 单边客户端身份验证：客户端对来自服务器的质询进行数字签名，从而向服务器进行身份验证。
- Mutual authentication: The client digitally signs a challenge from the server and the server digitally signs a challenge from the client. Thus both the client and server authenticate each other.
- 相互身份验证：客户端对来自服务器的质询进行数字签名，服务器对来自客户端的质询进行数字签名。因此，客户机和服务器都会相互验证。
This mechanism has two SASL keys corresponding to the two different modes:
此机制有两个对应于两种不同模式的SASL键：
- "9798-U-<algorithm>" for unilateral client authentication.
- “9798-U-<算法>”用于单边客户端身份验证。
- "9798-M-<algorithm>" for mutual authentication.
- “9798-M-<算法>”用于相互身份验证。
Each SASL key may be used with a list of algorithms. A list of supported algorithms is given in Section 4.
每个SASL密钥可与算法列表一起使用。第4节给出了支持的算法列表。
This section gives a brief description of the steps that are performed for unilateral client authentication. The actual data structures are described fully in Section 3.
本节简要介绍为单边客户端身份验证执行的步骤。实际数据结构在第3节中有详细描述。
a) The server generates a random challenge value R_B and sends it to the client.
a) 服务器生成一个随机质询值R_B并将其发送给客户端。
b) The client generates a random value R_A and creates a token TokenAB. The token contains R_A, the client's certificate and also a digital signature created by the client over both R_A and R_B. Optionally, it also contains an identifier for the server.
b) 客户端生成一个随机值R_a并创建一个令牌TokenAB。令牌包含R_A、客户端证书以及客户端通过R_A和R_B创建的数字签名。此外，它还包含服务器的标识符。
c) The client sends the token to the server.
c) 客户端将令牌发送到服务器。
d) The server verifies the token by:
d) 服务器通过以下方式验证令牌：
- verifying the client's signature in TokenAB (this includes full certificate path processing as described in [RFC2459]),
- 在TokenAB中验证客户端签名（包括[RFC2459]中所述的完整证书路径处理），
- verifying that the random number R_B, sent to the client in Step 1, agrees with the random number contained in the signed data of TokenAB, and
- 验证在步骤1中发送给客户端的随机数R_B是否与令牌ab的签名数据中包含的随机数一致，以及
- verifying that the identifier for the server, if present, matches the server's distinguishing identifier.
- 验证服务器的标识符（如果存在）是否与服务器的识别标识符匹配。
This section gives a brief description of the steps that are performed for mutual authentication. The actual data structures are described fully in Section 3.
本节简要介绍为相互身份验证执行的步骤。实际数据结构在第3节中有详细描述。
a) The server generates a random challenge value R_B and sends it to the client.
a) 服务器生成一个随机质询值R_B并将其发送给客户端。
b) The client generates a random value R_A and creates a token TokenAB. The token contains R_A, the client's certificate and also a digital signature created by the client over both R_A and R_B. Optionally, it also contains an identifier for the server.
b) 客户端生成一个随机值R_a并创建一个令牌TokenAB。令牌包含R_A、客户端证书以及客户端通过R_A和R_B创建的数字签名。此外，它还包含服务器的标识符。
c) The client sends the token to the server.
c) 客户端将令牌发送到服务器。
d) The server verifies the token by:
d) 服务器通过以下方式验证令牌：
- verifying the client's signature in TokenAB (this includes full certificate path processing as described in [RFC2459]),
- 在TokenAB中验证客户端签名（包括[RFC2459]中所述的完整证书路径处理），
- verifying that the random number R_B, sent to the client in Step 1, agrees with the random number contained in the signed data of TokenAB, and
- 验证在步骤1中发送给客户端的随机数R_B是否与令牌ab的签名数据中包含的随机数一致，以及
- verifying that the identifier for the server, if present, matches the server's distinguishing identifier.
- 验证服务器的标识符（如果存在）是否与服务器的识别标识符匹配。
e) The server creates a token TokenBA. The token contains a third random value R_C, the server's certificate and a digital signature created by the server over R_A, R_B and R_C. Optionally, it also contains an identifier for the client.
e) 服务器创建一个令牌TokenBA。令牌包含第三个随机值R_C、服务器的证书和服务器通过R_a、R_B和R_C创建的数字签名。还可以选择包含客户端的标识符。
f) The server sends the token to the client.
f) 服务器将令牌发送到客户端。
g) The client verifies the token by:
g) 客户端通过以下方式验证令牌：
- verifying the server's signature in TokenBA (this includes full certificate path processing as described in [RFC2459]),
- 验证TokenBA中的服务器签名（包括[RFC2459]中所述的完整证书路径处理），
- verifying that the random number R_B, received by the client in Step 1, agrees with the random number contained in the signed data of TokenBA,
- 验证客户端在步骤1中接收到的随机数R_B是否与TokenBA的签名数据中包含的随机数一致，
- verifying that the random number R_A, sent to the server in Step 2, agrees with the random number contained in the signed data of Token BA and
- 验证在步骤2中发送到服务器的随机数R_A是否与令牌BA的签名数据中包含的随机数一致，以及
- verifying that the identifier for the client, if present, matches the client's distinguishing identifier.
- 验证客户端的标识符（如果存在）是否与客户端的识别标识符匹配。
Note - Protocol data units (PDUs) SHALL be DER-encoded [X690] before transmitted.
注-协议数据单元（PDU）应在传输前进行DER编码[X690]。
TokenBA1 is used in both the unilateral client authentication and mutual authentication modes and is sent by the server to the client.
令牌BA1用于单边客户端身份验证和相互身份验证模式，并由服务器发送到客户端。
TokenBA1 contains a random value, and, optionally, the servers name and certificate information.
TokenBA1包含一个随机值，以及服务器名称和证书信息（可选）。
TokenBA1 ::= SEQUENCE {
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certPref [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
}
TokenBA1 ::= SEQUENCE {
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certPref [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
}
TokenAB is used in the unilateral client authentication and mutual authentication modes and is sent by the client to the server. TokenAB contains a random number, entity B's name (optionally), entity certification information, an (optional) authorization identity, and a signature of a DER-encoded value of type TBSDataAB. The certA field is used to send the client's X.509 certificate (or a URL to it) and a related certificate chain to the server.
TokenAB用于单边客户端身份验证和相互身份验证模式，由客户端发送到服务器。TokenAB包含一个随机数、实体B的名称（可选）、实体认证信息（可选）授权标识和类型为TBSDataAB的DER编码值的签名。certA字段用于将客户端的X.509证书（或其URL）和相关证书链发送到服务器。
The authID field is to be used when the identity to be used for access control is different than the identity contained in the certificate of the signer. If this field is not present, then the identity from the client's X.509 certificate shall be used.
当用于访问控制的标识与签名者证书中包含的标识不同时，将使用authID字段。如果此字段不存在，则应使用客户的X.509证书中的标识。
TokenAB ::= SEQUENCE {
randomA RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certA [1] CertData,
authID [2] GeneralNames OPTIONAL,
signature SIGNATURE { TBSDataAB }
TokenAB ::= SEQUENCE {
randomA RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certA [1] CertData,
authID [2] GeneralNames OPTIONAL,
signature SIGNATURE { TBSDataAB }
}(CONSTRAINED BY {-- The entityB and authID fields shall be included
-- in TokenAB if and only if they are also included in TBSDataAB.
-- The entityB field SHOULD be present in TokenAB whenever the
-- client believes it knows the identity of the server.--})
}(CONSTRAINED BY {-- The entityB and authID fields shall be included
-- in TokenAB if and only if they are also included in TBSDataAB.
-- The entityB field SHOULD be present in TokenAB whenever the
-- client believes it knows the identity of the server.--})
TBSDataAB ::= SEQUENCE {
randomA RandomNumber,
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
authID [1] GeneralNames OPTIONAL
}
TBSDataAB ::= SEQUENCE {
randomA RandomNumber,
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
authID [1] GeneralNames OPTIONAL
}
TokenBA2 is used in the mutual authentication mode and is sent by the server to the client. TokenBA2 contains a random number, entity A's name (optionally), certification information, and a signature of a DER-encoded value of type TBSDataBA. The certB field is to be used to send the server's X.509 certificate and a related certificate chain to the client.
TokenBA2在相互身份验证模式下使用，并由服务器发送到客户端。TokenBA2包含一个随机数、实体a的名称（可选）、认证信息和类型为TBSDataBA的DER编码值的签名。certB字段用于将服务器的X.509证书和相关证书链发送到客户端。
TokenBA2 ::= SEQUENCE {
randomC RandomNumber,
entityA [0] GeneralNames OPTIONAL,
certB [1] CertData,
signature SIGNATURE { TBSDataBA }
}(CONSTRAINED BY {-- The entityA field shall be included in TokenBA2
-- if and only if it is also included in TBSDataBA. The entityA
-- field SHOULD be present and MUST contain the client's name
-- from their X.509 certificate.--})
TokenBA2 ::= SEQUENCE {
randomC RandomNumber,
entityA [0] GeneralNames OPTIONAL,
certB [1] CertData,
signature SIGNATURE { TBSDataBA }
}(CONSTRAINED BY {-- The entityA field shall be included in TokenBA2
-- if and only if it is also included in TBSDataBA. The entityA
-- field SHOULD be present and MUST contain the client's name
-- from their X.509 certificate.--})
TBSDataBA ::= SEQUENCE {
randomB RandomNumber,
randomA RandomNumber,
randomC RandomNumber,
entityA GeneralNames OPTIONAL
}
TBSDataBA ::= SEQUENCE {
randomB RandomNumber,
randomA RandomNumber,
randomC RandomNumber,
entityA GeneralNames OPTIONAL
}
TrustedAuth ::= CHOICE {
authorityName [0] Name,
-- SubjectName from CA certificate
issuerNameHash [1] OCTET STRING,
-- SHA-1 hash of Authority's DN
issuerKeyHash [2] OCTET STRING,
-- SHA-1 hash of Authority's public key
authorityCertificate [3] Certificate,
-- CA certificate
pkcs15KeyHash [4] OCTET STRING
-- PKCS #15 key hash
}
TrustedAuth ::= CHOICE {
authorityName [0] Name,
-- SubjectName from CA certificate
issuerNameHash [1] OCTET STRING,
-- SHA-1 hash of Authority's DN
issuerKeyHash [2] OCTET STRING,
-- SHA-1 hash of Authority's public key
authorityCertificate [3] Certificate,
-- CA certificate
pkcs15KeyHash [4] OCTET STRING
-- PKCS #15 key hash
}
The TrustedAuth type can be used by a server in its initial message ("TokenBA1") to indicate to a client preferred certificates/public key pairs to use in the authentication.
TrustedAuth类型可由服务器在其初始消息（“TokenBA1”）中使用，以向客户端指示在身份验证中使用的首选证书/公钥对。
A trusted authority is identified by its name, hash of its name, hash of its public key, its certificate, or PKCS #15 key hash. If identified by its name, then the authorityName field in TrustedAuth contains the SubjectName of its CA certificate. If it is identified by the hash of its name then the issuerNameHash field contains the SHA-1 hash of the DER encoding of SubjectName from its CA certificate. If it is identified by the hash of its public key then the issuerKeyHash field contains the SHA-1 hash of the authority's public key. The hash shall be calculated over the value (excluding tag and length) of the subject public key field in the issuer's certificate. If it is identified by its certificate then the authorityCertificate field contains its CA certificate. If it is
可信机构通过其名称、名称哈希、公钥哈希、证书或PKCS#15密钥哈希进行标识。如果由其名称标识，则TrustedAuth中的authorityName字段包含其CA证书的SubjectName。如果通过其名称的散列来标识，则issuerNameHash字段包含来自其CA证书的SubjectName的DER编码的SHA-1散列。如果通过其公钥的散列来标识，则issuerKeyHash字段包含授权机构公钥的SHA-1散列。哈希值应根据发卡机构证书中的主题公钥字段的值（不包括标签和长度）进行计算。如果由其证书标识，则authorityCertificate字段包含其CA证书。如果是
identified by the PKCS #15 key hash then the pkcs15KeyHash field contains the hash of the CA's public key as defined in PKCS #15 [PKCS15] Section 6.1.4.
由PKCS#15密钥散列标识，然后pkcs15KeyHash字段包含PKCS#15[PKCS15]第6.1.4节中定义的CA公钥散列。
The certification data is a choice between a set of certificates and a certificate URL.
证书数据是一组证书和证书URL之间的选择。
The certificate set alternative is as in [RFC2630], meaning it is intended that the set be sufficient to contain chains from a recognized "root" or "top-level certification authority" to all of the sender certificates with which the set is associated. However, there may be more certificates than necessary, or there may be fewer than necessary.
证书集备选方案如[RFC2630]所示，这意味着该集足以包含从公认的“根”或“顶级证书颁发机构”到与该集关联的所有发送方证书的链。但是，证书可能比需要的多，也可能比需要的少。
Note - The precise meaning of a "chain" is outside the scope of this document. Some applications may impose upper limits on the length of a chain; others may enforce certain relationships between the subjects and issuers of certificates within a chain.
注：“链”的确切含义不在本文件范围内。某些应用可能会对链的长度施加上限；其他人可能会强制执行链中的主体和证书颁发者之间的某些关系。
When the certURL type is used to specify the location at which the user's certificate can be found, it MUST be a non-relative URL, and MUST follow the URL syntax and encoding rules specified in [RFC1738]. The URL must include both a scheme (e.g., "http" or "ldap") and a scheme-specific part. The scheme-specific part must include a fully qualified domain name or IP address as the host.
当certURL类型用于指定可以找到用户证书的位置时，它必须是非相对URL，并且必须遵循[RFC1738]中指定的URL语法和编码规则。URL必须包括方案（例如“http”或“ldap”）和方案特定部分。方案特定部分必须包括作为主机的完全限定域名或IP地址。
CertData ::= CHOICE {
certificateSet SET SIZE (1..MAX) OF Certificate,
certURL IA5String,
... -- For future extensions
}
CertData ::= CHOICE {
certificateSet SET SIZE (1..MAX) OF Certificate,
certURL IA5String,
... -- For future extensions
}
A random number is simply defined as an octet string, at least 8 bytes long.
随机数仅定义为八位字节字符串，长度至少为8字节。
RandomNumber ::= OCTET STRING (SIZE(8..MAX))
RandomNumber ::= OCTET STRING (SIZE(8..MAX))
This is similar to the "SIGNED" parameterized type defined in [RFC2459], the difference being that the "SIGNATURE" type does not include the data to be signed.
这类似于[RFC2459]中定义的“签名”参数化类型，区别在于“签名”类型不包括要签名的数据。
SIGNATURE { ToBeSigned } ::= SEQUENCE {
algorithm AlgorithmIdentifier,
signature BIT STRING
}(CONSTRAINED BY {-- Must be the result of applying the signing
-- operation indicated in "algorithm" to the DER-encoded octets of
-- a value of type -- ToBeSigned })
SIGNATURE { ToBeSigned } ::= SEQUENCE {
algorithm AlgorithmIdentifier,
signature BIT STRING
}(CONSTRAINED BY {-- Must be the result of applying the signing
-- operation indicated in "algorithm" to the DER-encoded octets of
-- a value of type -- ToBeSigned })
The "GeneralNames" type is defined in [RFC2459].
[RFC2459]中定义了“GeneralNames”类型。
The following signature algorithms are recognized for use with this mechanism, and identified by a key. Each key would be combined to make two possible SASL mechanisms. For example the DSA-SHA1 algorithm would give 9798-U-DSA-SHA1, and 9798-M-DSA-SHA1. All algorithm names are constrained to 13 characters, to keep within the total SASL limit of 20 characters.
以下签名算法被识别用于此机制，并由密钥标识。每个键将被组合成两种可能的SASL机制。例如，DSA-SHA1算法将给出9798-U-DSA-SHA1和9798-M-DSA-SHA1。所有算法名称都限制为13个字符，以保持SASL总限制为20个字符。
The following table gives a list of algorithm keys, noting the object identifier and the body that assigned the identifier.
下表列出了算法键，并指出了对象标识符和分配标识符的主体。
Key Object Id Body RSA-SHA1-ENC 1.2.840.113549.1.1.5 RSA DSA-SHA1 1.2.840.10040.4.3 ANSI ECDSA-SHA1 1.2.840.10045.4.1 ANSI
密钥对象Id主体RSA-SHA1-ENC 1.2.840.113549.1.1.5 RSA DSA-SHA1 1.2.840.10040.4.3 ANSI ECDSA-SHA1 1.2.840.10045.4.1 ANSI
Support of the RSA-SHA1-ENC algorithm is RECOMMENDED for use with this mechanism.
建议支持RSA-SHA1-ENC算法用于此机制。
The following example shows the use of the ISO/IEC 9798-3 Authentication SASL mechanism with IMAP4 [RFC2060].
以下示例显示了ISO/IEC 9798-3认证SASL机制与IMAP4[RFC2060]的结合使用。
The base64 encoding of challenges and responses, as well as the "+ " preceding the responses are part of the IMAP4 profile, not part of this specification itself (note that the line breaks in the sample authenticators are for editorial clarity and are not in real authenticators).
质询和响应的base64编码以及响应前的“+”是IMAP4配置文件的一部分，而不是本规范本身的一部分（请注意，示例验证器中的换行符是为了编辑清晰，而不是真实验证器中的换行符）。
S: * OK IMAP4 server ready
C: A001 AUTHENTICATE 9798-U-RSA-SHA1
S: + MAoECBI4l1h5h0eY
C: MIIBAgQIIxh5I0h5RYegD4INc2FzbC1yLXVzLmNvbaFPFk1odHRwOi8vY2VydHMt
ci11cy5jb20vY2VydD9paD1odmNOQVFFRkJRQURnWUVBZ2hBR2hZVFJna0ZqJnNu
PUVQOXVFbFkzS0RlZ2pscjCBkzANBgkqhkiG9w0BAQUFAAOBgQCkuC2GgtYcxGG1
NEzLA4bh5lqJGOZySACMmc+mDrV7A7KAgbpO2OuZpMCl7zvNt/L3OjQZatiX8d1X
buQ40l+g2TJzJt06o7ogomxdDwqlA/3zp2WMohlI0MotHmfDSWEDZmEYDEA3/eGg
kWyi1v1lEVdFuYmrTr8E4wE9hxdQrA==
S: A001 OK Welcome, 9798-U-RSA-SHA1 authenticated user: Magnus
S: * OK IMAP4 server ready
C: A001 AUTHENTICATE 9798-U-RSA-SHA1
S: + MAoECBI4l1h5h0eY
C: MIIBAgQIIxh5I0h5RYegD4INc2FzbC1yLXVzLmNvbaFPFk1odHRwOi8vY2VydHMt
ci11cy5jb20vY2VydD9paD1odmNOQVFFRkJRQURnWUVBZ2hBR2hZVFJna0ZqJnNu
PUVQOXVFbFkzS0RlZ2pscjCBkzANBgkqhkiG9w0BAQUFAAOBgQCkuC2GgtYcxGG1
NEzLA4bh5lqJGOZySACMmc+mDrV7A7KAgbpO2OuZpMCl7zvNt/L3OjQZatiX8d1X
buQ40l+g2TJzJt06o7ogomxdDwqlA/3zp2WMohlI0MotHmfDSWEDZmEYDEA3/eGg
kWyi1v1lEVdFuYmrTr8E4wE9hxdQrA==
S: A001 OK Welcome, 9798-U-RSA-SHA1 authenticated user: Magnus
By registering the 9798-<U/M>-<algorithm> protocols as SASL mechanisms, implementers will have a well-defined way of adding this authentication mechanism to their product. Here is the registration template for the SASL mechanisms defined in this memo:
通过将9798-<U/M>-<algorithm>协议注册为SASL机制，实现者将有一种定义良好的方式将此身份验证机制添加到他们的产品中。以下是本备忘录中定义的SASL机制的注册模板：
SASL mechanism names: 9798-U-RSA-SHA1-ENC 9798-M-RSA-SHA1-ENC 9798-U-DSA-SHA1 9798-M-DSA-SHA1 9798-U-ECDSA-SHA1 9798-M-ECDSA-SHA1 ; For a definition of the algorithms see Section 4 of this memo.
SASL机构名称：9798-U-RSA-SHA1-ENC 9798-M-RSA-SHA1-ENC 9798-U-DSA-SHA1 9798-M-DSA-SHA1 9798-U-ECDSA-SHA1 9798-M-ECDSA-SHA1；有关算法的定义，请参见本备忘录第4节。
Security Considerations: See Section 7 of this memo Published specification: This memo Person & email address to contact for further information: See Section 9 of this memo. Intended usage: COMMON Author/Change controller: See Section 9 of this memo.
安全注意事项：参见本备忘录第7节发布规范：本备忘录联系人和联系电子邮件地址，了解更多信息：参见本备忘录第9节。预期用途：普通作者/变更控制者：见本备忘录第9节。
The mechanisms described in this memo only provides protection against passive eavesdropping attacks. They do not provide session privacy or protection from active attacks. In particular, man-in-the-middle attacks aimed at session "hi-jacking" are possible.
本备忘录中描述的机制仅提供针对被动窃听攻击的保护。它们不提供会话隐私或主动攻击保护。特别是，针对会话“hi jacking”的中间人攻击是可能的。
The random numbers used in this protocol MUST be generated by a cryptographically strong random number generator. If the number is chosen from a small set or is otherwise predictable by a third party, then this mechanism can be attacked.
本协议中使用的随机数必须由加密强随机数生成器生成。如果该数字是从一个小集合中选择的，或者是第三方可以预测的，则该机制可能会受到攻击。
The inclusion of the random number R_A in the signed part of TokenAB prevents the server from obtaining the signature of the client on data chosen by the server prior to the start of the authentication mechanism. This measure may be required, for example, when the same key is used by the client for purposes other than entity authentication. However, the inclusion of R_B in TokenBA2, whilst necessary for security reasons which dictate that the client should check that it is the same as the value sent in the first message, may not offer the same protection to the server, since R_B is known to the client before R_A is chosen. For this reason a third random number, R_C, is included in the TokenBA2 PDU.
在TokenAB的签名部分包含随机数R_A可防止服务器在启动身份验证机制之前获取客户端对服务器选择的数据的签名。例如，当客户端将同一密钥用于实体身份验证以外的目的时，可能需要此度量。然而，在TokenBA2中包含R_B，虽然出于安全原因（要求客户端检查其是否与第一条消息中发送的值相同）是必要的，但可能无法为服务器提供相同的保护，因为在选择R_A之前，客户端知道R_B。因此，第三个随机数R_C包含在TokenBA2 PDU中。
[FIPS] FIPS 196, "Entity authentication using public key cryptography," Federal Information Processing Standards Publication 196, U.S. Department of Commerce/N.I.S.T., National Technical Information Service, Springfield, Virginia, 1997.
[FIPS]FIPS 196，“使用公钥密码的实体认证”，联邦信息处理标准出版物196，美国商务部/N.I.S.T.，国家技术信息服务局，弗吉尼亚州斯普林菲尔德，1997年。
[ISO1] ISO/IEC 9798-1: 1997, Information technology - Security techniques - Entity authentication - Part 1: General.
[ISO1]ISO/IEC 9798-1:1997，信息技术-安全技术-实体认证-第1部分：总则。
[ISO3] ISO/IEC 9798-3: 1997, Information technology - Security techniques - Entity authentication - Part 3: Mechanisms using digital signature techniques.
[ISO3]ISO/IEC 9798-3:1997，信息技术-安全技术-实体认证-第3部分：使用数字签名技术的机制。
[PKCS15] RSA Laboratories, "The Public-Key Cryptography Standards - PKCS #15 v1.1: Cryptographic token information syntax standard", June 6, 2000.
[PKCS15]RSA实验室，“公钥加密标准-PKCS#15 v1.1：加密令牌信息语法标准”，2000年6月6日。
[RFC1738] Berners-Lee, T., Masinter L. and M. McCahill "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC1738]Berners Lee，T.，Masinter L.和M.McCahill“统一资源定位器（URL）”，RFC 17381994年12月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[RFC2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC2060]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC20601996年12月。
[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月。
[RFC2195] Klensin, J., Catoe, R. and P. Krumviede "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997.
[RFC2195]Klensin，J.，Catoe，R.和P.Krumviede“简单质询/响应的IMAP/POP授权扩展”，RFC 21951997年9月。
[RFC2222] J. Meyers, "Simple Authentication and Security Layer", RFC 2222, October 1997.
[RFC2222]J.Meyers，“简单认证和安全层”，RFC22221997年10月。
[RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo "Internet X.509 Public Key Infrastructure: X.509 Certificate and CRL Profile", RFC 2459, January 1999.
[RFC2459]Housley，R.，Ford，W.，Polk，W.和D.Solo“互联网X.509公钥基础设施：X.509证书和CRL配置文件”，RFC 2459，1999年1月。
[RFC2630] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999.
[RFC2630]R.Housley，“加密消息语法”，RFC 2630，1999年6月。
[X509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998, Information Technology - Open Systems Interconnection - The Directory: Authentication Framework.
[X509]ITU-T建议X.509（1997）| ISO/IEC 9594-8:1998，信息技术-开放系统互连-目录：认证框架。
[X690] ITU-T Recommendation X.690 (1997) | ISO/IEC 8825-1:1998, Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).
[X690]ITU-T建议X.690（1997）| ISO/IEC 8825-1:1998，信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范。
Robert Zuccherato Entrust Technologies 1000 Innovation Drive Ottawa, Ontario Canada K2K 3E7
Robert Zuccherato委托技术1000创新驱动加拿大安大略省渥太华K2K 3E7
Phone: +1 613 247 2598
EMail: robert.zuccherato@entrust.com
Phone: +1 613 247 2598
EMail: robert.zuccherato@entrust.com
Magnus Nystrom RSA Security Box 10704 121 29 Stockholm Sweden
Magnus Nystrom RSA安全信箱10704 121 29瑞典斯德哥尔摩
Phone: +46 8 725 0900
EMail: magnus@rsasecurity.com
Phone: +46 8 725 0900
EMail: magnus@rsasecurity.com
APPENDICES
附录
A. ASN.1 modules
A.ASN.1模块
SASL-9798-3-1988
SASL-9798-3-1988
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL --
--全部出口--
IMPORTS
进口
Name, AlgorithmIdentifier, Certificate
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
Name, AlgorithmIdentifier, Certificate
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
GeneralNames
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-88(2)};
GeneralNames
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-88(2)};
TokenBA1 ::= SEQUENCE {
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certPref [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
}
TokenBA1 ::= SEQUENCE {
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certPref [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
}
TokenAB ::= SEQUENCE {
randomA RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certA [1] CertData,
authID [2] GeneralNames OPTIONAL,
signature SEQUENCE {
algorithm AlgorithmIdentifier,
signature BIT STRING
}
} -- The entityB and authID fields shall be included in TokenAB
-- if and only if they are also included in TBSDataAB. The entityB
-- field SHOULD be present in TokenAB whenever the client
-- believes it knows the identity of the server.
-- The signature operation shall be done on a
-- DER-encoded value of type TBSDataAB.
TokenAB ::= SEQUENCE {
randomA RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certA [1] CertData,
authID [2] GeneralNames OPTIONAL,
signature SEQUENCE {
algorithm AlgorithmIdentifier,
signature BIT STRING
}
} -- The entityB and authID fields shall be included in TokenAB
-- if and only if they are also included in TBSDataAB. The entityB
-- field SHOULD be present in TokenAB whenever the client
-- believes it knows the identity of the server.
-- The signature operation shall be done on a
-- DER-encoded value of type TBSDataAB.
TBSDataAB ::= SEQUENCE {
randomA RandomNumber,
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
authID [1] GeneralNames OPTIONAL
}
TBSDataAB ::= SEQUENCE {
randomA RandomNumber,
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
authID [1] GeneralNames OPTIONAL
}
TokenBA2 ::= SEQUENCE {
randomC RandomNumber,
entityA [0] GeneralNames OPTIONAL,
certB [1] CertData,
signature SEQUENCE {
algorithm AlgorithmIdentifier,
signature BIT STRING
}
} -- The entityA field shall be included in TokenBA2
-- if and only if it is also included in TBSDataBA. The entityA
-- field SHOULD be present and MUST contain the client's name
-- from their X.509 certificate. The signature shall be done
-- on a DER-encoded value of type TBSDataBA.
TokenBA2 ::= SEQUENCE {
randomC RandomNumber,
entityA [0] GeneralNames OPTIONAL,
certB [1] CertData,
signature SEQUENCE {
algorithm AlgorithmIdentifier,
signature BIT STRING
}
} -- The entityA field shall be included in TokenBA2
-- if and only if it is also included in TBSDataBA. The entityA
-- field SHOULD be present and MUST contain the client's name
-- from their X.509 certificate. The signature shall be done
-- on a DER-encoded value of type TBSDataBA.
TBSDataBA ::= SEQUENCE {
randomB RandomNumber,
randomA RandomNumber,
randomC RandomNumber,
entityA GeneralNames OPTIONAL
}
TBSDataBA ::= SEQUENCE {
randomB RandomNumber,
randomA RandomNumber,
randomC RandomNumber,
entityA GeneralNames OPTIONAL
}
TrustedAuth ::= CHOICE {
authorityName [0] Name,
-- SubjectName from CA certificate
issuerNameHash [1] OCTET STRING,
-- SHA-1 hash of Authority's DN
issuerKeyHash [2] OCTET STRING,
-- SHA-1 hash of Authority's public key
authorityCertificate [3] Certificate,
-- CA certificate
pkcs15KeyHash [4] OCTET STRING
-- PKCS #15 key hash
}
TrustedAuth ::= CHOICE {
authorityName [0] Name,
-- SubjectName from CA certificate
issuerNameHash [1] OCTET STRING,
-- SHA-1 hash of Authority's DN
issuerKeyHash [2] OCTET STRING,
-- SHA-1 hash of Authority's public key
authorityCertificate [3] Certificate,
-- CA certificate
pkcs15KeyHash [4] OCTET STRING
-- PKCS #15 key hash
}
CertData ::= CHOICE {
certificateSet SET SIZE (1..MAX) OF Certificate,
certURL IA5String
}
CertData ::= CHOICE {
certificateSet SET SIZE (1..MAX) OF Certificate,
certURL IA5String
}
RandomNumber ::= OCTET STRING (SIZE(8..MAX))
RandomNumber ::= OCTET STRING (SIZE(8..MAX))
END
终止
SASL-9798-3-1997
SASL-9798-3-1997
DEFINITIONS IMPLICIT TAGS ::=
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL --
--全部出口--
IMPORTS
进口
AlgorithmIdentifier, Name, Certificate
FROM PKIX1Explicit93 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-93(3)}
AlgorithmIdentifier, Name, Certificate
FROM PKIX1Explicit93 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-93(3)}
GeneralNames
FROM PKIX1Implicit93 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-93(4)};
GeneralNames
FROM PKIX1Implicit93 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-93(4)};
TokenBA1 ::= SEQUENCE {
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certPref [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
}
TokenBA1 ::= SEQUENCE {
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certPref [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL
}
TokenAB ::= SEQUENCE {
randomA RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certA [1] CertData,
authID [2] GeneralNames OPTIONAL,
signature SIGNATURE { TBSDataAB }
}(CONSTRAINED BY {-- The entityB and authID fields shall be included
-- in TokenAB if and only if they are also included in TBSDataAB.
-- The entityB field SHOULD be present in TokenAB whenever the
-- client believes it knows the identity of the server.--})
TokenAB ::= SEQUENCE {
randomA RandomNumber,
entityB [0] GeneralNames OPTIONAL,
certA [1] CertData,
authID [2] GeneralNames OPTIONAL,
signature SIGNATURE { TBSDataAB }
}(CONSTRAINED BY {-- The entityB and authID fields shall be included
-- in TokenAB if and only if they are also included in TBSDataAB.
-- The entityB field SHOULD be present in TokenAB whenever the
-- client believes it knows the identity of the server.--})
TBSDataAB ::= SEQUENCE {
randomA RandomNumber,
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
authID [1] GeneralNames OPTIONAL
}
TBSDataAB ::= SEQUENCE {
randomA RandomNumber,
randomB RandomNumber,
entityB [0] GeneralNames OPTIONAL,
authID [1] GeneralNames OPTIONAL
}
TokenBA2 ::= SEQUENCE {
randomC RandomNumber,
entityA [0] GeneralNames OPTIONAL,
certB [1] CertData,
signature SIGNATURE { TBSDataBA }
}(CONSTRAINED BY {-- The entityA field shall be included in TokenBA2
-- if and only if it is also included in TBSDataBA. The entityA
-- field SHOULD be present and MUST contain the client's name
-- from their X.509 certificate.--})
TokenBA2 ::= SEQUENCE {
randomC RandomNumber,
entityA [0] GeneralNames OPTIONAL,
certB [1] CertData,
signature SIGNATURE { TBSDataBA }
}(CONSTRAINED BY {-- The entityA field shall be included in TokenBA2
-- if and only if it is also included in TBSDataBA. The entityA
-- field SHOULD be present and MUST contain the client's name
-- from their X.509 certificate.--})
TBSDataBA ::= SEQUENCE {
randomB RandomNumber,
randomA RandomNumber,
randomC RandomNumber,
entityA GeneralNames OPTIONAL
}
TBSDataBA ::= SEQUENCE {
randomB RandomNumber,
randomA RandomNumber,
randomC RandomNumber,
entityA GeneralNames OPTIONAL
}
TrustedAuth ::= CHOICE {
authorityName [0] Name,
-- SubjectName from CA certificate
issuerNameHash [1] OCTET STRING,
-- SHA-1 hash of Authority's DN
issuerKeyHash [2] OCTET STRING,
-- SHA-1 hash of Authority's public key
authorityCertificate [3] Certificate,
-- CA certificate
pkcs15KeyHash [4] OCTET STRING
-- PKCS #15 key hash
}
TrustedAuth ::= CHOICE {
authorityName [0] Name,
-- SubjectName from CA certificate
issuerNameHash [1] OCTET STRING,
-- SHA-1 hash of Authority's DN
issuerKeyHash [2] OCTET STRING,
-- SHA-1 hash of Authority's public key
authorityCertificate [3] Certificate,
-- CA certificate
pkcs15KeyHash [4] OCTET STRING
-- PKCS #15 key hash
}
CertData ::= CHOICE {
certificateSet SET SIZE (1..MAX) OF Certificate,
certURL IA5String,
... -- For future extensions
}
CertData ::= CHOICE {
certificateSet SET SIZE (1..MAX) OF Certificate,
certURL IA5String,
... -- For future extensions
}
RandomNumber ::= OCTET STRING (SIZE(8..MAX))
RandomNumber ::= OCTET STRING (SIZE(8..MAX))
SIGNATURE { ToBeSigned } ::= SEQUENCE {
algorithm AlgorithmIdentifier,
signature BIT STRING
}(CONSTRAINED BY {-- Must be the result of applying the signing
-- operation indicated in "algorithm" to the DER-encoded octets of
-- a value of type -- ToBeSigned })
SIGNATURE { ToBeSigned } ::= SEQUENCE {
algorithm AlgorithmIdentifier,
signature BIT STRING
}(CONSTRAINED BY {-- Must be the result of applying the signing
-- operation indicated in "algorithm" to the DER-encoded octets of
-- a value of type -- ToBeSigned })
END
终止
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。