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
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
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.
同じ効果は、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.
この文書はSASL（簡易認証とセキュリティレイヤ）ISO / IEC 9798から3とFIPS PUB 196エンティティ認証に基づく認証メカニズムを定義します。
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パブ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つの異なるモードに対応する二つの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]),
- （[RFC2459]に記載されているように、これは完全な証明書パス処理を含む）TokenABにおけるクライアントの署名を検証し、
- 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]),
- （[RFC2459]に記載されているように、これは完全な証明書パス処理を含む）TokenABにおけるクライアントの署名を検証し、
- 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を作成します。トークンは、第三のランダムな値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]),
- （[RFC2459]に記載されているように、これは完全な証明書パス処理を含む）TokenBAにおけるサーバの署名を検証し、
- 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.
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の名前（任意選択で）、エンティティの認証情報、（オプション）承認のアイデンティティ、タイプ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 }
}(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.--})
}（{によって制約 - entityBとAUTHIDのフィールドが含まれなければならない - TokenABにし、それらはまたTBSDataABに含まれている場合だけ - 。クライアントそれはアイデンティティを知っていると信じている - いつでもentityBフィールドがTokenAB中に存在すべきですサーバの.--}）
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ハッシュが含まれています。それは、その公開鍵のハッシュで識別された場合、issuerKeyHashフィールドには、権限の公開鍵のSHA-1ハッシュが含まれています。ハッシュは、発行者の証明書のサブジェクトの公開鍵フィールドの値（除くタグと長さ）の上に計算しなければなりません。それは、その証明書によって識別された場合、その後authorityCertificateフィールドには、そのCA証明書が含まれています。それはのPKCS＃15キーハッシュによって識別された場合のPKCS＃15 [PKCS15]セクション6.1.4で定義され、その後pkcs15KeyHashフィールドには、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].
「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
キーオブジェクト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].
次の例では、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
S：* OK IMAP4サーバ準備C：A001のAUTHENTICATE 9798-U-RSA-SHA1 S：+ MAoECBI4l1h5h0eY C：MIIBAgQIIxh5I0h5RYegD4INc2FzbC1yLXVzLmNvbaFPFk1odHRwOi8vY2VydHMt ci11cy5jb20vY2VydD9paD1odmNOQVFFRkJRQURnWUVBZ2hBR2hZVFJna0ZqJnNu PUVQOXVFbFkzS0RlZ2pscjCBkzANBgkqhkiG9w0BAQUFAAOBgQCkuC2GgtYcxGG1 NEzLA4bh5lqJGOZySACMmc + mDrV7A7KAgbpO2OuZpMCl7zvNt / L3OjQZatiX8d1X buQ40l + g2TJzJt06o7ogomxdDwqlA / 3zp2WMohlI0MotHmfDSWEDZmEYDEA3 /卵kWyi1v1lEVdFuYmrTr8E4wE9hxdQrA == S：A001ようこそOK、9798-マグナス：U-RSA-SHA1は、ユーザーを認証し
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>登録して - 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.
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.
セキュリティに関する注意事項：詳細のために連絡するためにこのメモの人とEメールアドレス：このメモ公開された仕様のセクション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.
このメモで説明したメカニズムは、受動的な盗聴攻撃に対する保護を提供します。彼らは、能動的な攻撃からのセッションのプライバシーや保護を提供していません。具体的には、セッション "ハイジャック" を目指しman-in-the-middle攻撃が可能です。
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の包含は、認証メカニズムの開始前に、サーバによって選択されたデータにクライアントの署名を取得するからサーバーを防止します。同じキーがエンティティ認証以外の目的のためにクライアントによって使用されている場合、この尺度は、例えば、必要になることがあります。しかし、クライアントは、それが最初のメッセージで送信された値と同じであることを確認する必要がありR_Bがに知られているので、サーバに同じ保護を提供しないことを指示するセキュリティ上の理由のために必要な一方でTokenBA2でR_Bを含めること、 R_A前にクライアントが選択されています。この理由のために第三の乱数、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]は、196をFIPS「公開鍵暗号方式を使用してエンティティ認証、」連邦情報処理規格出版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 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]バーナーズ=リー、T.、Masinter L.およびM. McCahill "ユニフォームリソースロケータ（URL）"、RFC 1738、1994年12月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.
"単純なチャレンジ/レスポンスのためのIMAP / POP許可拡張子" [RFC2195] Klensin、J.、Catoe、R.及びP. Krumviede、RFC 2195、1997年9月。
[RFC2222] J. Meyers, "Simple Authentication and Security Layer", RFC 2222, October 1997.
[RFC2222] J.マイヤーズ、 "簡易認証セキュリティー層"、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.、フォード、W.、ポーク、W.およびD.ソロ "インターネット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）の仕様、Canonicalの符号化規則（CER）、および顕著な符号化規則（DER）。
Robert Zuccherato Entrust Technologies 1000 Innovation Drive Ottawa, Ontario Canada K2K 3E7
ロバートZuccheratoエントラストテクノロジーズ1000年イノベーションドライブオタワ、オンタリオカナダK2K 3E7
Phone: +1 613 247 2598 EMail: robert.zuccherato@entrust.com
電話：+1 613 247 2598 Eメール：robert.zuccherato@entrust.com
Magnus Nystrom RSA Security Box 10704 121 29 Stockholm Sweden
マグナスNystrom RSAセキュリティボックス10704 121 29ストックホルムスウェーデン
Phone: +46 8 725 0900 EMail: magnus@rsasecurity.com
電話：+46 8 725 0900 Eメール：magnus@rsasecurity.com
APPENDICES
付録
A. ASN.1 modules
A.のASN.1モジュール
A.1. 1988 ASN.1 module
A.1。 1988 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)}
名前、のAlgorithmIdentifier、PKIX1Explicit88から証明書{ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1、明示的に指定し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)};
PKIX1Implicit88 FROM GeneralNames {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-暗黙-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
終わり
A.2. 1997 ASN.1 module
A.2。 1997 ASN.1モジュール
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)}
AlgorithmIdentifier、名前、証明書PKIX1Explicit93 FROM {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1、明示的に指定し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)};
PKIX1Implicit93 FROM GeneralNames {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-pkix1-暗黙-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.
著作権（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 Editor機能のための基金は現在、インターネット協会によって提供されます。