[要約] RFC 3163は、ISO/IEC 9798-3認証SASLメカニズムに関する仕様であり、セキュアな認証プロトコルを提供するための標準化を目指しています。
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.
Copyright (C) The Internet Society (2001). All Rights Reserved.
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.
PKIの利点を備えた同様の効果は、既存の標準化過程（Standards Track）プロトコルであるTLS/SSLを使用することで得ることができます。
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（Simple Authentication and Security Layer）認証メカニズムを定義します。
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].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" は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よりも単純です。（TLSの全機能ではなく）この機能のみが要件である場合、この単純さは展開を容易にします。
- 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メカニズムには、2つの認証モードが含まれています。
- 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:
このメカニズムには、2つの異なるモードに対応する2つのSASLキーがあります。
- "9798-U-<algorithm>" for unilateral client authentication.
- 片方向クライアント認証用の「9798-U-<algorithm>」。
- "9798-M-<algorithm>" for mutual authentication.
- 相互認証用の「9798-M-<algorithm>」。
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が、TokenABの署名データに含まれる乱数と一致することを確認し、
- 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が、TokenABの署名データに含まれる乱数と一致することを確認し、
- 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を作成します。トークンには、3番目のランダム値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が、TokenBAの署名データに含まれる乱数と一致することを確認し、
- 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.
TokenBA1は、片方向クライアント認証と相互認証モードの両方で使用され、サーバーからクライアントに送信されます。
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
}
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の名前（オプション）、エンティティ認証情報、（オプションの）認可ID、およびタイプ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フィールドは、アクセス制御に使用されるIDが署名者の証明書に含まれるIDとは異なる場合に使用されます。このフィールドが存在しない場合、クライアントのX.509証明書のIDが使用されます。
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
}
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.--})
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
}
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 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キーハッシュによって識別されます。名前で識別される場合、TrustedAuthのauthorityNameフィールドには、CA証明書のSubjectNameが含まれます。名前のハッシュによって識別される場合、issuerNameHashフィールドには、CA証明書のSubjectNameのDERエンコードのSHA-1ハッシュが含まれます。公開鍵のハッシュによって識別される場合、issuerKeyHashフィールドには、認証局の公開鍵のSHA-1ハッシュが含まれます。ハッシュは、発行者の証明書のsubject public keyフィールドの値（タグと長さを除く）に対して計算されるものとします。証明書で識別される場合、authorityCertificateフィールドにはCA証明書が含まれます。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
}
A random number is simply defined as an octet string, at least 8 bytes long.
乱数は、少なくとも8バイトの長さのオクテット文字列として単に定義されます。
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]で定義された「SIGNED」パラメータ化タイプに似ていますが、違いは「SIGNATURE」タイプには署名対象のデータが含まれていないことです。
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].
「GeneralNames」タイプは[RFC2459]で定義されています。
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.
次の署名アルゴリズムは、このメカニズムでの使用が認められており、キーによって識別されます。各キーは組み合わされて、2つの可能なSASLメカニズムを作成します。たとえば、DSA-SHA1アルゴリズムは9798-U-DSA-SHA1および9798-M-DSA-SHA1となります。すべてのアルゴリズム名は、合計20文字のSASL制限内に収めるために、13文字に制限されています。
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
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].
次の例は、IMAP4 [RFC2060]を使用したISO/IEC 9798-3認証SASLメカニズムの使用を示しています。
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
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を参照。意図された使用法：COMMON。著者/変更管理者：このメモのセクション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.
このメモで説明されているメカニズムは、受動的な盗聴攻撃に対する保護のみを提供します。セッションのプライバシーやアクティブな攻撃からの保護は提供しません。特に、セッション「ハイジャック」を対象とした中間者攻撃が可能です。
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がクライアントに知られているため、サーバーに同じ保護を提供しない場合があります。このため、3番目の乱数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。、National Technical Information Service、Springfield、Virginia、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 Laboratories、「パブリックキー暗号化基準-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「Uniform Resource Locators（URL）」、RFC 1738、1994年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」、RFC 2060、1996年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 2195、1997年9月。
[RFC2222] J. Meyers, "Simple Authentication and Security Layer", RFC 2222, October 1997.
[RFC2222] J. Meyers、「Simple認証とセキュリティレイヤー」、RFC 2222、1997年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。and D. Solo "Internet 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 Entrust Technologies 1000 Innovation Drive Ottawa、Ontario Canada K2K 3E7
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
APPENDICES
付録
A. ASN.1 modules
A. ASN.1モジュール
SASL-9798-3-1988
SASL-9798-3-1988
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
BEGIN
-- EXPORTS ALL --
-- EXPORTS ALL --
IMPORTS
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)}
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
}
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
}
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
}
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
}
RandomNumber ::= OCTET STRING (SIZE(8..MAX))
END
SASL-9798-3-1997
SASL-9798-3-1997
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
BEGIN
-- EXPORTS ALL --
-- EXPORTS ALL --
IMPORTS
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)}
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
}
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
}
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
}
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
}
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 })
END
END
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright (C) The Internet Society (2001). All Rights Reserved.
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エディター機能への資金提供は、現在インターネットソサエティによって行われています。