[要約] 要約： RFC 3163は、ISO/IEC 9798-3認証SASLメカニズムに関する仕様であり、セキュアな認証プロトコルを提供するための標準化を目指しています。目的： 1. セキュアな認証プロトコルの標準化 2. ISO/IEC 9798-3に基づく認証メカニズムの提供 3. ネットワーク上の通信のセキュリティを向上させる
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）。全著作権所有。
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の利点を備えた同じ効果は、既存の既に標準トラックプロトコルである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 Entity Authenticationに基づいた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].
この文書のキーワード "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を生成し、トークントケナブを作成します。トークンには、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を生成し、トークントケナブを作成します。トークンには、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) サーバーはトークントークンバを作成します。トークンには、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が、トークン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 -Encoded [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証明書からの身元が使用されます。
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証明書の件名が含まれています。名前のハッシュによって識別される場合、IssuernameHashフィールドには、CA証明書からの件名のderエンコードのSHA-1ハッシュが含まれます。公開鍵のハッシュによって識別された場合、発行者KeyHashフィールドには当局の公開鍵のSHA-1ハッシュが含まれています。ハッシュは、発行者の証明書の主題公開キーフィールドの値（タグと長さを除く）で計算するものとします。証明書で識別された場合、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]で定義された「署名済み」パラメーター化されたタイプに似ています。違いは、「署名」タイプに署名されるデータが含まれていないことです。
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]で定義されています。
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を与えます。すべてのアルゴリズム名は13文字に制約され、20文字の総SASL制限内に保持されます。
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を参照してください。意図された使用法：Common Auther/Change Controller：このメモのセクション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_Bは、R_Bが知られているため、サーバーに同じ保護を提供しない場合があります。R_Aの前のクライアントが選択されます。このため、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
始める
-- 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)}
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
始める
-- 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)}
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
終わり
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。